Painless Multithreading: How to Verify RTOS Best Practices in Runtime
Developing reliable and performant RTOS applications is easier said than done, and is greatly facilitated by a solid software design that follows best practices in RTOS application development. While an RTOS makes it easier to develop more advanced applications, the use of multithreading brings new challenges in software design, verification and debugging. Such issues are often not apparent in the application code.
In this presentation, we will discuss a selection of best practices in RTOS-based software design and the concept of visual trace diagnostics. Finally, we will explore how visual trace diagnostics can be used to analyze the software design and detect deviations from best practices.
Why did Task B consume about 50% CPU time when it used HAL_Delay(10) instead of an RTOS delay function?
Yes, my presentation was a bit simplified in this regard. There are other options for implementing signals between tasks that have more clear meaning, like task notifications in FreeRTOS, or message queues.
Hi Tommy. The recorder library we use for FreeRTOS (and soon also Zephyr) can be used for bare metal systems as well, although you need to add suitable instrumentation. This is facilitated by the new SDK, that will be included in Tracealyzer v4.5 (coming soon).
Interrupts can be traced by calling the recorder library from the ISR. The overhead is typically a few microseconds, but depend on the processor and compiler settings. This is not recommended to trace highly frequent or timing-critical ISRs (where microseconds matter) as the overhead might become a problem.
Are there trace techniques for bare metal functions/tasks?
How is interrupt tracing handled, and what is the overhead for this?
Hi Gary. Thanks! Zephyr support is in progress. We are working on a new Tracealyzer release, v4.5.0, where Zephyr will be supported. This should be out in a few weeks. Target-side support will most likely be included in the next Zephyr release (v2.6) and I'm presenting the solution at the Zephyr Developer Summit on June 9. See https://github.com/zephyrproject-rtos/zephyr/wiki/2021-Zephyr-Developer-Summit.
Thanks for a great talk Johan!
Out of curiosity, does tracealyzer support Zephyr RTOS as well. All the demos I have seen at the conference so far have used freeRTOS.
Welcome to this presentation. I'm available here between 15-16 CET, and then in the live Q&A session. But you can also post questions here afterwards and I'll try to answer as soon as possible.
Hi, thanks for the talk.
I think the differences between Mutexes and semaphores in terms of priority inheritance is not the same across OS's. Vxworks (I beleive) provide priority inheritance for both semaphores and mutexes. However you are right to point out the complexity of semaphores and a relatively simple concept can get the unwary into a lot of trouble. We have had situations where you have 3 tasks sharing 2 semaphores, we can get a situation sharing two semaphores from both higher priority task, but when it release the higher priority task semaphore it maintains its higher priority despite only blocking a medium priority task, so causing a un-necessary delay in the higher task. These are largely caused by little known subtleties and different implementations of semaphores. This is not helped by the fact atht a) developers tend to throw semaphores and mutexes in as a safety feature, even if they are not actually needed and b) often the semaphore is used within the OS function calls itself, so you are not aware that a semaphore is being called
In fact the trend has to been look at alternatives to semaphores for this very reason