CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

How does %w work?

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
dluu13



Joined: 28 Sep 2018
Posts: 395
Location: Toronto, ON

View user's profile Send private message Visit poster's website

How does %w work?
PostPosted: Fri Apr 05, 2019 12:22 pm     Reply with quote

I'm using the PIC24FJ128GA204 on Microchip's PIC24 Curiosity dev kit along with CCS PCD 5.082.

I saw a post by Ttelmah a while ago suggesting somebody use the %w format specifier with int32's to avoid using floats.

However, when I try to use it, I get seemingly nonsensical output, with numbers that don't match up.

For example, here is my main function:
Code:
int main(void)
{
    uint32_t test1 = 18;
    uint32_t test2 = 123;
    uint32_t test3 = 554;
   
    delay_ms(100);
   
    fprintf(PC, "\r\n\r\n");
    fprintf(PC, "test1: %1.3w\r\n", test1);
    fprintf(PC, "test2: %1.3w\r\n", test2);
    fprintf(PC, "test3: %1.3w\r\n", test3);
   
    while(1){}

    return 0;
}


The code gives this output on my serial port:
Code:
test1: 0.040                                                     
test2: 0.150
test3: 0.5=0


I have tried plain int32 instead of uint32_t, int16, and different numbers, but I can't notice any pattern at all.
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Fri Apr 05, 2019 1:14 pm     Reply with quote

I compiled the program below with CCS vs. 5.082, and ran it in the
MPLAB vs. 8.92 simulator. I got this in the output window:
Quote:

test1: 0.018
test2: 0.123
test3: 0.554

Test program:
Code:
#include <18F46K22.h>
#fuses INTRC_IO, NOWDT, BROWNOUT, PUT, NOPBADEN
#use delay(clock=4M)
#use rs232(baud=9600, UART1, ERRORS, stream=PC)

#include <stdint.h>

//==========================
void main()
{
uint32_t test1 = 18;
uint32_t test2 = 123;
uint32_t test3 = 554;
   
delay_ms(100);
   
fprintf(PC, "\r\n\r\n");
fprintf(PC, "test1: %1.3w\r\n", test1);
fprintf(PC, "test2: %1.3w\r\n", test2);
fprintf(PC, "test3: %1.3w\r\n", test3);
   
while(TRUE);
}   
dluu13



Joined: 28 Sep 2018
Posts: 395
Location: Toronto, ON

View user's profile Send private message Visit poster's website

PostPosted: Fri Apr 05, 2019 1:18 pm     Reply with quote

Yeah that's what I expected to see.

I just found this super old thread talking about %w giving garbage when using PCD.
https://www.ccsinfo.com/forum/viewtopic.php?p=128178

That's a 9-year old thread though. I wonder if it's still messed up maybe :/

Perhaps it is ok when you are using PCH. However, I don't have any other PICs to test it out with at the moment.

Also, I am 99.99999% sure that my UART is set up properly. I have been using this similar setup for a long time now, and anything other than %w works.


Last edited by dluu13 on Fri Apr 05, 2019 1:25 pm; edited 1 time in total
gaugeguy



Joined: 05 Apr 2011
Posts: 296

View user's profile Send private message

PostPosted: Fri Apr 05, 2019 1:25 pm     Reply with quote

Try using %4.3w
The first number should be the total number of digits.
dluu13



Joined: 28 Sep 2018
Posts: 395
Location: Toronto, ON

View user's profile Send private message Visit poster's website

PostPosted: Fri Apr 05, 2019 1:30 pm     Reply with quote

I have tried various numbers for the first digit. I actually started with %5.2w.

%lw and %w both give the same results.

In this case, %4.3w gives exactly the same result as %1.3w. There must be a pattern, since I get the same result every single time.

Also, as I understand, the first number is the minimum width of the field, and if the number is larger, then the field will grow to fit it.

I'm wondering if it is a compiler bug, since an older user using PCD also had the same issue. I will email CCS and mention here if I get any results.
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Fri Apr 05, 2019 1:50 pm     Reply with quote

Here are the relevant compiler updates by date and compiler version:

Oct. 2015 -- 5.050 Fixed a bug when negative number were used with %W on 24 bit parts
Mar. 2015 -- 5.044 Corrected a formatting issue in %W (%LU, %LD should not have been affected)
Feb. 2015 -- 5.041 A problem with %w where if the digit after the . was 0 it did not output on the PIC24 is fixed
Jan. 2015 -- 5.037 The PIC24 printf() %w no longer forces the leading zeros
Nov. 2014 -- 5.031 Fixed a PIC24 bug in %w when used with signed numbers
dluu13



Joined: 28 Sep 2018
Posts: 395
Location: Toronto, ON

View user's profile Send private message Visit poster's website

PostPosted: Fri Apr 05, 2019 2:16 pm     Reply with quote

Unfortunately it looks like I am still having problems haha

I just tested on a PIC24FJ128GA308 and I am having the exact same output as the PIC24FJ128GA204.

Anyway, I am talking with CCS support now, and I have just sent over an LST file so hopefully we get to the bottom of this.
dluu13



Joined: 28 Sep 2018
Posts: 395
Location: Toronto, ON

View user's profile Send private message Visit poster's website

PostPosted: Mon Apr 08, 2019 1:44 pm     Reply with quote

Update:

I guess it was something with a compiler bug on PCD v5.082, seeing as how PCMP got it to work with PCH.

CCS support emailed me a couple of files to patch things up and it seems to work as expected now.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group