Home >
Live Q&A - Best Practices for RTOS Application Design
Jacob Beningo - Watch Now - Duration: 19:35
Typically I run the state machine within the task using a StateMachineRun function. I then expose API's that can be used to trigger state transitions from other context.
How to handle Asynchronous data reception in the system. For example if there 2 UART peripherals(no flow ctrl), that should accept data, that later should be processed by application. How should this be handled ?
You could use a UART Gate Keeping task to manage it. You could also use a semaphore to signal which UART the data came from. Also a queue. Many different patterns you can use. let me know if that makes sense.
Jacob, great talk and Q&A session. I’d love to use Tracealyzer to learn more about what my application is really doing under the hood, but it’s just too expensive for occasional use. Have you found others such as SystemView to be almost as useful? Also I’m using ST-Link v2 on a custom STM32 board for debugging, but the turnaround time after making a change and loading into flash takes a minute or so, multiple times during the day. I know ST-Link v3 exists, but there seem to be multiple models and doesn’t seem to be available. Is something like I-Jet or J-link really any faster in practice? I know they offer unlimited breakpoints, which would help. Are they also fully compatible with custom STM32 boards (i think using SWO)? Thanks!
Thanks for the question.
SystemView can give you some details, but not as powerful as Tracealyzer. STM32CubeMonitor could also be helpful. Not used it much yet, but looked interesting.
I'm biased here, in that I always find paying for a tool is well worth the cost. So if you work for a business, I'd recommend you get them to just buy the Tracealyzer license. My technique is to convert the cost for a tool to the number of hours of my labor it takes to equal it. So if the tool is $1500 and I make $50/hr, then if the tool will annually save me at least 30 hours of work and debugging, it's well worth the investment.
I have not used the ST-Link v2 in quite some time. I use my J-Link Ultra+ most of the time. Typically the erase and load time is < 5 seconds. You may be able to update the ST-Link Firmware to V3.
14:44:34 From Manuel Malagon : I don't have the "hand raise" icon. How do I ask a question on the microphone? 14:44:47 From Aabhas : Hi Jacob, Can we minimize communication between tasks by using shared memory? What problems can arise in the application? 14:45:01 From Dave Nadler : Not at all! Use the timer task callback to put something into a queue to start other processing. 14:45:13 From JCA Engineering : You can raise your hand from the reactions menu. 14:45:59 From afwaanquadri : I like the idea of placing Tasks info at one place. Been there were tasks were created all over the place :D 14:46:05 From Jean Labrosse : The Timer task execute data in order instead of by priority. So that defeats the idea of an RTOS 14:46:35 From afwaanquadri : I agree with Jean Labrosse 14:47:05 From ever : I will post my question here... if we have a NONE RTOS embedded system (legacy code) what will be the best practice to migrate to RTOS ?, what will be the best practice, seems in my expirience the best practice is to either stick the way it is OR rewrite everything 14:47:56 From Sergii Akhinko : How to handle Asynchronous data reception in the system. For example if there 2 UART peripherals(no flow ctrl), that should accept data, that later should be processed by application. How should this be handled ? 14:48:26 From Aldo Coronado : What is the best way to implement an application which has an inherent need for state control (i.e. state machine, controlled by driver inputs) in and RTOS design paradigm? I have implemented an Event Handler which distributes messages from a Queue to the running context, but so far hasn't been deterministic. 14:48:31 From Aditya S : Hi Jacob, I recently found using FreeRTOS that a memory pool I used to bind a channel input with an output (from one task to another) was overwritten when the task scheduler started. To get around it, I had to declare the buffers and the memory pool had outside of the stack. I had not come across this before, and wondered whether I just got lucky last couple of years with previous code where I had not had this issue before? And is this the case with other RTOSs as well? 14:49:41 From Dave Nadler : Adita, you should not be placing buffers and memory pool on stack. 14:49:43 From Jorge Conti : what is the best practice to define memory for each task? 14:50:16 From Dave Nadler : Adita, when tasks start, stack area from startup is used for other purposes - which is a good feature as otherwise memory is wasted. 14:52:03 From Jean Labrosse : In most cases, when the RTOS starts, the startup stack is LOST! There are ways to recover that. 14:52:34 From Dave Nadler : Its not lost, for example on Cortexx-4M it is reused as stack for ISRs. 14:52:46 From Aditya S : OK, thanks Dave. I think I follow. I suppose I probably got lucky previously based on the size of the pools defined. 14:52:51 From Dave Nadler : I'm speaking of FreeRTOS Jean. 14:52:51 From Rocco Brandi : what is the difference between Response Time and Execution Time? what can influence the response time of a task? 14:54:15 From Tim Michals : Are are not more RTOS vendors use lock free message queues? 14:54:23 From Nathan Jones : I think "response time" is similar to "deadline", meaning that it's the latest time the task can finish before something bad happens to the system (like not refreshing a screen at a sufficient rate). 14:54:28 From Davy Baker : How would you compare your go to methods, to Ganssle's? 14:54:30 From javi : ever, you can start by putting you baremetal infinite loop into a FreeRTOS task and then start creating new tasks for other parts as you progress, step by step 14:55:12 From Dave Nadler : Right Javi, or use this as a starting place for factoring what should be separate tasks. 14:55:14 From Jean Labrosse : Best practice to allocate memory, especially for stacks is STATIC. If you use malloc() to allocate task stacks as long as you never delete tasks. For sure, you should NEVER use malloc() and free() to allocate memory because of fragmentation. 14:56:08 From Andrei : Any useful plugins for looking at FreeRTOS tasks at a given moment (i.e. debug halt)? I mean, inspecting a queue (where if I remember correctly the "message" is copied) is pretty difficult 14:56:31 From Mark Z : Hey Jacob, something I was thinking about was how to guarantee the timing of a Real Time System that's using Rate Monotonic Scheduling and Interrupts. Interrupts can be small and fast and only set a flag so would it be good enough for RMS to verify the CPU Utilization of all the tasks plus the interrupts? Maybe switching to a different scheduling method that doesn't use interrupts would be preferrable (like polling server or deferred server?) 14:59:19 From Jean Labrosse : RTOS aware plugins in tools are STATIC and not dynamic so you have to STOP your application to see what happens. Not very useful for dynamic systems like control systems. 14:59:21 From Manuel Malagon : Tracealizer is expensive, what do you think about segger systemview? It is very good and it is free to use. 14:59:54 From Jean Labrosse : I used SystemView, I like it, super easy to use and last I checked, there was a free version. 15:00:21 From Jean Labrosse : Great job Jacob! 15:00:32 From Andrei : Thank you! 15:00:34 From Raul Pando : Thanks Jacob 15:00:35 From Mikael Albertsson : Thank you Jacob! 15:00:45 From Douglas Renaux : thanks alot 15:00:47 From Christopher Long : Thanks Jacob!
What is the best way to implement an application which has an inherent need for state control
(i.e. state machine, controlled by driver inputs) in and RTOS design paradigm?
I have implemented an Event Handler which distributes messages from a Queue to the running context, but so far hasn't been deterministic.