topic Re: Replacing Printf() & sprintf() Functions in Classic/Legacy CodeWarrior

Replacing Printf() & sprintf() Functions

v_dave — Tue, 14 Jul 2009 23:21:59 GMT

Hello All,

OK interesting issue that I have been told has happened before and has been solved by developers writing their own versions of printf().

I am using Codewarrior for DSC56800/E 8.1.1a and my target is the 56F8323 which has 32K of program space.

My issue is I am running out of codespace. I have turned on Optimizations to level 3 and it is set for smaller code over speed. I am still bumping into the code size limit and I have been going back through my code and optimizing where I can manually (which is a good thing). I have also used Processor Expert to generate a lot of my code.

In analyzing code usage I find that the excess bloat is not necessarily from PE but from some of the libs themselves. I use sprintf a lot to format my strings before I then transmit them to the outside world. Now I know I can modify putchr() to talk directly with a Serial port but I am actually using both ports and some parallel bits to get my data to the outside world so that is not really the best option.

In looking at the map file it appears that the printf.o is a huge codespace hog:

address size

000026AA 000002C9 .text   Fparse_format (MSL C 56800E.lib printf.o       )
00002973 00000172 .text   Flong2str (MSL C 56800E.lib printf.o       )
00002AE5 000000BA .text   Fround_decimal (MSL C 56800E.lib printf.o       )
00002B9F 000003D3 .text   Ffloat2str (MSL C 56800E.lib printf.o       )
00002F72 0000036C .text   F__pformatter (MSL C 56800E.lib printf.o       )
000032DE 0000002B .text   F__StringWrite (MSL C 56800E.lib printf.o       )
00003309 00000039 .text   Fvsnprintf (MSL C 56800E.lib printf.o       )
00003342 0000000D .text   Fsprintf (MSL C 56800E.lib printf.o       )

I have had another developer tell me they have handled this issue by writing their own printf() function. So my questions to the community:

1) Can writing your own printf() funtion really save you a lot of code space?

2) If you write your own printf() funtion how do you call it? Do you need to rename the function to something like myprintf()? How does that keep other lib functions (such as string handlers) from calling the original printf() and therefore still adding the bloat?

So if anyone who can point me to a good book or internet link on this subject I would be most appreciative.

Re: Replacing Printf() & sprintf() Functions

t_wahl — Fri, 11 Sep 2009 18:24:27 GMT

if your question is still urgend, then I have a small version (not all options are included, but can be adapted):

sprintf.c

Message Edited by t.dowe on 2009-09-11 11:30 AM

Re: Replacing Printf() & sprintf() Functions

Lundin — Fri, 11 Sep 2009 19:45:46 GMT

There is never a reason to use those functions in embedded systems, only PC programmers who don't know embedded programming use them. This opinion is shared by the widely recognized coding standard MISRA-C, rules 16.1 and 20.9.

Replace printf() with a slim function for serial I/O or LCD print out. Roughly 100 - 200 bytes of code.
Replace sprintf() with a slim int to ASCII function. Roughly 100 bytes of code.

Re: Replacing Printf() & sprintf() Functions

J2MEJediMaster — Tue, 15 Sep 2009 01:02:59 GMT

Check out FAQ-27705, which has a code example of a function that converts an integer to a string.

---Tom

Message Edited by J2MEJediMaster on 2009-09-14 03:18 PM

Re: Replacing Printf() & sprintf() Functions

v_dave — Tue, 15 Sep 2009 05:06:28 GMT

Hello All,

Thanks for the info. I am definetely still in need of the info.

I have never really had an issue with sprintf() in the past since most of my embedded applications have not been as large as my current one. All I am doing is combing some ASCII data with some numbers in a formatted string that will be sent out the serial port. I was thinking that using one function rather than a couple of functions (Integer->string followed by a strcpy() function) would have been cleaner and less overhead. I knew sprintf() was a resource hog but did not know it was that significant.

All this info has really helped and thanks again for your insights.