snprintf Release 2.0 rc 4

[ephogy]

I've just noticed that there seems to be a threading problem with printf and floating point values. (And I apologize of this has been covered before)
We have a network task and an LCD task, both of which utilize snprintf for generating the ASCII representation of floating point numbers, sometimes the floating point value destined for the LCD task ends up on the Network task, and vice versa.
We're using the Netburner SDK 2.0 rc 4, before spending money to renew the development kit, I'd like to know if this problem is resolved in 2.2/2.3, or whether I'll need to do something else on my part to use snprintf within multiple tasks?
Note: We have the TICKS_PER_SECOND set to 200.

Thanks in advance.

Edit: The Device in question is a MOD5272.

[Chris Ruff]

Are you discussing strings being interspersed by concurrent tasks? If that is the problem, downloading a new version won't help. You will need to build in semaphore protection so that when one task "has the con" other tasks wait.

I usually build a "manager" that owns the ability to do some shared operation and all competing tasks deal with the manager and lock each other out

Chris

[ephogy]

Are you discussing strings being interspersed by concurrent tasks?

The string operations are interspersed by concurrent tasks, however, the two tasks both use buffers that are allocated on the stack, and these two particular tasks never communicate. The strings are only generated when they're needed; the LCD tasks writes data to a serial port which is then interpreted by the LCD plugged into the corresponding serial port. The Network task generates the string when a networked computer asks for the information.

If I use snprintf, and only print integer values, there is never a problem. The problem only arises when floating point values are used.

To give a little more background on it, the network task generates about 3 KB worth of text, and takes approximately 300 ms from start of request, to receipt by the network computer. With task switches occurring every 5 ms, that leaves lots of room for other tasks to use printf to convert a float to ASCII.

I know I've read that newlib *used* to have reentrant problems with floating point values, but this was years ago. Do they still have reentrant problems?

[lgitlitz]

There was a reentrant problem that was fixed a few releases ago, I believe the final fix for this was introduced in NNDK2.1. This is a bit harder to track down the exact date of the fix since it is a change to the internals of the GNU libraries, not our general nburn system library. If you are doing floating point operations you should probably upgrade to the newest beta anyway since the new SRAM utilization will greatly increase the performance. You should add the task stack to SRAM for any task that deals with floats. You can do this by adding FAST_USER_STK as an attribute to the stack declaration...
DWORD MyTaskStack[MY_TASK_STACK_SIZE]__attribute__((aligned( 4 )));
...will become:
DWORD MyTaskStack[MY_TASK_STACK_SIZE]__attribute__((aligned( 4 ))) FAST_USER_STK;

-Larry

[ephogy]

Thanks, Larry

I'll update the development suite.

[zealott]

I have had this problem as well, I had to use semaphores every time I used printf and FP (i still use them).