Float to ASCII conversion without using sprintf function

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

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