Construction of μC/OS-II Hardware Abstraction Layer for LPC2292 Chip

introduction

In order to facilitate the porting of operating systems on different hardware structures, Microsoft Corporation of the United States first proposed the idea of ​​designing the underlying hardware-related parts into a separate hardware abstraction layer (HAL). The introduction of the hardware abstraction layer has greatly promoted the universality of embedded operating systems and made it possible for embedded operating systems to be widely used.

1 Introduction to μC/OS-II

μC/OS-II real-time operating system is a real-time operating system with open source code, which can be solidified, tailored, and has high stability and reliability. Its most distinctive feature is that the source code is open, which is easy to transplant and maintain. At present, μC/OS-II version 2.52 has passed the safety certification of the US Aviation Administration, and its stability and availability have been tested in practice. The application of μC/OS-II has covered many fields, such as cameras, medical equipment, audio and video equipment, etc.

2 Hardware Abstraction Layer Introduction

The hardware abstraction layer hides the hardware interface details of a specific platform and provides a virtual hardware platform for the operating system, making it hardware-independent and portable on multiple platforms. It provides abstracted hardware services to the operating system and applications through the hardware abstraction layer interface. It has the following main features:

① Hardware dependency. As the interface between the operating system and the hardware, the hardware abstraction layer (HAL) must provide the operating system with specific methods for operating the hardware.
② Operating system dependency. Different operating systems have their own software hierarchical structures, so different operating systems have specific hardware interface forms.

The hardware abstraction layer is a software layer above the hardware and below the operating system. Its main functions include:

① Initialize the system hardware;
② Provide the operating system with various interface functions for operating the hardware.

The initialization method of the system hardware is mainly provided by the hardware manufacturer; the various hardware interface functions and macro definitions of the operating system need to be written by the hardware and operating system users after they are familiar with the operating system and hardware platform. The hardware interface that μC/OS-II needs to complete mainly includes: type definition, task context switching, interrupt processing, task stack initialization and timing processing.

FIG1 is a functional diagram of the hardware abstraction layer.

Figure 1 Hardware abstraction layer functional diagram

3 Building a Hardware Abstraction Layer on LPC2292

3.1 Introduction to LPC2292

The LPC2292/LPC2294 microcontroller is based on a 16/32-bit ARM7TDMIS CPU that supports real-time emulation and embedded trace, with 256 KB of embedded high-speed Flash memory. The 128-bit wide memory interface and unique acceleration structure enable 32-bit code to run at the highest clock rate. Applications with strict control over code size can use 16-bit Thumb mode to reduce code size by more than 30% with little performance loss.

The LPC2292/LPC2294 is particularly suitable for automotive, industrial control applications, medical systems and fault-tolerant maintenance buses due to its 144-pin package, extremely low power consumption, multiple 32-bit timers, 8-channel 10-bit ADC, 2/4 (LPC2292/LPC2294) advanced CAN, PWM channels and up to 9 external interrupt pins. The LPC2292/LPC2294 contains 76 (using external memory) to 112 (single-chip) available GPIO ports. Due to the built-in wide range of serial communication interfaces, they are also very suitable for communication gateways, protocol converters and many other applications.

3.2 Type Definition

When porting μC/OS-II to the LPC2292 processor, first perform basic configuration and data type definition. Redefining data types is to increase the portability of the code, because different compilers provide different data lengths for the same data type. For example, int type is 16 bits in some compilers and 32 bits in others. Therefore, in order to facilitate porting, data types need to be redefined. The μC/OS-II type definitions are as follows:

typedef unsigned char BOOLEAN;/*Boolean variable*/
typedef unsigned char INT8U;/*Unsigned 8-bit integer variable*/
typedef signed char INT8S;/*Signed 8-bit integer variable*/
typedef unsigned short INT16U;/*Unsigned 16-bit integer variable*/
typedef signed short INT16S;/*Signed 16-bit integer variable*/
typedef unsigned int INT32U;/*Unsigned 32-bit integer variable*/
typedef signed intINT32S;/*Signed 32-bit integer variable*/
typedef floatFP32;/*Single-precision floating point number (32-bit length)*/
typedef doubleFP64;/*Double-precision floating point number (64-bit length)*/
typedef INT32UOS_STK;/*Stack is 32 bits wide*/

3.3 Task stack initialization

In μC/OS-II, the function OSTaskStkInit() initializes the task stack. In LPC2292, the task stack space is PC, LR, R12, R11, ..., R1, R0, CPSR, SPSR from high to low. After the stack is initialized, OSTaskStkInit() returns the new stack top pointer. Figure 2 shows the direction of task stack growth. The initialization process is as follows:

*stk = (OS_STK) task;/*PC*/
*--stk = (OS_STK) task;/*LR*/ //Register initialization R12 to R1
*--stk = 0;/*R12*/
*--stk = 0;/*R1*/
*--stk = (OS_STK)pdata;/* R0, parameter*/
*--stk = (USER_USING_MODE|0x00);/*SPSR, enable IRQ, FIQ interrupts*/[page]

Figure 2 The direction of stack growth

3.4 Task Context Switching

Task context management is responsible for the creation, deletion, and switching of task register contexts by the task management part in the embedded operating system kernel. The register context of a task is an important part of the tasks managed by the operating system kernel and is an image of the contents in the registers of the CPU kernel. Therefore, the implementation of context management depends on the organization of registers in the CPU kernel and is closely related to the architecture. The task context management of the general hardware abstraction layer uniformly defines the protection format of the register context in the architecture and provides an API interface for the basic operations of task management on the task context.

The task switching of μC/OS-II is actually achieved by changing the content in PC. PC is pointed to the place where the new task starts to run, and the current task (preempted task) environment is saved to the corresponding task stack, and the new task environment is restored from the task stack to the corresponding register.

μC/OS-II uses OS_TASK_SW() to complete task-level switching. When μC/OS-II is ported to LPC2292, the task switching code is as follows:

;OS_TASK_SW
;/****************************************************
;① Save the current task environment in the stack of the current task (preempted task)
;/****************************************************
STMFDSP!, {LR}; LR is actually the PC value corresponding to the task switch
STMFDSP!, {LR}
STMFDSP!, {R0R12}
MRSR0,CPSR
STMFDSP!,{R0}
;/****************************************************
;② Get the control block address of the current task (preempted task), the address is in R0; get
the SP address of the current task (preempted task), in R1; save the new SP to
the TCB of the current task (preempted task)
;/************************************************
LDRR0,=OSTCBCur
LDRR1,[R0]
STRSP,[R1]
;/******************************************************
;③ Get the new highest priority task control block address, save the highest priority task
address to the current task address
;/************************************************
LDRR2,=OSTCBHighRdy
LDRR1,[R2]
STRR1,[R0]
;/****************************************************
;④ Get the current new task SP
;/****************************************************
LDRSP,[R1]
;/****************************************************
;⑤ Restore the task environment
;/************************************************
LDMFDSP!,{R0}
MSRSPSR_csxf,R0
LDMFDSP!,{R0R12,PC}^

3.5 Interrupt Structure and Interrupt Handler Design

The design of interrupt structure and interrupt handler is the most important part of embedded operating system HAL. The interrupt mechanism is an important means for the operating system kernel to communicate with external devices, call task systems, handle errors, and implement real-time scheduling of tasks. Therefore, the management part of the hardware abstraction layer interrupt system is the key to the entire hardware abstraction layer.

μC/OS-II uses a two-step jump method. First, a jump instruction is placed at the interrupt vector defined by the ARM processor. After jumping to the specified location, the location is mapped for the second time. The location mapping is implemented through an assembly-defined macro. When μC/OS-II is ported to LPC2292, the definition of its macro assembly is as follows:

MACRO
$IRQ_Label HANDLER $IRQ_Exception_Function
EXPORT$IRQ_Label; Output label
IMPORT$IRQ_Exception_Function; Referenced external label

$IRQ_Label
SUBLR, LR, #4; Calculate the return address
STMFDSP!, {R0R3, R12, LR}; Save the task environment
MRSR3, SPSR; Save the status
STMFDSP, {R3, SP, LR}^; Save the user status R3, SP, LR, note that
BL$IRQ_Exception_Function cannot be written back; Call the interrupt handler in C language
;/****************************************************
; Compare the current task control block and the highest priority task control block for consistency. If they are consistent, restore the task environment directly; otherwise, task switching is required when the interrupt exits, and the CPU will run the task with the highest priority instead of the task running before the interrupt
;***********************************************
LDRR0, =OSTCBHighRdy
LDRR0, [R0]
LDRR1, =OSTCBCur
LDRR1, [R1]
CMPR0, R1
ADDSP, SP, #4*3
MSRSPSR_cxsf, R3
LDMEQFDSP!, {R0R3, R12, PC}^; restore environment
LDRPC, =OS_TASK_SW; call task switch
MEND

In order to use the ISR assembly macro, each ISR managed by μC/OS-II must be defined in the file IRQ.S in the format required by the macro assembly:

XXXX_HANDLERHANDLERXXXX_Exception

in:

XXXX_HANDLER is the starting address of the ISR, that is, the starting address of the assembly macro, and is used as the address of the interrupt vector when initializing the vector interrupt controller. The user names it according to the interrupt source, that is, replaces XXXX with the specific interrupt source name.

XXXX_Exception is the name of the function written by the user in C language. This function is called by the assembly macro, and the user can name it according to the actual interrupt source, that is, replace XXXX with the specific interrupt source name.

3.6 Timing Management

μC/OS-II requires a periodic interrupt source to generate system clock beats. μC/OS-II uses Timer0 of LPC2292 as a timer to generate clock beats. The implementation steps are:

Add interrupt handler Timer0_HandlerHANDLER Timer0_Exception Configure interrupt source timer T0IR = 0xffffffff; T0TC = 0; T0TCR = 0x01; T0MCR = 0x03; T0MR0 = (Fpclk / OS_TICKS_PER_SEC); Configure vector interrupt controller extern void Timer0_Handler(void); VICVectAddr0 = (uint32)Timer0_Handler; VICVectCntl0 = (0x20 | 0x04); Enable interrupt VICIntEnable = 1<<4;

4 Conclusion

The emergence of the hardware abstraction layer means that the designers of embedded operating systems do not need to consider the large differences in the hardware environment of embedded systems. They can concentrate on designing a universal operating system and leave the interface with the hardware to the hardware abstraction layer. This greatly improves the portability of embedded operating systems between different hardware platforms. Based on the LPC2292 hardware platform, this article details the construction method of the hardware abstraction layer of μC/OS-II, and provides a reference for its porting to other platforms.