This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Using fprintf to develop with DSP

Other Parts Discussed in Thread: TMS320F28335

Hello,

I am developping on TMS320F28335 with the XDS100v1 and I want to analyse some value at the end of a run (not in the variables table) and I have 2 issues.

1 - I have a problem with the fprintf function. I use it because I don't have the usb communication ready yet...

And my problem is that fprintf(fic, "%d.0%d\t, a, b) works but fprintf(fic, "%lf\t", c) doesn't work...nothing happen and the running seems to be busy. Why does it happen? Is it linked to the heap size of my program (0x400) ? What can I do ?

2 - The accuracy of calculation is not the best : when I have 129000 + 2e-7 -129000 = 0 but when I have 129000-129000+2e-7 = 2e-7. I know it is because of 16/32 bit calculation but is there any traditional way to avoid lost of accuracy of calculation ? Because 129000.0000007 = 129000  I am agree but at the end 129000+2e-7-129000 = 0 and it is aan issue for me...

Thank you.

  • Regarding the fprintf problem, please see if one of the tips on this page is helpful.

    Regarding the floating point calculation ... Have you tried using the 64-bit long double type?  

    Thanks and regards,

    -George

  • You need to use capital L to print long double float values:

    fprintf(fic, "%Lf\t", c);
  • But the issue is that c is not a long double but just a double so I thought

    %f float,

    %lf double and

    %Lf long double.

    Usually it works like it on computer why is it different on a DSP or on micro controller? I have a solution by dividing a number (unit and decimals) but this is the second time it happens to me (on microcontroller 16 bit and now on a DSP) so is it my falt (rules I know are not good) or is there a reason like different rules on embedded systems ?

  • Actually, %f is for double, and float arguments get promoted to double when you make a call to printf.  You may use %lf to print double arguments, but the 'l' is ignored.  This rule is part of the C standard, and it's the same on TI compilers as on the host compiler.

    Did you see the wiki page George referred to?   It discusses the fact that you may need a larger heap.

  • Thank you for your answers. I will read it more precisely but if the solution is to make the heap size bigger  (I don't have tested yet), I don't know the limit I can take and moreover I wouldn't understand why fprintf of 2 int concatenated works whereas fprintf of one double doesn't? It needs less heap size ? I am not a specialist, I am a newbie so it may  be a stupid  logic, but I believed that heap size was linked whith the quantity of use of fprintf and co and not linked whith the typedef of arguments of what I wanted to fprintf, is it false ?

  • And my problem is that fprintf(fic, "%d.0%d\t, a, b) works but fprintf(fic, "%lf\t", c) doesn't work...nothing happen and the running seems to be busy. Why does it happen? Is it linked to the heap size of my program (0x400) ? What can I do ?

    It seem to me that the TI printf implementation use buffers allocated on the stack so try to increase the stack size instead of the heap size.

    The basic printf uses  a basic buffer of  510 chars. To conver float it is used another function that add another  buffer of 510 (for the %f format ,100 for %e), so printing integer need less stack then printing float.

  • Hi Alberto,

    Thank you for your explanation, now it is clear for me. Thank your very much it is really useful. Have a good day.

    Regards,

    Cédric