Introduction

In today's consumer market, products tend to do more and consumers generally expect more. Washing machines report remaining time in a smartphone app. Smoke detectors do not just blink and beep - they communicate with other smoke detectors to locate the fire, alert emergency personnel, and inform the consumer about the location of the fire through voice messages. Many embedded applications, previously relying on a button and an LED, now report their status and get their input over different channels. Features that are perceived as simple, and often commoditized, put a high demand on the underlying software and hardware. According to the AspenCore EE|Times/embedded.com 2017 Embedded Markets Study, 19% think that managing increases in code size and complexity is their greatest technology challenge next year (2018), closely followed by integrating new technology or tools, 18%, and security concerns, 17%.

In conventional simple embedded systems, software is developed as linear code, with real-time requirements taken care of by dedicated on-board hardware, or as peripherals on a microcontroller (MCU). The moment all the peripherals, PCB real-estate, or budget is exhausted, the developer is forced to embed the real-time tasks inside a linear code, and fine-tune the system to get the expected behavior. Code re-usability is drastically reduced, and small changes in external hardware or application requirements make a big impact on software development and application testing.

A solution to this problem is to move to some sort of scheduling system as shown in Figure 1, allowing tasks to be assigned to a queue, prioritized, and run when needed. The AspenCore EE|Times/embedded.com 2017 Embedded Markets Study shows that 67% of all embedded projects run on an operating system, RTOS, kernel, software executive, scheduler, or similar. Of these, Embedded Linux is the biggest with 22%, closely followed by FreeRTOS at 20%, and in-house/custom at 19%.