Improve the real-time performance of embedded systems through task Separation

Abstract: This paper analyzes the influence of long tasks on the Real-time embedded system. Based on this, it is proposed that task separation is an effective way to improve the real-time embedded system, an example is provided to improve the real-time performance of embedded systems through task separation. Keywords: Embedded System Real-Time Kernel time slice task segmentation introduction with the rapid development of industry, people have higher requirements for real-time system. Advances in computer technology are also objectively possible to further improve real-time performance. Therefore, in recent years, the study of embedded real-time systems has become another hot topic in the single-chip application field. There are more and more real-time orchestration software, commercial software, and freeCode. However, there are many factors that affect the system's real-time performance, including hardware and software. This makes it easy to improve the system's real-time performance. In addition to using a high-performance CPU and an efficient real-time kernel, in the process of real-time system application, we also need to make specific analysis based on specific situations to make full use of the CPU efficiency and explore the real-time potential of the kernel. 1. Task and embedded multi-task Real-Time System 1.1 task and multi-task

Bytes

 

In a real-time embedded multi-task system, a task isProgramSegment. This segment is scheduled by the operating system as a basic unit. Typically, each task is an infinite loop and can only be in one of the following five States at a time. The five statuses are sleep, ready, running, waiting, and interrupted, as shown in 1. The execution process of a multi-task system is actually a series of processes in which the five States flow cyclically and are scheduled by the kernel in turn. Multi-task execution maximizes CPU utilization and modularize applications. 1.2 The embedded real-time multi-task system RTOS is essentially an embedded real-time kernel. It manages tasks, or allocates CPU time for each task, and is responsible for communication between tasks. Real-time kernels can be divided into two types: detachable and different deprivation types. Therefore, according to the different kernels used, embedded real-time systems can also be divided into two types: embedded real-time systems using the Uninterruptible kernel and embedded real-time systems using the deprived kernel. 2. long task problems in real-time systems 2.1 the definition of long tasks is in RTOs. Long Tasks mean that the entire task is executed for a long time, tasks that exceed the real-time requirements of one or more other tasks in RTOs and threaten the real-time performance of the entire RTOS. 2.2 Impact of long tasks on RTOS when the real-time kernel is available, long tasks are more likely to be interrupted by high-priority tasks due to long execution time; once a high-priority task enters the ready state, the CPU usage of the current task is denied, or the task is suspended, the high-priority task immediately gets control of the CPU. In this case, two problems may occur: one is that a long task may be interrupted by frequency, and the task cannot be executed completely for a long time; the other is that when a long task is interrupted, A large amount of on-site information may be stored to ensure that long tasks can continue to be executed after a high-priority task is returned. However, this requires a certain amount of system resources and the CPU time for saving the site itself. Therefore, the real-time performance will also decrease.

Bytes

When using the real-time kernel of the non-essential type, long tasks have more significant impact on RTOS, because in this kernel, the task-level response time depends on the longest task execution time. That is to say, because of the existence of long tasks, the task-level response time needs to be longer. The result is that the CPU stays in a long task for a long time, and other tasks do not respond in real time, or even cannot be executed at all. The real-time performance of the system is bound to decrease. In short, long tasks pose a serious threat to RTOS, whether it is using a pluggable kernel or an uninterruptible kernel. 3. The most effective way to solve long task problems is to separate tasks. Task splitting refers to dividing long tasks that affect the real-time performance of the system into several small tasks. In this way, the execution time of a single task becomes shorter, the system's task-level response time becomes shorter, and the real-time performance is improved. 3.1 analysis and computing of RTOS, of course, the separation of long tasks must be combined with the Kernel used in the system, as well as the requirements of various tasks for real-time performance, for necessary analysis and computing, in order to ensure the rationality and effectiveness of the separation, the specific steps are as follows: ① analyze the total number of tasks in the system, how high the requirements of these tasks for real-time performance, find the minimum execution frequency required by each task: F1, F2, F3 ...... FN. ② Calculate the actual execution time of each task, such as T1, T2, and T3 ...... Tn. ③ Determine the long task in the system if Max (T1, T2, T3 ...... Tn) ≤ min (1/F1, 1/F2, 1/F3 ...... 1/FN) the system does not have long tasks. If Max (T1, T2, T3 ...... Tn)> min (1/F1, 1/F2, 1/F3 ...... 1/FN) long tasks exist, and the execution time is max (T1, T2, T3 ...... Tn. ④ Do you need to split and analyze this long task? What causes the execution time to be too long? Can this time be shortened through program optimization? If yes, you do not need to split the task; otherwise, you need to split the long task. 3.2 common task segmentation methods include the following: ① A long task is divided into several small modules by function. Each module forms a small task, each small task executes a relatively independent function, and the execution time t must be ensured. This kernel mainly uses the time module inside the microcontroller to generate constant real-time interruptions, divides the CPU running time into time slices. The task scheduling of the kernel is completed at the beginning of the time slice, and each task must be completed within a single time slice. In this kernel, one clock interruption occurs every ms, and every 10 clock interruptions constitute one time slice (5 ms ). Task 1 has the highest priority, and is executed once every two time slices (10 ms). Task 2 executes once every four time slices (20 ms, if Task 6 has the lowest priority, the task is executed once every 64 time slices (320 ms. 4.2 keyboard task problems in the single-chip microcomputer system, the keyboard is mainly used to input data, code and commands, so the system must repeatedly scan and scan; first, there is a key wave press, the CPU immediately responds. The keyboard task subroutine is also designed according to this requirement. There are two Processing Methods: one is the interrupt method and the other is the query method. From the time when a key is pressed to the time when the key is released and the corresponding subroutine is transferred to terminate. Figure 3 shows how the task is scheduled by the kernel. In Figure 3, The △t is the time of the manual button, generally 100 ~ 300 ms. To illustrate the problem, 100 ms is used here. Make T1 "-t1 = △t1, t2"-t2 = △t2, then the execution time of a keyboard task is △t "= T" 2-T "1 = T2 + (T" 2-t2) -[t1 + (T "1-t1)] = T2 + △t2-T1-△t1 = t2-t1 + (△t2 + △t1) = △t + (△t2-△t1) as shown in figure 3, △t1 ≤ TMS △t2 ≤ 5 ms. In fact, because the execution of the two tasks is different, the time difference between Delta T1 and Delta T2 may be equivalent to several command cycles, but it is only an μs error. Furthermore, this is calculated in the form of time slice, so it can still be considered that Delta t2-delta T1 = 0 and thus there is delta T "= delta T + (delta t2-delta T1) = △t = 100 ms (20 time slices) That is to say, only one keyboard task is executed in the 20 clock slices, and most of the time is blank. During this period, 20-1 = 19 other tasks were missed, and the dotted line shown in Figure 3 is the 19 tasks that were missed during this Ms period. Obviously, this is not allowed in most multitasking systems. Therefore, in this real-time multi-task system, a keyboard task is a typical long task. To interrupt 19 other tasks, you must split the keyboard task. 4.3 split a keyboard task by dividing a keyboard task into multiple small tasks, which are completed by Multiple Task interruptions. We put it in Task 4 (1 execution in 80 ms ). In this way, ttask4 is ≤ttask ≤2ttask4, which ensures the complete and reliable execution of keyboard tasks and improves the CPU efficiency. Figure 4 shows the execution process of the split keyboard task.

Bytes

As shown in figure 4, a complete keyboard task consists of 2 ~ 3 Task interruptions. In case a, every task interruption occurs at the TA1 time. In the next time slice (5 ms), it is detected that a key is pressed to call the query value task; the first task interruption occurs at the time of TA2. In the next time slice (5 ms), the button is detected to have been released, jump to and execute the corresponding key processing program. In case B, when the second task is interrupted (tb2 moment), the key has not been released, so nothing is actually done; the third interruption (moment) to the subroutine corresponding to the key value. With this split, each subtask can be completed within 5 ms. If there are long tasks greater than 5 ms in the system, you can continue to split them according to this method; if not, the system task-level response time must be less than 5 ms. In this way, the real-time performance of the system is greatly improved from MS to 5 ms. This journal network supplemental edition (http://www.dpj.com.cn), introduced this task improved part of the source program. The conclusion is that task separation can significantly improve the real-time performance of multi-task systems. The improved source program has been successfully run in the greenhouse controller mc68hc908gp32. In addition, the LED and Sci tasks are separated successfully. After the improvement, in addition to the real-time improvement, the CPU execution efficiency is also significantly improved.