Hi Gang,
We have used Rabbits for years in a “somewhat realtime” application. We have a continuing problem in that adding a printf() for debug purposes in one costate can completely screw up timing in unrelated costates. Scanniing some of the forums implies I am not the only one who has had “fun” with this issue.
Looking at the printf code in stdio.lib it seems to use a putc in a tight loop (rather than one of the packet send routines which would be interrupt driven) so that is ties up the processor until the printf is completed. Is there way to do printing in background mode so it won’t interfere with the main loop?
We have been using costates but we are looking at uCos II for our next project, partly due to timing issues. What priority does a printf execute at? Does it run at the priority of the calling task? This means a printf in a low priority task would not block out higer ones but a printf in a high priority task would block out lower tasks. Better, but not ideal.
All I can think of is creating a very low priority task and queuing all prints to that task.
Added note: we use both serial port and ethernet Rabbit debuggers and the printf timing is distincly different between the two.
Any clues on how to limit the effect of printf()s on timing?
Thanks,
Kevin C.