From the hardware and software architecture of μC/OS-Ⅱ, we can see that the processor-related codes are mainly OS_CPU.H, OS_CPU_A.ASM and OS_CPU_C.C. The process of porting is to write these three files. OS_CPU.H includes constants, macros and types related to the processor defined by #define statements. Among them, the focus is on implementing the critical section code protection functions OS_ENTER_CRITICAL() and OS_EXIT_CRITICAL(). The function OS_ENTER_CRITICAL() implements interrupt disabling, and the function OS_EXIT_CRITICAL() implements interrupt enabling. Like all real-time kernels, μC/OS-Ⅱ needs to disable interrupts before processing critical section codes, and reopen interrupts after processing. This enables μC/OS-Ⅱ to protect critical section codes from damage by multitasking or interrupt service subroutines. Four simple assembly language functions need to be written in the OS_CPU_A.ASM file: The function OSStartHighRdy() is used to start running the task with the highest priority in the ready state. The code implementation based on MSP430F149 is as follows: OSStartHighRdy call #OSTaskSwHook mov.b #1, &OSRunning ; Kernel running mov.w SP, &OSISRStkPtr ; Save interrupt stack mov.w &OSTCBHighRdy, R13 ; Load the highest priority task stack mov.w @R13, SP POPALL ; Restore all registers reti ; Interrupt return The function OSCtxSw() is used to implement task switching under normal operating conditions, that is, to allow the task with the highest priority to obtain CPU control. The implementation code is as follows: OSCtxSw push sr ; Save interrupt SR pointer PUSHALL ; Save all registers mov.w &OSTCBCur, R13 mov.w SP, 0(R13) call #OSTaskSwHook mov.b &OSPrioHighRdy, R13 mov.b R13, &OSPrioCur mov.w &OSTCBHighRdy, R13 mov.w R13, &OSTCBCur mov.w @R13, SP POPALL reti ; Interrupt return The function OSIntCtxSw() is used to implement task switching in the interrupt service subroutine. The specific code is as follows: OSIntCtxSw call #OSTaskSwHook mov.b &OSPrioHighRdy, R13 mov.b R13, &OSPrioCur mov.w &OSTCBHighRdy, R13 mov.w R13, &OSTCBCur mov.w @R13, SP POPALL ;Restore all registers reti The function OSTickISR() is the system clock tick interrupt service routine, which is executed at a frequency of 10 to 100 Hz. Its main function is to check whether there are any tasks that have been suspended due to delays and become ready tasks. If so, OSIntCtxSw() is called to switch tasks, so as to run high-priority tasks. In the OS_CPU_C.C file, 10 C language functions need to be written. The only one that needs to be written is the stack initialization function OSTaskStkInit(). The other 9 functions only need to be declared and do not have to contain any code. Since the stack of MSP430F149 decreases from top to bottom, the implementation code of the stack initialization function OSTaskStkInit() is: OS_STK *OSTaskStkInit (void (*task)(void *pd), void *pdata, OS_STK *ptos, INT16U opt) { INT16U *top; opt = opt; /*Avoid compiler warning*/ top = (INT16U *)ptos; top--; *top = (INT16U)task; top--; *top = (INT16U)task; /*Interrupt return vector*/ top--; *top = (INT16U)0x0008; /* Status register*/ top--; ...... *top = (INT16U)pdata; top--; ...... return ((OS_STK *)top); /*Return the top pointer of the stack to the function that called it*/ } At this point, the porting of μC/OS-Ⅱ on MSP430F149 has been completed, and a multi-tasking application can be established to test the embedded operating system μC/OS-Ⅱ.
Is this the end of the porting? I understand that first, according to the different types of MCUs, the four functions in OS_CPU_A.ASM are rewritten using the corresponding assembly language, and then the stack types in OS_CPU_C.C are modified. However, I think that the porting means that the application can be written directly afterwards, but the other functions are empty, the system cannot be initialized, and the calling functions when creating tasks cannot be implemented, right?
Details
Published on 2018-7-8 23:32
Is this the end of the porting? I understand that first, according to the different types of MCUs, the four functions in OS_CPU_A.ASM are rewritten using the corresponding assembly language, and then the stack types in OS_CPU_C.C are modified. However, I think that the porting means that the application can be written directly afterwards, but the other functions are empty, the system cannot be initialized, and the calling functions when creating tasks cannot be implemented, right?