Embedded software construction method and device, electronic equipment and storage medium

Abstract

The invention discloses an embedded software construction method and device, electronic equipment and a storage medium, and belongs to the technical field of software development, the method comprises the steps that construction parameters configured by a user are provided, and the construction parameters comprise a hardware identifier used for specifying a target embedded hardware platform type; calling a corresponding configuration file from a preset configuration library according to the hardware identifier, wherein the configuration file is used for providing a compiler tool chain path and default compiling options related to the platform; generating a compiling rule frame based on the configuration file, wherein the compiling rule frame comprises a to-be-compiled file list, a final compiling option and a target generation rule; and executing compiling operation according to the compiling rule framework to generate a target output file. According to the method, the preset configuration file is automatically matched through the hardware identifier, so that manual configuration redundancy is greatly reduced; dynamic switching of tool chain configuration during cross-platform construction is realized, and zero modification of platform migration is ensured.

Description

Technical Field

[0001] This application relates to the field of software development technology, specifically to an embedded software construction method, apparatus, electronic device, and storage medium. Background Technology

[0002] Existing technologies mainly include embedded software build solutions based on IDE project files (such as Keil and IAR) and scripted build tools (such as Makefile, CMake, and SCons). These solutions rely on developers manually configuring parameters such as compiler paths, source file manifests, linker scripts, and header file directories, leading to the following problems: each project requires repeated maintenance of project files or build scripts; manual configuration is prone to inconsistencies, and the same code may produce different compilation results in different environments; changing MCU models requires modifying a large number of parameters; the build logic is tightly coupled with the project code, making it difficult to reuse and resulting in high maintenance costs. Summary of the Invention

[0003] This invention provides an embedded software construction method, apparatus, electronic device, and storage medium, aiming to solve the problems of redundant manual configuration, poor cross-platform compatibility, and unreliable incremental construction in existing embedded construction systems.

[0004] Firstly, an embedded software construction method is provided, including: Provide user-configurable build parameters, including a hardware identifier for specifying the target embedded hardware platform type; The corresponding configuration file is retrieved from the preset configuration library based on the hardware identifier. The configuration file is used to provide the platform-related compiler toolchain path and default compilation options. A compilation rule framework is generated based on the configuration file. The compilation rule framework includes a list of files to be compiled, final compilation options, and target generation rules. The compilation operation is performed according to the compilation rule framework to generate the target output file.

[0005] Secondly, an embedded software building apparatus is also provided, comprising: A parameter providing module is used to provide user-configured build parameters, including a hardware identifier for specifying the target embedded hardware platform type; The configuration retrieval module is used to retrieve the corresponding configuration file from the preset configuration library according to the hardware identifier. The configuration file is used to provide the platform-related compiler toolchain path and default compilation options. The framework generation module is used to generate a compilation rule framework based on the configuration file. The compilation rule framework includes a list of files to be compiled, final compilation options, and target generation rules. The compilation and execution module is used to perform compilation operations according to the compilation rule framework and generate target output files.

[0006] Thirdly, an electronic device is provided, including a communication module, a memory, and a processor. The communication module is used to receive construction parameters input by a user. The memory stores executable instructions and a preset configuration library. When the processor is configured to execute the executable instructions in the memory, it implements the embedded software construction method as described in any one of the first aspects.

[0007] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, the computer program being loaded by a processor to perform the steps of the embedded software construction method described in any one of the first aspects.

[0008] Beneficial effects: This application addresses the following issues by establishing a hardware identifier-driven automated build system and employing a dynamic mapping mechanism between "hardware platform and configuration file": 1) To address the redundancy of manual configuration, the hardware identifier automatically matches the pre-set configuration file, compressing the compiler path, option set, and other parameters that require manual configuration in traditional development into a single hardware platform selection, reducing manual intervention; 2) To address poor cross-platform compatibility, the toolchain configuration bound to the hardware identifier is dynamically loaded during the build process, enabling automatic switching of the compiler, adjustment of instruction set options, and replacement of linker scripts when switching from one platform to another, ensuring that the build method remains unchanged during platform migration; 3) To address the unreliability of incremental builds, a verification mechanism is established through the generated compilation rule framework, which can reduce invalid compilations and ensure build consistency after configuration changes.

[0009] Therefore, this application automatically matches the pre-configured configuration file with hardware identifiers, greatly reducing the redundancy of manual configuration; it enables dynamic switching of toolchain configuration during cross-platform builds, ensuring zero modification during platform migration; and it improves the reliability of incremental builds through a verification mechanism, ensuring build consistency after configuration changes. Attached Figure Description

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

[0011] Figure 1 This is a flowchart illustrating an embodiment of an embedded software construction method provided in this application; Figure 2 This is an architecture diagram of a build toolkit provided in one embodiment of this application; Figure 3 This is a flowchart illustrating an embedded software construction method provided in another embodiment of this application; Figure 4 This is a structural block diagram of an embedded software construction apparatus provided in an embodiment of this application. Detailed Implementation

[0012] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0013] In the description of this application, it should be understood that 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 indicated. Therefore, features defined as "first" or "second" may explicitly or implicitly include one or more of the stated features. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0014] "A and / or B" includes the following three combinations: A only, B only, and a combination of A and B.

[0015] The use of "applies to" or "configured to" in this application implies open and inclusive language, which does not exclude the applicability to or configuration to devices performing additional tasks or steps. Additionally, the use of "based on" implies openness and inclusivity, because processes, steps, calculations, or other actions "based on" one or more of the stated conditions or values ​​may in practice be based on additional conditions or values ​​beyond those stated.

[0016] In this application, the term "exemplary" is used to mean "serving as an example, illustration, or description." Any embodiment described as "exemplary" in this application is not necessarily to be construed as being more preferred or advantageous than other embodiments. The following description is provided to enable any person skilled in the art to make and use this application. Details are set forth in the following description for purposes of explanation. It should be understood that those skilled in the art will recognize that this application can be made without using these specific details. In other instances, well-known structures and processes are not described in detail to avoid obscuring the description of this application with unnecessary detail. Therefore, this application is not intended to be limited to the embodiments shown, but is consistent with the broadest scope of the principles and features disclosed in this application.

[0017] This application addresses the problems of complex manual configuration, poor cross-platform compatibility, and unreliable incremental builds in existing embedded build systems. It proposes an embedded software build method based on a modular build toolkit. This method establishes a hardware identifier-driven dynamic configuration mechanism, pre-setting multiple parameters (including toolchain paths and compilation options) that require manual maintenance in traditional build processes in standardized configuration files. Users only need to specify the hardware identifier (such as the target MCU type) through a simple `build.bat` batch script to automatically complete the entire build process. Furthermore, it adopts a lightweight architecture of "build toolkit + configuration library" (e.g., the entire build toolkit can be kept under 2MB), integrating Makefile automation scripts, the BusyBox toolset, and configuration files for multiple platforms to achieve process automation. In particular, verification mechanisms (such as compilation option difference detection and dynamic dependency tracking) ensure the reliability of incremental builds and reduce unnecessary compilation time. This provides an efficient, unified, and traceable build platform for embedded software development.

[0018] Please refer to Figure 1 This embodiment provides an embedded software construction method, including: S101, providing user-configured build parameters, including a hardware identifier for specifying the target embedded hardware platform type.

[0019] In a specific example, the build parameters also include user-defined compilation options, source code path parameters, and target file names; the build parameters input by the user are implemented through the build.bat script, which serves as the build entry layer and provides a configuration carrier file for the user-configured build parameters.

[0020] Understandably, `build.bat` (the build batch script) serves as the unified configuration entry point (i.e., the build entry layer), providing user-configurable build parameters. These parameters include the following key configuration items: 1) Hardware identifier (specifying the embedded hardware platform type), used to specify the target embedded hardware platform type. The system will automatically match the corresponding `mcu_type.mcudef` configuration file based on this hardware identifier; 2) User-defined compilation options, used to supplement or override the platform's default compilation options; 3) Source code path parameter, used to specify the location of the project's source code root directory; 4) Target filename, defining the rules for generating executable files (.elf) or library files (.a). The purpose of this step is to unify the configuration parameters, which are scattered across multiple locations in traditional build systems, such as IDE project files and Makefile variables, into a structured parameter set, input through a single interface (`build.bat`), thus achieving configuration standardization.

[0021] S102, retrieve the corresponding configuration file from the preset configuration library according to the hardware identifier. The configuration file is used to provide the platform-related compiler toolchain path and default compilation options.

[0022] In a specific example, the build parameters are converted into make command-compatible startup parameters using Startmake.bat, the number of CPU cores of the build computer is calculated, and the makefile is started to build in parallel.

[0023] Specifically, the compiler toolchain path is used to associate configuration files of multiple MCU platforms; the compiler toolchain path and compilation option parameters corresponding to each platform are injected into the global build environment variables.

[0024] Understandably, the corresponding configuration file is located in the `mcu_type.mcudef` configuration library of the build toolkit. The parameters—the compiler toolchain path and the platform's default compilation options—are extracted from this configuration file. These parameters are then converted into a startup parameter format that can be directly used by the `make` command. This step aims to: eliminate the workload of manually configuring the toolchain path in traditional build systems; avoid build failures due to incorrect paths; ensure consistency of compilation options across different projects on the same MCU platform; and automate platform adaptation. It also centralizes the management of platform-related parameters scattered across multiple configuration files (such as IDE project properties and environment variables).

[0025] S103, Generate a compilation rule framework based on the configuration file. The compilation rule framework includes a list of files to be compiled, final compilation options, and target generation rules.

[0026] In some embodiments, generating a compilation rule framework based on the configuration file includes: invoking a compilation tool located in the compiler toolchain path; scanning source files under the source code path parameter to generate the list of files to be compiled; merging the user-defined compilation options with the default compilation options to generate the final compilation options; and generating the target generation rules based on the suffix of the target file name, wherein the target generation rules include executable file rules or static library file rules.

[0027] In a specific example, the framework for generating compilation rules is implemented through a Makefile script. The Makefile script is configured to: scan the source files under the source code path parameter, generate a list of files to be compiled containing .c, .s, .h files and their corresponding linker scripts .ld; load the compiler toolchain path and default compilation options in the configuration file; and dynamically generate the target generation rules based on the target file name.

[0028] Understandably, the compilation rule framework generation process is triggered by parsing the configuration file. Specifically, this includes: scanning source code paths using Makefile to generate a structured file list, automatically identifying .c / .s source files and .h header files; generating final compilation options by dynamically merging platform default options with user-defined options; and automatically selecting executable file or static library file rules based on the target file name's suffix (e.g., .elf / .a). The purpose of this step is to: integrate scattered compilation parameters, file lists, and linking rules into a unified framework, ensuring different projects follow the same build specifications and achieving build standardization; eliminate the tedious work of manually maintaining Makefile dependencies through file scanning and rule generation mechanisms, improving automation; automatically switch between executable file and static library file rules based on the target file name's suffix, solving the problem of traditional IDEs requiring separate project configurations, and adaptively building two embedded build targets; and, combined with dependency tracking and option validation mechanisms, avoid build inconsistencies caused by configuration changes while maintaining fast incremental compilation, improving incremental build reliability. The compilation rule framework solves the problems of scattered configurations and difficult maintenance in existing technologies.

[0029] S104, Perform compilation operations according to the compilation rule framework to generate target output files.

[0030] In some embodiments, the compilation operation includes: invoking a compilation tool via the compiler toolchain path, and generating the target output file based on the list of files to be compiled, the final compilation options, and the target generation rules. The target output file is used for program deployment in the embedded system.

[0031] In some other embodiments, the step of performing the compilation operation according to the compilation rule framework includes: generating a dependency description file, which is used to record the dependency relationship between the target file and the header file; comparing the differences between the currently generated final compilation options and the historical compilation options; and triggering a full recompile when a difference is detected.

[0032] In some other embodiments, performing the compilation operation according to the compilation rule framework includes: calculating the number of CPU cores of the building computer; setting the number of threads for parallel compilation based on the number of CPU cores; and invoking a lightweight command-line toolkit to execute compilation environment commands.

[0033] In a specific example, the compilation operation is accomplished collaboratively through the following toolchain: The make.exe parser is used to parse the compilation rule framework in the Makefile script and execute the Makefile script. The busybox.exe toolset provides shell command support for the compilation process; The make.exe parser calls the compilation tools under the compiler toolchain path and completes the compilation operation in cooperation with the busybox.exe toolset.

[0034] Understandably, the make.exe interpreter loads and executes the previously generated Makefile script, and according to the compilation rule framework defined in the Makefile, calls the compiler under the toolchain path to compile the source files, calls the assembler to assemble the assembly files, and selects the target file to execute based on its file extension. The busybox.exe toolset provides the necessary shell command environment to support file operations. Therefore, this application is based on the automated execution of the compilation rule framework defined in the Makefile, while the toolchain call path comes from the configuration file (mcu_type.mcudef), the compilation options use the merged final compilation options, and it relies on the busybox toolset to provide cross-platform shell support. The purpose of this step is to: achieve automated conversion from source code to object files, ensure consistency between the compilation process and platform configuration, and support automatic differentiation between executable file rules and static library file rules.

[0035] Please refer to Figure 2 This application provides a standardized build toolkit to manage different target platforms, toolchains, build target rule types (such as .elf or .a), and compilation configuration parameters in a unified manner, thereby achieving a cross-platform, scalable, and automated embedded build process.

[0036] For example, the user initiates the build process by executing the build.bat script. The build.bat script, acting as a user configuration carrier, receives minimal project input (such as hardware identifiers, also known as the target MCU name, custom compilation options, linker paths, source code path parameters, and target file names) and passes it to the build toolkit. The build toolkit contains a series of specific tools and files, such as Startmake.bat (build starter), mcu_type.mcudef (configuration file), Makefile (core script for automated build), busybox.exe (lightweight command-line toolset), and make.exe (makefile parser). It provides the specific tools and technical support for implementing the embedded software build method described in this application. The embedded software build method described in this application covers the entire build process from the build entry point (e.g., starting the build with build.bat) to utilizing the collaborative work of various components within the build toolkit. For example, Startmake.bat converts the basic project configuration into make startup parameters, busybox.exe provides a shell command execution environment for the build process, and Makefile performs automated builds according to the compilation rule framework, ultimately realizing the entire build process from source code to the target output file.

[0037] Startmake.bat receives the basic project configuration from build.bat and transforms it into complex make startup parameters. It also calculates the number of CPU cores on the build computer, providing parameter support for parallel builds via the Makefile.

[0038] Each MCU platform has its own independent configuration file (mcu_type.mcudef), which includes the compilation toolchain path and name, compilation options (such as C code, assembly code, and linking options), and linking library options (such as math library import options).

[0039] The Makefile includes a project parsing module, a toolchain management module, a build rules module, and a dependency and incremental build module. The project parsing module automatically scans the source code tree under the source code path, identifies .c, .s, .h files and .ld linker scripts, and generates a list of build source files that supports multi-level directory structures. The toolchain management module automatically selects and imports the corresponding MCU configuration file based on the hardware identifier, injecting the toolchain path and compilation option parameters into the global build environment. The build rules module adaptively generates standard compilation, assembly, and executable file rules (if the target file name has a .elf extension), and static library file rules (if the target file name has a .a extension). The dependency and incremental build module finds and imports dependency description files (such as .d files), identifies the dependencies of the object file, compares the current and previous compilation options, and if they are inconsistent (e.g., the user adds custom parameters via build.bat), triggers a recompilation of the object file.

[0040] Busybox.exe provides a shell command execution environment for the build process, which is easier to write than Windows bat scripts and works better with Makefiles.

[0041] Among them, make.exe automatically compiles and builds the project according to the compilation rules framework in the Makefile.

[0042] In summary, after build.bat receives the build parameters (including hardware identifiers) from the user as the build entry point, the Startmake.bat build launcher converts the hardware identifiers into make startup parameters and calculates the number of CPU cores to determine the number of parallel compilation threads. Based on the hardware identifiers, the Makefile retrieves the corresponding mcu_type.mcudef configuration file from the configuration library to obtain the compiler toolchain path and default compilation options, generating a complete compilation rule framework that includes a list of files to be compiled, final compilation options, and target generation rules. Subsequently, the make.exe parser calls the shell command support provided by busybox.exe according to this compilation rule framework, and in conjunction with the toolchain path specified in the configuration file, sequentially performs source code compilation and target file linking / packaging operations, finally outputting executable file rules or static library file rules that meet the requirements of the target embedded hardware platform, thus realizing an automated build process.

[0043] Please refer to Figure 3 This embodiment provides an embedded software construction method, including: S301, the user executes the build.bat script, triggering the build process and parsing the input parameters.

[0044] Users start the build process by executing the build.bat script. This build.bat script acts as the build entry layer, receiving build parameters containing hardware identifiers, and then calls the startmake.bat build starter to complete the configuration and transfer of the initial build environment.

[0045] S302, Startmake.bat converts parameters such as hardware identifiers into a make-compatible format, supporting parallel build configurations.

[0046] startmake.bat parses the hardware identifier and user-defined parameters passed to build.bat, calculates the number of CPU cores on the host machine to determine the number of parallel compilation threads, and finally generates standardized make command parameters and calls make.exe to start the Makefile main build process.

[0047] S303, the Makefile scans the source code paths and generates a list of files to be compiled.

[0048] Makefile automatically traverses the source code path using a file system scanning module, identifying all .c source files, .s assembly files, associated .h header files, and corresponding linker scripts (.ld), generating a complete list of files to be compiled. This list supports multi-level directory structures and is dynamically updated.

[0049] S304 loads information about the compiler toolchain path and default compilation options from mcu_type.mcudef.

[0050] Based on the hardware identifier, the corresponding mcu_type.mcudef configuration file is retrieved from the preset configuration library, the target platform-specific compiler toolchain path and default compilation options are loaded, and the toolchain environment is initialized.

[0051] S305 merges the default compilation options in mcu_type.mcudef with user-defined options to form the final compilation options.

[0052] The default build options in the configuration file are merged with the user-defined build options entered by the user through build.bat to generate a temporary file containing all valid build parameters, ensuring that user-defined options take precedence in case of conflict.

[0053] S306 checks the compilation options and source file status to determine whether a full or incremental build should be triggered.

[0054] By comparing the temporary file of the "final build options" with the historical file of the "old build options," it is determined whether the build parameters have changed. If there are differences, the historical file is replaced and its timestamp is updated. This operation will trigger the subsequent dependency analysis module to mark that a full rebuild is required.

[0055] S307 generates executable file rules or static library file rules based on the suffix of the target file name.

[0056] Based on the suffix of the target file name (.elf / .a), a differentiated target generation rule is dynamically generated, while automatically adapting to the special processing requirements of the assembly instruction set of different MCU platforms.

[0057] S308, based on the detection results of S306, intelligently determines whether to execute a full or incremental build strategy.

[0058] By combining header file change records tracked by dependency description files (such as .d files) with the timestamp status of compilation option files, the system intelligently selects between full and incremental build modes: when critical dependency changes are detected, historical intermediate files are automatically cleared to ensure the consistency of build results.

[0059] S309, make.exe calls the toolchain compilation tools, which work in conjunction with busybox.exe to complete the automated build process.

[0060] According to the generated compilation rule framework, the platform toolchain is called in sequence to complete the source code compilation, assembly file processing, object file linking rules or static library file rules, and finally output the target output file that meets the requirements of the target embedded hardware platform.

[0061] Therefore, this application provides a simplified configuration interface through Build.bat, significantly reducing the build complexity of embedded projects; it adopts an independently encapsulated build toolkit to achieve a unified cross-platform build process, avoiding coupling with specific IDE project files and improving maintainability; while supporting incremental compilation, it ensures build consistency after configuration modifications through a compilation option change detection mechanism; the toolkit adopts a modular design to enhance extensibility and reusability, while maintaining extreme lightweightness, and can be directly managed in the library along with the project source code, ensuring project traceability.

[0062] In other words, this application systematically solves the building problems of embedded development in the prior art from six dimensions: simplified configuration (integrating hardware parameters and compilation options through a single build.bat entry point, replacing the complex process of manually writing makefiles), standardized process (using startmake.bat to automatically generate cross-platform build parameters, eliminating script differences between different developers), decoupled environment (the build toolkit is independent of the IDE and project files, avoiding toolchain pollution of the project directory), reliable build (ensuring consistency of incremental / full builds through a compilation option file verification mechanism), flexible expansion (the modular mcu_type.mcudef configuration system supports rapid access to new MCU platforms), and lightweight management (such as keeping the build toolkit within 2MB).

[0063] It should be noted that the purpose of this application is to dynamically configure the toolchain through hardware identifiers, intelligent merging mechanism of compilation options, and adaptive decision-making for incremental / full builds, but is not limited to basic tools such as busybox, make, makefile, and bat scripts. For example, make can be replaced with ninja and bat scripts can be replaced with shell scripts.

[0064] On the other hand, such as Figure 4 As shown, this embodiment provides an embedded software building device, including a parameter providing module 401, a configuration retrieval module 402, a framework generation module 403, and a compilation and execution module 404.

[0065] For example, the parameter providing module 401 is used to receive construction parameters input by the user, the construction parameters including a hardware identifier for specifying the target embedded hardware platform type.

[0066] For example, the configuration retrieval module 402 is used to retrieve the corresponding configuration file from a preset configuration library according to the hardware identifier. The configuration file is used to provide platform-related compiler toolchain paths and default compilation options.

[0067] For example, the framework generation module 403 is used to generate a compilation rule framework based on the configuration file, the compilation rule framework including a list of files to be compiled, final compilation options, and target generation rules.

[0068] For example, the compilation execution module 404 is used to perform compilation operations according to the compilation rule framework to generate target output files.

[0069] Specifically, the build parameters also include user-defined compilation options, linker file paths, source code path parameters, and target file names; the framework generation module 403 is further configured to: call the compilation tool located under the compiler toolchain path; scan the source files under the source code path parameters to generate the list of files to be compiled; merge the user-defined compilation options with the default compilation options to generate the final compilation options; and generate the target generation rules based on the target file names, wherein the target generation rules include executable file rules or static library file rules.

[0070] Specifically, the compilation and execution module 404 is further configured to: call the compilation tool through the compiler toolchain path, and generate the target output file based on the list of files to be compiled, the final compilation options, and the target generation rules.

[0071] Specifically, the parameter providing module 401 is implemented through the build.bat script, which serves as the build entry layer and is used to provide the configuration carrier file for the user-configured build parameters.

[0072] Specifically, the configuration retrieval module 402 converts the build parameters into make command-compatible startup parameters through Startmake.bat, calculates the number of CPU cores of the build computer, and starts the makefile for parallel build.

[0073] Specifically, the framework generation module 403 is implemented through a Makefile script, which is configured to: scan the source files under the source code path parameter, generate a list of files to be compiled containing .c, .s, .h files and corresponding linker scripts .ld; load the compiler toolchain path and default compilation options in the configuration file; and dynamically generate the target generation rules based on the target file name.

[0074] Specifically, the compilation execution module 404 is completed collaboratively through the following toolchain: make.exe parser, used to parse the compilation rule framework in the Makefile script and execute the Makefile script; busybox.exe toolset, providing shell command support for the compilation process; wherein, the make.exe parser calls the compilation tools under the compiler toolchain path and completes the compilation operation in cooperation with the busybox.exe toolset.

[0075] This embodiment also provides an electronic device, including a communication module, a memory, and a processor. The communication module is used to receive construction parameters input by a user. The memory stores executable instructions and a preset configuration library. When the processor is configured to execute the executable instructions in the memory, it implements the embedded software construction method described in any of the above embodiments.

[0076] This embodiment also provides a computer-readable storage medium storing a computer program thereon, which is loaded by a processor to execute the steps in the embedded software construction method described in any of the above embodiments.

[0077] In the embodiments of this application, the storage medium may be a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM), etc.

[0078] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0079] The above provides a detailed description of an embedded software construction method, apparatus, electronic device, and storage medium provided in the embodiments of this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for constructing embedded software, characterized in that, include: Provide user-configurable build parameters, including a hardware identifier for specifying the target embedded hardware platform type; The corresponding configuration file is retrieved from the preset configuration library based on the hardware identifier. The configuration file is used to provide the platform-related compiler toolchain path and default compilation options. A compilation rule framework is generated based on the configuration file. The compilation rule framework includes a list of files to be compiled, final compilation options, and target generation rules. The compilation operation is performed according to the compilation rule framework to generate the target output file.

2. The embedded software construction method according to claim 1, characterized in that, The build parameters also include user-defined compilation options, linker file paths, source code path parameters, and target file names; the compilation rule framework generated based on the configuration file includes: Invoke the compilation tools located in the compiler toolchain path; Scan the source files under the source code path parameter to generate the list of files to be compiled; The user-defined compilation options are combined with the default compilation options to generate the final compilation options; The target generation rules are generated based on the suffix of the target file name. The target generation rules include executable file rules or static library file rules.

3. The embedded software construction method according to claim 2, characterized in that, The compilation operation includes: The compiler tool is invoked through the compiler toolchain path to generate the target output file based on the list of files to be compiled, the final compilation options, and the target generation rules.

4. The embedded software construction method according to claim 1, characterized in that, The provision of user-configurable build parameters is implemented through the build.bat script, which serves as the build entry layer and is used to provide the configuration carrier file for user-configurable build parameters.

5. The embedded software construction method according to claim 4, characterized in that, Also includes: The Startmake.bat script converts the build parameters into startup parameters compatible with the make command, calculates the number of CPU cores on the build computer, and starts the makefile to build in parallel.

6. The embedded software construction method according to claim 2, characterized in that, The framework for generating compilation rules is implemented through a Makefile script, which is configured as follows: Scan the source files under the source code path parameter to generate a list of files to be compiled, including .c, .s, .h files and their corresponding linker scripts .ld. Load the compiler toolchain path and default compilation options from the configuration file; The target generation rule is dynamically generated based on the target file name.

7. The embedded software construction method according to claim 6, characterized in that, The compilation operation is completed collaboratively through the following toolchain: The make.exe parser is used to parse the compilation rule framework in the Makefile script and execute the Makefile script. The busybox.exe toolset provides shell command support for the compilation process; The make.exe parser calls the compilation tools under the compiler toolchain path and completes the compilation operation in cooperation with the busybox.exe toolset.

8. An embedded software construction apparatus, characterized in that, include: A parameter providing module is used to provide user-inputted construction parameters, including a hardware identifier for specifying the target embedded hardware platform type; The configuration retrieval module is used to retrieve the corresponding configuration file from the preset configuration library according to the hardware identifier. The configuration file is used to provide the platform-related compiler toolchain path and default compilation options. The framework generation module is used to generate a compilation rule framework based on the configuration file. The compilation rule framework includes a list of files to be compiled, final compilation options, and target generation rules. The compilation and execution module is used to perform compilation operations according to the compilation rule framework and generate target output files.

9. An electronic device, characterized in that, The method includes a communication module, a memory, and a processor. The communication module is used to receive construction parameters input by a user. The memory stores executable instructions and a preset configuration library. When the processor is configured to execute the executable instructions in the memory, it implements the embedded software construction method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, It stores a computer program, which is loaded by a processor to perform the steps in the embedded software construction method according to any one of claims 1-7.

Images