Using the Ucos real-time operating system is at school when the Mentor research project. At that time, the Internet to find the operating system porting tutorial and application tutorial according to gourd painting scoop, the function of implementation is just, not very deep to study this thing. Later work, idle to bored on the study of this only thousands of lines of code of the operating system, and not all the code to see, just read some of the content. Oneself still presumptuous try to write a simple operating system, and finally wrote the writing is brought to the ucos design ideas, and then simply "copy" code, although the operating system kernel understanding has a great help, but it is ashamed ah, not enough intelligence, to the operating system core designers more admiration, O ( ∩_∩) o haha ~
Prior to the development of the project STM32, the next step from the Ucos in STM32 transplant began to talk about the learning process. At that time, the system transplant was also based on the Development Board routines, such as OS_STK,OS_CPU_SR and the stack of the growth mode and other settings have been set according to the ARM-COREM3 hardware features, so the migration process is relatively simple. The following is purely personal understanding, if the wrong place, please criticize.
First of all, to talk about the overall architecture of Ucos operating system understanding, there are a lot of ucos each file is what to do the introduction of the article, here do not do a detailed introduction, you can search online. Ucos mainly includes timer management (OS_TMR.C), Tasks (OS_TASK.C), Inter-mission communication (OS_SEM.C,OS_MUTEX.C, etc.), memory management (OS_MEM.C), and processor-related underlying implementations. In addition to the processor-related underlying implementation, other things that are operating system kernel, processor-related implementations are different from the processor to achieve the specific implementation. Operating system porting The main operation is to do this part of the content.
Secondly, the personal understanding of how the Ucos operating system works is mainly divided into four points:
1. The operating system assigns a priority to each task, and when there is a task switch, the CPU usage is assigned to the highest priority task;
2. In the operating system kernel, when there is more important data operation, the data is guaranteed to be reliable and correct by switching interrupts;
3. Trigger the interrupt processing function by manually setting the value of the asynchronous interrupt register, which is the implementation of the communication operation between the tasks;
4. Interrupts will automatically save the value of the register, after the completion of the interrupt processing, will check whether there is a higher priority than the current task, so as to determine the task switching operation (this interrupt is more important is the "heartbeat" timer interrupt to ensure that no external interruption, the implementation of task switching);
Ucos's transplant on STM32 is based on the following three points in the work principle mentioned above, the 1th of which is what the operating system kernel does. The function declaration in the porting is in the operating system kernel, and for STM32, the function is implemented in OS_CPU_A.ASM. Next, analyze the various functions used in the migration process.
1. And the principle of operation 2nd related to the critical section of the Access function (in fact, the switch interrupt function).
#define Os_enter_critical () {cpu_sr = Os_cpu_sr_save ();};
#define Os_exit_critical () {os_cpu_sr_restore (CPU_SR);}.
2. Working principle 3rd related task switching functions
#define OS_TASK_SW () OSCTXSW ()
3. Working principle 4th related Interrupt Exit task switch function
OSINTCTXSW (), the function is called by the Osintexit function after the interrupt handler completes the operation, the implementation principle and OSCTXSW are the same, but the meaning is different.
These three functions are organized in this way:
Corresponding to 1, the function that enters the critical section is mainly realized by modifying the value in the interrupt register. Os_cpu_sr_save () modifies the value of the interrupt register by removing the values from the interrupt register into the CPU_SR and masking interrupts (NMI and hardware fault cannot be masked). Os_cpu_sr_restore () writes the value previously stored in CPU_SR to the interrupt register, reverting to the state before the mask break.
corresponding to 2 and 3, the function of the task switching, mainly by triggering interrupts, in the interrupt processing function by the high-priority task in the stack of the data into the CPU register, so as to achieve the task of switching. These two steps need to be noted in the STM32 boot process (i.e., STARTUP_STM32F10X_HD.S), you need to set the interrupt vector corresponding to the interrupt handler function Os_cpu_pendsvhandler (), the original Pend_svhandler () replaced.
For porting on STM32, it is more important to set the operating system's "heartbeat" function Systick_handler, the function code is as follows:
void Systick_handler (void) { os_cpu_sr cpu_sr; Os_enter_critical (); /* Tell Uc/os-ii, we are starting an ISR */ osintnesting+ +; Os_exit_critical (); Ostimetick (); /* Call Uc/os-ii ' s Ostimetick () */ osintexit ();}
The function first is the operating system nesting count self-add operation, when exiting the interrupt handler, the count variable will be reduced operation. Other references to osintnesting will be judged if the value is greater than 0, if it is out of the interrupt, if the value equals 0, then it has exited from the interrupt, and the add operation (osintnesting++) must correspond to the minus operation (osintnesting--) that exits the interrupt. Otherwise, the operations on the osintnesting will be considered to be always out of the interrupt handler.
Ostimetick is to wait for the delay time slice minus operation on all out-of-waiting tasks, and if the waiting time for a task has become 0, you need to add the task to readytable to prepare for the task switching to that task.
The Osintexit function first determines whether the nesting level variable osintnesting is greater than 0, if it is done, and then determines whether all interrupts have been processed, if so, the task is scheduled to switch to a high-priority task; This means that only the current interrupt handler is exited, and there is no end to other interrupt processing.
Operating system porting, a more important task stack for designing operating system switches, Ucos will have a ostaskstkinit action when creating a task that is designed to build a stack for the task that is currently being created, and the content stored in the stack is as if the task had just been interrupted. The simulation holds the values of some registers, and when the task switches to the current task, the saved contents are ejected from the stack by the Task Scheduler function, thus enabling the task to switch. Although the CPU will automatically save a portion of the register when the interrupt occurs, but we are implementing the class interrupt operation by simulation, so the CPU automatically saves the content, we should also give the simulation implementation when creating the task. Because the interrupt operation pops out the value of the register that the CPU automatically saves, during the task switching process, we also simulate the value of the stored auto-saved registers, such as XPSR, PC, LR, R12, r3-r0, etc. in STM32.
These operations are some of the key steps and principles of Ucos operating system porting on STM32, which are recorded as learning notes for later use. There are a lot of information about the operating system porting, for reference, in which Baidu Library has a "ucosii in STM32 on the transplant detailed" explanation is very good, for everyone to learn.
Ucos Real-time Operating system learning notes-porting of operating systems in STM32