I recently learned it’s possible to easily subscribe to all the comments posted on this blog. Given the quality of the comments that are posted here, I thought others may be interested too. The URL is feed://embeddedgurus.com/barr-code/comments/feed/.

In real-time systems, as in life, anything that can go wrong will! A nurse could be using a GUI task to change system parameters on a ventilator just as the attached patient’s lungs demand the most help from another task. Or an interrupt signal could start acting funny, generating a stream of unexpected ISR invocations. Or all of those at once. And something else.

The designers of hard real-time systems must design for such a worst-case. They must ensure that sufficient CPU and memory bandwidth are present to handle the worst-case demands that could be placed on the software—simultaneously. In simple terms, we must size the processor bandwidth to the worst-case scenario.

Safety for the users of our products emerges as a side effect of buying a faster (read “higher priced”) CPU. Rate Monotonic Analysis helps ensure we’ve specified the right processor clock rate, so the users are safe. RMA is also the optimal fixed-priority scheduling algorithm, which prevents us from over-paying for clock rate. If a set of tasks cannot be scheduled using RMA, it can’t be scheduled using any fixed-priority algorithm.

The basics of RMA are well covered in many places, including my article Introduction to Rate Monotonic Scheduling. In summary, Rate Monotonic Analysis gives us mathematics to prove all deadlines are always met when you’ve followed the Rate Monotonic Algorithm to assign priorities.

Rate Monotonic Algorithm is a procedure for assigning fixed priorities to tasks and ISRs to maximize their schedulability. A particular set of tasks and ISRs is considered schedulable if all deadlines will be met even in the worst-case scenario.  The algorithm is simple: “Assign the priority of each task and ISR according to its worst-case period, so that the shorter the period the higher the priority.” For example if Task 1 and Task 2 have periods of 50 ms and 100 ms, respectively, then Task 1 is given higher priority. This ensures that a long Task 2 job can’t prevent Task 1 from missing its more frequent deadline.

Too many of today’s real-time systems built with an RTOS are working by luck. Excess processing power may be masking design and analysis sins or the worst-case simply hasn’t happened—yet.  Bottom line: You’re playing with fire if you don’t use RMA to assign priorities to safety-critical tasks; it might be just a matter of time before your product’s users get burned.  Perhaps your failure to use RMA to prioritize tasks and prove they’ll meet deadlines explains one or more of those “glitches” your customers have been complaining about?

A reader of my monthly Firmware Update newsletter recently sent an e-mail to ask:

I am a firmware engineer. I read your recent blog post regarding the C stack, about which I have two questions: First, how can I increment or decrement the size of the stack in my code? Second, what size should I choose?

Here’s what I told him:

The size of the stack is set either in the linker command file or in the C or C++ startup code. You should be able to learn more about how to change the stack size from your specific compiler vendor’s manual or customer support.

Identifying the minimum stack size required for your specific application is made challenging by these stubborn facts:

– MEASURING the maximum stack growth during testing may not be sufficient. If you test for half a year, the product is sure to be run for a year or longer in the field. Have you really tested all possible cases? What about all possible series of interrupt service routines on top of that worst case use by main()?

– TOP DOWN ANALYSIS of the compiled code can be done to determine the number of function calls and interrupt service routines at maximum depth; their individual parameter and local variable use, etc. Unfortunately, these things may keep changing whenever you change the code and recompile.

The best approach is usually to perform a conservative top down analysis of the source code; when in doubt, always round up. Don’t forget about nested interrupt service routines. Double that conservative to set your initial stack budget. Then measure actual stack utilization during testing, preferably with code coverage analysis tools running–to ensure that you’ve tested all possible paths (except interrupts, which may run at different times in the field).

Then if you need to reclaim memory to ship the product, start shrinking the stack. But also put into place a high water mark system (e.g., 0xDEADBEEF) complete with supervisor code to put the product into a failsafe state if more than, for example, 80% of the stack is ever used.