Software Development Strategy Pros. and Cons.

Many embedded systems are so simple, or the tasks so few, that they do not require scheduling. On-board peripherals can solve any real-time or scheduling requirements, and, e.g., timers can be used to blink LEDs. External interrupts can react to button inputs. Few external signals are monitored, and few actions are necessary to achieve the expected behavior. In these systems, a full-blown RTOS scheduler would be overkill and will overcomplicate the software. In addition, the total software size will probably be so small that the implementation is easy to follow. There is little to no benefit in splitting the application into several executable tasks. Code reuse in this scenario is probably kept on a driver level.

In slightly more advanced applications, global flags and state machines in combination with hardware interrupts can be used to control the application flow. Tasks become more flexible, and it should be possible to re-use tasks between applications. However, the total system needs to take all tasks into account, as the run-time of single tasks greatly affects the overall system performance. Depending on the complexity of the application and the number of hardware interrupts available in the selected MCU, this might still be the preferred solution for many developers. This implementation is straightforward and can be tailored to fit the exact application need, and in that way, be very code size effective.

A homebrewed multitasking system is a big development effort. Once developed, the solution should be used for several projects to justify the development cost. In-depth knowledge of the CPU, registers, and RAM architecture is needed to develop the system. The system must be ported and developed for all the intended devices and platforms. Also, extensive testing and verification are needed as it is difficult to develop this functionality without the scheduler constantly manipulating critical CPU registers. The benefit is that the system can be tailored to fit the exact application need, which, in turn, means that code size and code overhead should be at a minimum.

A commercially available (RT)OS requires the developer to be comfortable using large software stacks. There is some cost involved for the developer to learn the selected (RT)OS, but once learned, the (RT)OS can be re-used across projects, applications, and often platforms. The drawback with a commercially available (RT)OS is that the system is developed to be as general as possible to work on many different applications and platforms. For the developer, this means that some software overhead will be present in the final application. Most (RT)OS implementations try to counter this by offering as much configurability as possible. The biggest learning effort for the developer is often configuring the (RT)OS correctly. A big benefit is that the (RT)OS is tested and verified over several devices, architectures, and platforms.