Home > On-Demand Archives > Q&A Sessions >
Live Q&A - Painless Multithreading: How to Verify RTOS Best Practices in Runtime
Dr. Johan Kraft - Watch Now - Duration: 20:29
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.
10:40:47 From Dave Nadler : Thanks for a great presentation! You didn't mention potential deadlock detection - Does Tracelyzer include detection of different-order mutex acquisition etc.? 10:43:48 From Keith J : Thanks Johan - One of the better explanations of priority inversion and inheritance I've seen. Will help me explain it to others. Thank you! 10:45:07 From Radu Pralea : Can we also analyze the RTOS implementation (calls)overhead (every platform is different)? 10:45:07 From Peter Sik : What can be a measure to help decide if using an RTOS is worth it compared to bare-metal? 10:45:44 From Michael Kirkhart : Not directly related, but are there static analysis tools which are RTOS aware and can flag potential deadlocks? 10:45:50 From Dave Nadler : Do you mean super-loop when you say bare metal? 10:45:56 From Peter Sik : Yes 10:46:12 From Gary : Does Tracealyzer support multi-core architectures like stm32h7? 10:46:18 From JackW : Is it possible to store Tracealyzer diagnostics in non-volatile memory on an air-gapped embedded device, to be extracted for analysis later? 10:46:45 From Gary : Is Tracealyzer RTOS agnostic? Can it be used with Zephyr? 10:47:08 From Dave Comer : How does (or does it) Tracealyizer work with QP? 10:47:44 From Erwin : Thanks for the good overview presentation. As Tracealyzer or better the trace library is currently more or less Bound to FreeRTOS hooks, are there any plans to extend further or even provide a bare metal library! JAcob you ar too fast :-) 10:51:31 From TommyPro : Sorry, joining late, so this question may have been asked. Are there trace techniques for bare metal functions/tasks? 10:52:45 From TommyPro : How is interrupt tracing handled, and what is the overhead for this? 10:53:37 From Dave Nadler : Follow-on to the air-gapped capture question: Can the complete trace stream be written to storage using a background task, for later analysis? 10:54:21 From Jorge Conti : Are there static analysis tools which are RTOS aware and can flag potential deadlocks? 10:57:15 From Dave Nadler : What different hardware connections are supported from target to host? 10:57:21 From Nathan Jones : QP is Miro Samek's framework 10:57:32 From Miro Samek : QP is a real-time embedded framework 10:57:39 From Michael Kirkhart : https://en.wikipedia.org/wiki/QP_(framework) 10:57:57 From Matjaz Finc : You showed an issue in the NASA Pathfinder - was it really running FreeRTOS or I misunderstood? 10:58:21 From Miro Samek : Pathfinder ran VxWorks 10:58:29 From Matjaz Finc : thanx 10:59:39 From Keith J : Thank you Johan!!! 10:59:54 From Miro Samek : QP works at a higher level of abstraction than a naked RTOS. QP has its own software tracing (called QS), which predates Tracelyzer by many years. 11:00:29 From JackW : Thank you! 11:00:39 From Dave Nadler : Thanks Johan!
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