uC/OS-II is a concise, easy-to-use priority-based embedded preemptive multitasking real-time kernel. Although it is very simple, it does free up my embedded development work to a great extent. Since it is an operating system kernel, once it is used, it will involve the problem of how to design application software based on the operating system.
1. Task framework of uC/OS-II
void task_xxx(void *pArg)
{
/* Initialization of this task */
……
/* Enter the infinite loop of this task */
while(1)
{
……
}
}
Each user's task must conform to the event-driven programming model, that is, the application of uC/OS-II must be the "event-driven programming model". A task first waits for an event to occur. The event can be issued by a system interrupt, or issued by other tasks, or it can be a time slice that the task itself waits for. When an event occurs, the task is processed accordingly, and after the processing is completed, it starts to wait for the occurrence of the next event. Such a recurring task processing model is an "event-driven programming model". The event-driven model also covers the interrupt-driven model, and uC/OS-II events come down to three aspects:
(1) Events sent by the interrupt service function
(2) Caused by the system delay time
(3) Events sent by other tasks.
The "event sent by the interrupt service function" means that whenever a hardware interrupt occurs, the interrupt service routine will inform the task in the form of an event, and the highest priority task waiting for the event will be run immediately; "system delay The event caused by "time up" is actually caused by a hardware interrupt, that is, the system timer interrupt. The "events sent by other tasks" are determined by the task code itself, which is a complete "soft event". Regardless of "soft event" or "hard event", the reason for uC/OS-II task switching is "event" anyway, so users must reflect the "event-driven programming model" when writing application code.
2. Task priority assignment of uC/OS-II
The task priority assignment of uC/OS-II needs to be analyzed according to different system designs. For example, tasks with higher real-time requirements have higher priority.
3. The software level of uC/OS-II
uC/OS-II will directly manipulate the hardware, for example: the task switching code must save and restore the registers of the CPU and coprocessor; the kernel time base clock of uC/OS-II needs the interrupt of the hardware timer.
BSP is the "Board Support Package", which includes an event-driven model developed based on uC/OS-II, and drivers that support multitasking. These drivers directly control each hardware module and use the system functions of uC/OS-II to To achieve multitasking capabilities, they should try to avoid applications directly manipulating the hardware and the uC/OS-II kernel. BSP should also provide a standard and unified API for applications, so as to achieve the purpose of clear software layers and reusable application software codes.
The application is the software developed by the user for the specific application needs, it must conform to the programming model of uC/OS-II, namely "event-driven programming model". The application program should also try to avoid directly controlling the hardware and directly calling the uC/OS-II system functions and variables. A perfect uC/OS-II system does not need an application program to be designed for specific hardware. That is to say, uC/OS-II must have a complete device driver, and the driver and BSP jointly provide a complete and standard API.
4. Attention should be paid to the use of mutex signal objects in uC/OS-II
Mutex object (Mutual Exclusion Semaphore) referred to as Mutex, is one of the uC/OS-II kernel objects, used to manage those resources that need exclusive access, and make it suitable for multitasking environment.
To create each Mutex, you need to specify an idle priority number, which must be higher than the priority of all tasks that may use this Mutex!
The Mutex implementation principle of uC/OS-II is roughly as follows:
When a low-priority task A applies for and gets a Mutex, it gains access to the resource. If a high-priority task B starts to run after that (task A has been deprived at this time), and also requires a Mutex, the system will increase the priority of task A to the priority specified by the Mutex. Since this priority is higher than the priority of any task that might use this Mutex, task A gets CPU control right away. Until task A releases the Mutex, task A returns to its original priority, at which time task B can own the Mutex.
It should be noted that when task A gets the Mutex, it should not wait for other kernel objects (such as semaphores, mailboxes, queues, event flags, etc.), but should complete the work as quickly as possible and release the Mutex. Otherwise, such a Mutex is useless, and the effect is worse than using a semaphore (Sem) directly!
Although a normal semaphore (Sem) can also be used to mutually exclusive access to an exclusive resource, it may cause a "priority inversion" problem. Assuming that the above example uses Sem, when task A gets Sem, then task C (assuming task C has a higher priority than A, but lower than B) will get CPU control if it is ready, so both task A and task B are Deprived of CPU control. Task C has a lower priority than B, but it gets the CPU first! And if task A is the lowest priority task, then it will not have the CPU until all tasks with higher priority than it are suspended, then task B (the highest priority task) is unlucky with it! This is the priority inversion problem, which is against the principle of "priority-based preemptive multitasking real-time operating system"!
To sum up, when multiple tasks access exclusive resources in uC/OS-II, it is better to use Mutex, but Mutex consumes more CPU time and memory. If a high-priority task wants to use exclusive resources, but doesn't care about long waits, Sem can be used, because Sem is the most efficient and memory-efficient kernel object.
5. uC/OS-II application should pay attention to calling OSSchedLock() and OSSchedUnlock() functions
The OSSchedLock() and OSSchedUnlock() functions of uC/OS-II allow the application to lock the current task from being preempted by other tasks. It should be noted when using: after you call OSSchedLock() and before calling OSSchedUnlock(), do not call any of OSFlagPend(), OSMboxPend(), OSMutexPend(), OSQPend(), OSSemPend(). Class event wait function! And it should be ensured that the OSSchedLock() and OSSchedUnlock() functions appear in pairs, especially in some branch conditional statements, various branch situations should be considered, and there should be no omissions!
The user needs to be reminded: when you call the switch interrupt function OS_ENTER_CRITICAL() and OS_EXIT_CRITICAL(), make sure that they appear in pairs, otherwise the system may crash! However, calling event wait functions such as OSFlagPend(), OSMboxPend(), OSMutexPend(), OSQPend(), OSSemPend() between the OS_ENTER_CRITICAL() and OS_EXIT_CRITICAL() functions is allowed.
6. uC/OS-II driver writing specification, especially recommended
It should be clarified first that we are talking about "drivers" here, not "interrupt service routines," two terms that are often confused by users.
(1) The interrupt service routine refers to a small program that will be called by the hardware interrupt controller immediately once a hardware interrupt occurs. Its operation is simple and clear, and the faster and simpler the better.
(2) The driver refers to a function set that encapsulates the details of a certain hardware operation, and it provides a unified, standard, clear and easy-to-use API to the application.
The writing of the interrupt service routine is often associated with the design of the driver. For example, if the driver provides the function of asynchronous operation, the interrupt service routine needs to prepare a buffer and a structure for it, and the interrupt service routine will automatically complete the required operation according to the member parameters of this structure. For another example, there are two designs of serial port (UART) interrupt service routines: based on data packet transmission and based on single-byte transmission. The former is suitable for communication programs in data packets, while the latter is suitable for applications such as HyperTerminal. .
If in a system, it is required to use the same hardware device to complete several different operation modes, it is necessary to design a general driver, and the driver can install various highly targeted interrupt service routines as required.
When designing the driver, special attention should be paid to the fact that the operation of some peripherals often takes a continuous and strict timing as an atomic operation, such as using I/O ports to access DS1302, 24C01, LM75A and so on. During the operation of this type of equipment, other tasks are not allowed to control the corresponding I/O ports, otherwise it will cause data errors or even device damage. Therefore, the driver of this kind of device should carefully design "atomic operation", and encapsulate the sequence control code that must operate continuously into an "atomic operation" with a mutex object to adapt to the multitasking environment. In fact, most devices are like this, and "atomic operations" need to be determined, such as LCD, RTL8019AS, Flash, and so on.
1. How should FPGA manufacturers and FPGA engineers transform in the AI era?
2. Introduce several embedded development tools, which may be useful!
3. Niu Ren has summed up the MCU application program architecture, just go and see!
4. April programming language rankings: the top three unchanged for ten thousand years
5. Learn C language with these 9 good open source books
6. Detailed explanation of ARM registers and assembly instructions
Disclaimer: This article is reproduced online, and the copyright belongs to the original author. If the copyright of the work is involved, please contact us, and we will confirm the copyright and pay the remuneration or delete the content according to the copyright proof .