Comments on: I hate RTOSes

By: Is an RTOS really the best way to design embedded systems? « State Space

Is an RTOS really the best way to design embedded systems? « State Space — Tue, 07 Jun 2011 17:46:07 +0000

[...] I consider this discussion to be a continuation of the topic from my post ( “I hate RTOSes”) [...]

By: Rom H.

Rom H. — Mon, 06 Sep 2010 15:26:13 +0000

“Why Threads Are A Bad Idea (for most purposes) ” http://web.cecs.pdx.edu/~walpole/class/cs533/spring2006/slides/51.pdf

By: Rom H.

Rom H. — Sun, 05 Sep 2010 16:34:32 +0000

I have read the TTE(old version,Chinese translation), It’s simple and stable, and easy testing . TTE views the program in the time sequence, periodically checks the event flags and handles them, and can handles some Simple random events. I think TTE is suitable for definitely coming events within a time range, but It’s a problem for low-power sleep mode, cann’t be in sleep mode with TTE. The QP can run in IOC mode and can buffer the the events, no limited for events coming time, and QP can enter low-power sleep mode if no events coming.

By: Petr

Petr — Sat, 08 May 2010 19:56:16 +0000

There are some theoretical results showing that threads (aka RTOS) are technically equivalent to event systems (you call state machines). This paper describes that threads are easier for humans to grasp and use.

“Why Events Are A Bad Idea (for high-concurrency servers)”
http://www.cs.berkeley.edu/~brewer/papers/threads-hotos-2003.pdf

By: Ignacio G. T.

Ignacio G. T. — Tue, 20 Apr 2010 15:52:52 +0000

Hello, Miro.

I have been using both RTOSes and state machines since the late 80s. And I’m never tired of learning new things, so I read this topic with pleasure. In fact, I read your Statecharts book some years ago, and applied successfully your ideas in some products with no RTOS.

What I missed in this discussion, and perhaps belongs to a new thread, is a comparison with another contender: time-triggered architectures. I read with curiosity “Patterns for time-triggered embedded systems” (available here: http://www.tte-systems.com/books/pttes ) and I found it a mix of a very simple event-driven mechanism (where the event is always a time event) and a curious scheduler. I have never tried this approach, Do you consider it useful?

By: Miro Samek

Miro Samek — Mon, 19 Apr 2010 23:50:59 +0000

Thank you everyone for great comments. I’d like to address most of the issues mentioned in your comments, but obviously I cannot do it all in one post. Therefore, I’d like to lay out my plan of attack, so that you know in which order I am going to build my argument:

1. In my next post I’ll talk about avoiding blocking in RTOS-based applications. I’ll introduce run-to-completion event-processing, the concept of an event-driven framework, and inversion of control.

2. I’ll talk about challenges of programming without blocking. I’ll explain what you need to sacrifice when you write non-blocking code and why this often leads to “spaghetti” code.

3. I’ll explain how state machines can work as powerful “spaghetti reducers” and why state machines didn’t catch on in the traditional event-driven GUI programming.

4. In the subsequent post I’ll explain the important things that an event-driven framework can easily do, but a traditional RTOS can’t.

5. I’ll describe the pros and cons of the most popular state machine implementation techniques in C.

6. I’ll describe the main shortcomings of the traditional state machines and how modern hierarchical state machines avoid them.

7. I’ll explain how modern modeling tools work and what kind of code they can generate.

8. I’ll plan to explain a very simple and absolutely portable cooperative kernel for executing event-driven state machines.

9. I’ll explain an ultra-light preemptive kernel that is ideal for executing state machines in run-to-completion fashion.

I count on interesting, challenging comments. Stay tuned!

By: Miro Samek

Miro Samek — Mon, 19 Apr 2010 23:17:32 +0000

I agree that the most important reason why one should still consider using a traditional blocking RTOS is compatibility with the existing software, such as TCP/IP, USB, or CAN communication stacks that are designed for a traditional blocking kernels.

On the other hand, there is absolutely no technical reason why communication stacks would require blocking. In fact, this kind of software is very event-driven by nature. For example, the popular, open source, lightweight TCP/IP stack lwIP uses internally a strictly event-driven API, exactly to reduce its memory footprint and increase performance. lwIP can run without a traditional blocking kernel, and a port of lwIP to the QP event-driven framework works beautifully (see state-machine.com/lwip). Porting other stacks (USB, CAN, etc.) is just a matter of time.

By: Miro Samek

Miro Samek — Mon, 19 Apr 2010 23:01:24 +0000

Great comment. Thank you for pointing out that RTOS is too heavy for many low-end systems, mostly because an RTOS requires a separate *stack* (RAM) for each task. In contrast, event-driven approach can have really tiny footprint, especially in RAM, which makes it ideal for high-volume, cost-sensitive applications such as motor control, lighting control, capacitive touch sensing, remote access control, RFID, thermostats, small appliances, toys, power supplies, battery chargers, or just about any custom system on chip (SOC or ASIC) that contains a small CPU inside. Also, because the event-driven paradigm naturally uses the CPU only when handling events and otherwise can very easily switch the CPU and peripherals into a low-power sleep mode, the paradigm is particularly suitable for ultra-low power applications, such as wireless sensor networks and implantable medical devices.

So, yes tiny event-driven frameworks are a viable alternative to the venerable “superloop” in low-end systems. For example, the ultra-lightweight QP-nano framework with hierarchical state machines, event queues, timers, and cooperative or preemptive scheduler can run in as little as 128 bytes of RAM and a few KB of ROM (see the eZ430 example included in the QP-nano distribution available from Sourceforge.net).

I plan to dedicate at least one post to low-end systems and scalability of the modern event-driven programming techniques based on state machines.

By: Ram

Ram — Mon, 19 Apr 2010 06:17:48 +0000

Miro,
You would perhaps agree that one valid reason to use RTOSs or for that matter general purpose embedded OSs, with or without QP, would be the protocol stacks (TCP/IP, USB etc) they provide.
One suggestion for overcoming your writer’s block: the article about event drive programming and deadlocks that you promised in replying to my comment on the Barr Code blog entry on race conditions.

By: Eduardo Viramontes

Eduardo Viramontes — Mon, 19 Apr 2010 02:37:53 +0000

Being an 8 & 16-bit developer for the last 5 years, I’ve had little experience with RTOSes until recently (I’ve started playing around with MQX on the Coldfire platform). In the low-end world you always find code filled with loops expecting events to happen, worst of all, there’s no RTOS controlling the software flow, so the MCU does stay there. On the other hand, these devices don’t run as much functions and/or code as a 32-bitter running an RTOS, so programmers usually find it’s ok to keep those loops as long as the final application ends up working (barely), even if they are unable to add more functions later on. This is a similar paradigm as what you’ve explained happens in RTOSes. I’ve worked a lot with state-machine implementations and have a love-hate relation with them, they are great, they get the job done, and a good implementation will allow you to add more functions later on (as long as it isn’t a “super loop” approach). The downside is that they’re quite difficult to correctly implement, there are usually too many flags and/or state variables to keep track of and each implementation is unique, unless you are working at a really formal place where everybody is actually following some sort of architecture standard. Anyway, I’m looking forward to your coming posts, I’d really like it if you could talk about implementations of event-driven approaches in low-end MCU.