Driver construction method, device and related equipment

Abstract

The present application provides a driver construction method, apparatus, and related equipment, the method comprising: obtaining basic code and a driver framework corresponding to an operating system; parsing the basic code to extract multiple external device information, wherein the multiple external device information includes the type of the external device, and the multiple external devices include devices other than the core in the chip; obtaining target external device information from the multiple external device information whose type matches the driver framework; docking the target external device information with the driver framework to obtain a correspondence between the target external device information and the driver framework; obtaining a driver file corresponding to the target external device information in the driver framework based on the correspondence, and using the driver file to construct a driver. The present application can improve the readability and maintainability of the code.

Description

Technical Field

[0001] The present application relates to the technical field of operating system driver construction, and in particular to a driver construction method, apparatus, and related equipment. Background Art

[0002] In the existing technology, there is no unified driver construction method for embedded operating systems of chips. Some operating systems use the official original old version BSP (Board Support Package) library for continuous compatibility and expansion. The framework is redundant and complex, and the readability and maintainability are poor. Summary of the Invention

[0003] The present application provides a driver construction method, apparatus and related equipment to solve the problem of poor code readability and maintainability.

[0004] In a first aspect, an embodiment of the present application provides a driver construction method, comprising:

[0005] Obtain the basic code and driver framework corresponding to the operating system;

[0006] Parsing the base code to extract a plurality of external device information, wherein the plurality of external device information includes types of a plurality of external devices, and the plurality of external devices include devices other than a core in the chip;

[0007] Acquire target external device information whose type matches the driver framework from among the plurality of external device information;

[0008] Connecting the target external device information with the driving framework to obtain a corresponding relationship between the target external device information and the driving framework;

[0009] A driver file corresponding to the target external device information in the driver framework is obtained based on the corresponding relationship, and a driver is constructed using the driver file.

[0010] In a second aspect, an embodiment of the present application further provides a drive construction device, comprising:

[0011] A first acquisition module is used to acquire the basic code and driver framework corresponding to the operating system;

[0012] a parsing module, configured to parse the basic code to extract a plurality of external device information, wherein the plurality of external device information includes types of a plurality of external devices, and the plurality of external devices include devices other than the core in the chip;

[0013] A second acquisition module is configured to acquire target external device information whose type matches the driving framework from among the plurality of external device information;

[0014] a docking module, configured to dock the target external device information with the driving framework to obtain a corresponding relationship between the target external device information and the driving framework;

[0015] The third acquisition module is configured to acquire a driver file corresponding to the target external device information in the driver framework based on the corresponding relationship, and construct a driver using the driver file.

[0016] In a third aspect, an embodiment of the present application further provides a communication device comprising: a transceiver, a memory, a processor, and a program stored in the memory and executable on the processor; the processor being characterized in that the processor is configured to read the program in the memory to implement the steps of the method described in the first aspect above.

[0017] In a fourth aspect, an embodiment of the present application further provides a readable storage medium for storing a program, which, when executed by a processor, implements the steps in the method described in the first aspect above.

[0018] In an embodiment of the present application, by obtaining target external device information whose type matches the driver framework from the multiple external device information, the target external device information is connected to the driver framework to obtain the correspondence between the target external device information and the driver framework, and based on the correspondence, the driver file corresponding to the target external device information in the driver framework is obtained, and the driver is constructed using the driver file to achieve support for the operating system, thereby improving the readability and maintainability of the driver code. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] In order to more clearly illustrate the technical solution of the present application, the following is a brief introduction to the drawings required for use in the embodiments or descriptions of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0020] Figure 1 This is one of the flowcharts of the driver construction method provided in the embodiment of the present application;

[0021] Figure 2 This is the second flow chart of the driver construction method provided in the embodiment of the present application;

[0022] Figure 3 This is a schematic diagram of the basic code directory provided by the embodiment of the present application;

[0023] Figure 4 This is one of the structural diagrams of the drive construction device provided in the embodiment of the present application;

[0024] Figure 5This is the second structural diagram of the drive construction device provided in the embodiment of the present application;

[0025] Figure 6 This is the third structural diagram of the drive construction device provided in the embodiment of the present application;

[0026] Figure 7 This is the fourth structural diagram of the drive construction device provided in the embodiment of the present application;

[0027] Figure 8 This is the fifth structural diagram of the drive construction device provided in the embodiment of the present application;

[0028] Figure 9 It is a structural diagram of the communication device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0029] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0030] The terms "first", "second" etc. in the embodiments of the present application are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequential order. In addition, the terms "comprise" and "have" and any deformation thereof are intended to cover non-exclusive inclusions, such as, the process, method, system, product or equipment comprising a series of steps or units need not be limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or that are intrinsic to these processes, methods, products or equipment. In addition, "and / or" is used in the present application to represent at least one of connected objects, such as A and / or B and / or C, and represents comprising independent A, independent B, independent C, and A and B all exist, B and C all exist, A and C all exist, and 7 situations that A, B and C all exist.

[0031] See also Figure 1 , Figure 1 This is one of the flowcharts of the driver construction method provided in the embodiment of the present application, such as Figure 1 As shown, the following steps are included:

[0032] Step 101: Obtain the basic code and driver framework corresponding to the operating system.

[0033] Wherein, above-mentioned basic code can be generated using general configuration tools, and reliability and versatility are higher, for example: for STM32 series chips, corresponding official configuration tool STM32CubeMX can be used to carry out general external device configuration and according to the setting requirements of operating system, some settings are configured, compatibility to different series chips can be improved, and reliability and versatility of generated code are improved. In addition, the basic code generated above corresponds to the BSP (Board Support Package, board support package) external device configuration of the above-mentioned operating system.

[0034] Step 102: Parse the basic code to extract a plurality of external device information, where the plurality of external device information includes types of a plurality of external devices, and the plurality of external devices include devices other than the core in the chip.

[0035] Specifically, the aforementioned external devices may include functional modules such as a timer, a UART (Universal Asynchronous Receiver / Transmitter), an SPI (Serial Peripheral Interface), a USB (Universal Serial Bus), an I2C (Inter-Integrated Circuit), and memory. The specific external devices corresponding to different chips may vary. Therefore, the extracted information about the multiple external devices can be information about the external devices corresponding to the chip, or it can be understood as information about the actual external devices in use.

[0036] Step 103: Obtain target external device information whose type matches the driving framework from among the plurality of external device information.

[0037] Among them, the above matching can be achieved by using a script to parse the above basic code. For example, the above basic code may include a main.c (chip and external device initialization code) file, a stm32xxxx_hal_msp.c (external device pin and clock initialization code) file, a stm32xxxx_it.c (interrupt management related code) file, and a system_stm32xxxx.c (chip management related code) file. The main.c file and the stm32xxxx_hal_msp.c file in the basic code can be parsed by a pre-set parsing script, and the external devices in the above basic code can be found by text character matching, and the information of the above-mentioned matched target external device can be extracted. Specifically, the above-mentioned target external device information may include information such as the handle, type, and name of the corresponding external device.

[0038] Step 104: docking the target external device information with the driving framework to obtain a corresponding relationship between the target external device information and the driving framework.

[0039] The docking of the target external device information with the driver framework may include docking of the target external device information list with the driver framework, wherein each target external device information corresponds to a device driver file, and correspondingly, the correspondence may include a correspondence between the target external device information list and the driver framework. Through the correspondence between the target external device information list and the driver framework, the device driver file corresponding to the target external device information in the driver framework can be determined. Thus, the docking process can be completed based on the target external device information, and the driver file corresponding to the driver can be determined to complete the driver construction.

[0040] Step 105: Obtain a driver file corresponding to the target external device information in the driver framework based on the corresponding relationship, and construct a driver using the driver file.

[0041] It is understood that after obtaining the correspondence between the target external device information and the driver framework according to the above steps, the driver file corresponding to the target external device can be obtained, and a driver can be constructed based on the target external device information, the correspondence between the target external device information and the driver framework, and the driver file. The constructed driver can avoid the existing problem of constraining the performance of some external devices due to considerations of framework compatibility, thereby optimizing the performance of these devices.

[0042] In an embodiment of the present application, by obtaining target external device information whose type matches the driver framework from the multiple external device information, the target external device information is connected to the driver framework to obtain the correspondence between the target external device information and the driver framework, and based on the correspondence, the driver file corresponding to the target external device information in the driver framework is obtained, and the driver is constructed using the driver file to achieve support for the operating system, thereby improving the readability and maintainability of the driver code.

[0043] In addition, some operating systems require customers to implement driver framework docking by themselves by providing upper-level interfaces, which is not customer-friendly. However, the embodiments of the present application obtain the basic code and driver framework corresponding to the operating system. The reliability and versatility of the basic code are high, and based on the corresponding relationship, the driver file corresponding to the target external device information in the driver framework is obtained, and the driver is built using the driver file, which automatically completes the selection and docking of the driver framework, making it more convenient for customers to use.

[0044] Optionally, parsing the basic code to extract multiple pieces of external device information in step 102 may specifically include:

[0045] Obtain common information from different external devices;

[0046] Constructing a parsing script based on the common information of the different external devices;

[0047] The base code is parsed based on the parsing script to extract a plurality of external device information.

[0048] It can be understood that the above-mentioned common information can also include the structure of different external devices. After finding the common information and structure of different external devices, the above-mentioned parsing script can be constructed according to the common information of different external devices determined above to realize the parsing of the basic code generated by different external device configurations, and the external device information in the above-mentioned basic code can be extracted by constructing an appropriate parsing script and using the text character matching of the parsing script.

[0049] In this embodiment, the basic code is parsed based on the parsing script to extract multiple external device information. The parsing script can be constructed according to the common information of different external devices to improve the compatibility with different external device information extraction methods.

[0050] Optionally, parsing the basic code based on the parsing script to extract multiple external device information includes:

[0051] matching a plurality of external devices based on the parsing script;

[0052] Retrieving handles of the plurality of external devices;

[0053] The plurality of external device information is acquired based on the handle.

[0054] Specifically, taking STM32 series chips as an example, above-mentioned basic code can use corresponding official tool STM32CubeMX software to generate, and basic external device code is maintained and configured for the needs of operating system by graphical configuration tool, improves the reliability and versatility of code, and improves the reliability and versatility of different series. Other series chips can also extract external device information according to the above method, and external device information can be flexibly defined, and this application does not limit this.

[0055] In this implementation, multiple external devices are matched based on the parsing script, handles of the multiple external devices are extracted, and the corresponding external device information can be obtained based on the handles.

[0056] Optionally, after obtaining the basic code and driver framework corresponding to the operating system in step 101, the method may further include the following steps:

[0057] Modify the name and function type of a first file in the base code based on the parsing script, where the first file includes chip and external device initialization code;

[0058] The driver calls the modified first file to initialize the chip and external devices.

[0059] Among them, the above-mentioned first file includes the chip and external device initialization code. The above-mentioned first file can correspond to the main.c file therein, and the main.c file can be modified to generate a bsp.c file through the above-mentioned parsing script: the main function in the above-mentioned first file is modified, that is, the main function is changed from a loop type function to a return type function, and a bsp.c file is generated, so that the operating system driver can call the above-mentioned bsp.c file to realize the initialization of the chip and external devices.

[0060] In this implementation, the name and function type of the first file in the basic code are modified based on the parsing script, and the driver can call the modified first file to initialize the chip and external devices.

[0061] Optionally, the step 104 of docking the target external device information with the driving framework to obtain a corresponding relationship between the target external device information and the driving framework includes:

[0062] Registering the target external device information into the driver framework;

[0063] The target external device information is connected to the driving framework by calling the encapsulation library to obtain the corresponding relationship between the target external device information and the driving framework.

[0064] It can be understood that after the above-mentioned target external device information is registered in the above-mentioned driver framework, there is a corresponding relationship between the above-mentioned target external device information and the information in the above-mentioned driver framework. In this way, by calling the encapsulation library to dock the above-mentioned target external device information with the above-mentioned driver framework, the docking code between the above-mentioned target external device information and the above-mentioned driver framework can be realized, that is, the corresponding relationship between the above-mentioned target external device information and the above-mentioned driver framework.

[0065] In this implementation, the extracted target external device information is connected to the driver framework to implement the driver construction, which can avoid the situation where the performance of some external devices is restricted due to compatibility considerations.

[0066] For easier understanding, the following examples are provided:

[0067] like Figure 2 As shown, Figure 2 This is the second flowchart of the driver construction provided in the embodiment of the present application, such as Figure 2 As shown, the following process may be included:

[0068] Use the official tool STM32CubeMX for graphical configuration: perform general external device configuration and configure some settings according to the operating system's setting requirements to generate basic code related to BSP external device configuration;

[0069] By thinking about the driver framework and refining the requirements of the driver framework layer, we found the common information and structure of different external devices, used the parsing script to parse the code generated by STM32CubeMX, and connected it to the driver framework layer: we added the parsing script to the scons automated build tool of the operating system, parsed the script before building, extracted the external device information, implemented the framework docking code, and added the usage flags of the external devices;

[0070] Add the corresponding driver framework file to the scons automated build tool to implement driver building.

[0071] Among them, the above-mentioned general external device configuration can use the official tool STM32CubeMX to maintain the basic external device code, thereby effectively improving the reliability and versatility of the code; the above-mentioned configuration of some settings according to the setting requirements of the operating system mainly includes the configuration of kernel task management interrupts, etc. The generated basic code directory is as follows Figure 3 As shown. The configuration process in the official tool STM32CubeMX can be understood as a prerequisite for implementing the above-mentioned driver construction. Specifically, it may include: canceling the interrupt entry used by the embedded operating system, configuring the system clock, and configuring external devices. By using the official graphical configuration tool STM32CubeMX for visual configuration and generating basic code, maximum compatibility with different series of STM32 chips can be achieved. Moreover, through specific configurations, such as configuring external devices and performing partial configuration according to the set requirements of the operating system, support for embedded operating systems can be achieved, improving the scalability and robustness of the code.

[0072] The above-mentioned parsing of the code generated by STM32CubeMX using the parsing script can specifically include the following process: Figure 3The main.c file and stm32xxxx_hal_msp.c file in the basic code directory are parsed. The text character matching of Python can be used to find the external devices actually used, and they are extracted in order and by name. For the STM32 series, the handle of the corresponding external device needs to be extracted, so that the official initialization information of the corresponding external device can be obtained, and the type and name of the external device can be written using this information; OS_DRIVER_DEFINE is used to bring stm32_xxx_driver into the registration process to register the external device: during the registration process, the above external device information is matched with the information in the driver architecture. When the types are the same, stm32_xxx_driver is called to register the above external device to the driver framework; the official encapsulation library is called for operation and docking to realize the driver design.

[0073] Among them, Figure 2 As shown, adding the corresponding driver framework file to the scons automated build tool can specifically include: obtaining the general device framework layer, the specific device framework layer, the device implementation + HAL library (Hardware Abstraction Layer, hardware abstraction layer), and obtaining the complete device driver file. Figure 2 As shown in the figure, after completing the external device information extraction, framework docking code implementation and adding the usage flag of the device through the parsing script, the driver construction can be realized by adding the corresponding driver file in the scons build tool.

[0074] In addition, the above driver building process can also include calling the parsing script (prebuild.py) to operate the main.c file, modifying the main.c file and generating the bsp.c file. The specific process includes: modifying the main function in the main.c file, changing the main function from a loop type function to a return type function, so that the operating system driver can call the hardware_init function in the bsp.c file to initialize the chip and external devices, such as Figure 3 As shown, the bsp.c file generated by the above call parsing script corresponds to Figure 3 bsp.c file in the directory (script conversion generated file).

[0075] In the embodiment of the present application, by means of the official graphical configuration tool STM32CubeMX of STM32, the maximum compatibility with different series of STM32 chips is achieved, configuration visualization is performed, and specific configuration is performed simultaneously, support for embedded operating systems is achieved, and the scalability and robustness of code are improved. Furthermore, by using appropriate parsing scripts and scons automated build tools, the parsing and rewriting of the basic code generated by official tool STM32CubeMX is achieved, the initialization code and external device information related to driving are obtained, so as to automatically complete the selection and docking of driver framework, and the whole process user is non-sensical, and allows customers to use more conveniently.

[0076] See also Figure 4 , Figure 4 This is one of the structural diagrams of the drive construction device provided in the embodiment of this application. Figure 4 As shown, the drive construction device 400 includes:

[0077] The first acquisition module 401 is used to acquire the basic code and driver framework corresponding to the operating system;

[0078] A parsing module 402 is configured to parse the basic code to extract a plurality of external device information, wherein the plurality of external device information includes types of a plurality of external devices, and the plurality of external devices include devices other than the core in the chip;

[0079] The second acquisition module 403 is configured to acquire target external device information whose type matches the driving framework from among the plurality of external device information;

[0080] The docking module 404 is used to dock the target external device information with the driving framework to obtain a corresponding relationship between the target external device information and the driving framework;

[0081] The third acquisition module 405 is configured to acquire a driver file corresponding to the target external device information in the driver framework based on the corresponding relationship, and construct a driver using the driver file.

[0082] Optional, such as Figure 5 As shown, the parsing module 402 may specifically include:

[0083] An acquisition unit 4021 is used to acquire common information of different external devices;

[0084] A construction unit 4022 is configured to construct a parsing script based on the common information of the different external devices;

[0085] The parsing unit 4023 is configured to parse the basic code based on the parsing script to extract a plurality of external device information.

[0086] Optional, such as Figure 6 As shown, the parsing unit 4023 may specifically include:

[0087] The parsing subunit 40231 is configured to match multiple external devices based on the parsing script;

[0088] The extraction subunit 40232 is used to extract the handles of the multiple external devices;

[0089] The acquisition subunit 40233 is configured to acquire the plurality of external device information based on the handle.

[0090] Optional, such as Figure 7 As shown, the driver construction device 400 may further include:

[0091] A modification module 406 is configured to modify the name and function type of a first file in the base code based on the parsing script, the first file including chip and external device initialization code;

[0092] The calling module 407 is used for the driver to call the modified first file to initialize the chip and external devices.

[0093] Optional, such as Figure 8 As shown, the docking module 404 may specifically include:

[0094] A registration unit 4041 is configured to register the target external device information in the driver framework;

[0095] The docking unit 4042 is configured to dock the target external device information with the driver framework by calling a packaging library to obtain a corresponding relationship between the target external device information and the driver framework.

[0096] The drive construction device 400 can realize the embodiment of the present application Figure 1 The various processes of the method embodiment and the achievement of the same beneficial effects are not described again here to avoid repetition.

[0097] The present application also provides a communication device. Figure 9 The communication device may include a processor 901, a memory 902, and a program 9021 stored in the memory 902 and executable on the processor 901. When the program 9021 is executed by the processor 901, Figure 1 Any steps in the corresponding method embodiments and achieving the same beneficial effects will not be repeated here.

[0098] A person skilled in the art will understand that all or part of the steps of the above-mentioned embodiment method can be completed by hardware related to program instructions, and the program can be stored in a readable medium. The embodiment of the present application also provides a readable storage medium on which a computer program is stored, and when the computer program is executed by a processor, the above-mentioned method can be implemented. Figure 1 Any steps in the corresponding method embodiments can achieve the same technical effects and will not be described again here to avoid repetition.

[0099] The storage medium may be a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0100] The above is a preferred implementation of the embodiment of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles described in the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A driver construction method, characterized in that: include: Obtain the basic code and driver framework corresponding to the operating system; Parsing the base code to extract a plurality of external device information, wherein the plurality of external device information includes types of a plurality of external devices, and the plurality of external devices include devices other than a core in the chip; Acquire target external device information whose type matches the driver framework from among the plurality of external device information; Connecting the target external device information with the driving framework to obtain a corresponding relationship between the target external device information and the driving framework; Based on the corresponding relationship, a driver file corresponding to the target external device information in the driver framework is obtained, and a driver is constructed using the driver file; The parsing of the basic code to extract a plurality of external device information includes: Obtain common information from different external devices; Constructing a parsing script based on the common information of the different external devices; The base code is parsed based on the parsing script to extract a plurality of external device information.

2. The method according to claim 1, wherein Parsing the basic code based on the parsing script to extract a plurality of external device information includes: matching a plurality of external devices based on the parsing script; Retrieving handles of the plurality of external devices; The plurality of external device information is acquired based on the handle.

3. The method according to claim 2, wherein After obtaining the basic code and driver framework corresponding to the operating system, the method further includes: Modify the name and function type of a first file in the base code based on the parsing script, where the first file includes chip and external device initialization code; The driver calls the modified first file to initialize the chip and external devices.

4. The method according to claim 1, wherein The step of docking the target external device information with the driving framework to obtain a corresponding relationship between the target external device information and the driving framework includes: Registering the target external device information into the driver framework; The target external device information is connected to the driving framework by calling the encapsulation library to obtain the corresponding relationship between the target external device information and the driving framework.

5. A drive construction device, characterized in that: include: A first acquisition module is used to acquire the basic code and driver framework corresponding to the operating system; a parsing module, configured to parse the basic code to extract a plurality of external device information, wherein the plurality of external device information includes types of a plurality of external devices, and the plurality of external devices include devices other than the core in the chip; A second acquisition module is configured to acquire target external device information whose type matches the driving framework from among the plurality of external device information; a docking module, configured to dock the target external device information with the driving framework to obtain a corresponding relationship between the target external device information and the driving framework; A third acquisition module is configured to acquire a driver file corresponding to the target external device information in the driver framework based on the corresponding relationship, and construct a driver using the driver file; The parsing module includes: an acquisition unit, used for acquiring common information of different external devices; A construction unit, configured to construct a parsing script based on the common information of the different external devices; A parsing unit is used to parse the basic code based on the parsing script to extract multiple external device information.

6. The device according to claim 5, characterized in that The docking module includes: A registration unit, configured to register the target external device information in the driver framework; The docking unit is used to dock the target external device information with the driving framework by calling the encapsulation library to obtain the corresponding relationship between the target external device information and the driving framework.

7. A communication device comprising: A transceiver, a memory, a processor, and a program stored in the memory and executable on the processor; wherein the processor is configured to read the program in the memory to implement the steps of the driver construction method as described in any one of claims 1 to 4.

8. A readable storage medium for storing a program, characterized in that: When the program is executed by a processor, the steps of the driver construction method according to any one of claims 1 to 4 are implemented.

Images