A modular, configurable, automated construction method and system for embedded systems

Abstract

The present application relates to the technical field of embedded software development automation construction, and particularly relates to a modular and configurable automation construction method for embedded systems, comprising the following steps: S1: a modular environment configuration and directory initialization step; S2: a source file collection and compilation step; S3: a linking and mapping file generation step; S4: a multi-partition batch data image generation step; S5: a construction product cleaning step; the S1 to S5 steps are driven by a command line based on a Makefile construction script, and logical linkage is formed between the steps through target dependency relationship. The present application replaces the graphical interface and background monitoring process of an integrated development environment with a command line tool chain, bypasses the parsing process of a large number of meta indexes and metadata by the integrated development environment when loading a project, and the continuous monitoring overhead of the integrated development environment on file system changes during runtime, so that the compilation startup time and incremental construction response time are greatly shortened.

Description

Technical Field

[0001] This invention relates to the field of automated construction technology for embedded software development, and in particular to a modular, configurable automated construction method and system for embedded systems. Background Technology

[0002] Embedded projects such as automotive electronics and industrial control, which have stringent requirements for operational stability and real-time performance, are mostly developed using graphical integrated development environments (IDEs). These tools integrate code editing, compilation, and debugging functions, making them intuitive and easy to use for small projects with minimal code and simple structures. This has long been a common development approach in the industry.

[0003] The complexity of embedded projects is increasing rapidly. The number of source code files in a single project can grow from hundreds to thousands. The project contains various low-level assembly files, business logic C files, and a large number of third-party driver libraries. The file dependencies of the entire project become intricate. Traditional integrated development environments, which were originally adapted to the running logic of small projects, are now finding it difficult to keep up with the development pace of large projects.

[0004] Traditional integrated development environments (IDEs) are designed from the outset to prioritize graphical interaction and full-featured integration, without being optimized for scenarios such as rapid construction of large-scale projects, cross-environment reuse, and automated pipeline integration. The graphical interface and the backend real-time monitoring of project files continuously consume hardware resources, and the entire build process and development tools are deeply bound together, making it difficult to separate them for independent use.

[0005] Traditional integrated development environments (IDEs) suffer from a series of problems when dealing with large-scale embedded projects, including slow compilation and startup, high incremental refresh latency, support for only serial compilation, high memory and computing power consumption leading to lag and crashes, repeated manual configuration for burning files to multiple storage partitions which is prone to errors, and the inability to directly migrate project configurations to automated processes which require additional adaptation scripts. Overall, these issues result in low build efficiency, high resource consumption, and weak automation and expansion capabilities, which have seriously hampered project iteration progress. Therefore, it is necessary to design a lightweight, modular, and fully automated embedded solution. Summary of the Invention

[0006] The purpose of this invention is to address the aforementioned shortcomings in the prior art by proposing a modular, configurable, and automated construction method and system for embedded systems.

[0007] To achieve the above objectives, the present invention adopts the following technical solution: a modular, configurable, and automated construction method for embedded systems, comprising the following steps: S1: Modular environment configuration and directory initialization steps, defining toolchain paths, project root directories and compilation parameters through a standardized variable set, and automatically generating a header file inclusion directory list and library file search paths based on the variables, while creating a directory structure for storing intermediate and output artifacts; S2: Source file collection and compilation steps. Automatically collect all source files and generate a source file list by recursively scanning the project directory tree. Perform incremental compilation judgment based on file timestamps and dependencies, and support multi-core parallel compilation scheduling. S3: Linking and mapping file generation step, skipping the intermediate scheduling layer of the integrated development environment, directly calls the linker to perform linking operations based on the target file list and linking parameters generated in the compilation step, generating executable files and mapping files; S4: Multi-partition batch data image generation step, based on the executable file, calls the format conversion tool with a single command and reads the pre-configured partition configuration file to generate data files and mapping files for at least one storage partition in batches; S5: Construct a product cleanup step, deleting intermediate and output files generated in steps S1 to S4 using a single command; Steps S1 to S5 are based on the Makefile build script to implement command-line driving. The steps are logically linked through target dependencies, and all configuration parameters are stored in text form in the build script and configuration file.

[0008] Preferably, the standardized variable set in S1 includes at least: a toolchain root directory variable, used to provide a unified call entry point for the compiler and format converter; a project root directory variable, used to recursively deduce all path configurations; compiler path variables and format converter path variables, used to encapsulate tool paths to avoid hardcoding; and the header file include directory list is automatically generated by shell commands, covering the device driver directory, user source code directory, toolchain system header file directory, and standard library header file directory. The compilation parameters include a customized set of parameters for the target chip architecture, which includes at least architecture type parameters, hardware accelerator enable parameters, floating-point operation specification parameters, and compilation diagnostic rule parameters.

[0009] Preferably, in S2, the source file collection recursively scans at least one source file directory tree using shell commands, automatically identifies and collects assembly files and C files, and generates a source file list. This collection process is performed once during the build and parsing phase. The incremental compilation judgment is based on the Makefile dependency engine. It records the dependency relationship between each target file and its corresponding source file and header file, and compares the file modification timestamps to determine whether recompilation is needed. Recompilation is only performed when the source file or its dependent header file is modified. The multi-core parallel compilation is achieved by calling the -jN parameter in the Makefile, where N is the number of parallel compilation tasks, and the value of N is determined according to the number of CPU cores of the development machine.

[0010] Preferably, the linking parameters in S3 include at least: output file control parameters, memory region configuration parameters, library file and library path parameters, and linking script file path parameters. The linking operation is performed directly based on the target file list and linking parameters, skipping the intermediate scheduling layer of the integrated development environment. The mapping file records the allocation addresses of each code segment and data segment in memory.

[0011] Preferably, the partition configuration file in S4 includes at least the following parameters: input executable file path, output data file path, output mapping file path, memory partition start address, memory partition size, and data format type; The batch generation is driven by the Makefile target dependency mechanism. Based on a unified executable file, it traverses at least one partition configuration file and calls a format conversion tool to generate the data file and mapping file corresponding to each partition respectively. The data file is a burning file in hexadecimal or binary format.

[0012] Preferably, it also includes S6: a large-scale engineering clustered parallel construction step; Step S6 is performed based on steps S1 to S5, and includes: a project list generation sub-step, which generates a project list to be built by reading a pre-configured project list file or automatically scanning project subdirectories in the project root directory that conform to the standard directory structure. The clustered parallel scheduling sub-steps encapsulate steps S2 to S4 of each project into independent sub-targets through the multi-target dependency and parallel scheduling mechanism of Makefile. It supports configuring the number of projects M to be executed simultaneously through the -jM parameter, where M is the number of parallel projects. The value of M is determined based on the memory resources and CPU cores of the development machine, realizing dual scheduling of project-level parallelism and single-project multi-core parallelism. The status monitoring and result summary sub-steps output log files independently during the build process of each project, and display the project name, current execution steps and execution status in real time on the console. After the build is completed, a summary report file is generated, recording the execution results, time consumption statistics and failure reasons of each project.

[0013] Preferably, the project subdirectories are organized according to a unified directory structure, including at least: a device driver directory, a user source code directory, a compilation output directory for storing intermediate products, and a storage partition directory for storing data image files. Each project subdirectory is independent of the others, and the intermediate and output products of each project are stored in their own subdirectories to avoid file conflicts when multiple projects are built in parallel. The total time for batch compilation meets the following requirements: ; in, M represents the time taken for serial compilation of a single project, where M is the number of parallel projects. For scheduling and logging overhead; The upper limit of the number of parallel projects M is determined by the number of CPU cores C on the development machine and the memory usage for compiling a single project. Decision, satisfaction: ; in, This represents the total available memory on the development machine.

[0014] A modular, configurable, and automated build system for embedded systems includes: a configuration management module for executing the automatic generation of standardized variable set definitions, compilation parameter configurations, header file inclusion directory lists, and library file search paths in S1. The configuration management module is implemented through a text-based configuration file, which supports cross-platform modification and reuse. The directory management module is used to perform the automatic creation operation of the output directory structure in S1; The source file management module is used to perform the recursive scanning of the project directory tree in S2 to collect all source files and generate a list of source files, as well as to perform incremental compilation judgment based on file timestamps and dependencies; The compilation scheduling module is used to execute the operation of calling the compiler in S2 to perform multi-core parallel compilation. The number of parallel tasks N is dynamically configured through the -jN parameter of the Makefile. The link management module is used to perform the linking operation by directly calling the linker in S3, generating executable files and mapping files; The batch data generation module is used to execute the operation in S4, which, based on the executable file, calls a format conversion tool and reads a partition configuration file through a single command to generate data files and mapping files for at least one storage partition in batches. The cleanup management module is used to perform the operation described in S5, which deletes intermediate and output files generated during the operation of each module using a single command. The configuration management module, directory management module, source file management module, compilation scheduling module, linking management module, batch data generation module, and cleanup management module are logically linked through target dependencies, and all are based on Makefile build scripts to implement command line drive to execute steps S1 to S5 of the method. By modifying the toolchain root directory variables, chip architecture parameters, and linking script file paths in the standardized variable set, the system adapts to different models of embedded chips and different development environments. Through single command-driven compilation of each module, a closed-loop construction of multi-partition data generation is achieved, and the construction products are directly used for chip programming or continuous integration deployment.

[0015] Preferably, it also includes a large-scale project clustering construction module, which includes: a project scanning submodule, used to perform the operation in S6 of generating a list of projects to be built by reading a pre-configured project list file or automatically scanning project subdirectories in the project root directory that conform to the standard directory structure; The parallel scheduling submodule is used to encapsulate the compilation, data generation, and cleanup steps of each project into independent sub-targets through the multi-target dependency and parallel scheduling mechanism of Makefile in S6, and configures the number of projects M to be executed at the same time through the -jM parameter, so as to realize the dual scheduling operation of project-level parallelism and single-project multi-core parallelism. The log aggregation submodule is used to perform the operations in S6, such as independently outputting a build log file for each project, displaying the execution status of each project in real time on the console, and generating an aggregation report file after the build is completed to record the execution results, time consumption statistics and failure reasons of each project. The project subdirectories are organized according to a unified directory structure. Each project subdirectory includes at least the following: device driver subdirectory, user source code subdirectory, compilation output subdirectory, memory partition subdirectory, and each project subdirectory is independent of the others.

[0016] Preferably, by modifying the toolchain root directory variables, chip architecture parameters, and linker script file paths in the standardized variable set, it adapts to different embedded chip models and different development environments; a single command drives the entire process from S1 to S4, achieving a closed-loop construction of compilation, linking, and multi-partition data generation, and the total time of the entire process satisfies: ; in, Initializing the S1 environment takes time. The compilation time for S2 S3 connection time consumption The generation time for S4 multi-partition data is relatively short, and the resulting artifacts can be directly used for chip programming or continuous integration deployment.

[0017] The design scheme proposed in this invention has the following beneficial effects during application: 1. This invention bypasses the graphical interface and background monitoring process of the integrated development environment (IDE) by replacing it with a command-line toolchain. This avoids the overhead of parsing a large number of meta-indexes and metadata during project loading and the continuous monitoring of file system changes during runtime. This significantly reduces compilation startup time and incremental build response time. At the same time, through a multi-core parallel compilation mechanism, multiple source files can be compiled simultaneously on different CPU cores, avoiding the efficiency bottleneck of traditional IDEs that only support serial compilation. 2. This invention uses a Makefile dependency engine to automatically record the dependencies between source files and header files, and combines this with file modification timestamps for accurate judgment. It can identify source files that have changed since the last build and their scope of impact, and only recompile these files while directly reusing the historical compilation products of the unchanged files, effectively avoiding the waste of time and computing resources caused by full recompiling. 3. This invention stores the configuration parameters of each step in text form in the Makefile script and configuration file, so that the configuration of all links in the build process can be directly viewed and modified. When it is necessary to migrate the build environment to other development machines or continuous integration systems, only a few path variables need to be modified to complete the adaptation. There is no need to develop special interface scripts for different environments, thus realizing the rapid portability and reuse of the build process on different platforms and environments. Attached Figure Description

[0018] Figure 1 This is a schematic diagram comparing the prior art of the present invention with the overall process of the present solution; Figure 2 This is a schematic diagram of the S1-S5 process of the present invention; Figure 3 This is a schematic diagram of the large-scale parallel processing of engineering processes according to the present invention. Detailed Implementation

[0019] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.

[0020] Example 1 Reference Figures 1-3 A modular, configurable, and automated build method for embedded systems includes the following steps: S1: Modular environment configuration and directory initialization steps, which define toolchain paths, project root directories and compilation parameters through a standardized variable set, and automatically generate header file inclusion directory lists and library file search paths based on variables, while creating a directory structure for storing intermediate and output artifacts; S2: Source file collection and compilation steps. Automatically collect all source files and generate a source file list by recursively scanning the project directory tree. Perform incremental compilation judgment based on file timestamps and dependencies, and support multi-core parallel compilation scheduling. S3: Linking and mapping file generation step, skipping the intermediate scheduling layer of the integrated development environment, directly calls the linker to perform linking operations based on the list of object files generated in the compilation step and the linking parameters, generating executable files and mapping files; S4: Multi-partition batch data image generation step, based on the executable file, calls the format conversion tool with a single command and reads the pre-configured partition configuration file to generate data files and mapping files for at least one storage partition in batches; S5: Build artifact cleanup step, which deletes intermediate and output files generated in steps S1 to S4 using a single command; Steps S1 to S5 are based on the Makefile build script to implement command-line driven operation. The steps are logically linked through target dependencies, and all configuration parameters are stored in text form in the build script and configuration file.

[0021] Furthermore, the standardized variable set in S1 includes at least: a toolchain root directory variable, used to provide a unified call entry point for the compiler and format converter; a project root directory variable, used to recursively deduce all path configurations; compiler path variables and format converter path variables, used to encapsulate tool paths to avoid hardcoding; and a header file include directory list, which is automatically generated by shell commands to include parameters, covering the device driver directory, user source code directory, toolchain system header file directory, and standard library header file directory. The compilation parameters include a customized set of parameters for the target chip architecture. The customized set of parameters includes at least architecture type parameters, hardware accelerator enable parameters, floating-point arithmetic specification parameters, and compilation diagnostic rule parameters.

[0022] Furthermore, in S2, source file collection recursively scans at least one source file directory tree via shell commands, automatically identifies and collects assembly files and C files, and generates a list of source files. This collection process is performed once during the build and parsing phase. Incremental compilation is based on the Makefile dependency engine. It records the dependency relationship between each target file and its corresponding source file and header file, and compares the file modification timestamps to determine whether recompilation is needed. Recompilation is only performed when the source file or its dependent header file is modified. Multi-core parallel compilation is achieved by calling the -jN parameter in the Makefile, where N is the number of parallel compilation tasks, and the value of N is determined according to the number of CPU cores on the development machine.

[0023] Furthermore, the linking parameters in S3 include at least: output file control parameters, memory region configuration parameters, library file and library path parameters, linker script file path parameters, linking operations are performed directly based on the object file list and linking parameters, skipping the intermediate scheduling layer of the integrated development environment, and mapping files record the allocation addresses of each code segment and data segment in memory.

[0024] Furthermore, the partition configuration file in S4 includes at least the following parameters: input executable file path, output data file path, output mapped file path, memory partition start address, memory partition size, and data format type; Batch generation is driven by Makefile target dependency mechanism. Based on a unified executable file, it traverses at least one partition configuration file and calls format conversion tools to generate data files and mapping files corresponding to each partition respectively; the data files are burning files in hexadecimal or binary format.

[0025] Furthermore, it also includes S6: a large-scale engineering clustered parallel construction step; Step S6 is executed based on steps S1 to S5 and includes: a project list generation sub-step, which generates a list of projects to be built by reading a pre-configured project list file or automatically scanning project subdirectories in the project root directory that conform to the standard directory structure. The clustered parallel scheduling sub-steps encapsulate steps S2 to S4 of each project into independent sub-targets through the multi-target dependency and parallel scheduling mechanism of Makefile. It supports configuring the number of projects M to be executed simultaneously through the -jM parameter, where M is the number of parallel projects. The value of M is determined based on the memory resources and CPU cores of the development machine, realizing dual scheduling of project-level parallelism and single-project multi-core parallelism. The status monitoring and result summary sub-steps output log files independently during the build process of each project, and display the project name, current execution steps and execution status in real time on the console. After the build is completed, a summary report file is generated, recording the execution results, time consumption statistics and failure reasons of each project.

[0026] Furthermore, the project subdirectories are organized according to a unified directory structure, including at least: a device driver directory, a user source code directory, a compilation output directory for storing intermediate artifacts, and a storage partition directory for storing data image files. Each project subdirectory is independent of the others, and the intermediate artifacts and output artifacts of each project are stored in their own subdirectories to avoid file conflicts when multiple projects are built in parallel. The total time for batch compilation meets the following requirements: ; in, M represents the time taken for serial compilation of a single project, where M is the number of parallel projects. For scheduling and logging overhead; The upper limit of the number of parallel projects M is determined by the number of CPU cores C on the development machine and the memory usage for compiling a single project. Decision, satisfaction: ; in, This represents the total available memory on the development machine.

[0027] A modular, configurable, automated build system for embedded systems includes: a configuration management module for automatically generating standardized variable set definitions, compilation parameter configurations, header file include directory lists, and library file search paths in S1. The configuration management module is implemented through a text-based configuration file and supports cross-platform modification and reuse. The directory management module is used to perform the automatic creation of the output directory structure in S1; The source file management module is used to perform the recursive scanning of the project directory tree in S2 to collect all source files and generate a list of source files, as well as to perform incremental compilation judgment based on file timestamps and dependencies; The compilation scheduling module is used to execute the multi-core parallel compilation operation called by the compiler in S2. The number of parallel tasks N can be dynamically configured through the -jN parameter in the Makefile. The link management module is used to perform linking operations by directly calling the linker in S3, generating executable files and mapping files; The batch data generation module is used to execute the operations in S4 based on executable files, calling the format conversion tool with a single command and reading the partition configuration file to generate data files and mapping files for at least one storage partition in batches. The cleanup management module is used to perform operations in S5 to delete intermediate and output files generated during the operation of each module using a single command. The configuration management module, directory management module, source file management module, compilation scheduling module, linking management module, batch data generation module, and cleanup management module are logically linked through target dependencies, and all of them are based on Makefile build scripts to implement command line drive to execute steps S1 to S5 of the method; By modifying the toolchain root directory variables, chip architecture parameters, and linker script file paths in the standardized variable set, the system adapts to different embedded chip models and different development environments. Through single command-driven compilation of each module, a closed-loop construction of multi-partition data generation is achieved, and the construction products are directly used for chip programming or continuous integration deployment.

[0028] Furthermore, it also includes a large-scale project clustering construction module, which includes: a project scanning submodule, used to perform the operation in S6 to generate a list of projects to be built by reading a pre-configured project list file or automatically scanning the project subdirectories in the project root directory that conform to the standard directory structure; The parallel scheduling submodule is used to encapsulate the compilation, data generation, and cleanup steps of each project into independent sub-targets through the multi-target dependency and parallel scheduling mechanism of Makefile in S6. The number of projects M to be executed at the same time is configured by the -jM parameter, realizing the dual scheduling operation of project-level parallelism and single-project multi-core parallelism. The log aggregation submodule is used to perform the following operations in S6: independently outputting build log files for each project, displaying the execution status of each project in real time on the console, and generating a summary report file after the build is completed to record the execution results, time consumption statistics and failure reasons of each project; The project subdirectories are organized according to a unified directory structure. Each project subdirectory includes at least the following: device driver subdirectory, user source code subdirectory, compilation output subdirectory, memory partition subdirectory, and each project subdirectory is independent of the others.

[0029] Furthermore, by modifying the toolchain root directory variables, chip architecture parameters, and linker script file paths in the standardized variable set, it adapts to different embedded chip models and development environments; by driving the entire S1 to S4 process with a single command, it achieves a closed-loop construction of compiling, linking, and generating multi-partition data, with the total process time meeting the following requirements: ; in, Initializing the S1 environment takes time. The compilation time for S2 S3 connection time consumption The generation time for S4 multi-partition data is relatively short, and the resulting artifacts can be directly used for chip programming or continuous integration deployment.

[0030] Example 2 Taking the embedded software construction of a motor control project in the field of automotive electronics as an example, the method of this invention is used to construct a single project; The developers first create a Makefile build script in the project root directory, and define a standardized set of variables according to step S1: point the toolchain root directory to the compiler installation path, point the project root directory to the current project path, and automatically recursively derive all source file paths and header file search paths based on the project root directory. Then, they execute the directory creation command to automatically generate a Debug directory for storing intermediate compilation files and a Memory directory for storing flashing files. The environment initialization process takes about 2 seconds. After completing the environment configuration, follow the S2 steps to perform compilation: The Makefile recursively scans all C and assembly files in the project directory tree using shell commands, automatically generating a complete list of source files. This process eliminates the need for manual addition of files in the IDE. During compilation, the Makefile automatically determines whether each source file needs to be recompiled based on the file modification timestamp. For unmodified source files, the historical compilation artifacts are reused without recompiling. Developers execute the `make -j8` command, utilizing an 8-core CPU to compile all 142 source files in parallel, with a full compilation taking approximately 52 seconds. When developers modify only one source file and then rebuild, incremental compilation takes only 0.8 seconds. After compilation, linking is performed according to step S3: Makefile directly calls the linker, which generates executable files and mapping files based on the list of object files generated during compilation and the pre-configured linking script. Then, according to step S4, the single command makedat is executed. Makefile automatically traverses the configuration files of the three partitions and calls the format conversion tool to generate the burning data files and mapping files of the three storage partitions in batches based on the unified executable file. This takes about 2 seconds. In traditional IDEs, this batch generation operation requires manual configuration of 14 parameters and takes more than 5 minutes. Finally, developers can delete all intermediate and output files with a single command by executing `make lean`. In this embodiment, developers can drive the entire closed-loop build process from environment preparation to multi-partition data image generation with a single makeall command, with a total time of about 60 seconds; in incremental build scenarios, it can be completed in just a few seconds, realizing an efficient development-debugging-verification iterative cycle.

[0031] Example 3 Taking an automotive ECU project in the field of automotive electronics as an example, the project contains 80 independent engineering sub-modules, such as CAN communication module, ADC sampling module, PWM drive module, etc. Each engineering sub-directory is organized according to a unified directory structure, including device driver directory, user source code directory, compilation output directory and memory partition directory. Developers maintain a project list file in the project root directory, listing all 80 project names to be built. When a full build is required, the command `makemulti-build-j40` is executed, and the system automatically performs the following operations according to the batch project clustering parallel build mechanism: The project scanning submodule reads the project list file and identifies all 80 projects and their corresponding paths. The parallel scheduling submodule uses the Makefile's multi-target dependency and parallel scheduling mechanism to encapsulate the compilation and linking steps of each project into independent sub-targets. Based on the development machine's 40-core CPU configuration, it triggers the compilation tasks of 40 projects to be executed in parallel. Each project further utilizes multi-core parallel compilation to achieve double speedup. The intermediate products of each project are stored in their own independent subdirectories, isolated from each other, to avoid file conflicts. During the build process, the console displays the execution status of each project in real time. After the build is completed, the log summary submodule automatically generates a summary report file, recording the execution results of all 80 projects. 78 projects succeeded and 2 projects failed, with the reasons for failure listed for developers to locate the problem. Subsequently, the developers execute the `makemulti-dat-j40` command. Based on the executable files generated for each project, the system triggers the multi-partition data image generation step in batches, synchronously generating multiple partition burning data files and mapping files for each of the 80 projects. The total time taken is about 20 seconds. Finally, the `makemulti-clean` command is executed to delete all intermediate and output products of all 80 projects with one click, without the need to clean up each project individually. In this embodiment, the full compilation of 80 projects is completed within 1 minute, which is 87.5% more efficient than the traditional IDE's sequential compilation of each project in 8 minutes; the batch data generation of all projects takes only 20 seconds, which is significantly more efficient than the traditional manual generation of each project.

[0032] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A modular, configurable, and automated construction method for embedded systems, characterized in that, Includes the following steps: S1: Modular environment configuration and directory initialization steps, defining toolchain paths, project root directories and compilation parameters through a standardized variable set, and automatically generating a header file inclusion directory list and library file search paths based on the variables, while creating a directory structure for storing intermediate and output artifacts; S2: Source file collection and compilation steps. Automatically collect all source files and generate a source file list by recursively scanning the project directory tree. Perform incremental compilation judgment based on file timestamps and dependencies, and support multi-core parallel compilation scheduling. S3: Linking and mapping file generation step, skipping the intermediate scheduling layer of the integrated development environment, directly calls the linker to perform linking operations based on the target file list and linking parameters generated in the compilation step, generating executable files and mapping files; S4: Multi-partition batch data image generation step, based on the executable file, calls the format conversion tool with a single command and reads the pre-configured partition configuration file to generate data files and mapping files for at least one storage partition in batches; S5: Construct a product cleanup step, deleting intermediate and output files generated in steps S1 to S4 using a single command; Steps S1 to S5 are based on the Makefile build script to implement command-line driving. The steps are logically linked through target dependencies, and all configuration parameters are stored in text form in the build script and configuration file.

2. The modular, configurable, and automated construction method for embedded systems according to claim 1, characterized in that: The standardized variable set in S1 includes at least: a toolchain root directory variable, used to provide a unified call entry point for the compiler and format converter; a project root directory variable, used to recursively deduce all path configurations; compiler path variables and format converter path variables, used to encapsulate tool paths to avoid hard coding; and the header file include directory list is automatically generated by shell commands, covering the device driver directory, user source code directory, toolchain system header file directory, and standard library header file directory. The compilation parameters include a customized set of parameters for the target chip architecture, which includes at least architecture type parameters, hardware accelerator enable parameters, floating-point operation specification parameters, and compilation diagnostic rule parameters.

3. The modular, configurable, and automated construction method for embedded systems according to claim 1, characterized in that: In S2, source file collection recursively scans at least one source file directory tree using shell commands, automatically identifies and collects assembly files and C files, and generates a list of source files. This collection process is executed once during the build and parsing phase. The incremental compilation judgment is based on the Makefile dependency engine. It records the dependency relationship between each target file and its corresponding source file and header file, and compares the file modification timestamps to determine whether recompilation is needed. Recompilation is only performed when the source file or its dependent header file is modified. The multi-core parallel compilation is achieved by calling the -jN parameter in the Makefile, where N is the number of parallel compilation tasks, and the value of N is determined according to the number of CPU cores of the development machine.

4. The modular, configurable, and automated construction method for embedded systems according to claim 1, characterized in that: The linking parameters in S3 include at least: output file control parameters, memory region configuration parameters, library file and library path parameters, and linking script file path parameters. The linking operation is performed directly based on the target file list and linking parameters, skipping the intermediate scheduling layer of the integrated development environment. The mapping file records the allocation addresses of each code segment and data segment in memory.

5. The modular, configurable, and automated construction method for embedded systems according to claim 1, characterized in that: The partition configuration file in S4 includes at least the following parameters: input executable file path, output data file path, output mapped file path, memory partition start address, memory partition size, and data format type; The batch generation is driven by the Makefile target dependency mechanism. Based on a unified executable file, it traverses at least one partition configuration file and calls a format conversion tool to generate the data file and mapping file corresponding to each partition respectively. The data file is a burning file in hexadecimal or binary format.

6. The modular, configurable, and automated construction method for embedded systems according to claim 1, characterized in that: It also includes S6: a large-scale, clustered, parallel construction step for engineering projects; Step S6 is performed based on steps S1 to S5, and includes: a project list generation sub-step, which generates a project list to be built by reading a pre-configured project list file or automatically scanning project subdirectories in the project root directory that conform to the standard directory structure. The clustered parallel scheduling sub-steps encapsulate steps S2 to S4 of each project into independent sub-targets through the multi-target dependency and parallel scheduling mechanism of Makefile. It supports configuring the number of projects M to be executed simultaneously through the -jM parameter, where M is the number of parallel projects. The value of M is determined based on the memory resources and CPU cores of the development machine, realizing dual scheduling of project-level parallelism and single-project multi-core parallelism. The status monitoring and result summary sub-steps output log files independently during the build process of each project, and display the project name, current execution steps and execution status in real time on the console. After the build is completed, a summary report file is generated, recording the execution results, time consumption statistics and failure reasons of each project.

7. The modular, configurable, and automated construction method for embedded systems according to claim 6, characterized in that: The project subdirectories are organized according to a unified directory structure, including at least: a device driver directory, a user source code directory, a compilation output directory for storing intermediate products, and a storage partition directory for storing data image files. Each project subdirectory is independent of the others, and the intermediate and output products of each project are stored in their own subdirectories to avoid file conflicts when multiple projects are built in parallel. The total time for batch compilation meets the following requirements: ； in, M represents the time taken for serial compilation of a single project, where M is the number of parallel projects. For scheduling and logging overhead; The upper limit of the number of parallel projects M is determined by the number of CPU cores C on the development machine and the memory usage for compiling a single project. Decision, satisfaction: ； in, This represents the total available memory on the development machine.

8. A modular, configurable, automated build system for embedded systems, characterized in that, include: The configuration management module is used to perform the automatic generation of standardized variable set definition, compilation parameter configuration, header file inclusion directory list and library file search path in S1 of claim 1. The configuration management module is implemented through a text-based configuration file, which supports cross-platform modification and reuse. The directory management module is used to perform the automatic creation operation of the output directory structure in S1 as described in claim 1; The source file management module is used to perform the operation of recursively scanning the project directory tree to collect all source files and generate a source file list in S2 of claim 1, as well as the operation of performing incremental compilation judgment based on file timestamps and dependencies; The compilation scheduling module is used to execute the operation of calling the compiler to perform multi-core parallel compilation in S2 as described in claim 1, and to dynamically configure the number of parallel tasks N through the -jN parameter of the Makefile; The link management module is used to perform the linking operation by directly calling the linker in S3 of claim 1, and to generate executable files and mapping files; The batch data generation module is used to perform the operation in S4 of claim 1, which, based on the executable file, calls a format conversion tool and reads a partition configuration file through a single command to generate data files and mapping files for at least one memory partition in batches. The cleanup management module is used to perform the operation described in claim 1, S5, of deleting intermediate and output files generated during the operation of each module by a single command. The configuration management module, directory management module, source file management module, compilation scheduling module, link management module, batch data generation module, and cleanup management module are logically linked through target dependencies, and all are based on Makefile build scripts to implement command line drive to execute steps S1 to S5 of the method described in claim 1. By modifying the toolchain root directory variables, chip architecture parameters, and linking script file paths in the standardized variable set, the system adapts to different models of embedded chips and different development environments. Through single command-driven compilation of each module, a closed-loop construction of multi-partition data generation is achieved, and the construction products are directly used for chip programming or continuous integration deployment.

9. A modular, configurable, automated build system for embedded systems according to claim 8, characterized in that: It also includes a large-scale project clustering construction module, which includes: a project scanning submodule, used to perform the operation in S6 of claim 6, which generates a list of projects to be built by reading a pre-configured project list file or automatically scanning the project subdirectories in the project root directory that conform to the standard directory structure; The parallel scheduling submodule is used to execute the multi-target dependency and parallel scheduling mechanism through Makefile in S6 of claim 6, which encapsulates the compilation, data generation and cleaning steps of each project into independent sub-targets, and configures the number of projects M to be executed at the same time through the -jM parameter, so as to realize the dual scheduling operation of project-level parallelism and single-project multi-core parallelism. The log aggregation submodule is used to perform the operations described in claim 6, namely, outputting a build log file independently for each project, displaying the execution status of each project in real time on the console, and generating a summary report file to record the execution results, time consumption statistics and failure reasons of each project after the build is completed. The project subdirectories are organized according to a unified directory structure. Each project subdirectory includes at least the following: device driver subdirectory, user source code subdirectory, compilation output subdirectory, memory partition subdirectory, and each project subdirectory is independent of the others.

10. The method according to any one of claims 1 to 7, characterized in that, By modifying the toolchain root directory variables, chip architecture parameters, and linker script file paths in the standardized variable set, it adapts to different embedded chip models and development environments; by driving the entire process from S1 to S4 with a single command, it achieves a closed-loop construction of compiling, linking, and generating multi-partition data, and the total time consumption of the entire process meets the following requirements: ； in, Initializing the S1 environment takes time. The compilation time for S2 S3 connection time consumption The generation time for S4 multi-partition data is relatively short, and the resulting artifacts can be directly used for chip programming or continuous integration deployment.

Images