This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Float to ASCII conversion without using sprintf function

Hello,

I am removing all sprintf() function from my souce code as this function does not allow me to set the proper thread stack size. Does anyone have any function that implements this conversion?

Thanks
Andre Moutinho

Parents
  • As Per mentioned there are a lot of things you are ignoring. I did give a strong HINT you should look at the EXISTING papers on this subject. It's not trivial the code your provided will work in narrow circumstances by the way (a lot of constraints). Perhaps you should define what you need to do before you go further? Also you may need to consider why you need to use sprintf in a thread separate from your primary thread.

    I believe you need to DEFINE your problem not just write code. It makes things much easier for yourself and other people when you set constraints that reduce possible difficulties in implementation. In my case for writing something equivalent to sprintf floating point formatting it was for what Per mentioned, to prevent buffer overrun. sprintf does not perform buffer overrun check, thus I had to make a variant that in no way could have a buffer overrun.

    You would be best served to do more research and planning on paper before you write any code. If you haven't defined your problem so that you can explain precisely and accurately what the constraints are "IE I can't use more than 128 bytes of stack space for this thread, this thread formats a double precision floating point for the user and places it on an LCD. The thread may not overrun the string buffer." etc etc. Those are constraints. Without specifications you are 'nailing jelly too a tree' (great book by the way).

    Stephen

Reply
  • As Per mentioned there are a lot of things you are ignoring. I did give a strong HINT you should look at the EXISTING papers on this subject. It's not trivial the code your provided will work in narrow circumstances by the way (a lot of constraints). Perhaps you should define what you need to do before you go further? Also you may need to consider why you need to use sprintf in a thread separate from your primary thread.

    I believe you need to DEFINE your problem not just write code. It makes things much easier for yourself and other people when you set constraints that reduce possible difficulties in implementation. In my case for writing something equivalent to sprintf floating point formatting it was for what Per mentioned, to prevent buffer overrun. sprintf does not perform buffer overrun check, thus I had to make a variant that in no way could have a buffer overrun.

    You would be best served to do more research and planning on paper before you write any code. If you haven't defined your problem so that you can explain precisely and accurately what the constraints are "IE I can't use more than 128 bytes of stack space for this thread, this thread formats a double precision floating point for the user and places it on an LCD. The thread may not overrun the string buffer." etc etc. Those are constraints. Without specifications you are 'nailing jelly too a tree' (great book by the way).

    Stephen

Children
  • Hello Stephen,

    Please read my previous reply. My application has more than 20 task and each task must have debug.

    Thanks
    Andre Moutinho

  • If you haven't debugged anything under an RTOS then I suggest you get some advice. Printfs in 20 different threads to debug your code is inadvisable and not likely to help you remain sane. It's difficult enough trying to debug something with a single thread but 20 is asking for serious trouble if you don't have a VERY well defined method.

    Break it down. Test each thread's code with all of it's possible states of error individually. This is not far fetched as I mentioned I wrote my own variant of printf, I had to guarantee that it WORKED correctly EVERY time and gave the correct answer EVERY time irregardless of what was thrown at it. I performed float point prints from -9999.99 to 9999.99 in 0.001 increments to verify it worked correctly (yes 2 million tests), and then -999.999 to 999.999 (another 2 million tests). That covers single precision floating points significant digits and all digits that would possibly be used. THEN I had to test out of range values and illegal floating point values etc. (generating random integers and type casting them as floats as well).

    This is a simple unit test. The specs are in the test itself (number ranges and digit count).

    You should do this amount of testing too each thread individually to insure that by itself (or 2 threads if it needs another to feed data too it etc) it works correctly.

    Printf on everything tends to just confuse things, and if you have 20 sources of debug data then you have 2^20 times the amount of possible confusion (binary joke had to be done).

    Once you have guaranteed each part of your program works correctly and leaves no unknown states the rest is relatively easy.

    Stephen