Common Software Architectures in Embedded Development

Microcontroller programs are familiar to everyone, but few truly consider architecture. As program development continues to increase, architecture becomes essential.

1. Time-Slice Polling Method

A program architecture design scheme that lies between sequential execution methods and operating systems. This design scheme should help embedded software developers reach a new level. If the following points are encountered during embedded software development, this design scheme can be considered the optimal choice for relatively complex embedded systems:

Currently, the design requirements do not necessitate an operating system.

Task functions do not need to be executed at all times; there are intervals (for example, buttons generally require software debouncing. Beginners usually delay for about 10ms before judgment, but this greatly wastes CPU resources. During this time, the CPU can handle many other tasks).

Real-time requirements exist.

This design scheme requires the use of a timer, generally set to 1ms (the timing can be arbitrary, but too frequent interrupts decrease efficiency, while long interrupts lead to poor real-time performance). Therefore, each task function’s execution time must be considered, and it is recommended that it does not exceed 1ms (if execution time can be optimized, it is best to do so; if not, the task’s execution cycle must be much greater than the time consumed by the task). Additionally, there should be no millisecond-level delays in the main loop or task functions.

Next, two different implementation schemes will be introduced, targeting both those unfamiliar with function pointers and those who wish to learn more.

1. Design Method without Function Pointers

2. Design Method with Function Pointers

2. Operating Systems

The embedded operating system EOS (Embedded Operating System) is a widely used system software that was primarily applied in industrial control and defense systems in the past. For microcontrollers, common options include UCOS, FreeRTOS, RT-Thread Nano, and RTX, among various preemptive operating systems (other operating systems like Linux are not suitable for microcontrollers).

Compared to the time-slice polling method, operating systems do not impose strict time requirements for each task execution. Task priorities can be set, and when a high-priority task is ready, it can preempt a low-priority task. Operating systems are relatively complex, so they are not detailed here.

Regarding how to choose a suitable operating system (comparative characteristics of RTOSs like uCOS, FreeRTOS, RTThread, RTX):

• uCOS: Rich online resources, very suitable for learning, but requires payment for product use.

• FreeRTOS: Free to use, hence widely adopted in many products.

• RT-Thread: A domestic IoT operating system with a wealth of components, also free. Documentation available at RT-Thread documentation center.

• RTX: A royalty-free, deterministic real-time operating system designed for ARM and Cortex-M devices.

Here is a comparative image from the internet:

3. Front-Back Sequential Execution Method

This is a common program framework design scheme for beginners. It does not require too much consideration, the code is simple, or the overall real-time and concurrency requirements of the system are not high. After initialization, it continuously calls self-written functions through a while(1){} or for(;;){} loop, without much consideration of the execution time of each function. In most cases, there are some millisecond-level delays in the functions.

Advantages: For beginners, this is the easiest and most intuitive program architecture, with simple and clear logic, suitable for simple logic and relatively low complexity software development.

Disadvantages: Low real-time performance. Due to the millisecond-level delays present in each function, even a 1ms delay can cause different execution intervals between functions. Although it can be mitigated by using timer interrupts, the prerequisite is that the time taken by the interrupt execution function must be short. As the complexity of the program logic increases, it can lead to confusion for later maintainers, making it difficult to clarify the program’s operational state.