| View previous topic :: View next topic |
| Author |
Message |
SamMeredith
Joined: 13 Jul 2018
Posts: 23
|
| Printf() with %w format and leading zeros |
 Posted: Wed Feb 19, 2020 6:14 am |
 |
|
I am getting unexpected output from the printf() family when using the %w format code with leading zeros (e.g "%05.2w").
I am using compiler version 5.078
| Code: |
#include <33EP512MC806.h>
#include <stdint.h>
#use delay(crystal = 12Mhz, clock = 120Mhz, AUX:clock = 48Mhz)
#pin_select U3RX = PIN_F1
#pin_select U3TX = PIN_F2
#use rs232(UART3, baud = 115200, parity = N, bits = 8, errors, TIMEOUT = 1, stream = DEBUG)
/*
*
*/
void main() {
int32_t value = 0x00000039;
fprintf(DEBUG, "\r\n%4d", value); // Outputs " 57" as expected
fprintf(DEBUG, "\r\n%5.2w", value); // Outputs " 0.57" as expected
fprintf(DEBUG, "\r\n%05.2w", value); // Outputs "00000000.57" I expcted "00.57"
}
|
Any idea what is going on here? |
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19451
|
|
| Posted: Wed Feb 19, 2020 7:37 am |
|
|
I'd talk to CCS.
It definitely looks wrong. In multiple ways!...
It actually looks as if with the leading 0 selected, it is outputting zeros
for the entire 32bit value, and ignoring the digit number it is being given!...
Ugh!...
There is another fault here I found while testing this. Change the number to
0x139, and it prints:
313
3.10
00000003.10
It is losing the last digit of the number!...
You really should be using %lw. int32, is a 'long', and without this it'll
lose data when the number goes over 65535. However it does exactly the
same with an int16, or with the 'L' there!... |
|
|
SamMeredith
Joined: 13 Jul 2018
Posts: 23
|
|
| Posted: Wed Feb 19, 2020 7:55 am |
|
|
Thanks Ttelmah.
I hadn't realised lw was needed, I'll be sure to use that.
I actually did spot the fault you mention when I went to build the posted MWE. Did you test my example code under MPLAB's simulator by any chance?
When I run my example on the real hardware I get the outputs above but when I run it on the MPLAB simulator I get:
57
0.51
00000000.51
I've worked around the issue for now by manually adding the leading zeros. I will contact CCS about a real fix.
Last edited by SamMeredith on Wed Feb 19, 2020 8:34 am; edited 1 time in total |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19451
|
|
| Posted: Wed Feb 19, 2020 8:16 am |
|
|
Yes I did use the simulator. Quick way to test.
That's good if it is only a simulator fault. Thought I would have seen
it if it was doing it for 'real', since I do use %lw in quite a few places.
However I don't use leading zeros, so hadn't spotted your main one!...
Actually, update on this. MPLAB-X simulates it OK. The fault is only
with the old MPLAB 8.92 simulator. |
|
|
dluu13
Joined: 28 Sep 2018
Posts: 395
Location: Toronto, ON
|
|
| Posted: Thu Feb 20, 2020 4:39 pm |
|
|
| I had this same bug a while ago on PCD but I was on 5.082. CCS sent me updated compiler v5.085 to fix this. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19451
|
|
| Posted: Fri Feb 21, 2020 1:42 am |
|
|
Just tested with 5.085, and it does the same.
Looks as if the fix got 'forgotten', and has not been included in the release
compiler...  |
|
|
dluu13
Joined: 28 Sep 2018
Posts: 395
Location: Toronto, ON
|
|
| Posted: Fri Feb 21, 2020 6:21 am |
|
|
Oh, I wasn't clear.
I had other problems with %w and lw format specifiers where I would just get totally unrelated numbers.
Even now, after the fix, there are some output glitches occasionally so I totally gave up on using lw and w... I wrote a function that converts a number to BCD and prints it out with a string and places a decimal point where I want:
http://www.ccsinfo.com/forum/viewtopic.php?t=58018 |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
