printf() with MC9S08JM60

[moparnick]

Hello All,

I have been trying to get the printf() function to work using the MC9S08JM60.  I am using the DEMOJM board and modifying the 'getting started'  terminal program.  I have tried to include different libraries out of the freescale folder on my c:\ drive but I either get errors or when I send a command through hyperterminal to print nothing happens (program seems to crash).  I saw another thread where termio.c was included into the project, however this has not worked for me.  Is there something/librarie I need to utilize? thanks 

[Lundin]

I suspect you might have to create a float number project to get printf to work. Pick float numbers in the new project wizard and see if that solves anything.

Anyway... why can't you just light some LEDs or whatever instead? Getting printf to work is a waste of time, as you can't use it in production code anyhow.

[AndersJ]

I agree with Lundin about Printf being useless, at least in some respects,

such as being resource hungry and slow.

I am curious about why you (Lundin) don't like it?

Comments appreciated,

Anders J

[Lundin]

Main reason to avoid it: printf() is using variable argument lists (va_list). This is perhaps one of the dumbest, most superfluous things in the C language. They are incredibly bug prone: you can pass any number of parameters to the function and it will go haywire. There is no type checking of the parameters either, so you can pass anything to it and it won't detect it.

printf() is indeed extremely resource-heavy and slow. If you only wish to print out an integer value, you will still have to link all bulky float handling code, all formatting code etc etc. Because the compiler can't tell at compile time what you are passing to printf(), it cannot evaluate the format string. No matter what you pass to printf(), chances are you will only be using < 5% of the code linked.

sprintf() etc are also superfluous, as even a beginner programmer should be able to write their own type- and number base

conversion routines.

scanf() etc functions shouldn't be used either, because they have buffer overflow issues.

So in other words, the whole stdio.h library shouldn't be used for anything but debug- and hobbyist programs. MISRA C bans stdio.h.

[Lundin]

Ironically, five minutes after writing this post I encountered such a bug in real life, so I thought I should share it here:

I aided in debugging a problematic Windows program where none could understand why the program sometimes wrote strange rubbish output to files.

The program was using fprintf() and the bug was that at one line, a C++ string object was passed to fprintf (by value!) rather than a C string. Ie:

string str;

fprintf(file, "%s", str);

rather than

fprintf(file, "%s", str.c_str());

As you might know, C++ has even stronger type checking than C. Yet the modern Windows C++ compiler failed to see the above bug. No typechecking, no warnings... just because of the va_list used by fprintf. Had for example C++ file handling been used instead, the bug would have been killed at the first compile early on in development, rather than far later, in production code.

[moparnick]

Your probably right.  Our professor is having us bench mark the jm60 again the coldfire (v1 I think).  Basically we write an algorithm (mine is to sort 4 long integers) and time how long it takes to do the sort many times.  So I was just trying to see If my code was functioning correctly by printing out the final result.  I have been trying to use sprintf() but I get a lot of garbage/wingdings spit back out at me.

[darknight]

Hi,

I have use printf with 9s08aw60, take a look here : Terminal

you must modify the termio.h with your sci fonction or take the code sample with the link.