Method for porting from embedded operating system structured to unstructured device driver

Abstract

The application discloses a method for transplanting a structured device driver of an embedded operating system to an unstructured device driver, and belongs to the technical field of compatibility of embedded operating systems. The method takes a structured device driver of an embedded operating system with a unified management system for an embedded platform and peripheral devices as input, analyzes each part of the structured device driver of the embedded operating system, divides the driver code in a more fine-grained manner, recombines and encapsulates the function interface of the unstructured device driver, and realizes the driving development of the unstructured device driver without the unified management system for the embedded platform and the peripheral devices on new devices and complex devices, so that the code design difficulty is simplified, the development efficiency is improved, and the development time is shortened.

Description

Technical Field

[0001] This invention relates to the field of embedded operating system compatibility technology, and more specifically to a method for porting structured device drivers from embedded operating systems to unstructured device drivers. Background Technology

[0002] In recent years, embedded systems have become increasingly popular, and embedded devices are being used more and more widely. A significant portion of these embedded systems run on operating systems such as Linux and Android. These embedded operating systems have a unified, structured management system for embedded platforms and peripheral devices, and with the passage of time and widespread application, they have also provided comprehensive structured device driver support for various embedded platforms and peripheral devices.

[0003] However, in many cases, the aforementioned embedded operating systems cannot meet the real-time requirements of tasks in real-time application scenarios, necessitating the use of embedded real-time operating systems (RTOS). Embedded ROS, however, are unstructured device drivers, and most lack a unified management system for peripherals. Different operating systems have different software interface definitions, and even within the same operating system, each peripheral driver has its own distinct software interface. Furthermore, embedded ROS do not offer as broad a coverage of device drivers for various embedded platforms and peripherals as operating systems like Linux. For developers of unstructured device drivers, redeveloping device drivers due to device replacement is almost unavoidable, resulting in long development cycles and significant challenges in developing complex device drivers.

[0004] Therefore, there is an urgent need to study a method for porting structured device drivers from embedded operating systems to unstructured device drivers, in order to solve the problems of long development cycles and high difficulty in developing complex device drivers. Summary of the Invention

[0005] The technical problem solved by this invention is to overcome the shortcomings of the prior art and provide a method for porting structured device drivers from embedded operating systems to unstructured device drivers, thereby shortening the development cycle for unstructured device drivers and reducing development difficulty.

[0006] The technical solution of this invention is:

[0007] A method for porting structured device drivers from embedded operating systems to unstructured device drivers includes:

[0008] Obtain device hardware information and define it at the corresponding software interface of the unstructured device driver;

[0009] Based on the device structure in the structured device driver, the corresponding software interface is constructed in the unstructured device driver;

[0010] Based on the operation function pointers in the structured device driver, obtain the device initialization operation, device-related register configuration operation, device "input" operation, and device "output" operation functions, and reassemble and encapsulate the above operations according to the unstructured device driver interface definition.

[0011] Preferably, by analyzing the physical layer file corresponding to the device in the structured device driver, hardware information related to the device is obtained, including: device manufacturer information, device control register name and function description, address space and bit width of the device control register, device interrupt number and device clock.

[0012] Preferably, the corresponding software interface is constructed in the unstructured device driver based on the device structure in the structured device driver, as follows:

[0013] The device-related structures and configuration macro definitions are obtained from the device structure definition section of the structured device driver in the embedded operating system and then ported to the header file of the unstructured device driver.

[0014] The preferred method for repackaging the device initialization operations is as follows:

[0015] Based on the device initialization operation in the structured device driver of the embedded operating system, the device is reset, the cache is cleared, and the register state is reset at the device initialization function pointer of the unstructured device driver.

[0016] The preferred method for recombining and encapsulating operations on configuration device-related registers is as follows:

[0017] Based on the configuration of device-related register operations in the structured device driver of the embedded operating system, the initial value of the device control register is configured at the device enable function pointer of the unstructured device driver, thus configuring the device to the expected working state.

[0018] The preferred method for repackaging device "input" operations is as follows:

[0019] Information is obtained from the "read" function of the structured device driver in the embedded operating system, and the "input" operation from the physical layer to the driver is implemented in the unstructured device driver based on the information.

[0020] Information is obtained from the "write" function of the structured device driver in the embedded operating system, and the "input" operation from the application layer to the driver is implemented in the unstructured device driver based on the information.

[0021] The preferred method for repackaging the device's "output" operations is as follows:

[0022] The output functionality of the "read" and "write" functions in the structured device driver of the embedded operating system is ported, and the "output" operation in the unstructured device driver is implemented based on the output functionality.

[0023] Preferably, structured device drivers refer to drivers for embedded platforms and peripheral devices that have a unified management system in the embedded operating system, and different devices use the same set of software interfaces for physical information and operation interfaces; unstructured device drivers refer to drivers for embedded platforms and peripheral devices that do not have a unified management system in the embedded operating system, and each peripheral device driver corresponds to its own different software interface.

[0024] The beneficial effects of this invention are:

[0025] This invention leverages the extensive support of embedded operating systems for various structured device drivers to enable the porting of structured device drivers to unstructured device drivers. It solves the problems of long development cycles for unstructured device drivers and high development difficulty for complex device drivers, greatly simplifies code design, improves development efficiency, and shortens development time. Attached Figure Description

[0026] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0027] Figure 1 This is a flowchart illustrating the method for porting a structured device driver from an embedded operating system to an unstructured device driver according to the present invention.

[0028] Figure 2 This is a schematic diagram illustrating the data flow of an Ethernet data transmission device in a preferred embodiment of the present invention. Detailed Implementation

[0029] The technical solutions and advantages of the present invention will be described in detail below with reference to the accompanying drawings and preferred embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0030] This invention proposes a method for migrating structured device drivers from embedded operating systems to unstructured device drivers. Structured device drivers refer to drivers for embedded platforms and peripheral devices that have a unified management system in the embedded operating system, and different devices use the same set of software interfaces for physical information and operation interfaces. Unstructured device drivers refer to drivers for embedded platforms and peripheral devices that do not have a unified management system in the embedded operating system, and each peripheral driver corresponds to its own different software interface.

[0031] The method of this invention analyzes various parts of the structured device driver in an embedded operating system, obtains device-related information, divides the driver code with finer granularity, and reassembles and encapsulates it using the software interface of the unstructured device driver, including the following steps:

[0032] Step S1: Obtain device register information;

[0033] By analyzing the physical layer file corresponding to the device in the structured device driver, hardware information related to the device is obtained, including: device manufacturer information, device control register name and function description, address space and bit width of the device control register, device interrupt number and device clock, which are defined at the corresponding software interface in the unstructured device driver.

[0034] Step S2: Construct the device structure;

[0035] Analyze the device structure definition part in the structured device driver of the embedded operating system, obtain the device-related structures and configuration macro definitions, and port them to the header file of the unstructured device driver.

[0036] Step S3: Build device operation.

[0037] This paper analyzes the operation function pointers of the structured device drivers in embedded operating systems, and further divides the device initialization operations, configuration of device-related register operations, device "input" operations, and device "output" operations into more granular categories. These operations are then recombined and encapsulated according to the function pointers and functions of the unstructured device drivers.

[0038] The device initialization part of the structured device driver in the embedded operating system is recombined and encapsulated as follows: the device is reset, cached and other stored data is cleared, and the register state is reset at the device initialization function pointer of the unstructured device driver.

[0039] The device operating state configuration part in the structured device driver of the embedded operating system is recombined and encapsulated as follows: the initial value of the device control register is configured at the device enable function pointer of the unstructured device driver to configure the device to the expected operating state.

[0040] This code retrieves information from the "read" function of a structured device driver in an embedded operating system to implement "input" operations from the physical layer to the driver in an unstructured device driver. It also retrieves information from the "write" function of a structured device driver in an embedded operating system to implement "input" operations from the application layer to the driver in an unstructured device driver.

[0041] This allows us to extract the output functionality from the "read" and "write" functions of the structured device driver in the embedded operating system and implement the "output" operation in the unstructured device driver.

[0042] This invention takes a structured device driver for an embedded operating system with a unified management system for embedded platforms and peripheral devices as input. It analyzes the various parts of the structured device driver in the embedded operating system, divides the driver code with finer granularity, and reassembles and encapsulates it according to the function interface of the unstructured device driver. This enables the development of drivers for new and complex devices for unstructured devices that do not have a unified management system for embedded platforms and peripheral devices. It simplifies the code design difficulty, improves development efficiency, and shortens development time.

[0043] Example:

[0044] Although structured device drivers differ across embedded operating systems and device types, the implementation process and methods remain the same. Taking the porting of a DMA device driver for Ethernet data transfer in an embedded Linux operating system to an unstructured DMA device driver as an example... Figure 2 This is a schematic diagram illustrating the data flow of Ethernet data transmission in a DMA device according to a preferred embodiment of the present invention. The porting process described in this embodiment is as follows: Figure 1 As shown, it includes the following steps:

[0045] Step S1: Analyze the device tree file corresponding to the DMA device in the embedded Linux system to obtain the device-related hardware information as shown in Table 1:

[0046] Table 1

[0047]

[0048]

[0049] Where `interrupt_num` is the interrupt number of the DMA device, `reg_0_addr` in the `reg` attribute is the address of the first register of the DMA device, and `reg_0_bit_width` is the bit width of the first register of the DMA device. The information for the other registers can be obtained similarly. In the header file of the unstructured DMA device driver, the corresponding macros are defined for use by the operating system.

[0050] Step S2: Analyze the DMA engine interface used by the DMA device in the embedded Linux system to obtain the DMA device descriptor definition. Construct the same device structure in the header file of the unstructured DMA device driver, as shown in Table 2:

[0051] Table 2

[0052]

[0053] Step S3: Construct device operations. Analyze the DMA device driver in the drivers directory of the Linux kernel source tree within the embedded Linux system. Implement the DMA device operation function pointers according to the interface definitions in the unstructured DMA device driver, including initializing the DMA device, configuring the relevant DMA device registers, and implementing the DMA device's "input" and "output" operations.

[0054] S31, in the unstructured device driver, allocate address space for the DMA descriptor and clear the data and status in the DMA descriptor to complete the DMA device initialization, as shown in Table 3:

[0055] Table 3

[0056]

[0057] S32, Configure the DMA descriptor to set the DMA to the expected operating state, as shown in Table 4:

[0058] Table 4

[0059]

[0060] S33, the data acquisition part of the "read" function of the DMA device is ported to the embedded Linux system, and the Ethernet data is "input" from the DDR memory unit to the DMA cache in the unstructured DMA device driver, as shown in Table 5:

[0061] Table 5

[0062]

[0063] S34, configure the DMA status flags and start DMA transfer, as shown in Table 6:

[0064] Table 6

[0065]

[0066] A DMA data transfer is successfully completed when the DMA status flag automatically switches from "1" to "0" on the hardware.

[0067] In summary, this invention provides a method for porting a DMA device driver from an embedded Linux system to an unstructured DMA device driver. Through the above description of the implementation methods, those skilled in the art can clearly see that the development process of unstructured device drivers is significantly simplified compared to traditional methods. This process fully utilizes the extensive support of embedded operating systems for various structured device drivers, reduces the difficulty of unstructured device drivers supporting new and complex devices, greatly improves development efficiency, and shortens the development cycle.

[0068] It will be understood by those skilled in the art that the above description is merely a preferred embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention are included within the scope of protection of the present invention.

Claims

1. A method for porting structured device drivers from embedded operating systems to unstructured device drivers, characterized in that, include: Obtain device hardware information and define the device hardware information at the corresponding software interface of the unstructured device driver; Based on the device structure in the structured device driver, the corresponding software interface is constructed in the unstructured device driver; Based on the operation function pointers in the structured device driver, obtain the device initialization operation, device-related register configuration operation, device "input" operation, and device "output" operation functions, and reassemble and encapsulate the above operations according to the unstructured device driver interface definition; The repackaging and recombining of device initialization operations is as follows: Based on the device initialization operation in the structured device driver of the embedded operating system, the device is reset, the cache is cleared, and the register state is reset at the device initialization function pointer of the unstructured device driver; The repackaging and recombining of operations related to configuration device registers is as follows: Based on the configuration of device-related register operations in the structured device driver of the embedded operating system, the initial value of the device control register is configured at the device enable function pointer of the unstructured device driver to configure the device to the expected working state. The repackaging of device "input" operations is as follows: Information is obtained from the "read" function of the structured device driver in the embedded operating system, and the "input" operation from the physical layer to the driver is implemented in the unstructured device driver based on the information. Information is obtained from the "write" function of the structured device driver in the embedded operating system, and the "input" operation from the application layer to the driver is implemented in the unstructured device driver based on the information. The repackaging of device "output" operations is as follows: The output functionality of the "read" and "write" functions in the structured device driver of the embedded operating system is ported, and the "output" operation in the unstructured device driver is implemented based on the output functionality.

2. The method for porting a structured device driver from an embedded operating system to an unstructured device driver according to claim 1, characterized in that, By analyzing the physical layer file corresponding to the device in the structured device driver, hardware information related to the device can be obtained, including: device manufacturer information, device control register name and function description, address space and bit width of the device control register, device interrupt number and device clock.

3. The method for porting a structured device driver from an embedded operating system to an unstructured device driver according to claim 1, characterized in that, Based on the device structure in the structured device driver, the corresponding software interface is constructed in the unstructured device driver, as follows: The device-related structures and configuration macro definitions are obtained from the device structure definition section of the structured device driver in the embedded operating system and then ported to the header file of the unstructured device driver.

4. The method for porting a structured device driver from an embedded operating system to an unstructured device driver according to claim 1, characterized in that, Structured device drivers refer to drivers for embedded platforms and peripheral devices that have a unified management system within the embedded operating system, with different devices using the same set of software interfaces for physical information and operation interfaces. Unstructured device drivers refer to drivers for embedded platforms and peripheral devices that do not have a unified management system within the embedded operating system, with each peripheral device driver corresponding to its own different software interface.

Images