Live Q&A - Best Practices for RTOS Application Design

Certainly!

Below are a few good ones and classics:

• Clean Architecture by Robert Martin
• Real-time Concepts for Embedded Systems by Qing Li
• Test Driven Development for Embedded C by James Grenning
• Real-time C++ by Chris Kormanyos
• Definitive Guide to ARm Cortex-M23 and Cortex-M33 Processors by Joseph Yiu
• The Art of Designing Embedded Systems by Jack Ganssle
• C in a Nutshell by Peter Prinz and Tony Crawford
• Expert C Programming Deep Secrets by Peter Van Dev Linden

Obviously there?s a ton more, but hopefully that helps give you some reading ideas!

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.

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.

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.

Its great to hear a few mentions of uC/OS-III. I use it every day and the book is very clear. I enjoyed your talk about MPUs also.

Thanks! That is good to know!

There are two main ways I do it.
1) Analytical by using a static code analyzer. (Can also do it manually, but the code analyzer is faster)

2j through testing. Can use tools like RTOS aware debugging, ides, Tracealyzer, rtos stack monitors, stack watermarks, etc.

Thanks for the question. Yes so TYPE was my generic way of putting in some pseudo code that a developer would update. So TYPE would be replaced by uint32_t, uint8_t, or whatever type the application required. We could probably make it void or some generic return that is case into what is needed.

Thanks for the questions. Please see below:

1) I would suggest that you pass the data by pointer. You can have a shared memory location of 256 bytes that stores several messages. Then pass the pointer to the memory location.

2) Basically the task that needs to respond quickly has the higher priority. For example, the response time on a vehicle brake peddle may be 30 ms, while the knob on a radio might be 100 ms. The brake peddle should therefore have the higher priority.

3) I use Tracealyzer to measure how my system is performing. It measures response time, execution time, periodicity and several other metrics.

4) I typically use a tool like Visio, eDraw Max or even sometimes PowerPoint.

Thanks! I?m glad to hear that you like the approach! I hope it helps!

Response time will look at how quickly the task needs to start executing when it becomes due to run. Execution time is just based on how much CPU time the task needs to runs.

Great suggestion! Totally agree!

Yes great suggestion / observation! These are often easy to overlook.

Thanks. So, I try to use this pattern if I can to manage my application tasks when it makes sense. Certainly third party libraries will create their own tasks such as spinning off TCP/IP, MQTT or other tasks. To find these, I usually have to trace the system.

With the other kernel objects, I generally try to abstract them into the modules that use them so that they are hidden.

To make it easier to use with an MPU ... ;-) After doing this for 20+ years I generally do everything in powers of two so it's just natural. Moving averages need to be done, power of two elements. Allocate memory, power of two. etc.

I 100% agree on never using dynamic memory. Unfortunately my examples are lazy in that they use dynamic memory. Prior to FreeRTOS v8, they didn't even support static allocation so the only way to safely allocate a task was to dynamically allocate it at start-up and then leave it there.

Thanks for the question. There can be situations where it makes sense to avoid using the interrupts or at least need to be super careful how they are used. For example, if you are using input capture to calculate frequency or duty cycle and calculating in the ISR, you may find that with signals that are 5 KHz and up that most of your time is spent servicing the input capture interrupts. In these instances, it can make more sense to poll the timer at a known interval and take an average of the edges that were detected ( well at least for frequency measurement. That won't work for duty cycle).

Thanks for the question. I don't actually. It's just notation that I started to use when I started to use RTOS based systems. I will do some checking to see if there is anything already formalized and if not, maybe i'll look to do so. Thanks for the feedback/question.

There are different design patterns that can be used to handle something like this. First, I generally would have a single task to handle the incoming UART data. No need for two tasks to interface to similar devices. I would then use an interrupt, either from the UARTs or even DMA, to signal via a semaphore that there is data to be processed. The ISR would push the incoming byte into a circular buffer and then the UART task would manage the data that was received. This will vary from application to application but usually its served up to another function or task that validates it and figures out what to do with it.

Thanks for the question. Execution time is how long it takes for the task to run. Response time is how long it takes until the task is able to run.

Thanks for the question. For low power systems, I generally try to make everything as event driven as possible. I try to eliminate periodic tasks. An event wakes the system up and signals a task that needs to run, it runs signals any others and when done the idle task is there to put the system back to sleep.