Discussion and Implementation of the Method of Porting μC/OS-Ⅱ to ARM7

With the rapid development of embedded technology, real-time multitasking operating systems as a software platform have gradually become the mainstream of international embedded systems. At present, there are a large number of mature real-time embedded operating systems in the world. Usually, the basic requirements for embedded software are small size, fast instruction speed, good tailorability and portability. At present, there are many real-time operating systems, such as VxWorks, Windows CE, pSOS, QNX, LynxOS, etc. These operating systems have the characteristics of high reliability and strong real-time performance, but they are all commercial operating systems, expensive, and people often find it difficult to accept. The emergence of μC/OS-Ⅱ operating system is a great impact on these commercial operating systems.

1 Introduction to μC/OS-Ⅱ Operating System

μC/OS-Ⅱ is a real-time operating system with open source code and a free operating system. Program developers can rewrite the source code to meet their own requirements and cut out unnecessary parts to make the operating system small, flexible, and able to meet the needs of users' specific operating systems. In order to improve the real-time capability of the system, μC/OS-Ⅱ can divide a complex application into multiple independent tasks and assign priorities according to the importance of the tasks. The scheduling of tasks is completely completed by the real-time kernel of μC/OS-Ⅱ, which mainly includes task status management, selecting the highest priority task, executing tasks and canceling tasks. The μC/OS-Ⅱ kernel is also responsible for CPU time allocation. CPU time is always allocated to interrupt events first, followed by the task with the highest priority in the task queue. The communication between different tasks can be completed through the semaphore, mailbox, information queue and other mechanisms provided by μC/OS-Ⅱ. Most of its code is written in C language, which has strong portability. Therefore, it has been widely adopted internationally since 1997.

2 Analysis of its software and hardware system and portability

The core code of μC/OS-Ⅱ is very small, and program developers only need to do a small amount of work to port it to their own target board. Figure 1 is the software and hardware architecture of the embedded system based on μC/OS-Ⅱ.

Although most of the source code of μC/OS-Ⅱ is written in C language, the code related to the processor is still implemented in assembly language. As can be seen from Figure 1, the main work of porting μC/OS-Ⅱ is to modify the code related to the processor. They are concentrated in 3 files. Among them, OS_CPU.H contains the definition of constants, macros and structures related to the processor; OS_CPU_C.C and OS_CPU_ASM define the functions used for low-level task switching, exiting interrupt service routines, shielding interrupts at the CPU level, opening interrupts, initializing task stacks, and interrupt service routines for clocks, etc. In order to make the application run on μC/OS-Ⅱ, the hardware and device drivers used in the application must be modified accordingly.

3 Porting work of μC/OS-Ⅱ

3.1 Code related to the application

This part is for users to customize the appropriate kernel service functions according to their own application system, including 2 files: OS_CFG.H and INCLUDES.H.

OS_CFG.H is used to configure the kernel. Users can modify the kernel as needed, leaving the necessary parts and removing the unnecessary parts, such as the maximum number of tasks that the system can provide, whether to customize the mailbox service, whether to provide the dynamic priority change function, etc. All configuration changes, including the addition and subtraction of header files, are made in this file.

INCLUDES.H system header file, the file required by the entire real-time system program, includes the kernel and user header files, so that each .C file in the user project does not need to consider which header files it actually needs.

3.2 Processor-related code

This is the most critical part of the transplant. The kernel organically combines the application system and the underlying hardware into a real-time system. To make the same kernel applicable to different hardware systems, there needs to be an intermediate layer between the kernel and the hardware. This is the processor-related code. Different processors have different codes. We need to handle this part of the code ourselves when transplanting. In μC/OS, this part of the code is divided into 3 files: OS_CPU.H, OS_CPU_A.ASM, OS_CPU_C.C.

3.2.1 OS_CPU.H

contains processor-related constants, macros, and type definitions defined with #define, including system data type definitions, stack growth direction definitions, interrupt enable and disable definitions, system soft interrupt definitions, etc.

(1) Data types that are not dependent on compilation

μC/OS-Ⅱ does not use the definitions of data types such as short, int, and long in the C language, because they are related to the processor type and imply non-portability. Instead, they are replaced by integer data types with strong portability, which is both intuitive and portable. According to the characteristics of the ADS compiler, the code is:

typedef unsigned char BOOLEAN;
typedef unsigned char INT8U;
typedef signed char INT8S;
typedef unsigned short INT16U;
typedef signed short INT16S;
typedef unsigned int INT32U;
typedef signed int INT32S;
typedef float FP32;
typedef double FP64;
typedef INT32U OS_STK;

(2) Use soft interrupt SWI as the underlying interface

Because the ARM7 processor core with T variables has two instruction sets, user tasks can use two processor modes. In order to make the underlying interface function independent of the processor state and not need to know the function location when the task calls the corresponding function, this example uses the soft interrupt instruction SWI as the underlying interface, and uses different function numbers to distinguish different functions. The SWI service function code is:

[page]

(3) OS_STK_GROWTH

μC/OS-Ⅱ uses the structure constant OS_STK_GROWTH to specify the stack growth method. The code is:

#define OS_STK_GROWTH 1

3.2.2 OS_CPU_C.C

contains C functions related to transplantation, including stack initialization and the implementation of some hook functions, but the most important one is OSTaskStkInit() function, which is called by the system itself when the user creates a task to initialize the stack of the user task. Under the ARM7 architecture, the task stack space decreases from high to low, and stores the initialization stack structure of PC, LR, R12, ..., R1, R0, CPSR in turn. When the user initializes the stack, OSTaskStkInit() returns the fixed address pointed to by the new stack pointer STK. OSTaskCreate() and OSTaskCreateExt() will obtain the address and save it to the task control block TCB. Several other hook functions must be declared, but they may not contain task codes. These hook functions are all empty functions in this port.

3.2.3 OS_CPU_A.S

Most of the work of μC/OS-Ⅱ porting is concentrated on the porting of OS_CPU_A.S file. In this file, the most difficult work is concentrated on the implementation of the two functions OSIntCtxSw and OSTickISR. This is because the implementation of these two functions is related to the porting ideas of the porter and the settings of the relevant hardware timers and interrupt registers. In the actual porting work, these two places are also prone to errors. This part requires the operation of the processor registers, so it must be written in assembly language, including 4 sub-functions: OSStartHighRdy(), OSCtxSw(), OSIntCtxSw(), OSTickISR().

OSStartHighRdy() This function first calls the hook function OSTaskSwHook(), and then sets the OSRunning flag to true, indicating that the task starts to execute, thereby ensuring the correct execution of the task switching operation, and then obtains the stack pointer of the task from the task control block with the highest priority, initializes the stack pointer register SP, and then restores other registers to start executing the highest priority task.

OSCtxSw() This function is called in the task-level task switching function. First, save the processor registers, store the current SP in the task TCB, load the SP of the ready highest priority task, restore the values ​​of all processor registers from the task stack of the new task, and then execute the interrupt return instruction.

OSIntCtxSw() This function is to perform the task switching function in ISR. Its principle is basically the same as the task-level switching. The only difference is that ISR has saved the CPU registers. Therefore, do not perform similar operations again. Just adjust the stack pointer accordingly.

OSTickISR() This function is the system clock beat interrupt service function. First, save the processor registers, then call the OSIntEnter() function to ensure that the number of interrupt nesting levels does not exceed 255. If this condition is met, save the stack pointer to the task control block TCB of the current task, then clear the interrupt for the device that generated the interrupt, and re-enable the interrupt. Next, call OSTimeTick() to maintain the internal timing of μC/OS-Ⅱ and call OSIntExit() to determine whether the execution of this interrupt service program makes the higher priority task ready.

4 μC/OS-Ⅱ Testing

After completing the transplantation work, we need to test whether the transplantation is correct. This is actually the last step of the transplantation process. We should first test the transplanted μC/OS-Ⅱ without adding any application code, that is, we should first test the operation of the kernel itself. The purpose of this is that if some parts fail to work properly, it is a problem with the transplantation itself, not a problem caused by the application code. The transplantation test is mainly divided into the following steps:

First, we must understand the compiler system used by the processor. This step depends on the compiler used. During this period, there is no code testing. Secondly, we need to verify the OSTaskStkInit() and OSStartHighRdy() functions in OS_CFG. In the H file, set OS_TASK_STAT_EN to 0, and only let an idle task OS_TaskIdle() run, check whether there is an error, and then verify the task-level switching OSCtxSw() function, add the OSTimeDly() function in the test task TaskTest(), and the OSTimeDly() function then calls OS_Sched(), which calls the OSCtxSw() function written in assembly language. If SWI is configured correctly, the CPU will start executing OSCtxSw(). Finally, it is necessary to verify the OSIntCtxSw() and OSTickISR() functions.

When the above test steps are successful, you can try to run some specific tasks, and make the test more complicated from simple to complex to further verify the stability of the kernel and the system performance.

A simple LED flashing control task is established here, and its code is as follows:

After loading, if the LED light flashes normally, the test is successful and the kernel runs normally. If there is a problem with the test, you must carefully find out the problem. Don't ignore the hardware problem, compiler, etc. Of course, you can also use other tests, such as serial port testing.

5 Conclusion

The above is the general method of porting μC/OS-Ⅱ on ARM7, but it needs to be modified appropriately for different processors. RTOS is a hot spot in embedded applications today. The application of RTOS can improve product reliability and reduce the R&D cycle. Among them, μC/OS-Ⅱ has good real-time performance and a small amount of code, occupies less space, has high execution efficiency, and the porting method is relatively simple. Therefore, it is very important to master the porting method of μC/OS-Ⅱ.