convert integer to string

[Gerald1]

hi,

how could i convert an integer to an string with sprintf?

cu

[colinh]

I'll answer your question with a question - Do you really need this 'sprintf' functionality to occur in the ISR?  To me there are not many good reasons I can think of to do data formatting of this type in an ISR - keep them "mean and lean"

If you absolutely must then you can do a series of divisions by reducing powers of 10.  If you are only dealing with a 16 bit unsigned int then:

Code:

uint16 value = 12345;     // test value.uint8 string[6];uint8 *ptr = string;*ptr = '0' + value/10000;    // extract 10s of thousandsvalue = value%10000;ptr++;*ptr = '0' + value/1000;     // extract thousandsvalue = value%1000;ptr++;....*ptr = '0' + value/10;value = value%10;ptr++;*ptr = '0' + value;

But at the end of the day it is still doing a lot of library calls. 

It doesn't do leading zero stripping or any justification and doesn't handle negative values.  It could also be improved ROM wise by using a looping construct.

Hope this points you in the right direction...

[Gerald1]

is there maybe somthing faster then sprintf..because iam doing the sprintf in the interrupt service routine...

[CompilerGuru]

Just a few notes.

First, please don't cross post, otherwise different people will answer the same questions without knowing from each other and that just wastes time.

And now to the question. The best advice is to do as little computation in the interrupt as possible.
So can you not change the code so it does the int to string conversion outside of it?
Calling sprintf or doing that conversion in the interrupt handler will probably take quite a while and therefore delay other interrupts.
So don't use sprintf. It's an advanced ANSI function, dangerous to use, many traps which are not detected at compile time.
If you really want to use it, things to look out
- in
http://forums.freescale.com/freescale/board/message?board.id=CW816COMM&message.id=3902#M3902
>"sprintf(str, "%s", 4);"
%s expects a string. %i or %u are for ints.
- I think the library provided sprintf is not thread safe out of the box, so in order to use it in a interrupt handler
  you have to change libdefs.h and recompile the ANSI lib. (advanced, recommendation: don't use sprintf in interrupt handlers :smileywink: )
- sprintf needs a lot of stack, more than usually given. Calling sprintf from within an int handler means: your app needs more than twice the amount of a single sprintf call. Be really careful with the stack size.


So best is if you can move your computations out of the int handler. If not, do the computation with a special purpose int to string conversion routine.

Daniel

[JimDon]

sprintf(str, "%s", 4); // Dont't do this!

Don't do that! Unless you happen to have a string at address 4. In the case of %s, it is expecting a pointer, and will likely crash things, or at the very least not do what you want.

Do this:

sprintf(pStr, "%d", i);   // correct way to convert an integer
sprintf(pStr, "%ld", i);  // correct way to convert a long


It will cost you about 2K-3.5K of ROM, and if you need to so string stuff, it is well worth it. Much better to use a very well tested lib than spending time trying to re-invent it. The lib code is very well written, very well tested, and most likely faster and certainly more reliable that what you will come up with.

As mentioned it may not be thread safe, so if you do it on an interrupt, you can't do it in the foreground loop without some sort of interlocking mechanism. As for crashing the stack on on interrupt thread, it really does not matter where you do it, if your stack is too small it will crash. (the interrupt could happen during the call to sprintf - same amount of stack space either way).

Please refer to the CW helps if you are unfamiliar with sprintf. I wouldn't count on a thread to inform me of all the details. Like most things in "C", it is very powerful, and will let you shoot a bigger hole in you foot if you do not take the time to learn it well. A sharp knife cuts deep when mishandled.

BTW lib calls are never guaranteed "thread safe" because it is not possible for the lib to understand the context of your thread. It is up to you the make them so. Some might be by their nature, but you can't count on it. This is by design and necessary.