This article is very popular: Differences between CPU, SoC, and MCU

MCU (Microcontroller Unit) and SoC (System on a Chip) are two different types of embedded systems that typically run different types of operating systems, depending on their application scenarios and hardware resources.

1. MCU (Microcontroller Unit):

• Type: An MCU is a microcontroller that integrates a processor core, memory, peripherals, and other basic functions on a single chip.

• Application Scenarios: Commonly used in simple, real-time embedded systems, such as sensor control, embedded devices, etc.

• Operating System: In most cases, MCUs do not run traditional operating systems but use Real-Time Operating Systems (RTOS) or bare-metal programming. RTOS can provide real-time performance, lightweight task scheduling, and event handling.

• Type: An SoC is a complex chip that integrates a processor core, memory, peripherals, and possibly other processing units (such as GPU, DSP, etc.).

• Application Scenarios: Typically used in more complex, multi-purpose embedded systems, such as smartphones, embedded computers, embedded systems-on-a-chip, etc.

• Operating System: SoCs can run more complex operating systems, including Linux, Android, FreeRTOS, etc. The specific choice depends on application requirements and hardware resources. In some resource-limited cases, bare-metal programming or lightweight RTOS can also be chosen.

In general, MCUs are more inclined to use RTOS or bare-metal programming in scenarios with high real-time requirements and limited resources, while SoCs have greater flexibility and can run more complex operating systems, suitable for multi-purpose embedded applications. The choice of operating system is usually determined by specific application requirements and hardware resources.

1. Should MCU choose bare-metal or RTOS?

The choice between bare-metal (Bare-Metal) or RTOS (Real-Time Operating System) for MCUs depends on specific application needs and project requirements. Each choice has its advantages and applicable scenarios.

Bare-metal programming:

1. Resource Efficiency: Bare-metal programming is usually more lightweight, requiring no additional operating system overhead, making it more suitable for resource-limited embedded systems.

2. Real-Time Performance: For applications with extremely high real-time requirements, bare-metal programming can provide more precise control, as there is no additional task scheduling and interrupt latency.

3. Simple Structure: Bare-metal programming is relatively simple, without the complexity of an operating system, making it suitable for simple control applications, such as sensor control, timer applications, etc.

RTOS:

1. Multi-Tasking: If the application requires handling multiple tasks simultaneously, RTOS provides task scheduling and management mechanisms, simplifying concurrent processing of multiple tasks.

2. Abstraction Layer: RTOS provides an abstraction layer, simplifying developers’ operations on the underlying hardware and improving code portability.

3. Maintainability: RTOS can improve code maintainability, making it easier to understand and debug through task division and modular design.

4. Time Management: For applications requiring precise time management and processing, RTOS can provide more reliable time management and scheduling.

Considerations for Choosing:

1. Application Requirements: Determine the nature and needs of the application; if it is a simple, real-time control task, bare-metal programming may be sufficient. If multiple tasks or complex control logic need to be handled, RTOS may be more appropriate.

2. Resource Constraints: Consider hardware resource limitations; if the MCU has very limited resources, bare-metal programming may be more suitable. If there are sufficient resources and you wish to simplify the development process, RTOS may be a good choice.

3. Developer Experience: Developers’ experience with bare-metal programming or RTOS is also a consideration. For experienced developers, bare-metal programming may be easier to grasp; for complex projects, RTOS provides a higher level of abstraction, which may be easier to manage.

The final choice should be weighed based on specific project needs, developers’ skill levels, and hardware resources. In some projects, a combination of bare-metal programming and RTOS can also be used to choose the appropriate strategy based on specific task requirements.

Many recent graduates entering the workforce have a bit of fear of RTOS because they have always developed bare-metal in school. In fact, choosing a lightweight RTOS like FreeRTOS provides you with some “weapons” that can actually reduce the difficulty of developing complex functions.

2. Why do most SoCs choose Linux as the operating system?

There are several reasons why most SoCs choose Linux as their operating system, including some key factors:

1. Wide Support: Linux is an open-source operating system that has received widespread support and community participation globally. This allows most SoC vendors to easily provide Linux kernels and related drivers for their hardware.

2. Rich Software Ecosystem: Linux has a large and rich software ecosystem, including open-source tools, libraries, applications, etc. This allows developers to more easily access and utilize various existing software resources, accelerating the application development process.

3. Multi-User Support: Linux is a multi-user, multi-tasking operating system suitable for embedded application scenarios that require supporting multiple users running multiple tasks simultaneously. This is a very important feature for some complex SoCs, such as smartphones and embedded computers.

4. Strong Network Support: The Linux kernel supports a rich set of network protocols and features, suitable for embedded systems requiring network connectivity. This is crucial for applications that connect to the internet, perform remote management, and data transmission.

5. Open Source: The open-source model of Linux allows SoC manufacturers to customize and optimize it according to their needs. This openness helps adapt to various hardware architectures and meet different market demands.

6. Stability and Reliability: Linux has become very stable and reliable after long-term development and testing. This is essential for application scenarios that require high system stability.

7. Community Support and Updates: Linux has a large community support, with new kernel versions and patches released regularly, meaning SoC manufacturers and developers can access the latest features, security, and performance optimizations.

Considering these factors, Linux has become the operating system of choice for many SoCs, especially in scenarios where complex tasks need to be handled, with a rich software and hardware ecosystem, requiring network connectivity and multi-user support. However, there are also some resource-limited or real-time demanding application scenarios that may choose other operating systems, including Android or RTOS.

Some chips are mainly targeted at peripherals for Linux systems and do not consider peripherals for MCUs. For example, some Qualcomm Wi-Fi chips only support Linux driver porting. Therefore, without support from the chip manufacturer, it is impossible to use it in non-Linux scenarios.

3. About RT-Linux

RT-Linux is a real-time operating system (RTOS) based on the Linux kernel, which modifies and extends the Linux kernel to provide real-time performance. The goal of RT-Linux is to maintain the generality and power of Linux while providing support for real-time tasks, making it usable in applications requiring high real-time performance.

Here are some main features and introductions to RT-Linux:

1. Real-Time Performance: RT-Linux aims to provide predictable and controllable real-time performance. By introducing real-time schedulers and interrupt handling mechanisms, it can ensure that tasks are executed within specified times to meet the needs of real-time systems.

2. Linux Kernel Extension: RT-Linux is an extension and modification of the Linux kernel. It retains the generality and rich functionality of Linux while adding real-time task schedulers, hard real-time interrupts, and other real-time features.

3. Real-Time Scheduler: RT-Linux introduces a real-time scheduler that allows tasks to be scheduled based on priority and deadlines. This helps ensure that real-time tasks are executed on time without interference from non-real-time tasks.

4. Hard Real-Time Interrupts: RT-Linux provides a hard real-time interrupt mechanism to ensure that for some time-sensitive tasks, responses can be made with very low latency.

5. POSIX Compatibility: RT-Linux maintains compatibility with the POSIX standard, making it more compatible with many existing real-time applications and development tools.

6. Open Source: RT-Linux is open-source software released under the GPL license. This allows developers to freely access, modify, and distribute the source code.

7. Applicable Scope: RT-Linux is suitable for applications requiring both Linux generality and real-time performance, such as industrial control systems, embedded control systems, communication systems, etc.

RT-Linux has several main versions, some of which are well-known:

1. RTLinux/GPL: The earliest version of RT-Linux, developed by RTLinux Corporation (now Wind River Systems). RTLinux/GPL is a real-time extension module that achieves hard real-time performance by inserting a real-time scheduler into the Linux kernel.

2. RTLinuxFree: An open-source version of RT-Linux/GPL, aimed at providing real-time extensions to the Linux kernel to enhance its usability in real-time embedded applications.

3. RTAI (Real-Time Application Interface): RTAI is an independent real-time extension that provides real-time support for the Linux kernel. RTAI has similar goals to RTLinux but with slightly different implementation methods and architectures.

4. Xenomai: Xenomai is a real-time framework that provides hard real-time performance by running a real-time kernel (Cobalt) on top of the Linux system. Xenomai differs from RTLinux in that it does not use a kernel plugin approach but runs real-time tasks in user space.

5. PREEMPT-RT: PREEMPT-RT is not a specific version of RT-Linux but a real-time extension added to the Linux kernel to enhance its preemptiveness. It modifies the Linux kernel to introduce more preemptiveness to improve its real-time performance.

These versions each have different designs and implementations, and developers should determine the most suitable version based on project needs, hardware platforms, and personal experience. The field of real-time Linux solutions is still evolving, and developers can choose appropriate solutions based on specific project circumstances.

4. Why is bare-metal programming also called front-end and back-end?

Bare-metal systems are typically divided into polling systems and front-end and back-end systems.

Polling System

The polling system refers to the process of initializing relevant hardware during bare-metal programming and then having the main program continuously loop in a dead loop to sequentially perform various tasks. The pseudocode for the polling system is shown in the code block below. The polling system is a very simple software structure, usually suitable for tasks that only need to execute code sequentially without requiring external events to drive the completion. In the code listing, if only LED flipping, serial output, LCD display, etc., are implemented, then using a polling system will be very perfect. However, if key operations that require detecting external signals are added, such as simulating an emergency alarm, then the system’s real-time response capability will not be as good.

Front-End and Back-End System

Compared to the polling system, the front-end and back-end system adds interrupts based on the polling system. External event responses are completed in interrupts, while event handling returns to the polling system. In this context, we refer to interrupts as the front-end, while the infinite loop in the main function is referred to as the back-end.

When executing the back-end program sequentially, if an interrupt occurs, the interrupt will interrupt the normal execution flow of the back-end program and switch to execute the interrupt service program, marking the event in the interrupt service program. If the event to be handled is very brief, it can be processed in the interrupt service program; if the event requires handling more tasks, it will return to the back-end program for processing. Although the response and handling of events are separated, the handling of events is still executed sequentially in the back-end program. However, compared to the polling system, the front-end and back-end system ensures that events are not lost, and with the ability to nest interrupts, this can greatly improve the program’s real-time response capability. In most small projects, the front-end and back-end system is well utilized.

Supplementing a question asked by a non-IT professional friend after the last article was published:

5. Is MCU the same as a microcontroller?

MCU (Microcontroller Unit) typically refers to a microcontroller unit, while a microcontroller is usually referred to as a single-chip microcontroller. These two terms are often used interchangeably in the field of embedded systems.

A microcontroller (Microcontroller) is a chip that integrates a processor core (CPU), memory (RAM, Flash, etc.), input/output interfaces (I/O), timers, counters, communication interfaces, and other functional modules. Microcontrollers are typically designed to control various tasks in embedded systems, such as sensor control, data acquisition, and executing specific control algorithms.

MCU (Microcontroller Unit) is a broader term that refers to the entire microcontroller system containing a processor core, memory, and peripherals. In practical use, the distinction between these two terms is not very strict and is often used interchangeably, while the term microcontroller is more commonly used to refer to microcontrollers in embedded systems.

Prior reading:

Differences between CPU, SoC, and MCU

Domestic SoC manufacturers

Which MCU is strong after a wave of acquisitions?