Control Methodology
You may think that after writing the state machine for flashing a few LEDs and a buzzer that control metholody is a simple task that doesn’t require further discussion. However, add in a multi-threaded operating system, asynchronous events, more objects to control and boom, suddenly control methodlogy is no simple topic.
Child Pages
Real Time Operating Systems (RTOS, multiple process)
Let’s not get confused here, RTOS’s still need state machine or other control methodologies, but they offer increased simplicity of these state machines and a powerful architecture to handle concurrent matters. Their principal function is to provide processes (or tasks), aka separate sections of code which can run concurrently (at the same time).
The central control code which handles the switching between tasks and memory allocation is called the kernel.
RTOS’s can either be co-operative or pre-emptive. With a co-operative RTOS you cannot guarantee a fixed time from when an event occurs and the process related to this event runs. This is because processes can only be executed when the kernel gets a return call from a previously called process, the kernel has no ability to stop the cpu half-way through a process to begin another. However, interrupts (in the physical/hardware sense), can still ‘interrupt’ the CPU (for example, in embedded systems, the ‘interrupting ability’ of ‘interrupts’ is built into hardware, and there is no way of stopping it…(well, at least without disabling it)).
However, you guessed it, preemptive RTOS’s can halt the current process to execute another, hence they are slightly more real-time than their co-operative counter-parts. Preemptive RTOS’s are more complex and memory intensive than co-operative ones. Most advanced RTOS’s these days are preemptive.
Examples
FreeRTOS (http://www.freertos.org/)
Currently officially supports 20+ architectures and is open-source and free to use in commercial applications without having to disclose your code. Huge support from its large user-base. Designed for embedded systems. Can be both co-operative or pre-emptive.
Micrium uC/OS-II
A (stolen straight from their marketing blurb) “Portable, ROMable, scalable, preemptive, real-time deterministic multitasking kernel for microporcessors, microcontrollers and DSPs”. Supports a number of architectures. The only problem with it is the price! At over US$5000 for a license, you have to have a good reason for buying it.
Frameworks
QL’s QP framework and the associated QM modelling tool are prevelent tools for developing event driven embedded applications. Based on my experience with QM, the program appears highly polished and is coupled tightly with the code. You can even build and upload code for the Arduino from within QM, so you never have to open the Arduino IDE!
Boost has a Meta State Machine (MSM) library. Probably unsuitable for embedded applications, due to the depedance on high-level containers and other Boost objects.
Other External Links
- The State Machine Framework - Qt Reference Documentation (https://doc.qt.io/archives/4.6/statemachine-api.html)
- State Machines - Basics of Computer Science (http://blog.markwshead.com/869/state-machines-computer-science/)