Configuration generation method, embedded equipment, device and storage medium

Abstract

The invention relates to the technical field of embedded software development, and provides a configuration generation method and device, embedded equipment and a storage medium, and the method comprises the steps: obtaining a configuration item set of a peripheral module of an embedded processing chip; describing a configuration item set of each peripheral module based on a configuration description language to obtain a configuration item description file; when the configuration item description file is called by the configuration menu graphic tool, a corresponding configuration parameter input interface is generated; the configuration parameter input interface displays configuration options of each peripheral module; and generating a configuration file based on the configuration parameters of the external module received by the displayed configuration parameter input interface. Through the modifiable drive configuration of the peripheral drive separated from the onboard drive, efficient modification and adaptation of the drive source code can be completed by modifying the configuration parameters when hardware changes occur, the development efficiency is improved, migration is facilitated to meet the requirements of collaborative development, transplantation and the like, and the development and later maintenance cost is reduced.

Description

Technical Field

[0001] The present disclosure relates to the technical field of embedded software development, and in particular to a configuration generation method, an embedded device, an apparatus, and a storage medium. Background Art

[0002] In embedded system development, C has long been widely used as a core development language due to its proximity to underlying hardware, high efficiency, and portability. Specifically, C can directly manipulate registers, memory addresses, and hardware peripherals (such as timers and ADC modules), achieving precise hardware control through pointer and bit operations. This meets the stringent real-time, low-power, and resource-intensive requirements of embedded devices. For example, in industrial control, automotive electronics, and IoT devices, code written in C can be directly embedded into the firmware of microcontrollers (such as the ARM Cortex-M series) to implement key functions such as sensor data acquisition, signal processing, and communication protocol stacks. However, compared to higher-level languages ​​like Python and Java, C has significant limitations in development flexibility and engineering efficiency. First, C lacks the abstraction mechanisms inherent in high-level languages ​​(such as classes and inheritance, and garbage collection in object-oriented programming). This necessitates manual encapsulation and modular design for code reuse, resulting in relatively high development complexity.

[0003] Typically, in embedded software driver development, the driver must be matched to different hardware. A common approach is to write fixed code and parameter configurations in the code. When writing code for an embedded processing chip (such as an MCU), it is necessary to configure various registers of the peripherals and configure the drivers for the onboard hardware. Typically, because the parameter configurations for the embedded processing chip's peripherals (such as registers and interfaces) and the driver source code for the onboard hardware are fixed and cannot be modified, if the hardware design changes (such as changes to the MCU connection pins or onboard hardware), the driver source code will need to be significantly modified and tested due to the lack of development flexibility of the C language commonly used in embedded development. Major changes may even require redevelopment.

[0004] Furthermore, fixed driver source code presents significant limitations in portability and reuse, resulting in low overall project development efficiency and hindering driver source code maintenance and upgrades. For example, controlling an LED light through an MCU requires the MCU's GPIO peripheral driver source code. The GPIO output is then controlled based on the LED's lighting level to turn the LED on and off. In addition to GPIO level control, PWM control can also be used, offering more diverse control functions (such as controlling LED brightness or creating a breathing effect). These are all LED drivers, or "onboard driver source code." However, GPIO and MCU peripherals differ. A common approach is to directly implement an LED driver by writing driver source code for the corresponding GPIO or PWM pins within the driver. This can be cumbersome to modify later, and is generally limited to the current hardware. This code is not flexibly adaptable to different projects and is highly hardware-dependent, making subsequent maintenance difficult and hindering collaborative feature development. Summary of the Invention

[0005] In view of the above-mentioned shortcomings of the prior art, the purpose of the present disclosure is to provide a configuration generation method, an embedded device, an apparatus and a storage medium to solve the problems in the related art.

[0006] A first aspect of the present disclosure provides a configuration generation method, which is applied to the generation of a configuration file for a driver source code; the configuration generation method comprises: obtaining a configuration item set of a peripheral module of an embedded processing chip; describing the configuration item set of each peripheral module based on a configuration description language to obtain a configuration item description file; when the configuration item description file is called by a configuration menu graphic tool, being used to generate a corresponding configuration parameter input interface; the configuration parameter input interface displays configuration options for each peripheral module, the configuration options comprising: sub-options that are allowed to be operated to input configuration parameters; the sub-options are determined by the configuration item set; based on the configuration parameters of the peripheral module received by the displayed configuration parameter input interface, a configuration file is generated for use in configuring the driver source code; wherein, the code of the function set corresponding to the configuration item set is pre-packaged into the driver source code for selection and enablement based on the configuration file.

[0007] In an embodiment of the first aspect, the configuration parameter input interface includes: a first driver type option for selecting to configure peripheral driver source code; when the first driver type option is selected, a first configuration sub-interface including configuration options for each peripheral module is displayed.

[0008] In an embodiment of the first aspect, the configuration parameter input interface also includes: a second driver type option for selecting an onboard driver source code for configuration; a second configuration sub-interface that displays configuration options of the onboard driver source code when the second driver type option is selected, and a first configuration sub-interface corresponding to a peripheral driver source code that the onboard driver source code depends on.

[0009] In an embodiment of the first aspect, the configuration options of each peripheral module include: an enable control for being operated to select the corresponding peripheral module; and the method includes: in response to the enable control being enabled, displaying each sub-option included in the corresponding configuration option.

[0010] In an embodiment of the first aspect, the configuration parameters of the peripheral module received based on the displayed configuration parameter input interface are generated, including: in response to the first driver type option being selected, displaying a first configuration sub-interface; in response to an output operation, generating a first configuration file for the peripheral driver source code according to the input information of the configuration options in the first configuration sub-interface.

[0011] In an embodiment of the first aspect, the configuration parameters of the peripheral module received based on the displayed configuration parameter input interface are generated to generate a configuration file, including: in response to the first driver type option corresponding to the peripheral driver source code being selected, displaying a first configuration sub-interface; in response to the second driver type option corresponding to the onboard driver source code being selected, displaying a second configuration sub-interface; wherein, the second configuration sub-interface includes: a configuration option for inputting identification information of the peripheral driver source code, the identification information being used to index to call the peripheral driver source code; in response to an output operation, a second configuration file for the onboard driver source code is generated based on the input information of the configuration options in the first configuration sub-interface and the second configuration sub-interface.

[0012] In an embodiment of the first aspect, the peripheral module includes at least one of the following: GPIO, AFIO, ADC, I2C, SPI, USART, CAN, CRC; and / or the configuration item set includes any multiple of the following: a register corresponding to a target function on an embedded processing chip or a driver name in an official library, a peripheral communication mode, a peripheral pin multiplexing, a peripheral type, a data length, a data endianness, a clock rate, and a clock enable; and / or the configuration file includes: a configuration header file or a configuration static library; and / or the configuration generation method further includes: in response to hardware changes of the embedded processing chip, providing the configuration parameter input interface for updating the configuration parameters to adapt to the hardware changes, and forming an updated configuration file.

[0013] A second aspect of the present disclosure provides an embedded device, comprising: an embedded processing chip; and a memory storing a driver program, wherein the driver program is configured by using a configuration file obtained by the configuration generation method according to any one of the first aspects as a driver source code.

[0014] A third aspect of the present disclosure provides a computer device, comprising: a processor and a memory; the memory stores a computer program or instructions; the processor is configured to run the computer program or instructions to execute the configuration generation method as described in any one of the first aspects.

[0015] A fourth aspect of the present disclosure provides a computer-readable storage medium storing a computer program or instructions, wherein the computer program or instructions are executed to perform the configuration generation method as described in any one of the first aspects.

[0016] As described above, the present disclosure relates to the field of embedded software development technology, and provides a configuration generation method, embedded equipment, apparatus and storage medium, the method comprising: obtaining a configuration item set of a peripheral module of an embedded processing chip; describing the configuration item set of each peripheral module based on a configuration description language to obtain a configuration item description file; when the configuration item description file is called by a configuration menu graphical tool, it is used to generate a corresponding configuration parameter input interface; the configuration parameter input interface displays the configuration options of each peripheral module; based on the configuration parameters of the peripheral module received by the displayed configuration parameter input interface, a configuration file is generated. By separating the modifiable driver configuration of the peripheral driver from the onboard driver, the efficient modification and adaptation of the driver source code can be completed by modifying the configuration parameters when hardware changes occur, thereby improving development efficiency, facilitating migration to meet the needs of collaborative development, transplantation, etc., and reducing the cost of development and later maintenance. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 A flowchart illustrating a configuration generation method in an embodiment of the present disclosure is shown.

[0018] Figure 2 A schematic diagram showing a configuration parameter input interface generated by the menuconfig tool according to a configuration item description file in one embodiment of the present disclosure.

[0019] Figure 3 A schematic diagram showing the principle of implementing an onboard driver calling a peripheral driver in an embodiment of the present disclosure.

[0020] Figure 4 A simplified flowchart illustrating configuration from a user's perspective in an embodiment of the present disclosure is shown.

[0021] Figure 5 A schematic diagram showing the software architecture of an application in an embodiment of the present disclosure.

[0022] Figure 6 A schematic diagram of a module configuration generating device in one embodiment of the present disclosure is shown.

[0023] Figure 7 A schematic diagram showing the structure of an embedded device in an embodiment of the present disclosure is shown.

[0024] Figure 8 A schematic diagram showing the structure of a computer device in one embodiment of the present disclosure is shown. DETAILED DESCRIPTION

[0025] The following describes the embodiments of the present disclosure through specific examples. Those skilled in the art can easily understand the other advantages and effects of the present disclosure from the information disclosed in this disclosure. The present disclosure can also be implemented or applied through different specific embodiments. The details of the present disclosure can also be modified or changed according to different viewpoints and application modules without departing from the spirit of the present disclosure. It should be noted that the embodiments and features in the embodiments of the present disclosure can be combined with each other unless there is a conflict.

[0026] The following is a detailed description of the embodiments of the present disclosure with reference to the accompanying drawings so that those skilled in the art can easily implement the present disclosure. The present disclosure can be embodied in many different forms and is not limited to the embodiments described herein.

[0027] Throughout the present disclosure, reference to terms such as "one embodiment," "some embodiments," "examples," "specific examples," or "some examples" means that a specific feature, structure, material, or characteristic described in conjunction with that embodiment or example is included in at least one embodiment or example of the present disclosure. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in any one or a group of embodiments or examples. Furthermore, those skilled in the art may combine and integrate different embodiments or examples, and features of different embodiments or examples, as described in the present disclosure, without conflicting requirements.

[0028] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features being referred to. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one such feature. In the context of this disclosure, "a group" means two or more, unless otherwise specifically defined.

[0029] In order to clearly describe the present disclosure, components not related to the description are omitted, and the same or similar components throughout the specification are denoted by the same reference numerals.

[0030] Throughout this specification, when a device is said to be "connected" to another device, this includes not only "direct connection" but also "indirect connection" with other elements interposed therebetween. Furthermore, when a device is said to "include" a certain component, unless otherwise stated, this does not exclude the inclusion of other components but rather implies that the device may include other components.

[0031] Although the terms first, second, etc. are used in this document to represent various elements in some examples, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, the first interface and the second interface, etc. are represented. Furthermore, as used in this document, the singular forms "one," "an," and "the" are intended to also include the plural forms, unless there is a contrary indication in the context. It should be further understood that the terms "comprise" and "include" indicate the presence of the described features, steps, operations, elements, modules, projects, types, and / or groups, but do not exclude the presence, occurrence, or addition of one or a group of other features, steps, operations, elements, modules, projects, types, and / or groups. The terms "or" and "and / or" used herein are interpreted as inclusive, or mean any one or any combination. Therefore, "A, B, or C" or "A, B, and / or C" means "any of the following: A; B; C; A and B; A and C; B and C; A, B, and C." Exceptions to this definition only occur when the combination of elements, functions, steps, or operations is inherently mutually exclusive in some way.

[0032] The technical terms used herein are intended only to refer to specific embodiments and are not intended to limit the present disclosure. The singular form used herein also includes the plural form unless the statement explicitly indicates otherwise. The term "comprising" as used in this specification is intended to specify specific features, regions, integers, steps, operations, elements, and / or components and does not exclude the presence or addition of other features, regions, integers, steps, operations, elements, and / or components.

[0033] Although not defined differently, all terms used herein, including technical and scientific terms, have the same meanings as those generally understood by those skilled in the art to which this disclosure belongs. Terms defined in commonly used dictionaries are additionally interpreted as having meanings consistent with relevant technical literature and the current message. Unless otherwise defined, they should not be overly interpreted as ideal or highly formalized meanings.

[0034] In the field of embedded system development, C has long been widely used as a core development language due to its proximity to underlying hardware, efficiency, and portability. Code written in C can be directly embedded into the firmware of microcontrollers (such as the ARM Cortex-M series). However, due to its proximity to underlying hardware, C has significant limitations in development flexibility and engineering efficiency. Current embedded software driver development requires tailoring the driver to specific hardware. A common approach is to pre-define fixed code and parameter configuration within the code. However, the lack of flexibility inherent in C, a language widely used in embedded development, requires significant modifications and testing of the driver source code, and significant changes often require redevelopment.

[0035] Furthermore, the fixed driver source code has significant drawbacks in porting and reuse, resulting in low overall project development efficiency and hindering driver source code maintenance and upgrades. Furthermore, the code cannot be flexibly adapted to different projects and is highly hardware-dependent, making subsequent maintenance cumbersome and hindering collaborative feature development.

[0036] In view of this, embodiments of the present disclosure provide a configuration generation method for generating a configuration file for a driver source code. Using this configuration file, the driver source code can be quickly configured without modifying the code. Furthermore, when hardware changes occur, users only need to adaptively modify the parameters in the configuration file to quickly adapt the driver source code to the hardware.

[0037] Specifically, in the disclosed embodiments, the inventive concept is to transform driver source code development into driver library development, separating the development of fixed drivers, originally encompassing peripherals and onboard components, into two parts. One part involves the development of peripheral driver source code for the embedded processing chip. Peripherals refer to auxiliary function modules integrated into the embedded processing chip, referred to herein as "peripheral modules." Embedded processing chips include, but are not limited to, microprocessors (MCUs, also known as single-chip microcomputers), which are integrated chips integrating a processor core and various peripheral modules. Peripheral modules include, but are not limited to, at least one of the following: general-purpose input / output (GPIO), alternate function input / output (AFIO), analog-to-digital converter (ADC), inter-integrated circuit bus (I2C), serial peripheral interface (SPI), universal synchronous / asynchronous receiver / transmitter (USART), controller area network (CAN), CRC check module, etc. The other part involves the development of onboard driver programs (e.g., Flash memory, audio chip, gyroscope, etc.). The peripheral driver source code is used as a foundation and is specifically implemented as driver source code for the peripheral modules within the embedded processing chip, enabling the use of the peripheral modules within the embedded processing chip. Onboard driver source code refers to the driver source code for connecting to other chips outside the embedded processing chip via peripheral communication. This driver is implemented by calling the peripheral driver source code of the corresponding embedded processing chip. For example, if the gyroscope driver is using the MCU's SPI for communication, the MCU's SPI peripheral must be configured, and then the SPI driver interface must be used to write the driver for the gyroscope chip. The SPI communication is used to configure the MCU's registers and controls. The disclosed method of separating peripheral drivers from onboard drivers can be implemented by first configuring an independent peripheral driver source code for the SPI, and then calling the interface of the SPI peripheral driver source code to configure and control the gyroscope chip. Thus, the program that calls the interface, configuration, control, and calculation of the SPI peripheral driver source code can generate an independent gyroscope driver, namely the onboard driver source code. Consequently, the SPI peripheral driver source code is not bound to the gyroscope's onboard driver source code and can be reused. It can be used with the onboard driver source code for different onboard hardware, such as flash chips, audio chips, and other chips, saving SPI driver adaptation time. Furthermore, as a basic driver, the SPI driver can be continuously upgraded and iterated to add functionality.

[0038] Furthermore, in the disclosed embodiments, the peripheral driver source code, or the peripheral driver source code and the onboard driver source code, can be encapsulated into a universal driver module, which acts like a "black box" and contains the comprehensive functions of the peripheral module and provides configuration options for the corresponding functions. When the configuration parameters are selected, the functions of the corresponding peripheral module are enabled. Thus, the user only needs to select the required configuration parameters in the required configuration options to configure the driver source code parameters (and various registers) without modifying the code. This facilitates efficient adaptation of the peripheral driver source code and possible changes to the peripheral module in the event of hardware changes such as changes in onboard hardware. For example, the SPI driver, as a basic driver, can be quickly iterated and upgraded by modifying the configuration parameters. Furthermore, the encapsulated universal driver module can be used by different people, supporting collaborative development, shared use, and maintenance by multiple people, effectively improving development efficiency and avoiding duplicate development.

[0039] like Figure 1 , which is a flow chart showing a configuration generation method in an embodiment of the present disclosure.

[0040] The configuration generation method comprises:

[0041] Step S101: Acquire a configuration item set of a peripheral module of an embedded processing chip.

[0042] In some embodiments, a set of potentially usable embedded processing chips can be collected, and the union of various configuration items (corresponding to each function of the peripheral modules) of each of the embedded processing chips can be collected to obtain the configuration item set. It will be appreciated that the more comprehensive the configuration item coverage listed in the configuration item set, the more versatile the universal driver module. Across various driver development requirements, users can find the target configuration items they need to meet the needs of universal driver configuration.

[0043] For example, embedded processing chip A and embedded processing chip B both have SPI peripheral modules, designated as SPIA and SPIB. Configuration items for both SPI A and SPI B include: clock phase and polarity (CPHA & CPOL); device type (master / slave); data order (MSB / LSB); data width (e.g., 8 bits, 16 bits); and clock frequency (e.g., 11250000Hz). Assuming that SPI B's configuration items also include pin selection (GPIO pins corresponding to SCK, MOSI, and MISO), these configuration items are added to the configuration item set.

[0044] Step S102: Describe the configuration item set of each peripheral module based on the configuration description language to obtain a configuration item description file.

[0045] In some embodiments, the configuration description language can be implemented as Kconfig, etc. Kconfig is a configuration description language and file format used to configure system options in the Linux kernel and many other open source projects. It is mainly used to generate and manage project configuration options. The uses of Kconfig include: defining configuration options, such as enabling or disabling a kernel function, selecting driver source code, setting parameters, etc. Organizing configuration options, such as through menus, submenus, etc., so that the configuration options are clearly layered and easy for users to select. Setting dependencies: defining dependencies between configuration options, such as an option is only visible or selectable when another option is enabled. Generate a configuration interface: cooperate with a build system (such as Kbuild) to generate a user-friendly configuration interface (such as a text menu, a graphical interface, etc.). Generate a .config file: the choices made by the user through the configuration interface will be saved in a .config file, which is used to guide the subsequent compilation process. Then, the configuration item description file can be implemented as a .config file.

[0046] For example, here is a code example for configuring an SPI peripheral "SPI3" to be a "Master / Slave" peripheral using the Kconfig language:

[0047] config SPI3_DEVICE_TYPE

[0048] bool "SPI3 Device Type (Master / Slave)"

[0049] default y

[0050] help

[0051] Set SPI3 as Master (y) or Slave (n).

[0052] Step S103: When the configuration item description file is called by the configuration menu graphic tool, it is used to generate a corresponding configuration parameter input interface.

[0053] In some embodiments, in conjunction with Kconfig, the configuration menu graphical tool in step S102 may be implemented as menuconfig. The menuconfig tool allows users to interactively configure .config files.

[0054] The configuration parameter input interface displays configuration options for each peripheral module, and the configuration options include: sub-options that are allowed to be operated to input configuration parameters; the sub-options are determined by the configuration item set.

[0055] like Figure 2 , which is a schematic diagram showing a configuration parameter input interface generated by the menuconfig tool according to a configuration item description file in one embodiment of the present disclosure.

[0056] In some embodiments, the configuration parameter input interface includes: a first driver type option for selecting a configuration peripheral driver source code. When the first driver type option is selected, a first configuration sub-interface including configuration options for each peripheral module is displayed.

[0057] exist Figure 2 In the example of the first driver type option, “Using spi bus driver” is used, and “[*]Using spi bus driver” indicates that it is selected, and when selected, the first configuration sub-interface below it is displayed.

[0058] The first configuration sub-interface is exemplified by a menu interface for using the SPI bus driver ("Using SPI Bus Driver"), displaying configuration options for various SPI peripherals, such as SPI1, SPI2, SPI3, SPI4, SPI5, and SPI6. Each configuration option can be enabled (selected) or disabled (deselected) in the menu using the up and down keys or the spacebar. The enable control is represented by "[]." In the interface, an "*" within the "[]" indicates that the corresponding configuration option has been selected, i.e., "[*]." In the figure, the SPI3 configuration option ("[*] Using SPI3 Bus") is selected, displaying its sub-options, each used to set SPI3 parameters (such as clock mode, data bit width, pin multiplexing, etc.). Saving the configuration after configuration updates the parameters.

[0059] It is understandable that the configuration options shown in the figure select the logic of the sub-options contained in the display. For example, the configuration options for spi3 are pre-defined in the code of the .config file. For example, the .config file contains code that displays the following sub-options if the user enables spi3 (for example, "if RT_USING_SPI3").

[0060] As an optional example, each sub-option may further include lower-level options, such as a grandchild option, a great-grandchild option, etc. Figure 2 In the dialog, arrows indicate that an option also contains sub-options, which can be expanded by selecting them, such as by pressing Enter.

[0061] In other embodiments, the configuration parameter input interface may further include: a second driver type option for selecting an onboard driver source code for configuration; when the second driver type option is selected, a second configuration sub-interface displays configuration options for the onboard driver source code, and a first configuration sub-interface corresponding to the peripheral driver source code that the onboard driver source code depends on. It is understood that the parameters configured in the second configuration sub-interface and the first configuration sub-interface will be saved together.

[0062] As an example, if the onboard driver source code needs to be configured, it is necessary to determine whether to rely on the peripheral driver source code for different configurations. If there is a dependent peripheral driver source code, the first configuration sub-interface of the dependent peripheral driver source code can be enabled. After the dependent peripheral driver source code is configured, the onboard driver source code is configured through the first configuration sub-interface, and the identification information of the peripheral driver source code that the onboard driver source code depends on is filled in / selected when configuring the first configuration sub-interface. The identification information is used to index and search the peripheral driver source code for calling, and the identification information may include, for example, a name.

[0063] It is worth mentioning that the first configuration sub-interface, the second configuration sub-interface, etc. can be independent pop-up interfaces, or different display areas within an overall interface (such as the configuration parameter input interface). The specific implementation method can be designed according to actual needs and is not limited to the illustration.

[0064] Step S104: generating a configuration file based on the configuration parameters of the peripheral module received on the displayed configuration parameter input interface for use in configuring the driver source code.

[0065] In some embodiments, the configuration file may be in the form of a configuration header file, or in the form of a static library file.

[0066] As an example, after saving the configuration in menuconfig, the .config file is converted to a configuration header file (such as a .h file). The configuration header file contains macro definitions generated for various configuration items. For example, in a generated configuration header file named spi3_config.h, the following macro definitions are exemplarily included:

[0067] #define RT_USING_SPI3 1

[0068] #define SPI3_CLOCK_MODE 0

[0069] #define SPI3_DEVICE_TYPE 1 / / 1 = Master, 0 = Slave

[0070] #define SPI3_DATA_BIT_ORDER 1 / / 1 = MSB, 0 = LSB

[0071] #define SPI3_DATA_WIDTH 8

[0072] #define SPI3_CLOCK_FREQ (11250000)

[0073] ......"

[0074] In some embodiments, the header file and source file of the driver source code may directly or indirectly reference the configuration header file to pass configuration parameters to the driver source code through macro definitions during compilation.

[0075] For example, the header file of the driver source code and the source file reference the configuration header file. The sample code is as follows:

[0076] #include "spi3_config.h" / / Include the configuration header file generated by Kconfig.

[0077] And, in order to use the SPI interface, you can make corresponding logic definitions in the source file of the driver source code. The sample code is as follows:

[0078] / / If SPI is enabled, declare the interface:

[0079] #ifdef CONFIG_SPI_ENABLE ......

[0081] / / Declare SPI driver interface

[0082] void spi_init(void);

[0083] int spi_send(const uint8_t *data, uint32_t len);

[0084] int spi_receive(uint8_t *data, uint32_t len);

[0085] #endif / / CONFIG_SPI_ENABLE .....

[0087] If the user enables SPI3, during the compilation phase of the driver source code, configuration parameters (such as clock mode, GPIO pins, etc.) will be read from the corresponding configuration header file (such as spi3_config.h) to implement parameterized configuration of the driver source code.

[0088] The above method flow is briefly described through an example. For example, the Kconfig language is used to describe the driver configuration options (such as whether SPI3 is enabled, clock frequency, pin multiplexing, etc.) to generate a .config file. The user selects the configured driver type through menuconfig: peripheral driver only, or onboard driver source code that relies on (calls) peripheral driver source code, and allows the user to enter the corresponding peripheral module parameters and then save it as a configuration file.

[0089] Let's briefly discuss header files and source files in embedded systems. In embedded system or operating system development, the header files of driver source code typically contain declarations, macro definitions, structures, function prototypes, and other information necessary for interacting with hardware peripherals. These files define the functional interfaces of the peripherals, enabling the driver's implementation code and calling code to interact with the hardware correctly and efficiently. In embedded systems, header files can be in the .h format.

[0090] Source files can be in .c format and can reference header files using the #include directive and the header file name, such as #include "spi_driver.h". The driver source code file can implement the functional interfaces declared in the header file (such as initialization and data transmission and reception), directly manipulate hardware registers, call the official library driver for the embedded processing chip, handle hardware details (such as pin multiplexing, clock configuration, and interrupt management), or adjust behavior (such as baud rate and data bit width) based on configuration macros.

[0091] As an example, here is a code sample of a header file that contains configuration options:

[0092] #if defined(SPI1_DATA_WIDTH_8)

[0093] #define SPI1_DATA_WIDTH 8

[0094] #elif defined(SPI1_DATA_WIDTH_16)

[0095] #define SPI1_DATA_WIDTH 16

[0096] #endif / *#if defined(SPI1_DATA_WIDTH_8)* /

[0097] This code example provides configuration options for the data width of the SPI1 bus. That is, SPI1_DATA_WIDTH is set to 8 bits or 16 bits. If 8 bits are defined, "if defined(SPI1_DATA_WIDTH_8)" is used, then "#define SPI1_DATA_WIDTH 8" is defined. If 16 bits are defined, "if defined(SPI1_DATA_WIDTH_8)" is used, then "#define SPI1_DATA_WIDTH 16" is defined.

[0098] As an example, here is a code example from a driver code source file:

[0099] #if defined(RT_USING_SPIBUS1)

[0100] struct rt_spi_configuration spi1_cfg =

[0101] {

[0102] .mode = (SPI_CLOCK_MODE | SPI1_SB_TYPE | SPI1_DEVICE_TYPE),

[0103] .data_width = SPI1_DATA_WIDTH,

[0104] .max_hz = SPI1_CLOCK_VALUE

[0105] };

[0106] #endif

[0107] What this code does is:

[0108] When RT_USING_SPIBUS1 is enabled, define and initialize a SPI1 bus configuration structure spi1_cfg to configure the operating mode, data bit width and maximum communication frequency of the SPI 1 bus.

[0109] In some embodiments, the header files (e.g., .h files) and source files (e.g., .c files) of driver source code (peripheral driver source code or onboard driver source code) can reference the configuration header files using the #include statement, and the code can be conditionally compiled using the #if statement to control whether the code is valid. Ultimately, the driver source code is compiled (e.g., using GCC) using the user-configured parameters.

[0110] In actual applications, you can use build tools (such as scons, make, etc.) to build a project, include the configuration header file and driver source code in the project, and use tools such as GCC to compile the driver source code. Use the macro definitions in the configuration header file to inject configuration parameters into the driver source code for configuration to obtain the compiled executable file, that is, the driver program.

[0111] It is worth mentioning that the code of the function set corresponding to the configuration item set is pre-packaged into the driver source code for selection and enablement based on the configuration file. Specifically, in order to enable the driver source code (such as the peripheral driver source code, or the onboard driver source code that calls the peripheral driver source code) to implement any function selected in the configuration item set, the source file and header file of the driver source code can be written according to the configuration item set, that is, the code of the function set corresponding to the configuration item set is written into the source file. For example, the pin selection function of the SPI peripheral may not be used in the driver source code that needs to be developed at present and may not include this function, but it still needs to be reserved in the source file code of the driver source code in advance so that it can be used for the development of other driver source codes that require the SPI peripheral pin selection function.

[0112] The specific application of the method in the embodiment of the present disclosure is then explained through practical application examples. First, the principle of the peripheral driver being called by the board-level driver is briefly explained.

[0113] To control the onboard hardware connected to a peripheral module through an embedded processing chip, the corresponding peripheral driver must be callable by upper-level applications or onboard drivers in software. Peripheral drivers are typically registered in a linked list, indexed by their peripheral driver name. This linked list facilitates centralized management and search for peripheral drivers, supporting the dynamic addition and removal of peripheral drivers. Upper-level applications or onboard drivers can use the peripheral driver's identification information (such as its name) within the code to locate and call the peripheral driver. For example, when initializing the source code for a peripheral driver (such as SPI1 or SPI2), the upper-level application or onboard driver source code can use the driver name (such as "spi1") to search the linked list for the corresponding instance of the peripheral driver source code. After configuring and initializing the found peripheral driver source code, the driver's standard interface is used. This driver standard interface provides read / write, control, open / close operations on the peripheral module.

[0114] However, to realize the functions of these peripheral device drivers, it is necessary to perform relevant configuration on the peripheral device driver source code during the compilation phase. For this purpose, the method in the embodiment of the present disclosure can be implemented.

[0115] like Figure 3 FIG. 1 is a schematic diagram showing the principle of implementing an onboard driver calling a peripheral driver in an embodiment of the present disclosure.

[0116] exist Figure 3 The following parts are shown: writing configuration item description file 301, generating configuration header file 302, writing peripheral driver source code 303, writing onboard driver source code 304, configuring and generating driver 305, etc.

[0117]

Writing Configuration Item Description File 301

[0118] In the disclosed embodiments, taking the SPI peripheral driver as an example, a configuration item set corresponding to the common functionality of the SPI peripheral can be first described using a configuration description language (e.g., Kconfig), forming an association between each SPI peripheral module and its corresponding configuration item, and generating a configuration item description file. The configuration item set may include, for example, registers corresponding to the target function on an embedded processing chip or driver names in official libraries, peripheral communication modes, peripheral pin multiplexing, peripheral type, data length, data endianness, clock rate, clock enable, and so on. Each configuration item in the initial configuration item description file may have default configuration parameters.

[0119] Generate configuration header file 302

[0120] The user configures the parameters of the configuration description file according to the peripheral driver functions to be implemented. For example, use a configuration menu graphical tool (such as menuconfig) to open the configuration item description file, modify the default configuration parameters of the required configuration items to the required parameters, and save the file to generate a configuration header file.

[0121]

Writing peripheral driver source code 303

[0122] Write the peripheral driver source code for the functions of the peripheral modules that need to be implemented, including the header file and source file of the peripheral driver code.

[0123]

Writing onboard driver source code 304

[0124] After the peripheral driver code is written, the onboard driver code is written according to the functions of the onboard hardware that need to be implemented. The peripheral driver name can be written into the code according to the peripheral driver it depends on to be used for indexing and finding the corresponding peripheral driver, and the functions of various interfaces of the peripheral driver are implemented.

[0125] In some embodiments, the driver code can be developed using a POSIX-compatible interface, and user-space programs can interact with it using standard POSIX file operations (open(), read(), write(), ioctl(), etc.). This approach makes the driver's calls similar to those for ordinary files, conforming to the POSIX standard and facilitating cross-platform compatibility. POSIX stands for Portable Operating System Interface of UNIX (abbreviated as POSIX). The POSIX standard defines the interface standards that the operating system should provide to applications. The POSIX standard aims to achieve software portability at the source code level. In other words, a program written for a POSIX-compatible operating system should be compilable and executable on any other POSIX operating system (even one from another manufacturer), aiming to be compatible with more operating systems and upper-layer applications, facilitating reuse and subsequent maintenance.

[0126] [Configure and generate driver 305]

[0127] After writing the configuration header file and driver code (which can be only the peripheral driver source code, or the peripheral driver source code and onboard driver source code), you can use the configuration header file to compile the driver source code to obtain the driver program, that is, the executable file.

[0128] The configuration header file combines the advantages of reusability, requiring only the configuration parameters of the relevant configuration items to be modified when modifying / enabling / disabling driver functions, and meeting the requirements for efficient operation in embedded software. During the compilation phase, the configuration header file is used to precompile the relevant code segments and data of the driver source code, implement parameter configuration, delete unnecessary code segments (such as driver functions for disabled peripheral modules) and file names, and generate the required peripheral driver executable file.

[0129] Let's take an example to illustrate how to delete unnecessary code segments. Suppose Kconfig defines an option when writing a configuration item description:

[0130] config MY_DRIVER_ENABLE

[0131] bool "Enable My Driver"

[0132] default y

[0133] The user enabled this option through menuconfig, and the generated .config file contains:

[0134] CONFIG_MY_DRIVER_ENABLE=y

[0135] Based on this, the configuration header file autoconf.h file is generated, which contains macro definitions:

[0136] #define CONFIG_MY_DRIVER_ENABLE 1

[0137] In the corresponding driver source code, the following code may be written:

[0138] #include

[0139] #if CONFIG_MY_DRIVER_ENABLE

[0140] void my_driver_init(void) {

[0141] / / Initialization code

[0142] }

[0143] Then, during the pre-compilation phase of the driver source code, the decision on whether to retain the definition of the my_driver_init() function will be made based on the parameters defined in the macro in autoconf.h. If CONFIG_MY_DRIVER_ENABLE is 0, the corresponding code segment will be removed.

[0144] In the method of the disclosed embodiments, a configuration description language (such as Kconfig syntax) can be used to write the driver's configuration logic and parameters. A configuration menu graphical tool (such as the menuconfig tool) is then used to output the corresponding configuration header file based on the Kconfig file for use by the driver software. The driver's source and header files are then compiled to configure the driver source code based on the output header file, resulting in an executable file or driver static library. It should be noted that Kconfig+menuconfig only implements the configuration logic and interactive graphical interface in specific scenarios. This combination can be varied in other embodiments, such as using custom tools, and is not intended to be limiting.

[0145] There are two important points in the above method:

[0146] First, the logic of the configuration item description file and the parameters that need to be configured are written, and the configuration header file used by the configuration menu graphical tool is output to form various macro-defined configuration parameters.

[0147] Secondly, the source file and header file of the driver code can be written according to the description of the configuration item set in the configuration item description file, so that the macro definitions of various parameters can be enabled by using the parameters generated in the configuration item description file, and the macro definitions are used in the code to configure the parameters and various enables. Therefore, under this principle, the macro definition parameters can be modified using the configuration item description file + configuration menu graphical tool, that is, the modification of various configuration parameters can be realized and the configuration header file can be generated. Furthermore, in the compilation stage, the configuration header file can be used to compile the driver source code to obtain an executable file or a driver static library file.

[0148] The configuration generation method further includes: in response to a hardware change of the embedded processing chip, providing the configuration parameter input interface for updating the configuration parameters to adapt to the hardware change, and forming an updated configuration file.

[0149] Since the software can be easily reused, it is suitable for long-term use and maintenance, which is beneficial to improving software quality. It can be used with simple configuration, which greatly reduces development efficiency. After the development standards are unified, it is convenient for later maintenance. After the functions are split, it is convenient for multiple people to collaborate on development. The use of standard interfaces is conducive to the migration of upper-level applications and the migration of other software. Due to the convenient configuration, there is no need to redevelop after the underlying hardware changes, so the cost of development and later maintenance can be greatly reduced.

[0150] To simplify the above principle, Figure 4 FIG. 1 is a simplified flowchart showing a configuration performed from a user's perspective in an embodiment of the present disclosure.

[0151] exist Figure 4 The process includes:

[0152] Step S401: Start the configuration menu graphic tool.

[0153] Specifically, the user starts the configuration menu graphic tool and reads the configuration item description file to generate and display the configuration parameter input interface.

[0154] Step S402: Select the drive type.

[0155] Specifically, the user can select the type of driver to be configured in the configuration parameter input interface. If only the peripheral driver needs to be configured, that is, step S403, then step S404 is entered: enabling the configuration options to be configured.

[0156] And, step S405: select / input required configuration parameters;

[0157] Then, proceed to step S406: save / output configuration.

[0158] Among them, depending on the purpose, the configuration file can be saved as a configuration header file, or output as a static library file.

[0159] In step S407: compile the driver source code to generate an executable file.

[0160] Alternatively, in step S408: a configuration static library file is generated.

[0161] If the onboard driver needs to be configured, that is, step S409, and the onboard driver has a peripheral driver that it needs to rely on, step S410 can be triggered: first configure the parameters of the corresponding peripheral driver, and then proceed to step S411: configure the parameters of the corresponding onboard driver, and fill in / select the name of the dependent peripheral driver in the corresponding configuration option. After completing the parameter configuration, step S406 is also entered, and depending on the purpose, step S407 can be jumped to generate an executable file, or step S408 can be used to generate a configuration static library file.

[0162] It is understood that based on the method in the embodiments of the present disclosure, when, for example, a hardware change occurs, the configuration parameters can be quickly modified using the above method to achieve efficient completion. In some embodiments, the configuration generation method further includes: in response to a hardware change of the embedded processing chip, providing the configuration parameter input interface for updating the configuration parameters to adapt to the hardware change, and generating an updated configuration file.

[0163] For example, apply Figure 4 In the process of FIG, when a hardware change occurs, the user can execute step S401: start the configuration menu graphic tool. Specifically, the user starts the configuration menu graphic tool and reads the configuration item description file to generate and display the configuration parameter input interface.

[0164] Step S402: Select the drive type.

[0165] Specifically, the user can select the type of driver to be configured in the configuration parameter input interface. If only the peripheral driver needs to be configured, that is, step S403, then step S404 is entered: enabling the configuration options to be configured.

[0166] And, step S405: select / input required configuration parameters;

[0167] Here, the user can input configuration parameters adapted to the new hardware after the change.

[0168] Then, proceed to step S406: save / output configuration.

[0169] The saved configuration file may be a configuration header file depending on the purpose.

[0170] In step S407: compile the driver source code to generate an executable file.

[0171] Alternatively, in step S408: a configuration static library file is generated.

[0172] If the onboard driver needs to be configured, that is, step S409, and the onboard driver has a peripheral driver that it needs to rely on, step S410 can be triggered: first configure the parameters of the corresponding peripheral driver, and then proceed to step S411: configure the parameters of the corresponding onboard driver, and fill in / select the name of the dependent peripheral driver in the corresponding configuration option. After completing the parameter configuration, step S406 is also entered, and depending on the purpose, step S407 can be jumped to generate an executable file, or step S408 can be used to generate a configuration static library file.

[0173] Therefore, in a scenario where, for example, hardware changes occur, for example, the onboard hardware connected to the SPI bus changes from a gyroscope to other hardware, such as an ADC, its onboard driver changes, and the configuration parameters in the peripheral driver also need to be modified accordingly. In an optional example, the user can modify the configuration parameters in the configuration item description file through menuconfig to adapt to the new hardware, generate an updated configuration header file, and use the updated configuration header file to compile the current peripheral driver source code, so that the updated peripheral driver executable file can be obtained to achieve efficient adaptation. Similarly, if the embedded processing chip undergoes hardware changes, it can also be modified through menuconfig according to the parameter characteristics of the new embedded processing chip to adapt to the new embedded processing chip, generate an updated configuration header file, and use the updated configuration header file to compile the current peripheral driver source code, so that the updated peripheral driver executable file can be obtained to achieve efficient adaptation.

[0174] like Figure 5 , which shows a schematic diagram of the software architecture of an application in an embodiment of the present disclosure.

[0175] exist Figure 5 In the figure, the hardware layer, middle layer and application layer are shown.

[0176] The hardware layer includes hardware devices such as embedded processing chip 501 and onboard hardware 502 .

[0177] The middle layer includes source codes for driving the embedded processing chip, onboard hardware, etc., such as peripheral driver source code 503 and onboard driver source code 504 .

[0178] Among them, there may also be configuration item description files 505, configuration files 506 (such as configuration header files, static library files), etc. The top layer is the application layer. Between the driver and the hardware layer, the chip official library 507 of the embedded processing chip 501 may also be included to provide a software development kit for the development of the embedded processing chip 501. It may include a hardware abstraction layer (HAL), a bottom driver layer, middleware, etc. In some embodiments, the hardware abstraction layer of some manufacturers provides a standardized access interface to the MCU peripherals, and optionally, can shield the bottom register operation details. In some embodiments, the bottom driver library (LL) contains lightweight drivers that are closer to the hardware, which are more efficient than the HAL library but have a lower level of abstraction.

[0179] like Figure 6 It should be noted that the principle and technical implementation of the configuration generating device 600 can refer to the configuration generating method in the previous embodiment, so it will not be repeated in this embodiment.

[0180] exist Figure 6 , the configuration generation device 600 is shown, and the device is used to generate a configuration file of a driving source code.

[0181] The configuration generating device 600 includes:

[0182] The acquisition module 601 acquires a configuration item set of a peripheral module of an embedded processing chip.

[0183] The configuration description module 602 is used to describe the configuration item set of each peripheral module based on the configuration description language to obtain a configuration item description file.

[0184] The configuration interaction interface module 603 is used to generate a corresponding configuration parameter input interface when the configuration item description file is called by the configuration menu graphical tool. The configuration parameter input interface displays the configuration options of each peripheral module, and the configuration options include: sub-options that can be operated to input configuration parameters; the sub-options are determined by the configuration item set.

[0185] The configuration file generation module 604 generates a configuration file based on the configuration parameters of the peripheral module received by the displayed configuration parameter input interface for use in configuring the driver source code; wherein the code of the function set corresponding to the configuration item set is pre-packaged into the driver source code for selection and enablement based on the configuration file.

[0186] In some embodiments, the configuration parameter input interface includes: a first driver type option for selecting to configure peripheral driver source code; when the first driver type option is selected, a first configuration sub-interface including configuration options for each peripheral module is displayed.

[0187] In some embodiments, the configuration parameter input interface also includes: a second driver type option for selecting the onboard driver source code for configuration; a second configuration sub-interface that displays the configuration options of the onboard driver source code when the second driver type option is selected, and a first configuration sub-interface corresponding to the peripheral driver source code that the onboard driver source code depends on.

[0188] In some embodiments, the configuration options of each peripheral module include: an enable control for being operated to select the corresponding peripheral module; the method includes: in response to the enable control being enabled, displaying each sub-option included in the corresponding configuration option.

[0189] In some embodiments, the configuration parameters of the peripheral module received based on the configuration parameter input interface being displayed are used to generate a configuration file, including: displaying a first configuration sub-interface in response to a first driver type option being selected; and generating a first configuration file for the peripheral driver source code based on the input information of the configuration options in the first configuration sub-interface in response to an output operation.

[0190] In some embodiments, the configuration parameters of the peripheral module received based on the displayed configuration parameter input interface are used to generate a configuration file, including: in response to the first driver type option corresponding to the peripheral driver source code being selected, displaying a first configuration sub-interface; in response to the second driver type option corresponding to the onboard driver source code being selected, displaying a second configuration sub-interface; wherein, the second configuration sub-interface includes: a configuration option for inputting identification information of the peripheral driver source code, the identification information being used to index to call the peripheral driver source code; in response to an output operation, a second configuration file for the onboard driver source code is generated based on the input information of the configuration options in the first configuration sub-interface and the second configuration sub-interface.

[0191] In some embodiments, the peripheral module includes at least one of the following: GPIO, AFIO, ADC, I2C, SPI, USART, CAN, CRC; and / or, the configuration item set includes any multiple of the following: registers corresponding to the target function on the embedded processing chip or driver names in the official library, peripheral communication mode, peripheral pin multiplexing, peripheral type, data length, data endianness, clock rate, clock enable; and / or, the configuration file includes: a configuration header file or a configuration static library; and / or, the configuration generation method further includes: in response to hardware changes of the embedded processing chip, providing the configuration parameter input interface for updating the configuration parameters to adapt to the hardware changes, and forming an updated configuration file.

[0192] It should be noted that in Figure 6The various functional modules in the embodiments can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using software, they can be implemented in whole or in part in the form of a computer program or instruction product. A computer program or instruction product includes one or a group of computer programs or instructions. When a computer program or instruction is loaded and executed on a computer, the process or function according to the present disclosure is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer program or instruction can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another computer-readable storage medium.

[0193] and, Figure 6 The devices disclosed in the embodiments can be implemented using other module division methods. The device embodiments shown above are merely illustrative. For example, the module division is merely a logical functional division. In actual implementation, other division methods may be used, such as a group of modules or modules that can be combined or dynamically integrated into another system, or some features that can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between devices or modules shown or discussed can be through some interface, and the indirect coupling or communication connection between devices or modules can be electrical or other forms.

[0194] in addition, Figure 6 Each functional module and submodule in the embodiments may be dynamically integrated into a single processing component, each module may exist physically independently, or two or more modules may be dynamically integrated into a single component. The aforementioned dynamic components may be implemented in hardware or as software functional modules. If the aforementioned dynamic components are implemented as software functional modules and sold or used as independent products, they may also be stored in a computer-readable storage medium. The storage medium may be a read-only memory, a magnetic disk, or an optical disk, etc.

[0195] It should be noted that the processes or methods represented by the flowcharts of the above embodiments of the present disclosure can be understood as modules, segments, or portions of code that include one or a group of executable instructions configured to implement the steps of a specific logical function or process. Furthermore, the scope of the preferred embodiments of the present disclosure includes alternative implementations in which functions may be performed in a different order than that shown or discussed, including performing functions substantially simultaneously or in reverse order depending on the functions involved.

[0196] For example, Figure 1 The order of the steps in the method embodiments may be changed in specific scenarios and is not limited to the above.

[0197] like Figure 7, which shows a structural diagram of an embedded device 700 in an embodiment of the present disclosure.

[0198] The embedded devices 700 include, but are not limited to, various devices with embedded systems. For example, in the field of medical rehabilitation, they can be implemented as medical diagnostic and monitoring devices, therapeutic and auxiliary devices, rehabilitation training devices, or other medical embedded devices 700. Specifically, rehabilitation training devices include, but are not limited to, upper limb rehabilitation robots, lower limb rehabilitation robots, hand rehabilitation trainers, speech and cognitive rehabilitation training devices, intelligent prosthetic or exoskeleton rehabilitation training robots, etc. Medical diagnostic and monitoring devices include, but are not limited to, scanners, portable blood glucose meters, smart blood pressure monitors, smart thermometers, electrocardiogram (ECG) monitors, blood oxygen saturation meters (SpO2), or continuous body temperature monitoring patches. Therapeutic and auxiliary devices include, but are not limited to, pacemakers, insulin pumps, ventilators, etc. Other medical embedded devices 700 include, but are not limited to, ultrasound diagnostic devices, sleep apnea monitors, etc.

[0199] In the consumer electronics sector, it can be implemented as, for example, smartphones / tablets, smart TVs / set-top boxes, smart watches / bracelets, or heart rate / blood oxygen sensors. In the home appliance and smart home sector, it can be implemented as, for example, smart refrigerators / air conditioners, smart speakers, or washing machines / microwave ovens. In the industrial control and automation sector, it can be implemented as, for example, programmable logic controllers (PLCs), industrial robots, and environmental monitoring equipment (e.g., various sensors for temperature, humidity, gas, angle, displacement, etc.). In the network communications sector, it can be implemented as, for example, routers / switches, wired or wireless network nodes, base stations, or network cameras. In the Internet of Things sector, it can be implemented as IoT terminals, such as NB-IOT, LoRa, Bluetooth nodes, and smart locks. In the transportation and automotive electronics sector, it can be implemented as, for example, in-car entertainment systems, ESPs, or electric vehicle charging stations.

[0200] Since the application scope of the embedded device 700 is too broad, it can only be cited here as an example and cannot be fully covered. However, for those skilled in the art, it should be conceivable that other existing implementations of the embedded device 700 can all be applied to the method in the embodiments of the present disclosure, and is not limited to the type of embedded device 700 exemplified above.

[0201] The embedded device 700 includes an embedded processing chip 501 , and the embedded processing chip 501 includes but is not limited to any one of MCU, SoC, FPGA, etc.

[0202] The embedded device 700 includes an internal memory 702, which may include volatile memory (Volatile Memory) for temporarily storing data when running programs, such as random access memory (RAM). The internal memory 702 stores a driver (which may include an executable file of a peripheral driver or an onboard driver). The driver is configured by using a configuration file generated by the configuration generation method according to the embodiment of the present disclosure using the driver source code.

[0203] like Figure 8 FIG. 1 is a schematic diagram showing the structure of a computer device in one embodiment of the present disclosure.

[0204] The computer device 800 may be exemplified as a processing terminal, such as a server, a desktop computer, a laptop computer, a tablet computer, a smart phone, or other terminals.

[0205] The computer device 800 includes a bus 801, a processor 802, and a memory 803. The processor 802 and the memory 803 can communicate with each other via the bus 801. The memory 803 can store computer programs or instructions. The processor 802 implements the method flow or function of the previous embodiment by running the computer program or instruction in the memory 803, for example Figure 1 The configuration generation method in .

[0206] Bus 801 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus. Buses can be divided into address buses, data buses, control buses, etc. For ease of illustration, although only one thick line is used in the figure, this does not mean that there is only one bus or only one type of bus.

[0207] In some embodiments, the processor 802 may be implemented as a central processing unit (CPU), a microprocessor unit (MCU), a system on a chip (SoC), or a field programmable gate array (FPGA). The memory 803 may include volatile memory, such as random access memory (RAM), for temporarily storing data while running programs.

[0208] The memory 803 may also include a non-volatile memory (non-volatile memory) for data storage, such as a read-only memory (ROM), a flash memory, a hard disk drive (HDD), or a solid-state disk (SSD).

[0209] In some embodiments, the computer device 800 may further include a communicator 804. The communicator 804 is used to communicate with the outside world. In a specific example, the communicator 804 may include one or a group of wired and / or wireless communication circuit modules. For example, the communicator 804 may include one or more of a wired network card, a USB module, a serial interface module, etc. The wireless communication protocols followed by the wireless communication module include, for example, near field communication (NFC) technology, infrared (IR) technology, Global System for Mobile communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Time-Division Code Division Multiple Access (TD-SCDMA), Long Term Evolution (LTE), Bluetooth (BT), Global Navigation Satellite System (GNSS), etc. One or more of the following.

[0210] In an embodiment of the present disclosure, a computer-readable storage medium may be provided, storing a computer program or instruction, which is executed to implement the method flow or function of any of the previous embodiments, such as Figure 1 The configuration generation method in .

[0211] That is, the method steps in the above embodiments are implemented as software or computer code that can be stored in a recording medium (such as a CD ROM, RAM, floppy disk, hard disk or magneto-optical disk), or are implemented as computer code originally stored in a remote recording medium or a non-transitory machine-readable medium downloaded via a network and to be stored in a local recording medium, so that the method represented herein can be stored in such software processing on a recording medium using a general-purpose computer, a dedicated processor or programmable or dedicated hardware (such as an ASIC or FPGA).

[0212] The present disclosure may also provide a computer program product, which includes one or more computer programs or instructions that, when executed, fully or partially execute the processes or functions in the present disclosure. The computer program product includes one or more computer programs or instructions.

[0213] A computer program or instruction can be stored in a readable storage medium or transferred from one readable storage medium to another. For example, the computer program or instruction can be transferred from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The readable storage medium can be any accessible medium or a data storage device such as a server or data center that integrates one or more accessible media. The accessible medium can be a magnetic medium such as a floppy disk, hard disk, or magnetic tape; an optical medium such as a digital video disk; or a semiconductor medium such as a solid-state drive. The computer-readable storage medium can be a volatile or non-volatile storage medium, or can include both volatile and non-volatile types of storage media.

[0214] In summary, the present disclosure relates to the technical field of embedded software development, and provides a configuration generation method, embedded equipment, apparatus and storage medium, wherein the method comprises: obtaining a configuration item set of a peripheral module of an embedded processing chip; describing a configuration item set of each peripheral module based on a configuration description language to obtain a configuration item description file; when the configuration item description file is called by a configuration menu graphic tool, it is used to generate a corresponding configuration parameter input interface; the configuration parameter input interface displays the configuration options of each peripheral module; and a configuration file is generated based on the configuration parameters of the peripheral module received by the displayed configuration parameter input interface. By separating the modifiable driver configuration of the peripheral driver from the onboard driver, the efficient modification and adaptation of the driver source code can be completed by modifying the configuration parameters when hardware changes occur, thereby improving development efficiency, facilitating migration to meet the needs of collaborative development, transplantation, etc., and reducing the cost of development and subsequent maintenance.

[0215] The above embodiments are merely illustrative of the principles and effects of this disclosure and are not intended to limit this disclosure. Anyone skilled in the art may modify or alter the above embodiments without departing from the spirit and scope of this disclosure. Therefore, any equivalent modifications or alterations made by a person skilled in the art without departing from the spirit and technical concepts disclosed herein shall be encompassed by the scope of protection of this disclosure.

Claims

1. A configuration generation method, characterized in that: The configuration file used to drive the source code is generated; the configuration generation method includes: Get the configuration item set of the peripheral module of the embedded processing chip; Describe the configuration item set of each peripheral module based on the configuration description language to obtain a configuration item description file; When the configuration item description file is called by the configuration menu graphic tool, it is used to generate a corresponding configuration parameter input interface; the configuration parameter input interface displays the configuration options of each peripheral module, and the configuration options include: sub-options that can be operated to input configuration parameters; the sub-options are determined by the configuration item set; Based on the configuration parameters of the peripheral module received by the displayed configuration parameter input interface, a configuration file is generated for use in configuring the driver source code; wherein the code of the function set corresponding to the configuration item set is pre-packaged into the driver source code for selection and enablement based on the configuration file.

2. The configuration generation method according to claim 1, characterized in that: The configuration parameter input interface includes: a first driver type option for selecting to configure the peripheral driver source code; when the first driver type option is selected, a first configuration sub-interface including configuration options of each peripheral module is displayed.

3. The configuration generation method according to claim 2, characterized in that: The configuration parameter input interface also includes: a second driver type option for selecting an onboard driver source code for configuration; a second configuration sub-interface that displays configuration options of the onboard driver source code when the second driver type option is selected, and a first configuration sub-interface corresponding to the peripheral driver source code that the onboard driver source code depends on.

4. The configuration generation method according to claim 2, characterized in that: The configuration options of each peripheral module include: an enable control for being operated to select the corresponding peripheral module; the method includes: In response to the enabling control being enabled, each sub-option included in the corresponding configuration option is displayed.

5. The configuration generation method according to claim 2 or 3, characterized in that: The generating of a configuration file based on the configuration parameters of the peripheral module received from the displayed configuration parameter input interface includes: In response to the first drive type option being selected, displaying a first configuration sub-interface; In response to the output operation, a first configuration file for the peripheral driver source code is generated according to the input information of the configuration options in the first configuration sub-interface.

6. The configuration generation method according to claim 3, characterized in that: The generating of a configuration file based on the configuration parameters of the peripheral module received from the displayed configuration parameter input interface includes: In response to a first driver type option corresponding to the peripheral driver source code being selected, displaying a first configuration sub-interface; In response to a second driver type option corresponding to the onboard driver source code being selected, a second configuration sub-interface is displayed; wherein the second configuration sub-interface includes: a configuration option for inputting identification information of the peripheral driver source code, the identification information being used for indexing to call the peripheral driver source code; In response to the output operation, a second configuration file for the onboard driver source code is generated based on input information of the configuration options in the first configuration sub-interface and the second configuration sub-interface.

7. The configuration generation method according to claim 1, characterized in that: The peripheral module includes at least one of the following: GPIO, AFIO, ADC, I2C, SPI, USART, CAN, CRC; and / or the configuration item set includes any multiple of the following: register corresponding to the target function on the embedded processing chip or driver name in the official library, peripheral communication mode, peripheral pin multiplexing, peripheral type, data length, data big and small endian, clock rate, clock enable; And / or, the configuration file includes: a configuration header file or a configuration static library; and / or, the configuration generation method also includes: in response to hardware changes of the embedded processing chip, providing the configuration parameter input interface for updating the configuration parameters to adapt to the hardware changes, and forming an updated configuration file.

8. An embedded device, characterized in that: include: Embedded processing chip; The memory stores a driver program, wherein the driver program is configured by using a configuration file obtained by the configuration generation method according to any one of claims 1 to 7 as a driver source code.

9. A computer device, characterized in that: include: processor and memory; The memory stores computer programs or instructions; The processor is configured to run the computer program or instructions to perform the configuration generating method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that A computer program or instruction is stored, and the computer program or instruction is executed to perform the configuration generation method according to any one of claims 1 to 7.

Images