FreeRTOS on Zybo


I am trying to run the various examples given in the FreeRTOS user guide on a Zybo Z7 board. I am viewing the output on Tera Term. For the most part, the output matches what’s given in the guide except that my output lines sometimes get printed half-way due to a task getting switched or blocked. This effect is not seen in the screen shots in the guide. Am I missing something here? Also this seems to indicate that some tasks will be left halfway and picked up later? This might not be a good thing if this is a real time control system. What would be the ways to handle this?

Here’s a screenshot of my output :

Thanks for the help, and the great software and tutorials!

Hi yogesh,

what you are seeing is totally to be expected and logical. Since the serial output executes in the context of the task that does the output, it may be preempted according to the scheduling schema.

If you need real time, DO NOT use serial diagnostic output. It will dramatically change your timing. I refer to this as the “Heisenberg effect of computing,” since the observation of your runtime behavior will change the behavior itself. If you need to obtain real time information about your application, there are better (although generally less convenient) debugging and monitoring strategies.

1 Like

FreeRTOS is operating in a preemptive fashion in that demo. It will periodically run the scheduler to ensure the task with the highest priority is still running.
If your system cannot tolerate switching in a periodic way, it is possible to use FreeRTOS in a cooperative manner where tasks voluntarily yield when it is most appropriate.

In general, prioritized tasks and preemptive switching works very well for many real-time systems.

If your system cannot tolerate serial messages being disturbed as shown above there are a few ways to solve that. For example, the serial messages could be protected by a mutex preventing a context switch during the printing. OR a single task could manage all the serial printing while other tasks send the messages via queue or streams. Increasing the baudrate can also increase the chances that the messages will be sent before the preemption occurs.

An example of serializing debug messages using one task (as mentioned by @n9wxu) is here: amazon-freertos/iot_logging_task_dynamic_buffers.c at master · aws/amazon-freertos · GitHub


Alright thank you everyone. I think using a mutex would be a good way to handle not just serial messages but writing critical registers.