Embedded Computing Design

In business, “table stakes” represents a minimum requirement to participate in a market. Today, there are over a hundred open-source and commercial RTOS in the embedded market. A vast majority of them don’t have functional safety certification. Given this, it’s evident that RTOS functional safety certification is not “table stakes” today, but maybe it should be!

It’s midnight the day before the product release and your system just crashed. As you follow the execution back from the point of the fault, you find yourself deep inside the Real-Time Operating System (RTOS) code. If you don’t have professional support, your only option is to try and figure out why the RTOS is failing yourself. Of course, you have to first figure out how the RTOS works to even have a chance at understanding what is going wrong. If you are fortunate enough to figure this all out, you are then tasked with trying to fix the issue – and then ensure the fix is propagated back into the next 3^rd party RTOS release.

The origin of the phrase “penny wise and pound foolish” comes from the 1621 work The Anatomy of Melancholy by Robert Burton. The idea behind this phrase is that we sometimes concentrate so hard on small costs that we can overlook larger opportunities to reduce costs or increase gains. This mindset has beset embedded development for quite some time and continues to do so.

It’s relatively easy to design an embedded system using an excessively powerful microprocessor with a plentiful amount of memory. However, this is generally not the reality in the resource constrained world of deeply embedded devices.

These days we are all a bit insecure when it comes to embedded security. It’s a fast-moving area with new threats emerging all the time. Worst of all, we in embedded typically live in a resource-constrained hardware world, which is at odds with most security defense mechanisms.

There is a seemingly endless number of RTOSes used with embedded MCUs, most of which have their own proprietary functionally as well as a unique API. Some of the APIs are good, and some not quite as good. In reality, the delta between a good and less-good RTOS API is quite small — most RTOS APIs will do the trick. As I look back on my last 30+ years, I’ve come to realize propriety RTOS APIs have had and continue to have a profound negative impact on embedded development and on our industry as a whole.