In part 1, we have introduced the topics that are covered as part of this column series - “Smart World of IoT.” As mentioned in part 1, most IoT nodes are a combination of sensors, computing, and connectivity, with the latter two playing very important roles. In part 2, we discussed the connectivity part of IoT - “There Are No Wires on Me.”  In part 3, we covered more details on evolution of computing architectures along with radio. In this part, we will be exploring software considerations of various CPU architectures for building embedded solutions.

Sensing, organizing, analyzing, presenting, and decision-making on information requires software. We have been using various platforms to perform this at varying levels of capabilities for decades. Now that we have extremely small devices running from single-cell batteries with the power of 80486-based personal computers from the late 1990s, the next question is obvious – the software. With bare-metal, real-time operating systems (RTOS), and true operating systems like Linux to choose from, we’ll run into the similar problems explored in Radio and the Computer, but from a software point of view.

Starting with a scalable software architecture is must for any embedded application. Thought must be given to the possible future enhancements software that might be called up to provide before finalizing the programming architecture for your embedded application. Many engineers consider this as an afterthought because they are used to writing code on top of operating systems.

Another important consideration is cost. As system capabilities increase, so does the need for faster processors, more code memory, and RAM. Figure 1 below shows a typical feature Vs cost diagram for an embedded system, although lines between different tiers are blurred when it comes to possible hardware choices:

Bare-metal programming is preferred in situations where:

• The application is simple and implemented on low-end processors.
• The application needs to extract every cycle of CPU power and the overhead introduced by an OS is unacceptable.
• Security and safety are closely tied to hardware where the system is performing and functioning as per exact expectations and the system is continuously behaving like this all the time.
• There are constraints to hardware cost and a need for excellent efficiency.

Many embedded applications are infinite loops wherein they perform one task, then another task, and so on, repeating the same functionality. Most of these tasks are dependent upon each other. Bare-metal programming is not ideal for such situations as the code should be predictable, understandable, and should be easy to debug. Having a scheduler makes the life of an embedded engineer more simple - each software module can be designed independently, then linked and scheduled with the others using the help of a scheduler. Therefore, an RTOS is preferred as code complexity increases and the system requires a powerful microprocessor/microcontroller. An RTOS becomes a necessity when MCUs integrate more memory and peripherals. A complex IoT application may require more interrupt sources, more functions, and more standard communications interfaces - mainly wireless. An RTOS will likely be needed in such complex solutions.

An RTOS can make full use of feature-rich MCUs, especially when provided with middleware that can handle complex tasks that otherwise would require a true OS. However, there are many non-overlapping areas of complexity and capability when it comes to software. An RTOS with added middleware can approach the capabilities of general-purpose operating systems. For example, middleware can add features such as filesystems, networking, graphics, and complex input support albeit with added development efforts compared to a true OS that supports these features natively. Some RTOSes even support POSIX APIs that can somewhat re-use code from Linux/Unix applications.

When application complexity increases beyond a certain limit, however, a general-purpose embedded operating system comes into picture. This is when processors say, “give me an MMU and I can solve all your problems.” Due to their code size and primary memory requirements, expensive SRAM and NOR memories become impractical. Most embedded versions of general-purpose operating systems require at least 16-32 MB of primary memory and 64+MB of code storage to run properly. Fortunately, application processors and general-purpose operating systems are capable of dealing with cheaper, slower memories such as DRAMs and NAND flash.

You won’t lose “real time capabilities” when you move to an embedded general-purpose OS. They’re capable of running real-time applications, at slightly higher latency levels, with varying levels of determinism (“soft real-time”). But most applications do not require “hard real-time” features. A well validated application running on an embedded OS can be as bulletproof and deterministic as a similar application running on RTOS with the help of middleware.

With application processors and memory reducing in cost every year thanks to the continued silicon scaling and the abundance of engineers who are more comfortable with a proper OS, many applications that would otherwise use an RTOS are now finding the application processor + proper OS combination cost effective and yielding shorter time-to-market as well.

In the next column, we’ll focus on integration – cramming more features into your embedded system without necessarily increasing the number of ICs on your board. Stay tuned!

Jaya Kathuria Bindra works as an Applications Manager at Cypress Semiconductor Corporation where she is managing the Embedded Applications Group and Solutions Development using the PSoC platform. She has 14+ years of experience in the Semiconductor Industry. She earned an executive management credential from IIM, Bangalore and holds a BS in Electronics Engineering from the Kurukshetra University. Jaya can be reached at [email protected].    

Nidhin MS works as a Staff Applications Engineer at Cypress Semiconductor Corporation. He has seven years of technical experience with analog, power electronics, touch sensing, embedded computing and connectivity and holds a bachelor’s degree in Electronics and Communication Engineering.