In a previous
newsletter
we discussed some practical differences between embedded general purpose operating systems (GPOS) and real time operating systems (RTOS). In this article we consider the trade off between bare metal programming and using an operating system in embedded designs.
Consider the spectrum of embedded device applications, for example, from recordable greeting cards to data acquisitions systems on instrumentation satellites. These applications vary greatly in complexity and therefore require very different design choices. Somewhere along this spectrum of complexity lies a threshold wherein implementing an OS would be overkill given the business requirements of the system, and may increase overall system cost if additional hardware resources were designed in to accommodate the additional memory requirements. Conversely, rolling a bare metal system for a satellite controller may be an unnecessarily monumental task considering the availability of embedded operating system kernels to reliably handle and compartmentalize the minutiae of the system.
Hardware resource availability in the aforementioned examples plays a large part in this decision making process, as do the number of software tasks, peripherals, and interrupt sources. It is difficult to define where this threshold lies and is further complicated by the bias of skill, experience, and habit of the designer. That said, embedded operating systems such as the various flavors of embedded Linux, RTOS, and others feature stacks which may be worth implementing on even small scale projects.
Small projects implementing networking, flash read/writes, and/or USB features may benefit from the software stacks that are typically included in embedded operating systems. Also, many feature low level driver abstraction, allowing the designer to focus more time on application details rather than driving peripherals. In many cases adopting such operating systems, even for small applications, allows for greater value to be derived from a given project by reducing overall development time.
For example, consider the design for a cloud connected door lock. This system would require an Ethernet or LTE driver to make requests to the server, a file system to track users, and some security layers to prevent unauthorized access. The initial proof-of-concept version of this device would benefit greatly from an embedded OS solution. Going the OS route in the initial design would substantially lower engineering design costs and speed up the development time as designers are free to focus on business logic rather than taking time to develop the driver level logic. Further, the production version of this system would also benefit from using an operating system. Incorporating operating systems that are backed by years of development grants substantial reliability when compared to drivers written on a per-project basis. This is especially crucial in the context of security as an attacker would likely find it much more difficult to gain access to a system running a mature OS. The trade off is an increase in unit price of these devices due to the additional hardware requirements, such as faster processors and/or greater memory and power requirements.
These additional hardware costs are not always justified. Consider a system which blinks an LED. In the simplest case, this can be implemented in a handful of lines in C. One only needs to register the peripheral/GPIO, register a timer, and implement a while(1) loop which toggles the peripheral as a function of the time. In a production context, implementing this design on hardware capable of supporting an OS would be very expensive compared to the alternative such as an 8-bit PIC. While the former is priced in the range of dollars, the latter is priced in cents.
Designers may benefit from using an embedded OS in designs which require certification. Since some applications require deterministic timing, using an off-the-shelf solution with a safety certified scheduler and years of development behind it may be a much better option than attempting to develop one’s own one-off counterpart and then having to certify it. Though safety critical systems will still be subject to the certification process, some RTOS’ include pre-certification documentation which aid in this process.
Embedded operating systems can provide a wide range of value, from lowering design overhead, to helping with safety certification, to historical reliability. Though not appropriate for all designs, the future of embedded development is sure to feature more operating system based designs as hardware resource costs continue to shrink and embedded applications become increasingly sophisticated.
-SD
