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
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.