dsPIC30F3013: PCWHD v 4.101 printf on float

[WK]

I am having a problem with PCWHD in compiling a pgm for the 30F3013.
I am using the same format that worked fine long ago with PCM for the
pic 16C66 and in 2004 it worked fine with PCH for the pic 18F2620.
x is a float (which defaults to float 32) and x looks fine in memory
(x is sin of 0.5 rad). The line that sends x out is:

[starfire151]

I have the CCS dsPIC Analog Development Board and tried to get a serial output as you've stated. Here are my results:

float x;
x = sin(0.5);
printf("%1.7e", x);
4.7942551970481872558593750000000000000000000000E-01

double x;
x = sin(0.5);
printf("%1.7e", x);
4.7942553841493973365572855982463806867599487304E-01

float x;
x = sin(0.5);
printf("%1.7f", x);
0.4794255

float x;
x = sin(0.5);
printf("%1.7g", x);
0.4794255

float x;
x = (float) sin(0.5);
printf("%1.7e", x);
4.7942551970481872558593750000000000000000000000E-01

I'm using PCWHD version 4.104 (latest release as of yesterday). It appears this problem may be in the math.h library for 16-bit processors?

There doesn't seem to be much support (on either this forum or the CCS Tech Support) for issues related to the dsPIC family. CCS Tech Support just assigns you an ID number and sometimes someone to work the issue. If you can manage to get someone to actually respond and are unfortunate enough to have to reply with additional information, you are just assigned another ID number and put into the queue again! The CCS Tech Support system seems to be broken... at least with issues related to the dsPIC family...

Dave

[WK]

Dave, thanks for the feedback. I tested printf "e" format on
4.104 (30f3013) and got the same result as you but I am
running sim in MPLAB (w uart option turned on). ie w float x;
x=sin(0.5); was sent with << printf("%1.7e",x); >> (note that
I am not using the CCS sin routine but rather my own and
note that nothing changes if you use 9.7e or 5.5e etc) and
is output thus :

4.7942554950714111328125000000000000000000000000E-01

seems that there are 16*3=48 characters before the exponent.
4.104 is better than 4.101 in that it is consistent and tacks
the exponent on the end of the over-long string of characters.
I find that if you take the first 8 or 9 characters, ignore
the next thirty some-odd and then grab the last three you have
the right number. Tried to do that inside the PIC code via a
function call inside the printf (this normally works well PCM
and PCH) but no such luck PCD 4.104). So for now I am doing
that elsewhere.

Re PCD bug support: I turned in a PCD subtract float bug
recently and got excellent feedback from CCS the next day.
Turns out a bug in MPLAB is the problem (they ran my code
both MPLAB and the CCS dsp starter and bug was in MPLAB
handling of one of the status bits). I found a work-around
for now.