Real-time systems based on bare metal programming

introduction

In the design of embedded control systems, how to effectively coordinate multiple tasks to make their action sequence reasonable and their response speed fast is often a very important aspect that designers consider, and it is also an important indicator to measure and test the comprehensive performance of a system. In order to meet the real-time requirements in the coordinated control of multiple tasks, designers often consider embedding a popular real-time operating system in the system. There are also some verified and excellent real-time operating systems to choose from. Some source codes are even provided free of charge. There are also a large number of successful source code examples on the Internet. Programming based on real-time operating systems can greatly shorten the development cycle, and real-time performance is also sufficiently guaranteed. One of the costs of programming based on real-time operating systems is that the length of the program code is increased; the second cost is that more RAM space is required. Without expanding the off-chip memory, low- and medium-end microcontrollers are difficult to handle. On the other hand, most low- and medium-end application systems can also guarantee a certain degree of real-time performance through reasonable design and the use of bare metal programming (without real-time operating system) methods to meet the requirements of real-time control. This is what this article will introduce.

1 System Design Principles

1.1 Ensure real-time performance by designing timed interrupt intervals

In order to meet the real-time response requirements of multiple tasks in the control system, timer interrupts can be used as the system clock. The interval of each interrupt is the minimum basic unit of the clock, and this value must be less than or equal to the maximum allowable response time of the most time-critical task among the controlled tasks. The shorter the timer interval, the faster the response, but the heavier the burden on the system CPU (because the CPU sleeps less and less). This is a pair of contradictory things, and the designer needs to coordinate carefully to achieve the most perfect effect. For example, in a batching control system, if the feeding speed is 20 kg/s and the batching error is required to be 1 kg, the real-time performance of the system must be guaranteed within 50 ms. In order to leave room, the timer interrupt interval can be set to 20 ms.

1.2 Manage multitasking by keeping an eye on all tasks

Tasks can be divided into different types according to the different degrees of real-time requirements of each task. The more stringent the real-time requirements of the task, the more frequently the system needs to "look after" it. For tasks with low real-time requirements, the system can "look after" it for a longer time interval. For example, there are two tasks A and B. Task A must be "looked after" 10 times per second, and task B must be "looked after" 2 times per second. The control flow is shown in Figure 1. As can be seen from Figure 1, task A is "looked after" once every 0.1 s, and task B is "looked after" once every 0.5 s. Several tasks with basically the same real-time requirements can be "looked after" in turn, and their program flow is shown in Figure 2.

Figure 1 Processing tasks with different real-time requirements

Figure 2 Processing tasks with basically the same real-time requirements [page]

By placing all tasks in a timing monitoring loop to "look after" them, each task can be "looked after" in real time. The key to the problem is how the system "looks after" each task. If the time required for a task to run once is much less than the timing interval, the task can be arranged to be fully executed once when the system "looks after" it. In this case, "looking after" a task and "running" a task are the same thing. If the running time of a task is much longer than the timing interval, for example, in the batching system, a batching task takes tens of seconds, and the timing interval is only 20 ms, therefore, when "looking after" the task, it is impossible to wait for it to complete before "looking after" other tasks, otherwise the system will crash. For this reason, the system's "looking after" time for any task must be much less than the timing interval, only in this way can the system ensure that it completes the "looking after" of all tasks in a timing interval. It can be seen from this that in this method, no task can occupy the CPU alone for a long time, but is constantly "looked after" by the system, and the normal operation of each task is maintained by "looking after".

1.3 Decompose the task into several states

For tasks whose execution time is greater than the timer interval, their execution process is composed of several different states. In different states, the system needs to "look after" in different ways. For this purpose, a state variable is set for this task to indicate the current state of the task. When the system "looks after" the task, it first reads the state variable of the task, and then performs the corresponding "look after" operation according to the value of the state variable.

In order to enable the system to get out of a task in time and "look after" other tasks in time, any "looking after" operation must be very short (much shorter than the timing interval). If a certain state of a task requires the system to "look after" for a long time (such as performing a relatively complex data processing), this state must be decomposed into several states until the processing time required for each state is much shorter than the timing interrupt interval. You can also set several flags to put these time-consuming processes in the background.

1.3 Decompose the task into several states

① This method has no concept of priority. All tasks are taken care of equally. There is no "task scheduling" problem. It fundamentally simplifies the system software design and greatly reduces the requirements for hardware resources.

② This method is similar to the "time slice cycle" method, but there are two differences: first, the "time slice" obtained by each task is not fixed, and is related to the current state of the task. When the task is in a stopped state, the time required for its "care" operation is relatively short, and the "time slice" occupied is also relatively short; second, the "time slice" is divided by the "care" operation. The "care" of each task is a complete process, and there is no interruption, so there is no need to configure a "stack" for each task. Communication and synchronization between tasks can be completed through variables and flags, which is also relatively simple to implement.

③ Since this method has to constantly "look after" tasks in a "stopped state", it is obvious that the time utilization rate is not high. When the number of system tasks is large or the real-time requirements are very high, it is difficult to be competent. Therefore, this method can only be used in low- and medium-end systems with a small number of tasks; systems with a large number of tasks or high real-time requirements should still use programming methods based on real-time operating systems.

2 Design Examples

The design method of this type of system is now explained by combining a design example of a batching system. In the batching system, each ingredient in the formula is configured by an independent hopper and measured by an independent electronic scale. During the batching operation, in order to improve work efficiency, each hopper is charged at the same time, and the charging is stopped when the weight specified in the formula is reached. When all hoppers have completed the charging process, they will discharge the materials at the same time (or in a predetermined order) for mixing. After all hoppers have finished discharging materials, the next batching process will automatically start after a few seconds.

The following tasks need to be run in this system:

◆ Keyboard management tasks: Collect the operator's keystrokes and interpret them for execution, to set recipe data and batching times, and control system operation.

◆ Display tasks. Display the current status of the system and related data.

◆ Data collection task: Read the current data of each electronic scale.

◆ Batching control task: Determine the working status of the hopper according to the formula requirements and the current data of the electronic scale.

◆ Control signal output task: Output corresponding control signals according to the hopper status.

◆ Clock task: Provides a time base for the system so that each task can run at a specified rhythm.

◆ Sleep task: Let the system enter sleep state during idle time to improve the system's anti-interference ability.

The software structure of the system is shown in Figure 3. On the left is the main program, which only arranges the sleep task; on the right is the timer interrupt subroutine, which arranges all other tasks. [page]

Figure 3 Schematic diagram of system software structure

Except for the batching control task, the running time of other tasks is much shorter than the timing interval, and they can be completely run once in each timing interruption, so the running process can be written out using ordinary programming methods. The batching control task cannot be completed in one timing interruption, and can only be completed by the method of continuous "looking after". If the running time (running cycle) of the batching task is 40 s and the timing interruption interval is 20 ms, each batching process is achieved through 2000 "looking after". Assuming that the formula has four ingredients, the system has four hoppers working in parallel. The "looking after" operation of the "batch control" task is actually composed of "looking after hopper 1", "looking after hopper 2", "looking after hopper 3", and "looking after hopper 4" (as shown in Figure 2), that is, each timing interruption must "look after" the four hoppers in turn. The "looking after" operation mode of the four hoppers is basically the same. Due to the difference in formula data, the status of the four hoppers may not be synchronized at all times. If the "drop" phenomenon during material addition is not considered, for one hopper, the "looking after" operation contents are designed as listed in Table 1.

The batching process is started by keyboard operation (making the "allowed batching" flag = 1), and each subsequent batching operation is started by the state 5 of the previous batching until the predetermined number of batching times is completed.

As can be seen from Table 1, all the “look after” operations are composed of a “judgment-branch” structure, and the operation time is also very short, which meets the design requirements.

3 Summary

Note: When the value of the state variable is 5, in order to synchronize and avoid repeated calculation of the batching times, only hopper 1 performs the specified operation, and other hoppers do not perform any operation and end the supervision directly.

In real-time multitasking systems, to ensure the real-time performance of the system, the use of a real-time operating system is the preferred design solution; however, in low-end and mid-range systems, in order to simplify the design and reduce costs, bare metal programming can also meet the requirements using the method introduced in this article. In the product market where low-end and mid-range systems account for a large proportion, the programming method introduced in this article is obviously helpful in reducing costs and improving product competitiveness.