So far in this series we have been discussing how to create threads and properly size their stack so that developers are able to efficiently use their RAM while not risking a stack overflow. There is far more to thread management than simply getting the stack size correct. Developers need to understand how to make sure that all their threads will be able to meet their real-time deadlines. In order to accomplish this, developers need to employ some best practices and a commonly used scheduling technique known as rate monotonic analysis (RMA) which is sometimes referred to as rate monotonic scheduling (RMS).
Before diving into the details on how to perform a RMA, it is important for developers to realize that RMA is a starting point for ensuring that all tasks will meet their deadlines. RMS is a great theoretical starting point for developers but RMS assumes that
Even with these assumptions, performing an RMA will provide a developer with a foundation from which they can determine whether their task priorities are appropriate and determining if their design is moving in the right direction. One result from RMA is that the theoretical limit for CPU load to meet real-time deadlines with in infinite number of threads is 69.3%. means that any analysis that shows a CPU usage greater than or equal to 70% for periodic threads is probably not going to work in real life without threads missing their deadlines! The remaining 30% is used for non-periodic threads and interrupts.
There are several steps that developers can follow to perform an RMA analysis on their own application. These include
When performing an analysis on threads for an SSP application, beware that some frameworks have internal threads! For example, the audio playback framework has an internal thread with a preset priority that would be easy for developers to overlook if they did not know it existed. The best way to identify these internal threads is to check the documentation for frameworks in the application and look for a Thread Priority property in the framework properties. An example can be seen below:
When an internal thread exists, developers need to review the documentation and datasheet to determine the frameworks requirements and add it into the RMA. Few things can be as dangerous as overlooking a thread in an analysis!
As a simple example, let’s say a developer has three tasks that need to execute as shown below:
Developers can first determine if scheduling their threads is even possible by summing the execution time divided by the period as shown below:
1/5 + 2/10 + 4/10 = 0.80
For three tasks, RMA shows that the CPU utilization must be:
U = 3(21/3 – 1) = 0.77976
In this case, 0.80 > 0.77976 which means that the threads will not be schedulable without optimizing the system. If the execution time for the Thread 1 could be decreased by 50%, the result would be 0.70 which is less than 0.77976. At that point, the developer would assign priorities starting with the thread that runs the most frequently (Thread 1) down to the least frequent thread (Thread 2).
Using RMS provides developers with a good starting point for determining thread priorities. The only way to truly know if deadlines are being met and that no issues exist is to test and monitor the system. In the next post, we will look at the TraceX tool and how it can be used identify all the threads in the application and spot potential issues with the real-time performance. Until next time,
Live long and profit!
Hot Tip of the Week
You can easily find any new Renesas Synergy™ Platform projects for your kit from the Synergy Tools and Kits page. For example, from https://www.renesas.com/en-us/products/synergy/tools-kits.html you can select Sample Code to see a list of all the sample code for that various kits. The list is sorted by date so the most recent items show up first. See if you can find the HMI Brushless DC (BLDC) Motor Controller – Application Project from Feb 13, 2017 near the top of the list.