Event or polled based embedded MCU system architecture?

Question

I have prior experience in writing both event and poll based embedded systems (for tiny MCU's with no preemptive OS).

In an event based system, tasks usually receives events (messages) on a queue and handles them in turn.

In a polled based system, tasks polls status with a certain interval and responds to change.

Which architecture do you prefer? Can both co-exist?

UPDATE: POINTS MADE

POLL BASED
- Tight coupling related to timing aspects (@Lundin)
* Can co-exist alongside event system using queues (@embedded.kyle)
* Fine for smaller programs (@Lundin)

EVENT BASED
+ More flexible system in the long run (@embedded.kyle)
- RTOS edition adds complexity (@Lundin)
* Small programs = state-machine controlled (@Lundin)
* Can be implemented using queues and a "super-loop" (inside controller/main) (@embedded.kyle)
* Only true "events" are hw interrupts ones (@Lundin)

RELATED QUESTIONS
* Looking for a comparison of different scheduling algorithms for a Finite State Machine (@embedded.kyle)

RELATED INFO
* "Prefer Using Active Objects Instead of Naked Threads" (@Miro)
http://www.drdobbs.com/parallel/prefer-using-active-objects-instead-of-n/225700095
* "Use Threads Correctly = Isolation + Asynchronous Messages" (@Miro) http://www.drdobbs.com/parallel/use-threads-correctly-isolation-asynch/215900465

Answer 1

Actually, event-driven programming and threads can be combined and the resulting pattern is widely known as "active objects" or "actors".

Active objects (actors) are encapsulated, event-driven state machines, which communicate with one another asynchronously by posting events to each other. Active objects process all events in their own thread of execution (at least conceptually, if a cooperative scheduler is used), so they avoid by design most concurrency hazards.

Actors and active objects are all the rage (again) in the general-purpose computing (you can search for Erlang, Scala, Akka). Herb Sutter has written a couple of good articles that explain the "active object" pattern: "Prefer Using Active Objects Instead of Naked Threads" (http://www.drdobbs.com/parallel/prefer-using-active-objects-instead-of-n/225700095) and "Use Threads Correctly = Isolation + Asynchronous Messages" (http://www.drdobbs.com/parallel/use-threads-correctly-isolation-asynch/215900465)

Here is what Herb says in the first of these articles:

"Using raw threads directly is trouble for a number of reasons ... Active objects dramatically improve our ability to reason about our thread's code and operation by giving us higher-level abstractions and idioms that raise the semantic level of our program and let us express our intent more directly. As with all good patterns, we also get better vocabulary to talk about our design. Note that active objects aren't a novelty: UML and various libraries have provided support for active classes"

So, all this is really not new. But what's perhaps less known, especially in the embedded systems community, is that active objects are not only fully applicable to the embedded systems, but they are actually a perfect match for embedded and they are lighter than a traditional RTOS.

I've been using the event-driven active objects for over a decade now and have created the QP family of active object frameworks for embedded systems (see http://www.state-machine.com/). I would never go back to the polling "superloop" or the raw RTOS.

Answer 2

There is really no such thing as "event-driven" on a bare bone MCU platform, despite what the buzzword-spitters are trying to tell you. The only kind of true events you can receive are hardware interrupts.

Depending on the nature of the application and its real time requirements, interrupts may or may not be suitable. Generally, it is far easier to achieve deterministic real time with a polling system. However, systems relying solely on polling are very hard to maintain, because you get tight coupling between all timing aspects.

Suppose you try to start up a LCD, which is slow. Instead of polling some timer repeatedly while burning CPU cycles in an empty loop, you would perhaps decide to receive some data over a bus in the meantime. And then you want to print the data received on the LCD. Such a design has created a tight coupling between the LCD startup time and the serial bus, and another tight coupling between the serial bus and the printing of data. From an object-oriented point-of-view these things are not related to each other at all. If you were to speed up the serial bus at some point in the future, then suddenly you could encounter LCD printing bugs, because it has not finished starting up when you try to print on it.

In a small program, it is perfectly fine to use polling like in the above example. But if the program has potential of growing, polling will make it very complex and the tight coupling will ultimately lead to many strange and fatal bugs.

On the other hand, multi-threading and RTOS adds quite a lot of extra complexity which in turn can lead to bugs as well. Where to draw the line isn't simple to determine.

Out of personal experience I'd say that any program smaller than 20-30k LOC will not benefit from scheduling and multitasking, beyond simple state machines. If the program gets larger than that, I'd consider a multitasking RTOS.

Also, low-end MCUs (8- and 16-bitters) are far from suitable to run an OS. If you find that you need an OS to handle complexity on a 8- or 16-bit platform, you probably picked the wrong MCU to begin with. I'd be sceptical against any attempts to introduce an OS on anything smaller than a 32-bitter.

Answer 3

I prefer whichever architecture is best suited to the application at hand.

Both can co-exist in a multilevel queue architecture. One queue works on a poll basis running in the main loop. While another, most likely tasked with higher priority events, works by using interrupt based preemption.

See my answer to this SO question for a more detailed explanation and comparison of the different scheduling algorithms.