I've noticed that sprintf seems to round the whole number part of doubles incorrectly. The below code loads string 's' with a value that seems to be rounded down to the closest 100 Hz. This causes my app grief, and I sure wish I could figure out how to use sprintf to print all the digits to the left of the decimal point correctly. Anyone have any advice on this question...? #define CRYSTAL (20000000.0) #define MUL (1401.0) #define DIV (255.0) #define MCK (CRYSTAL*(MUL+1.0)/(DIV*2.0)) double fClock = MCK; // debugger shows fClock as 54980392 sprintf(s,"%1.0f",fClock); // incorrectly loads s with "54980400" The funny thing is that I can use sprintf to load strings with "%11.09f" as the format string, and it's right 9 places to the right of the decimal point. I just can't figure out why it can't handle the integer part of double precision floating point numbers as well. Thanks, Seadog.
OUCH!! Sorry for not doing the investigation you asked for right away. I did do it after the fact, and I'm further puzzled by what I found. According to the CARM compiler reference, the double data type does use 64-bits to store the values of variables. But, if you also search for 'precision' in the CARM reference, you'll find a reference somewhere else to the FLOAT64 compiler directive that must be used to enable double precision floating point math. Unfortunately, there's no mention of the need for the FLOAT64 compiler directive in the text for the double data type. A seeming contradiction is that KEIL's tech support response also included "The Keil CARM compiler currently does not support Double Precision Floationg Point (DPFP) numbers, and that support will not get added soon." So, in hindsight, it doesn't look a timely answer to your question would've helped solve the problem anyway, even if I would've found out about and used the FLOAT64 compiler directive. I did (and still do) appreciate your willingness to help resolve this issue. Pardon my ignorance, but I had assumed that a double was a double, and math using doubles would work as expected unless otherwise plainly indicated. If I ever have a reason to go back to the prior CARM compiler I'll try to remember to test the FLOAT64 directive just to see what happens. Currently, it looks to me like there's still a contradiction relative to what you can do with doubles and the CARM compiler. The bottom line... Per KEIL's suggestion I have upgraded to the RealView compiler, and the problem I was having with sprintf and math using doubles went away when I did that.
"OUCH!!" Er, yes, sorry, I hadn't had enough coffee this morning. I would guess that tech support are more likely to be correct than the manual and 64 bit doubles are not supported, but I'd be most interested to hear the result of your test.