Requirements for embedded systems are getting more and more complex over time.

Today, many embedded systems are reaching the complexity and level of features of a PC or a smartphone. But, at the same time, they should keep the high level of reliability and performance of their “ancestors.”

For end users, it may be acceptable to have an app crashing on their phone or tablet. However, it is not acceptable that a software issue prevents them from using their heating system, or does not allow them to pay for parking or to control an industrial machine.

Features like connectivity and user interfaces need complex software architectures and compliance to standards. Using an operating system is often the best way to implement these kind of features.

On the other side, a full-featured operating system may increase the complexity of hardware access, interrupt handling and other critical tasks, or may not meet the latencies expected to complete them.

For those tasks, small real-time operating systems (RTOSs) or bare-metal firmware have been the simplest and most reliable solution, giving developers full control of the hardware.

To solve those issues, in many embedded system designs, a microcontroller takes care of the most critical parts of the system and communicates with an application processor that provides user interface and connectivity features. Those processors are usually connected using a serial link and additional lines used to generate interrupts.

This approach is quite common in today’s embedded systems, but it has some drawbacks that many developers might have already discovered during their working experience.

The two CPUs must communicate and this requires extra hardware resources on both processors. Managing a communication channel adds complexity and synchronization issues that impact the development time and reliability of the firmware. Sharing large amounts of data will require additional effort, splitting the information in “chunks” that fit the limited amount of RAM that is usually available on microcontrollers.

Some new system-on-chips (SoCs) can provide a different solution for these kind of problems: asymmetrical multicore architecture.

Today, most servers, personal computers, tablets, and even smartphones leverage multicore technologies to provide better performances and a more responsive user interfaces. It is most likely that you are reading this using a multicore device, even when you are reading it on your smartphone!

Symmetrical multicore processors usually leverage a high-level OS that can split many tasks on the different cores. Multiple tasks will run at the same time and share data in RAM. This provides more processing power for end-user applications and system tasks.

Asymmetrical multicore SoCs take a different approach. The chips contains multiple cores having different architectures. This makes moving tasks from one core to the other quite complex, if not impossible, but, on the other hand, may provide to developers the right cores to run both high-level OS and RTOS/firmware inside the same chip.

What are the advantages of this approach compared to the “traditional” one of using microcontrollers and application processors on the same board? What are the tools and features that developers can leverage to implement reliable and full-featured embedded systems?

An example of this approach is Freescale’s Vybrid processor. The VF6xx include a Cortex A5 core, suitable to run Linux or other high-level operating systems and a Cortex-M4 core, suitable for RTOSs or bare-metal firmware. There are other SoCs that use the same approach and provide multiple Cortex-A and Cortex-M/R/ARM7 cores or Cortex-A and DSPs inside the same package.

In the Vybrid, both cores share access to internal and external RAM (the M4 is limited to 256 MB) and to all the integrated peripheral devices.

This approach provides more flexibility compared to separate processors. Hardware resources can be controlled from one core or the other just by changing software. This makes hardware designs simpler and more flexible, not requiring modifications of the hardware if developers discover that latencies or other reasons force them to move control of a device from the application processor to the microcontroller or vice versa. And this makes designs more re-usable, allowing usage of this kind of SoCs on computer-on-modules (COMs).

Shared access to RAM makes exchanging large amounts of data quite simple, the only care required is that data is allocated in contiguous physical memory addresses because the M4 core has no MMU. Usually the application processor will use virtual addresses to access the same memory that the RTOS/firmware references using its physical address.

If a core needs to report an event to the other, it can simply generate an interrupt on it. There is no faster way to get a CPU’s attention than this and it does not requires the extra GPIO pins required by an external processor.

Obviously, when multiple CPUs need to share memory, you will need to synchronize access to it and the Vybrid provides hardware semaphores to do that. A core can try to acquire a semaphore and if it’s not free it can wait for an interrupt as soon as it’s available. This can make synchronization between two different schedulers much more manageable, even if the number of semaphores is limited.

However, there are also some disadvantages using the asynchronous approach: In the Vybrid there is no way to limit access to a specific peripheral device or memory range to just one of the cores, this will require some care in ensuring that concurrent access from the two cores does not happen by mistake. New generation cores may provide better security mechanism to prevent unexpected behaviours generated by the other core accessing the wrong addresses.

Separate processors may provide more choice in terms of integrated peripherals and it may be hard to certify software running on a core inside the same chip than code running on an external processor. Those issues may keep the “traditional” approach more suitable for some designs, but the advantages of integration could be great in many scenarios.

In our next article, we will look more deeply in the Vybrid’s architecture and provide some usage samples showing how Linux can cooperate with an RTOS or bare-metal firmware.

Valter Minute is Embedded Software Engineer at Toradex.