Using a RTOS in multicore-based MCU designs

A real-time operating system provides a framework for

multicore that can dramatically reduce time to market

BY JEAN J. LABROSSE
Founder, President, and CEO
Micrium
www.micrium.com

Recently introduced multicore-based MCUs have raised the complexity level of embedded system designs. The use of an RTOS, however, provides a framework for multicore that can dramatically reduce time to market.

RTOS fundamentals

A real-time kernel is software that manages the time of a CPU and ensures that critical tasks are processed in a timely manner. The term “real-time operating system” (RTOS) is often confused with real-time kernels; a kernel is actually a subset of an RTOS. An RTOS thus consists of a kernel and possibly such additional services as a file system (FS), a TCP/IP-stack, USB stacks (device and/or host), a graphical user interface (GUI), CANbus, and possibly other components.

A full-featured RTOS is generally not necessary for most embedded systems and in fact, it’s quite possible to design a product using a subset of the services available from an RTOS. For example, a digital SLR camera might only use a kernel, an FS, a GUI, and a USB device stack.

Most 32-bit embedded designs would benefit from the use of a real-time kernel, given that a kernel offers a framework to build upon as well as the ability to split application code into smaller, more manageable chunks. The framework includes many useful services for the application programmer such as multitasking; interrupt management, intertask communication and signaling, resource management, time management, memory partition management, and more. Most kernels used for embedded systems are “preemptive,” meaning that the kernel always executes the most important task that is ready to run. Preemptive kernels are also event driven, which basically means that tasks are designed to wait for events to occur in order to execute. For example, a task could wait for a timer to expire and another task can wait for a packet to be received on an Ethernet controller, or another for a character to be received on a UART.

Many embedded programmers shy away from using a kernel because they fear that kernels add too much complexity to their application. It turns out that you only need a handful of services to get your project off the ground with a kernel. It is possible to write fairly complex multitasking application with the use of only five API functions out of the nearly 70 API calls offered by µC/OS-III, for example. You can thus build your kernel knowledge as you are bringing your application up.

Multicore in MCUs

Microcontrollers have traditionally been equipped with single cores. However, using NXP Semiconductors’ LPC4300 series as an example, there are Cortex-M4 and Cortex-M0 cores besides a full complement of peripherals including an Ethernet controller, dual USB 2.0, quad UART, LCD controller, motor control PWM, timers, CAN 2.0, dual I2 C, 10-bit ADC, 10-bit DAC, AES decryption, and an Inter Processor Communication (IPC).

This dual-core configuration is called asymmetrical multiprocessing (AMP) since the cores are not identical. AMP is generally the preferred architecture when designing embedded systems, given the dedicated nature of such systems. Thus, unlike general-purpose computers that are used for different applications at different times, embedded systems generally have known functions at design time.

Performance is the first thing one thinks about when considering the use of a multicore device, but, just as important especially for battery-operated embedded systems, multiple cores allow you to run your product slower and thus reduce the power consumption with basically the same performance as a single-core system running at a much higher frequency.

For the LPC4300, the Cortex-M0 is designed as a slave to the Cortex-M4. The Cortex–M0 core, used as an I/O controller, offloads I/O and interrupts from the Cortex-M4, which can be used, unbothered, to perform control algorithms (PID loops, state machines, etc.) and computationally intensive operations (audio compression/decompression, image processing, filtering, encryption, etc.). Figure 1 shows the relationship between the Cortex-M4 and the Cortex-M0 in the LPC4300 for a possible industrial control system.

Fig. 1: Industrial controller running on an NXP LPC4300.

NXP provides code for the IPC but this does not preclude the use of other IPCs such as the one defined by the Multicore Association called Multicore Communication Application Programming Interface (MCAPI).

MCAPI provides a lightweight and efficient communication stack. Communication is performed using channels and a channel can be used to send scalars or packets. The transport mechanism for MCAPI is flexible and can be shared memory, I/O ports, or other on-board devices.

MCAPI, as well as tools to configure and optimize multicore applications, is available from third parties such as Polycore Software. Scalable to any number of cores, it should be considered when migrating applications to different CPU architectures using a standard API instead of being locked into a vendor-specific one.

Multicore and RTOSs

Having multiple cores doesn’t render obsolete the need for an RTOS kernel as shown in Fig. 1. A kernel is still highly desirable to make optimum use of both cores. In fact, in the above example, both cores run their own instance of the same or possibly different kernels to manage the multiple tasks.

Debugging a multiple-core system is certainly more complicated than a single-core system, but if you keep a clean separation of functionality between cores then each can be debugged in isolation and possibly by different development teams. One team could work on the Cortex-M4 code and another on the I/O devices and then get together to integrate both pieces. Obviously, each team would have its own evaluating board so it could develop and test software separately prior to merging both pieces.

A kernel such as µC/OS-III allows a designer to determine CPU use on a per-task basis and thus better optimize the design by load balancing the tasks between cores. This load balancing would typically be done at design time as opposed to run time. In other words, having an RTOS kernel makes it easier to move functionality between cores.

Ideally, both cores would be identical since that would allow both teams to use the exact same tools and kernel port. This would make development slightly easier since you would not have to deal with the slightly different cores. It’s quite possible that NXP and/or other semiconductor manufacturers will be introducing such devices in a not so far future. Also, it’s quite unlikely that these devices will be limited to only two cores. AMP is very scalable and in the coming years, we should see MCUs with many cores showing up on the market.

Multicore-based MCUs increase the complexity of embedded system designs but offers the benefit of increased performance as well as lower power consumption. Each core should use an RTOS to make better use of the CPU and its associated resources and functions. Intercore communication should be kept to a minimum to avoid interdependencies. ■

About the author

Jean Labrosse is the founder, president, and CEO of Micrium and the creator of the µC/OS-III family of products. He has published several books including µC/OS-III, The Real-Time Kernel, available as a free PDF download at www.micrium.com.