sprintf for float

[kris]

Hi there,
I am using PCWHD ver4.093 (latest) but each time when I call:

[PCM programmer]

Always post your PIC.

[kris]

I am using diPic33FJ256GP506. We have no problem with PCWH Ver3.236 with PIC18FXXX.
Since diPic33FJ256GP506 required the upgraded compiler we just bought it found sprintf failed.
Thanks!

[kris]

Here is the headers I include. Any header files missing to call sprintf ?

[PCM programmer]

I don't have the PCD compiler, so I can't test it.

[mkuang]

This may sound stupid but did you include diPic33FJ256GP506.h ? I didn't see that header file in your list.

[Guest]

Yes I did:
#include <33FJ256GP506.h>
#DEVICE ADC=12
.....

For now I have to make my own function to convert a float value to a string.
I believe it's a bug of PCWHD ver4.093.

[mkuang]

Sounds like you ought to contact CCS. They aren't the fastest to respond but generally they are very helpful.

[Sean631]

I have the same problem with 4.085. I am compiling code for the 30F3014 My update subscription ran out, so i guess I am stuck with this problem for now. Printing floats seems like pretty basic functionality, but it appears to be broken. I've tried doing it every which way with different size floats, using sprintf to a string, etc. Its broken.

[Ttelmah]

Contact CCS anyway. For 'major' demonstrable faults like this, they will often offer some degree of 'grace' (usually one version with the specific problem fixed). This is so fundamental, that you need to pursue it....

As one 'totally silly' suggestion, have you tried explicitly declaring the variable as float32, float48, and float64, rather than relying on the default 'float' declaration?. I'd not put it past the compiler to accidentally be missing the overload for a default 'float', and trying to print it as the wrong type.

Have you tried without a size at all?. In the past there was a problem with the float on older compilers, that was fixable by explicitly declaring a size. I'd again consider the possibility of this being the 'reverse' fault....

Does it do the same with 'printf', rather than sprintf?. It may be that they have fixed the problem with the former. If so, you can simulate sprintf, by writing your own function to put characters into a string, and calling this with printf.

Best Wishes

[FvM]

I didn't yet see the said code failing with PCD (up from V4.084). It possibly happens under specific conditions.
Can you show an example that fails reproducible?

[sean631]

Found the problem.

I had this in my .h file:

#device ADC=12

I don't know why this would effect fprintf or sprintf, but when I commented the line out, I was able to print floats normally.

[jmd02]

Hi there,
I'm having the same problem with the version 4.099 of PCWHD.
When using the printf function trying to show a float on the LCD, the program resets.
I tried to trap the possible errors (address, stack, math, osc., dma, and so on) but no trap is executing.
I have a counter interrupt executing at 500Hz. When the timer/interrupt is disabled the printf executes ok.
I'm using a 24FJ128GB106, and already tried removing the #device... statement with no results.
Any suggestion?

thanks
Juan

[sean631]

I never really figured the problem out. I realized that I had another program (header file and skeleton code generated from the ccs wizard), where floats printed normally. I looked for differences between the two projects (i'm using MPLAB IDE with CCS compiler) and realized that the only difference was that I had added the #device ADC=12 line to the malfuctioning project's .h. I commented the line out and that fixed it.
My program crashed when fprintf was run with a float as an argument (%f or %g in format string).
I assume that for whatever reason, the fprintf function thought the float was a different size or format that what it actually was, causing the processor to run amok trying to print it.

[sean631]

I should mention that I tried IEEE formated 32-bit floats, as well as 64 bit floats - neither had any effect, program still crashed.