Design and implementation of a universal driver framework under μC/OS-II

1. Overview

Using embedded operating systems in embedded application systems can improve the development efficiency of application systems and enhance the stability and reliability of embedded application systems. Therefore, using embedded operating systems in embedded application systems will become the mainstream design of embedded application systems [1]. μC/OS-II is an excellent embedded real-time operating system designed by American scholar Labrosse [2]. It is an open-source, portable, curable, customizable, preemptive real-time multitasking operating system that has been widely used.

μC/OS-II provides the basic functions that an operating system must have, including task management, semaphore management, mailbox management, message queue management, event management, time management, and memory management, but it does not provide device management and file system management. Some researchers have expanded the file subsystem functions of μC/OS-II [3]. In practical applications, effective management of system devices is also a very important task. Therefore, it is necessary to expand μC/OS-II to achieve this function. This paper designs a universal driver framework for μC/OS-II to manage system devices in a unified manner. Under this framework, the differences in system hardware can be shielded. Under the premise of unconstrained use of hardware capabilities, a unified and consistent calling interface API is provided for upper-level applications, thereby achieving effective management of system devices.

2. Basic model of the general driver framework under μC/OS-II

In order to provide a unified and consistent system device call interface for upper-level applications, it is necessary to abstract the access operations of upper-level applications to system devices. In this regard, Unix and Linux systems have been relatively successful [4][5]. This paper draws on the successful experience of Unix and Linux systems, and at the same time takes into account the particularity of embedded operating systems, and establishes a general driver framework model for μC/OS-II as shown in Figure 1. The general driver framework model shown in Figure 1 includes three levels:

(1) Upper-layer access abstract interface layer: At this layer, through the abstraction of device access operations, five access interface APIs are provided for upper-layer applications: UDFOpen, UDFRead, UDFWrite, UDFIoctrl, and UDFClose, which are used to open the device, read the device, write the device, control the device, and close the device, respectively.

(Figure 1 General driver framework model)

(2) Device management core data structure layer: This is the core of the general driver framework. At this layer, a unique device name is assigned to each hardware device in the system. The upper-level application passes the device name as a parameter to the UDFOpen function to locate and address the core management data structure of the corresponding device. Through addressing, the UDFOpen function obtains the core management data structure of the corresponding device, locates the corresponding device driver module, obtains the operation function table of the corresponding hardware device, and then accesses other interface functions of the abstract interface layer through the upper layer, such as UDFRead, UDFWrite, UDFIoctrl, and UDFClose, to achieve unified access control of the device.

(3) Hardware device driver module layer: This layer is the implementation layer of the hardware device driver module function. The driving of each hardware device is completed in the corresponding hardware device driver module. In principle, each hardware device driver module needs to implement the following functions: devOpen, devRead, devWrite, devIoctrl and devClose to respectively complete the opening, reading, writing, control and closing of the corresponding device. Of course, according to the characteristics of the specific device, only part of the five driver functions can be implemented. For example, if a device does not support write operations, then there is no need to implement the devWrite function.

The following is a brief description of the working principle of the model: First, before the upper-layer application can access the hardware device, it needs to open the device to be operated, which can be achieved by calling the UDFOpen function of the "upper-layer access abstract interface layer". The upper-layer application passes the device name of the device to be opened to the UDFOpen function. The UDFOpen function obtains the core data structure of the corresponding device from the "device management core data structure" through the device name, and then obtains the operation function table of the corresponding device, and calls the devOpen function of the device driver module to initialize the device. When the initialization of the corresponding device is completed, the UDFOpen function returns a handle to the upper-layer application, which is the basis for the upper-layer application to perform subsequent device operations. Now suppose that the upper-layer application needs to read data from the device, which is accomplished by calling the UDFRead function of the "upper-layer access abstract interface layer": the upper-layer application passes the device handle and related read parameters returned by the UDFOpen function to the UDFRead function, which uses the handle to obtain the core data structure of the corresponding device from the "device management core data structure", and then obtains the operation function table of the corresponding device, and calls the devRead function of the device driver module to perform a read operation on the device. When the read operation is completed, the read data is returned to the upper-layer application. Other operations such as UDFWrite, UDFIoctrl, and UDFClose are similar.

3. Implementation of the general driver framework under μC/OS-II

3.1 Implementation Environment

This paper implements the designed universal driver framework in the following environment: the development tool uses ARM's ADS 1.2, and the target board uses the SmartARM2210 development board developed by Zhou Ligong Company with LPC2210 as the microcontroller [6]. LPC2210 is a microcontroller with ARM7TDMI-S as the core, supporting 8-bit, 16-bit, and 32-bit buses, and has a wealth of on-chip peripherals, including two UART interfaces with 16-Bytes FIFO and a high-speed I2C interface. The development host is connected to the target board via EasyJTAG to establish a cross-development debugging environment.

3.2 Design and implementation of device management core design data structure

As mentioned above: the general driver framework is centered on the "device management core data structure", which plays a connecting role in the model. The device management core data structure includes two structures: UDFFrAMEwork and UDFOperatioNS, which are defined as follows:

typedef STruct {

INT8U deviceName[UDF_MAX_NAME]; //Device name

INT8U deviceType; //1—block device, 2—character device;

INT8U canShared; //0---cannot be shared, 1--can be shared

INT16U openCount; //For shared devices, this field is the count of the number of times it is opened;

UDFOperatiONs op; //Device operation function table provided by the device driver module;

} UDFFramework;[page]

This structure describes the characteristics of the system device, including: device name, device type, open count of shared devices, device operation function table, etc. It describes all devices in the system by establishing an array of UDFFramework structures, and locates the device operation function table UDFOperations structure through the device name field deviceName. The UDFOperations structure is defined as follows:

typedef struct {

INT32S (*devOpen)(void *pd);

INT32S (*devRead)(INT8S *buffer, INT32U blen, INT32U lenToRead, INT8U waitType);

INT32S (*devWrite)(INT8S *buffer, INT32U lenToWrite, INT8U waitType);

INT32S (*devIoctl)(INT32U too, void *pd);

INT32S (*devClose)(void *pd);

} UDFOperations;

This structure defines the operation function table of the corresponding device. The implementation of the specific operation function is provided in the corresponding device driver module. The device driver module can be installed into the UDFFramework structure by using the device driver installation function of the universal driver framework.

3.3 Design and implementation of upper layer access abstract interface layer

Based on the device management core data structure, the upper access abstract interface layer provides 5 API functions for upper layer applications: UDFOpen, UDFRead, UDFWrite, UDFIoctrl, and UDFClose. This article uses UDFOpen and UDFRead as examples to illustrate the implementation logic of these API functions. The implementation logic of the UDFOpen function is as follows:

INT32S UDFOpen(char *deviceName, void *pd)

{

Find the device named deviceName in the UDFFramework structure array;

if (find a device named deviceName) {

if (the device has been opened by other applications) {

if (device cannot be shared)

Return error information and return;

else

Increase the device's open counter openCount by 1

}

else {

Get the UDFOperations structure data of the device from the UDFFramework structure and call the devOpen function of the device to initialize the device;

Return the array subscript of the UDFFramework structure as the handle to the upper-layer application;

}

}

else {

It prompts that the device driver is not installed and returns;

}

}

The implementation logic of the UDFRead function is as follows:

INT32S UDFRead(INT32U handle, INT8S *buffer, INT32U blen, INT32U lenToRead, INT8U waitType)

{

Determine whether the parameter handle is legal;

if (handle is legal)

return UDFF[handle].op.devRead(buffer, blen, lenToRead, waitType);

else

Return error information and return;

}

3.4 Design and implementation of hardware device driver module

This paper implements the driver module of the UART0 device and the E2PROM device of the I2C interface device CAT1025JI-30 under the universal driver framework. The UART0 device of LPC2210 meets the 16C550 industrial standard and has a 16-byte receive FIFO and a 16-byte transmit FIFO. This paper uses the interrupt method to receive data and the query method to send data. According to the design requirements of the device driver module of the universal driver framework, the following driver functions are implemented for UART0: UART0Open, UART0Read, UART0Write, UART0Ioctrl, UART0Close, and the UART0 driver module is installed into the UDFFramework structure array through the device driver installation function InstallDriver of the universal driver framework. The implementation of the driver module for the CAT1025JI-30 device is similar.

4. Conclusion

This paper designs a universal driver framework model under μC/OS-II to achieve unified and consistent management of system hardware devices, and implements it on a development board with ARM7TDMI-S as the core and LPC2210 as the microcontroller. The results show that the framework is simple to implement but has good performance in terms of efficiency and reliability. At the same time, although the framework is implemented on the LPC2210 development board, the code is written in ANSI C and can be easily ported to other types of target boards.

The author's innovation: Under μC/OS-II, a simple but efficient universal driver framework is proposed and designed. On the one hand, it expands the functionality of μC/OS-II. On the other hand, under the management of this universal driver framework, it can achieve unified management of system hardware devices and provide a unified and consistent calling interface for upper-level applications, facilitating upper-level applications' access control to hardware devices.