Christmas Tree RTOS

By Ralph Moore

President

Micro Digital

September 05, 2014

Christmas Tree RTOS

Embedded systems should be designed the same way that we decorate Christmas trees. The tree is the RTOS, and there are many to choose from. You should...

Embedded systems should be designed the same way that we decorate Christmas trees. The tree is the RTOS, and there are many to choose from. You should pick one that’s well-shaped, has many branches, and fits your room.

The next step is to hang the lights, which represent the skeleton of your application, consisting of tasks, RTOS services, and stubs. Stubs are written by you to simulate eventual task code. For example, if you know that a task will be performing many computations, then you would include statements that perform additions, subtractions, memory accesses, etc., and then cause the stub to loop an appropriate number of times to simulate the estimated operations needed for the full calculation. Stubs can be refined as time goes on and as algorithms become better understood. You also might be able to borrow similar code from other projects to use for stubs.

As you begin to hang the lights, you’ll want to plug them in occasionally to see how they look. You do this by running your skeleton under a debugger with an RTOS-aware plug-in. This allows observing the interaction of threads (ISRs, LSRs, and tasks), profiling to see where bandwidth is being used and how much overhead is left, performance measurements, power measurements, etc. You can also plug in the middleware at this point and create stubs to put it to work.

Since little effort has been invested so far, you can conveniently make big changes, such as moving light strings around to see if you get a better result. While others are decorating the baubles, you can be refining the design until all agree that this will be the best Christmas tree ever.

The next stage is to hang the baubles which represent the real code that does the job. Note that each stub establishes boundary conditions for the actual code, like the time budget, inputs, outputs, etc. Because you have a working skeleton, the baubles can be introduced gradually and the results observed. You may want to move some baubles higher or lower in the tree hierarchy to achieve a better effect. Or a bauble may need to be reworked, perhaps painted a different color. At the same time, remaining stubs can be refined to give an increasingly better picture of the final system.

The final step is to add the tinsel – the wow factor. At this point, you have a reliable working system, and you’re just trying to please marketing and management. The objective of this methodology is to avoid being painted into a corner, or worse yet, to run out of paint.

More information on this design methodology is available in the smx User’s Guide.

Ralph Moore, President and Founder of Micro Digital, graduated with a degree in Physics from Caltech. He spent his early career in computer research, then moved into mainframe design and consulting.

Ralph Moore, Micro Digital

I am no longer running the daily business at Micro Digital. Instead, I have been involved for the past four years in improving the smx RTOS kernel. smx is a hard-real-time multitasking kernel, which is intended for embedded systems that require high efficiency and high performance.

More from Ralph