Transplantation of μC/OS-II System on AVM Processor

μC/OS-II is powerful and supports 56 user tasks. Its kernel is preemptive and supports a variety of commonly used inter-process communication mechanisms such as semaphores, mailboxes, and message queues. It has been successfully applied to many commercial embedded systems and is a mature and stable real-time kernel. Unlike most commercial RTOS, μC/OS-II makes all source code public, and 90% of the code is written in standard ANSI C language, which makes the program readable and portable. At the same time, it is available for free, and only a small license fee is charged even for commercial applications. Therefore, it is of great significance to study, research, develop, and apply the μC/OS-II real-time operating system.

Samsung S3C44B0X microprocessor is a cost-effective microcontroller solution provided by Samsung for handheld devices and other embedded applications. It uses ARM's 16-bit/32-bit RISC structure, the core is ARM7TDMI, and it works at 66MHz. The following components are integrated on the chip: 8K Cache, external memory controller, LCD controller, 4 DMA channels, 2 UARTs, 1 multi-master I2C bus controller, 1 I2C bus controller, as well as 5-channel PWM timer and 1 internal timer, 8-channel 12-bit ADC, etc. It can achieve seamless connection with commonly used peripheral devices and has powerful functions. At present, it is widely used in China.

1 μC/OS-II Real-time Operating System Structure

Figure 1 illustrates the hardware and software architecture of μC/OS-II. The application is at the top level of the entire system, and each task can be considered to have exclusive CPU, so it can be designed as an infinite loop. μC/OS-II processor-independent code provides μC/OS-II system services, and applications can use these API functions for memory management, inter-task communication, and task creation and deletion.

Most of the μC/OS-II code is written in ANSI C, so μC/OS-II has good portability, but some processor-related code still needs to be written in C and assembly language. The porting of μC/OS-II needs to meet the following requirements:

① The processor's C compiler can generate reentrant code;

② You can use C calls to enter and exit critical section code;

③The processor must support hardware interrupts and requires a timer interrupt source;

④ The processor needs a hardware stack that can accommodate a certain amount of data;

⑤The processor needs to have instructions that can exchange data between the CPU registers and the core and stack.

The S3C44B0X processor fully meets the above requirements.

2 Transplantation of real-time kernel μC/OS-II on S3C44B0X

We use the ARM SDT compiler, and porting μC/OS-II mainly includes the following steps.

(1) Set the processor and compiler related code in OS_CPU.H

*************************************************

Compiler-dependent data types

*************************************************

typedef unsigned char BOOLEAN;

typedef unsigned char INT8U; /*8-bit unsigned integer*/

typedef signed char INT8S; /*8-bit signed integer*/

typedef unsigned short INT16U; /*16-bit signed integer*/

typedef signed short INT16S; /*16-bit unsigned integer*/

typedef unsigned long INT32U; /*32-bit unsigned integer*/

typedef signed long INT32S; /*32-bit signed integer*/

typedef float FP32; /*single-precision floating point number*/

typedef double FP64; /*Double precision floating point number*/

typedef unsigned int OS_STK; /*The stack entry width is 16 bits*/Code related to ARM processor:

#define OS_ENTER_CRITICAL () ARMEnableInt() /*enable interrupt*/

#define OS_STK_GROWTH 1 /*The stack grows from high address to low address*/

(2) Write 6 operating system related functions in C language (OS_CPU_C.C)

void OSTaskStkInit(void(task)(void *pd),void *pdata,void *ptos,INT16U opt)

{ unsigned int *stk;

opt = opt; /*Because the "opt" variable is not used, prevent the compiler from generating warnings*/

stk = (unsigned int *)ptos; /* load stack pointer */

/*Create context for new task*/[page]

*--stk=(unsigned int)task; /*lr*/

*--stk=(unsigned int)task /*pc*/

*--pcs=0; /*r12*/

*--pcs=0; /*r11*/

*--pcs=0; /*r10*/

*--pcs=0; /*r9*/

*--pcs=0; /*r8*/

*--stk=0; /*r7*/

*--stk=0; /*r6*/

*--pcs=0; /*r5*/

*--stk=0; /*r4*/

*--stk=0; /*r3*/

*--pcs=0; /*r2*/

*--pcs=0; /*r1*/

*--stk=(unsigned int)pdata; /*r0*/

*--stk=(SVC32MODE0x0); /*cpsr IRQ,

*--stk=(SVC32MODE0x0); /*spsr IRQ, turn off FIQ*/

return((void*)stk);

}

The last five functions are hook functions and no code is required:

void OSTaskCreateHook(OS_TCB *ptcb)

void OSTaksDelHool (OS_TCB *ptcb)

void OSTaskSwHook(void)

void OSTaskStatHook(void)

(3) Write four processor-related functions in assembly language (OS_CPU.ASM)

OSStartHighRdy() ; Run the highest priority ready task

LDR r4, addr_OSTCBCur; get the TCB address of the current task

LDR r5, addr_OSTCBHighRdy; get the TCB address of the high priority task

LDR r5,addr_OSTCBHighRdy; Get the TCB address of the high priority task

LDR r5,[r5] ; get the stack pointer

LDR sp,[r5] ; switch to new stack

STR r5,[r4] ;Set the new TCB address of the current task

LDMFD sp!,{r4}

MSR CPSR_cxsf,r4

LDMFD sp!,{r0-r12,lr,pc}; start a new task

END

OSCtxsw() Task-level task switching function

STMFD sp!,{lr} ;Save PC pointer

STMFD sp!,{lr} ;Save lr pointer

STMFD sp!, {r0-r12}; Save register file and return address

MRS r4,CPSR

STMFD sp!,{r4} ;Save the current PSR

MRS r4,SPSR

STMFD sp!,{r4}

;OSPrioCur=OSPrioHighRdy

LDR r4,addr_OSPrioCur

LDR r5,addr_OSPrioHighRdy

LDRB r6,[r5]

STRB r6,[r4]

; Get the TCB address of the current task

LDR r4,addr_OSTCBCur

LDR r5,[r4]

STR sp,[r5] ;Save the stack pointer on the TCB of the preemptive task

; Get the TCB address of the high priority task [page]

LDR r6,addr_OSTCBHighRdy

LDR r6,[r6]

LDR sp,[r6] ;Get the stack pointer of the new task

；OSTCBCur=OSTCBHighRdy

STR r6,[r4]

; Get the TCB address of the current new task

LDMFD sp!,{r4}

MSR SPSR_cxsf,r4

LDMFD sp!,{r4}

MSR SPSR_cxsf,r4

LDMFD sp!,{r0-r12,lr pc}

OSIntCtxSw(); interrupt-level task switching function

LDMIA sp!,{al-vl,lr}

SUBS pc,lr,#4

SUB lr,lr,#4

MOV r12,lr

MRS lr,SPSR

AND lr,lr,#0XFFFFFE0

ORR lr,lr,#0XD3

MSR CPSR_CXSF,lr

OSTickISR() ;Interrupt service function

STMDB sp!,{r0-r11,lr}

MRS r0,CPSR

ORR r0,r0,#0x80; ;Set interrupt disable flag

MSR CPSR_cxsf,r0 ;Interrupt end

LDR r0,I_ISPC

LDR r1,=BIT_TIMER0

STR r1,{r0}

BL IrqStart

BL osTimeTick

BL IrqFinish

LDR r0,=need_to_swap_context

LDR R2,[R0]

CMP r2,#1

LDREQ pc,=_CON_SW

After completing the above work, μC/OS-II can run on the ARM processor.

3 Issues to note when using μC/OS-II system

①μC/OS-II is different from time-sharing operating systems such as Linux and does not support time slice rotation. It is a priority-based real-time operating system. The priority of each task must be different (analyzing its source code will reveal that μC/OS-II uses the priority of the task as the task identifier. If the priority is the same, the tasks will be indistinguishable). The task with the highest priority that enters the ready state will first obtain the right to use the CPU. Only after it hands over the right to use the CPU can other tasks be executed. Therefore, it can only be multi-tasking, not multi-process, at least not the kind of multi-process we are familiar with.

②μC/OS-II provides a protection mechanism for shared resources. μC/OS-II is an operating system that supports multitasking. We can divide a complete program into several tasks, and different tasks perform different functions. For shared resources (such as serial ports), μC/OS-II also provides a good solution. Generally, the semaphore method is used. We create a semaphore and initialize it. When a task needs to use a shared resource, it must first apply for this semaphore. In this process, even if a task with a higher priority enters the ready state, it cannot use the resource because it cannot obtain the semaphore. In μC/OS-II, it is called priority inversion. Simply put, the high-priority task must wait for the completion of the low-priority task. In the above case, it is inevitable that the priority will be reversed between the two tasks. Therefore, when using μC/OS-II, you must have a clear understanding of the system you are developing before you can choose whether to use a semaphore for a certain shared resource.

③μC/OS-II memory management is not perfect. In analyzing many μC/OS-II application examples, it is found that the creation of task stack space and memory partitions adopts the method of defining global arrays, which is simple to implement but not flexible and effective enough.

The compiler will put the global array as an uninitialized global variable in the data segment of the application image. The size of the array is fixed and cannot be changed dynamically during use after the image is generated. For the task stack space, a large array definition will cause memory waste; a small definition will cause the task stack to overflow and cause the system to crash. For memory partitions, it is difficult to define the size of the array used by the memory partition without knowing how much free memory space is left for the user after the system is initialized. In addition, μC/OS-II currently only supports fixed-size memory partitions, which can easily cause memory waste. μC/OS-II should be improved in the future to support variable-size memory partitions. Therefore, it is important to clearly understand the free memory space after the system is initialized. Therefore, the use of global arrays to allocate memory space should be avoided. The key is to know the size of the code segment and data segment of the entire application after compilation and linking, how they are located in the target board memory, and the size of the target board memory.

In short, with the increasing complexity of various intelligent embedded systems and the increasing real-time requirements of the systems, and with the accelerated development of application software towards systematization, the powerful real-time operating system μC/OS-II will have greater development.