Principles of Embedded Application Software task division

Principles of Embedded Application Software task division

(Http://macmingcheng.blogspot.com /)

In the Application Software Design of Single Chip Microcomputer Based on Real-time Operating System (RTOs), "task" is an important concept. Some experts pointed out that [1] It is an art to divide an application system into several tasks and define what each task is responsible. There is no rule that everyone should abide by for the division of tasks. There are different solutions for different people to design a system with the same specifications. However, until now, it is difficult to see a detailed and systematic introduction to the task division methods in the relevant papers. In this paper, the method of dividing tasks is studied in depth, and on this basis, the guidelines for compiling the application software based on the rtx51 tiny real-time operating system are given from a practical point of view.

1. Concept of task and application software development process

In the development of embedded real-time multi-task system, a task represented by C code is an infinite loop program. A task cannot return or exit, but can be killed, including killed or killed by another task [2]. The concept of a task is the same as that of a process in an operating system. A task is an independent execution process and can compete for CPU time with other concurrent tasks.

RTOs-based Single-Chip Application Software Development Process: firstly, the functions of the application software are defined according to the system design scheme, and then the RTOS concurrency characteristics (or quasi-concurrency characteristics) are combined ), divide the functions to be implemented by the application software appropriately, that is, divide the functions of the application software into several task modules according to certain principles, and carefully confirm the communication and latency between tasks.

2. Principle of task division

There are three principles for job Division.

2.1 Principle 1

Principle 1: place access from the same peripheral in a task.

The driver segment that operates on each independent hardware (such as a serial communication port) is placed in a task. That is to say, to operate a device resource, you only need to execute the corresponding task. In this way, whenever a task is switched, it will not affect any independent "peripherals.

This can avoid special problems of the embedded operating system-resource conflicts and re-entry problems, and facilitate system maintenance and upgrade. To implement communication between tasks, you can call the OS _send_signal function and global variables.

A resource conflict occurs when task a accesses a resource. task a switches from task a to Task B, task B also accesses this resource and changes its status. When task a is executed again, a conflict or uncertainty may occur. The so-called "re-import" refers to the assumption that job A is running a function, and Job B also runs this function after job switchover, in this way, the field when task a executes this function is damaged, which may lead to incorrect results when task a executes the function. This problem occurs especially in the operations of serial interface devices, such as serial ports, serial A/D, and D/A devices.

2.2 Principle 2

Principle 2 is to improve the system's real-time performance through task separation.

In an embedded real-time multi-task system, a task is a program segment. This program is scheduled in segments by the operating system as a basic unit. Typically, each task is an infinite loop.

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 classified into two types: detachable and non-deprived. 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.2.1 definition of long tasks

In RTOS, a long task means that the execution time of the entire task is longer than the real-time requirements of one or more tasks in RTOs, tasks that threaten the real-time performance of the entire RTOS. It should be noted that long tasks and complex tasks cannot be confused. The execution time of complex tasks is not necessarily long, and simple tasks may also constitute long tasks.

2.2.2 Impact of long tasks on RTOS

When the real-time kernel of the detachable type is used, 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 is immediately controlled by the CPU. In this case, two problems may occur: one is that a long task may be interrupted frequently during execution, 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.

When a real-time kernel is used, the effect of long tasks on RTOS is more obvious, because in this kernel, the task response time depends on the longest task execution time. That is to say, because of the existence of long tasks, the task 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 receive real-time response, 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.

2.2.3 solution to long task Problems

The most effective way to solve the problem of long tasks is to separate tasks. The so-called "task separation" 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 response time becomes shorter, and the real-time performance is improved.

(1) Analysis and Calculation of tasks

Of course, the separation of long tasks must be combined with the Kernel used in the system, as well as the requirements for real-time performance of each task, and the necessary analysis and calculation can ensure the rationality and effectiveness of the separation, the procedure is as follows.

① Analyze the total number of tasks in the system, and determine the minimum execution frequency (F1, F2 ,..., FN ).

② Calculate the actual execution time of each task (T1, T2 ,..., Tn)

③ Determine long tasks in the system. If Max (T1, T2 ,..., Tn) ≤ min (1/F1, 1/F2 ,..., 1/FN), the system does not have long tasks. If Max (T1, T2 ,..., Tn)> min (1/F1, 1/F2 ,..., 1/FN), there is a long task, and the execution time is max (T1, T2 ,..., Tn.

④ Analyze whether this long task needs to be split, and analyze the reason for the long execution time. 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.

(2) implement separation of long tasks

You can use the following two methods to separate Common Tasks:

① A long task is divided into several small modules by function. Each module forms a small task, and each small task implements a relatively independent function, and the execution time must be t

② Some long tasks are special, such as keyboard tasks and dynamic LED digital display tasks. It is difficult to divide them into several small modules with relatively independent functions according to the above method. At this time, it is generally based on the principle of convenient storage of on-site information, it is forcibly divided into several small tasks, each small task in min (1/F1, 1/F2 ,..., 1/FN) Actively saves the on-site information and gives up control of the CPU during the time, and continues to execute when it is scheduled again by the kernel. This separation method is relatively complex, and the boundaries between tasks are not very obvious. It seems to be not separated, but it is actually completed by Multiple Task interruptions.

2.3 Principle 3

Principle 3 is to use the decoupling principle in software engineering for task division.

The decoupling principle in software engineering can be used to divide the tasks of applications. Coupling between tasks is an important factor affecting the complexity of software. The following design principles should be adopted: Data coupling should be used whenever possible, control coupling and feature coupling should be used less, and the scope of public environment Coupling should be limited, NO content coupling is required. For specific methods, see books on software engineering, for example, document [3].

3. Application Software Design Guide based on rtx51 tiny

Rtx51 is a real-time multi-task operating system developed by Keil software for the 8051 series single-chip microcomputer [4]. Rtx51 has two different versions.

(1) Full Version rtx51 full

The full version of rtx51 allows four priority task time slice rotation scheduling and preemptive task switching, which can be used concurrently. Signals and information can be transmitted between tasks through the mailbox system, and memory can be allocated and released from a storage pool, it can force a task to wait for interruption, timeout, and signals or messages sent from another task or interruption.

(2) Small version rtx51 tiny

The small version of rtx51 tiny is a subset of rtx51, which can easily run on a single 8051 system without any external memory. Rtx51 tiny only supports time slice rotation task switching and signal-based task switching. It does not support preemptive Task Switching and can utilize the interruption function in parallel, it can force a task to wait for interruption, timeout, and signal from another task or interruption. It cannot process information or allocate or release memory. Rtx51 tiny is an irrevocable real-time operating system kernel.

The Design of Single Chip Microcomputer Application Software Based on rtx51 tiny real-time operating system should first be based on the quasi-concurrency characteristics of rtx51 tiny operating system, divide the functions to be implemented by the application software based on the above three principles into several task modules, and carefully confirm the communication and latency between tasks.

The guidelines for compiling rtx51 tiny-based application software are as follows:

① Include the header file rtx51tny. h In the application.

② Do not write the main function main () in C language (). The rtx51 tiny operating system kernel already has its own main function ().

③ The application should include at least one task function ).

④ The rtx51 tiny application must interrupt enabling (Ea = 1) because the rtx51 tiny operating system uses the timer t0 interrupt.

⑤ The application calls at least one rtx51 tiny system function (such as OS _wait); otherwise, the linker will not include the rtx51 tiny system library in the application.

⑥ Task task0 is the first function executed in the application. In task 0, you must call the OS _create_task function to run other tasks.

7. The task function does not have to exit or return. The task must use a while (1) structure or other similar structures. The task function does not contain parameters or return values. Use the system function OS _delete_task to suspend a running task (halt.

The write method of the interrupt service program in the dig command is the same as that in the tiny operating system that does not use the rtx51.

There are two ways to compile and link an application by using the compile tool. One is to use the integrated development environment μ vision 2 IDE, and the other is to use the command line tool CommandLine tools. Generally, the integrated development environment μvision 2 ide provided by Keil software is used.

Use the integration development environment μvision 2 ide provided by Keil software to create the rtx51 tiny application as follows:

① Run the integration development environment μvision 2 ide of Keil software.

② Run the menu command project → options for target 'target 1' to open the target dialog box, and select the target tab in the dialog box.

③ Select rtx51 tiny from the drop-down list box of operating system, as shown in 1.

 

Figure 1 rtx51 tiny real-time operating system

4 Conclusion

This article provides three principles for dividing tasks, they are "access to the same peripherals in a single task", "improve the real-time performance of the system through task separation", and "the" decoupling principle "in software engineering for task division ". Practice has proved that the principles for dividing these tasks are effective. In addition, the guidelines for compiling Real-Time Linux Application Software Based on rtx51 tiny are provided from a practical point of view. In fact, the rtx51 tiny real-time operating system has very low hardware requirements for the target system. With the development of semiconductor technology, it is easy to purchase Single Chip Microcomputer chips that can run embedded real-time operating systems.

People are increasingly aware of the necessity of introducing Real-time Operating Systems in embedded system design [5]. In many embedded systems, the system is required not only to respond to random external events in a timely manner, but also to quickly process them. Generally, multiple tasks need to be executed at the same time, and responds to each task in real time. Practice has proved that the use of embedded real-time operating system as the design platform and operation platform of application software is a good choice.