Code writing method adaptive to multi-model air monitors

Abstract

The invention relates to the field of embedded systems, discloses a code writing method adaptive to multi-model air monitors, and is used for solving the problems of high development and maintenance cost, complex firmware version and the like of multi-model equipment in the prior art. The method comprises the following steps of loading a complete source code, analyzing a function requirement according to a configuration file of target equipment, cutting a function module irrelevant to the target equipment, carrying out dependency relationship analysis and logic repair on cut codes, then recombining the cut codes, generating a simplified code project adaptive to the target equipment, generating a firmware file through compiling, and storing the firmware file in a server. And burning the generated firmware to the target equipment. According to the method, the firmware can be dynamically generated according to different target equipment models, flexible adaptation of multi-model equipment is achieved, the development cost is reduced, the code size is optimized, the equipment function deployment efficiency is improved, and the method is suitable for rapid production and maintenance of multi-model and small-batch air monitors.

Description

Technical Field

[0001] The present invention relates to the technical field of embedded systems, and in particular to a code writing method adapted to multiple models of air monitors. Background Art

[0002] As an important device in environmental monitoring, air monitors are widely used in industrial, agricultural and civil fields to monitor the concentration of pollutants in the air in real time. However, with the complexity of application scenarios, different users have significantly different requirements for monitoring content, communication protocols and hardware interfaces. At present, air monitors on the market are usually designed with different models for different functional requirements. Although this approach can meet diverse needs, there are many problems in the development, production and maintenance process.

[0003] In the prior art, in order to support different communication protocols or hardware interfaces, it is usually necessary to design and develop firmware for each device model separately. This development method not only leads to an increase in repetitive workload, but also significantly increases development costs. In addition, since each model of firmware has a specific functional configuration, its code is not universal, which leads to the complexity of code management and waste of resources. At the same time, the hardware platforms of different models of devices usually need to be designed and maintained separately, further increasing the difficulty of production and maintenance.

[0004] In the production process, in order to meet the market demand for multiple equipment models, existing technologies require the manufacture and storage of multiple types of equipment hardware, which increases inventory pressure and the difficulty of production line management. After the equipment is delivered, after-sales service needs to provide specific technical support for each equipment model, further increasing after-sales costs and service complexity.

[0005] In summary, the existing technologies in the development, production and maintenance of multiple models of air monitors generally have problems such as low development efficiency, high cost, low code reuse rate, and complex production and maintenance. These problems are particularly prominent in an environment with diversified demands and fierce market competition, and a solution that can reduce development costs, improve production efficiency and equipment flexibility is urgently needed. Summary of the invention

[0006] In view of the shortcomings of the prior art, the present invention provides a code writing method for adapting to multiple models of air monitors. Through modular code cutting and reorganization, flexible adaptation of multiple models of air monitors is achieved, development costs and maintenance complexity are reduced, and equipment production efficiency is improved.

[0007] To achieve the above objectives, the present invention is implemented through the following technical solutions: a code writing method adapted to multiple models of air monitors, comprising the following steps: Load the complete source code for multiple models of air monitors; Analyze the complete source code according to the configuration files of the target device; Cut out functional modules irrelevant to the target device based on configuration files and code logic; Reorganize the trimmed code by analyzing the coupling and dependency relationships between modules; Compile the reorganized code to generate the adapter firmware for the target device; Write the generated firmware to the target device.

[0008] Preferably, the step of analyzing the complete source code according to the configuration file of the target device includes: Search the variables and module information defined in the configuration file to determine the functional modules required by the target device; Traverse the complete source code file and locate the code snippet corresponding to the variable or module in the configuration file; Analyze the validity conditions of the function modules according to the macro definition statements and conditional compilation statements in the C language; Filter out valid code modules related to the target device functions and record the validity conditions and their dependencies.

[0009] Preferably, the step of cutting out functional modules irrelevant to the target device according to the configuration file and the code logic includes: Traverse all macro definitions in the complete source code and mark the effective scope of each macro definition; Based on the target device functional requirements in the configuration file, match the macro definitions and related code modules that need to be retained; The macro definitions and their code modules that do not meet the configuration file requirements are shielded or marked as invalid; According to the logical structure of conditional compilation statements, cut out the code fragments that are irrelevant to the target device; Generate a streamlined code version that only retains the target device functions, and record the code module change relationship before and after trimming.

[0010] Preferably, the step of reorganizing the tailored code by analyzing the coupling and dependency relationships between modules includes: Traverse the pruned code modules and record the function call relationships, variable dependencies, and data transfer paths between modules; Based on the recorded dependencies, find broken dependencies or undefined calls caused by pruning operations; Repair modules with broken dependencies, including adding alternative logic, relinking functions, or introducing necessary shared variables; Merge modules related to the target device functions to ensure the logical structure of the tailored code is complete; Generate a fixed dependency table and record the adjusted module call path.

[0011] Preferably, the step of reorganizing the tailored code by analyzing the coupling and dependency relationships between modules further includes: Determine the module set that needs to be reorganized based on the functional module requirements defined in the target device configuration file; Build a new module calling sequence according to the dependencies between modules and generate a module logic tree; Rearrange the trimmed valid code modules in the order of the logic tree to build a new code project structure; Identify scenarios where cross-module calls or variable sharing are required, and establish a global sharing mechanism; Save the reorganized code project to ensure that it is functionally consistent with the target device.

[0012] Preferably, the step of compiling the reorganized code to generate the adaptation firmware of the target device includes: Load the reorganized code project and parse the module definition, variable declaration and macro configuration in the code; Generate a list of compilation options based on the functional requirements of the target device, including the target architecture, optimization level, and hardware resource restrictions; Call the standardized compilation tool chain to compile code modules one by one, parse and optimize function calls and data access paths in the code; Check for syntax errors, undefined variables, or unresolved dependencies that may occur during compilation, and output detailed debugging information if errors exist; After successful compilation, link all modules to generate firmware files, and record the compilation log and version information of the generated files; Perform integrity check on the generated firmware file to ensure that it is compatible with the hardware and functional requirements of the target device.

[0013] Preferably, the step of writing the generated firmware into the target device comprises: Write the generated firmware file to the target device memory via Bluetooth or USB interface, and verify the device function after the firmware is written.

[0014] Preferably, the complete source code is a general code base that supports multiple air monitor models, including but not limited to air monitors that monitor carbon dioxide, carbon monoxide or ozone.

[0015] Preferably, the method can dynamically generate different firmware according to different configuration files of the target device model.

[0016] The present invention also provides a code writing device adapted to multiple models of air monitors, including: Storage module, used to store complete source code for multiple models of air monitors; The processing module is used to load the complete source code, parse the configuration file, cut the functional modules that are not related to the target device, and reorganize the cut code; A compiling module, used for compiling the reorganized code to generate the adapter firmware of the target device; Communication module, used to write the generated firmware to the target device.

[0017] The present invention provides a code writing method adapted to multiple models of air monitors. It has the following beneficial effects: 1. The present invention realizes the ability to adapt to multiple target device models through dynamic cutting and modular reorganization based on configuration files. The functional requirements of different devices do not need to be redeveloped, and the adapted firmware can be quickly generated by providing the corresponding configuration files, which significantly improves the development and production efficiency.

[0018] 2. The present invention adopts modular design and code reuse technology to avoid the high cost of developing firmware for each device model. By cutting out device-independent codes, redundant development work is reduced, and the code maintenance and upgrade process is simplified.

[0019] 3. By cutting and optimizing the complete source code, the present invention significantly reduces the code volume of the firmware. The streamlined code reduces the device's demand for storage and processor resources, so that a more economical hardware platform can be used, further reducing the cost of the device.

[0020] 4. The present invention supports dynamic firmware generation, can quickly generate and deploy firmware files according to device model requirements, and shortens device delivery time. It is especially suitable for multi-model, small-batch device production scenarios, effectively improving the market competitiveness of products.

[0021] 5. In the process of module cutting, the present invention ensures the integrity and correctness of the cut code through dependency analysis and logic repair technology. The code after module reorganization can run normally, avoiding function loss or abnormality caused by dependency breakage.

[0022] 6. Through a unified code framework and modular design, the present invention reduces the number of firmware versions and the difficulty of management. During the production process, only one complete code base needs to be maintained, and the functional requirements of different devices can be met by tailoring the configuration files, which significantly simplifies version management.

[0023] 7. The present invention supports rapid adaptation of new functions or new device models by updating configuration files without modifying the complete source code. This high scalability enables the device to quickly respond to market demand and improve the flexibility and life cycle value of the product.

[0024] 8. The present invention simplifies the production process of equipment through a unified hardware platform and a method of dynamically configuring firmware, reduces the types of spare parts and inventory pressure. In the after-sales process, the device function can be quickly repaired or expanded by updating the configuration file, thereby improving service efficiency and user satisfaction. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] Figure 1 It is a schematic diagram of the method flow of the present invention; Figure 2 It is a schematic diagram of the structure of the device of the present invention; Figure 3 The figure is a schematic diagram of a method flow of an embodiment of the present invention.

[0026] Among them, 10, storage module; 20, processing module; 30, compilation module; 40, communication module. DETAILED DESCRIPTION

[0027] The following will be combined with the drawings in the specification of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0028] Please refer to the attached Figure 1 The present invention provides a code writing method for adapting multiple models of air monitors, aiming to achieve efficient adaptation of multiple models of air monitors through intelligent cutting and reorganization of general codes, reduce development and maintenance costs, and improve production efficiency. The method of the present invention includes the following specific steps: S1. Load the complete source code for multiple air monitors; S2. Analyze the complete source code according to the configuration file of the target device; S3, cut out the functional modules irrelevant to the target device according to the configuration file and code logic; S4. Reorganize the pruned code by analyzing the coupling and dependency relationships between modules; S5, compile the reorganized code to generate the adapter firmware of the target device; S6. Write the generated firmware to the target device.

[0029] In this embodiment, step S1 is the process of loading the complete source code for adapting multiple models of air monitors. The complete source code is the core foundation of the present invention, and includes all supported sensor modules, communication protocols, and hardware interface implementation logic.

[0030] In general, the complete source code consists of multiple functional modules, each of which is developed independently and organized according to specific rules, such as: Core logic modules, including data acquisition, processing algorithms and sensor control; Communication module, supporting protocols such as Modbus, MQTT, HTTP, etc. Hardware interface module, adapting to interfaces such as RS485, Wi-Fi, Bluetooth, etc.

[0031] Specifically, in this embodiment, the loading process of the complete source code includes the following contents: First, the general code base is organized in the form of file directories, and all functional modules are divided by type. For example, sensor-related codes are located in one folder, including the specific implementation codes of carbon dioxide sensors, carbon monoxide sensors, and ozone sensors. Communication protocol implementation codes are located in another folder, including parsing, transmission, and encryption functions of various protocols.

[0032] In one possible implementation, when the system loads the complete code base, it scans the directory structure to obtain the file path and file type information of each module. This process helps with subsequent module selection and tailoring. As an option, loading can be achieved by recursively traversing the directory to ensure that all module files are loaded into memory.

[0033] Generally, the complete source code contains several necessary configuration files, which define the common parameters of the code module. For example: The sensor types supported by the device; Default communication protocol; Default hardware interface configuration.

[0034] As an implementation method, these configuration files are parsed first during the loading process to confirm the functional scope in the complete code. After loading is completed, the system temporarily stores this information in memory for subsequent steps.

[0035] In some embodiments, the complete code also includes a test module for simulating the function implementation in different device environments. For example, the data acquisition function of a carbon dioxide sensor can be tested through a virtual device interface or the compatibility of a communication protocol can be tested through a simulated network. These test modules are marked as "non-essential modules" during the loading process and usually do not enter the subsequent cutting and reorganization process.

[0036] Specifically, after loading is complete, the system will generate a module list that lists all loaded modules and their functional scope. For example: Module name: such as "CO2_Sensor"; Module type: such as "sensor module"; Module status: such as "can be cut" or "required module".

[0037] As an option, the loading process can also include verification of the code version, for example, by verifying the version number of the complete source code and the recorded information in the function description file to ensure the consistency of the code with the device configuration. This step can effectively avoid cutting and reorganization errors caused by code mismatch.

[0038] In another possible implementation, the loading of the complete source code can also support dynamic expansion, for example, additionally loading new sensor modules or protocol modules based on the existing code base to meet the expansion requirements of device functions. At this time, the system will automatically update the module list to ensure that the newly loaded modules can participate in the subsequent steps.

[0039] Finally, after loading is complete, the system will generate a loading log, recording the number of loaded modules, file path, and loading status. This log can be used to trace the subsequent cutting and debugging process.

[0040] Through the above loading steps, the complete source code is fully imported into the system, providing the necessary technical foundation for subsequent cutting, reorganization and compilation.

[0041] In this embodiment, step S2 is a process of analyzing the complete source code according to the configuration file of the target device. The purpose of this step is to identify the functional modules required by the target device from the complete source code as the basis for subsequent tailoring operations.

[0042] Generally, the configuration file uses a structured format, such as JSON or XML, to specifically define the target device model information, supported sensor types, communication protocols, and hardware interface requirements. The content of the configuration file clarifies the functional scope of the target device, making it easier for the system to select and tailor modules. For example, the configuration file may contain the following: Device model: specifies the specific target device, such as "MSD-A"; Functional modules: List the functional modules supported by the target device, such as "carbon dioxide sensor" and "carbon monoxide sensor"; Communication protocol: defines the communication methods supported by the device, such as "Modbus" and "MQTT"; Hardware Interface: describes the communication interface of the device, such as "RS485" and "Wi-Fi".

[0043] In one possible implementation, the system first parses the top-level structure of the configuration file to extract the device model and its function definition. Then, the system matches the relevant modules in the complete source code according to the sensor type and protocol requirements defined in the configuration file. For example, if the configuration file specifies that the target device requires a CO2 sensor function, the system will mark all CO2 sensor-related code snippets from the complete source code, including data acquisition, calibration algorithms, and data transmission logic.

[0044] Specifically, the system will perform a matching process for each function definition in the configuration file. For example, for the communication protocol, the system will analyze the protocol specified in the configuration file and locate its implementation module in the complete source code, such as the connection management module of the MQTT protocol or the data parsing module of the Modbus protocol.

[0045] As an option, the system can also filter out code modules that match the hardware configuration of the target device based on the hardware interface information in the configuration file. For example, if the target device supports Wi-Fi interface but not Bluetooth interface, the system will automatically mark the Bluetooth-related code as "invalid module" for subsequent trimming.

[0046] In some embodiments, the configuration file not only contains the function definition of the target device, but also can attach hardware constraints, such as processor performance limitations or storage capacity limits. When parsing the configuration file, the system will further optimize the module selection based on these constraints. For example, for devices with limited storage capacity, the system will give priority to lightweight communication protocol modules.

[0047] Generally, the complete source code contains many code snippets related to macro definitions, such as conditional compilation logic implemented using #ifdef or #define statements. In one possible implementation, after parsing the configuration file, the system will combine the macro definition information in the source code to determine which macros need to be activated. For example, if a carbon dioxide sensor is defined in the configuration file, the system will activate the code snippet related to #define SUPPORT_CO2 and block the code of the undefined module.

[0048] As an option, the system will also generate a module dependency table during the analysis process to record the dependencies between the target module and other modules. For example, if the CO2 sensor module depends on a shared calibration algorithm, the system will mark the dependency in the dependency table. This helps avoid removing necessary dependent modules during subsequent trimming.

[0049] In some embodiments, the parsing of the configuration file also includes a verification process, such as checking whether the modules listed in the configuration file exist in the complete source code. If it is found that the configuration file references a non-existent module, the system will output a warning message so that the developer can correct it in time.

[0050] Finally, after the configuration file is parsed, the system will generate a module selection list, recording all the functional modules and their dependencies required by the target device. This list will serve as a direct input for the subsequent cutting and reorganization steps to ensure the integrity and functionality of the cut code.

[0051] Through the above process, this embodiment can accurately analyze the functional requirements of the target device and provide technical support and decision-making basis for subsequent tailoring operations.

[0052] In this embodiment, the purpose of step S3 is to cut out functional modules irrelevant to the target device according to the configuration file and code logic, thereby generating a more concise and efficient code structure and providing an optimized code foundation for subsequent steps.

[0053] Generally, the complete source code contains multiple device function modules and common logic, some of which may be irrelevant to the functional requirements of the target device, so these irrelevant modules need to be removed through the trimming operation. The trimming process needs to ensure the integrity of the code and the consistency of the functions to avoid the loss of functions or the destruction of the code structure due to module removal.

[0054] Specifically, the trimming operation is based on the module selection list, which is generated by parsing the configuration file in step S2 and records the module information that needs to be retained and removed by the target device. In a possible implementation, the system first marks the functional modules in the complete source code one by one, including "necessary modules", "non-necessary modules" and "dependent modules". Among them: Essential modules are core functions of the target device, such as sensor driver code; Non-essential modules are code snippets that are not relevant to the target device, such as unused communication protocols; Dependent modules are modules that have a logical or data coupling relationship with necessary modules, such as calibration algorithms for sensor data.

[0055] As an option, the trimming operation starts with file-level removal. The system will mark the corresponding code files in the complete source code as "invalid files" according to the "non-essential modules" list in the module selection list and remove them from the project structure. For example, if the target device only supports carbon dioxide sensors, the system will directly remove the code files related to carbon monoxide and ozone sensors.

[0056] In some embodiments, the system not only performs tailoring at the file level, but also operates at the code level. For example, the complete source code may use conditional compilation statements (such as #ifdef and #define) to achieve selective activation of functional modules. The system parses these conditional compilation statements and combines the configuration file information to determine which code segments need to be retained and which code segments need to be blocked. Specifically, when a certain sensor type is defined in the configuration file, the system activates the corresponding macro definition, such as #define SUPPORT_CO2, and removes other inactivated macro definition code segments.

[0057] As an implementation method, the trimming process also needs to deal with the dependencies between code modules. For example, when a module depends on another code marked as "non-essential module", the system will determine whether the dependency can be replaced or removed. If the dependency cannot be replaced, the system will re-mark the module as "essential module" to ensure the functional integrity of the code.

[0058] In another possible implementation, the trimming process will perform a detailed analysis of the functions and variables in the module. For example, if a module only uses some functions or variables, and the rest are not called by the target device, the system will trim the uncalled parts to further optimize the code size. The trimmed modules will be reorganized to adapt to the functional requirements of the target device.

[0059] Generally, after the trimming is completed, the system will record the removed code and generate a trimming log. The trimming log includes the name, type and reason for removal of each removed module. This log can be used for debugging and tracing in subsequent steps.

[0060] As an option, the system will also perform preliminary verification on the tailored code, such as checking the logical integrity and data consistency of the code. If a logical error or dependency break is found, the system will record the details in the log and prompt the user to fix it.

[0061] Through the above-mentioned trimming operation, this embodiment can effectively remove code modules irrelevant to the target device, reduce code complexity and storage occupancy, and provide an efficient and optimized code foundation for code reorganization and compilation in subsequent steps.

[0062] In this embodiment, the purpose of step S4 is to reorganize the tailored code by analyzing the coupling and dependency relationships between modules, thereby ensuring that the tailored code can run normally and maintain functional integrity and logical consistency.

[0063] Generally, after code pruning, the function calls, variable dependencies, or logical associations between the original modules may be interrupted due to the removal of the modules. Therefore, this step reorganizes the pruned code logic and solves possible dependency issues through static analysis and dependency repair.

[0064] Specifically, before executing code reorganization, the system will perform dependency analysis on the pruned code modules. This analysis includes the following aspects: Function call dependency: Check whether the module retained after pruning has any calls to the removed module functions. If a call is found to be broken, the system will repair the call path by replacing logic or adding an adaptation layer.

[0065] Variable sharing dependencies: Identify access to global variables in the retained modules and ensure that the dependent variables are still available after pruning. For example, if a module depends on a shared sensor data variable that is defined in the removed module, the system needs to redefine or migrate the variable.

[0066] Logic control dependency: Analyze the logic path of the trimmed module to ensure that all branch conditions and control flows are fully implemented. For example, if some sensor modules are removed, the system will adjust the logic control path to avoid triggering the non-existent module functions.

[0067] In one possible implementation, the system builds a dependency graph based on the calling relationships between modules. Each node in the graph represents a code module, and the edges represent the dependency paths between modules. By traversing the dependency graph, the system can automatically identify broken dependency paths and take appropriate measures to repair them. For example, if a module calls the initialization function of a removed module, the system replaces the original function with a simplified version of the initialization logic.

[0068] As an option, the system will also perform logic optimization on the trimmed code modules, such as merging modules with similar functions or rearranging the calling order of modules to improve the running efficiency of the code. For example, when multiple modules rely on the same sensor data processing logic, the system can extract the processing logic into an independent module for other modules to share and call.

[0069] In some embodiments, the reorganization operation also includes adjusting the interfaces between modules. For example, the trimmed module may need to modify its input and output interfaces to adapt to the new code structure. If the input parameters of a module originally come from the removed module, the system will adjust the interface logic so that its input parameters come from the calculation results of the retained module.

[0070] As an implementation method, after the code is reorganized, the system will generate a new code project structure, which is reorganized based on the functional requirements of the target device. For example, the modules retained after cutting will be grouped according to functional types, such as "sensor module", "communication module" and "data processing module". This reorganized structure facilitates subsequent compilation and debugging.

[0071] In another possible implementation, the system will also perform preliminary verification on the reorganized code. For example, the system will simulate the data transfer path between modules to ensure that all calls and variable accesses are executed correctly. If problems are found, the system will record detailed error information and return to the reorganization step for repair.

[0072] Generally, after the code reorganization is completed, the system will generate a dependency repair report and module relationship diagram, which records in detail all dependency repair contents and the calls and data flow paths between modules. This information can be used for subsequent debugging and function verification.

[0073] Through the above operations, this embodiment ensures the logical integrity of the pruned code, eliminates possible dependency issues, and optimizes the code structure through module reorganization, providing a reliable technical foundation for subsequent compilation and operation.

[0074] In this embodiment, the purpose of step S5 is to compile the reorganized code to generate the adaptation firmware of the target device. This step converts the reorganized code module into a binary firmware file that can be directly run on the target device hardware, providing a basis for subsequent device burning and function realization.

[0075] Generally, the reorganized code needs to go through multiple steps of compilation, including syntax checking, code optimization, and binary file generation. To ensure that the generated firmware can accurately adapt to the target device, this step will be compiled and set according to the hardware configuration and functional requirements of the target device.

[0076] Specifically, the system first loads the reorganized code project and extracts hardware-related parameters based on the configuration file of the target device. These parameters include but are not limited to: The processor architecture of the target device, such as ARM Cortex-M or RISC-V; Memory size and partition layout, such as the capacity and starting address of flash and RAM; The type of external hardware interface, such as I2C, SPI, or UART.

[0077] In one possible implementation, the system generates a compilation option list based on the above hardware parameters, which includes the compiler's target architecture settings, memory optimization level, and debug information retention options. For example, for low-power devices, the system will enable a higher code compression level; while for high-performance devices, it will prioritize retaining more debug information for functional verification.

[0078] As an option, the compilation process is divided into multiple stages, including code preprocessing, syntax parsing, target code generation and linking. In the preprocessing stage, the system will parse all macro definitions and conditional compilation statements to ensure that only code modules related to the target device are compiled. For example, for devices that support carbon dioxide sensors, the preprocessing stage will activate the code related to this function while shielding the implementation logic of other sensors.

[0079] In some embodiments, the system will also perform static optimization on the reorganized code, such as merging redundant function calls or deleting useless variable definitions. This optimization can further reduce the size of the firmware while improving operating efficiency. For example, if there is an unused debug function in a module, the system will remove it during compilation.

[0080] In the target code generation phase, the system converts the high-level language logic in the reorganized code into machine code that adapts to the target device processor instruction set. For example, for ARM architecture devices, the system generates target code in the ARM Thumb instruction set format; and for RISC-V architecture devices, it generates the corresponding instruction set.

[0081] In one possible implementation, after compilation is complete, the system enters the linking phase to link all target code modules into a complete firmware file. During the linking process, the system resolves all function calls and global variable references to ensure that their addresses can be resolved correctly. If undefined symbols or duplicate definitions are found, the system will output detailed error information for developers to fix.

[0082] Generally, the generated firmware file needs to conform to the storage layout of the target device. For example, some devices require the firmware file to be stored in a specific segmented format, such as the boot code is located in the header of the firmware, and the data segment is located in a fixed address range. In this case, the system will adjust the segment layout of the firmware file according to the device requirements and generate the corresponding load table.

[0083] As an option, the system also performs integrity checks on the generated firmware file, such as calculating the file's hash value or checksum to ensure that the file has not been tampered with. This verification information can be used to verify the correctness of the firmware loading after the device is burned.

[0084] In some embodiments, the system generates a compilation report after the compilation and linking are completed. The report contains the following contents: List of compiled modules; The size and segment layout of the firmware; Warnings or optimization messages that appear during compilation.

[0085] Through the above operations, this embodiment can ensure that the generated firmware file can not only accurately adapt to the hardware of the target device, but also optimize the operating efficiency and resource usage to the maximum extent, providing reliable guarantee for the functional realization of the device.

[0086] In this embodiment, the purpose of step S6 is to write the generated firmware file into the target device to ensure that the target device can load and execute the adapted functional logic. This step involves the transmission, burning and functional verification of the firmware, and is a key link in realizing the functions of the target device.

[0087] Generally, the firmware file needs to be transferred to the device's memory through an interface supported by the device. The target device may support multiple interface types, such as USB, UART, Wi-Fi, or Bluetooth. Different interfaces require corresponding transmission protocols and tools for data exchange.

[0088] Specifically, in one possible implementation, the system will first detect the interface type of the target device and establish a communication connection. For example, if the target device supports a USB interface, the system will establish communication with the device through a standard USB transfer protocol (such as DFU mode); for devices that support Bluetooth, the system will transmit data through a Bluetooth protocol stack (such as BLE GATT). After the connection is established, the system will verify the communication status of the device to ensure the normal operation of the interface.

[0089] As an option, the firmware file may need to be encrypted before transmission to prevent unauthorized copying or tampering. For example, the system can symmetrically encrypt or sign the firmware file and restore the integrity of the file by decrypting or verifying the signature after receiving it on the target device. This security measure is particularly suitable for industrial equipment that requires high confidentiality.

[0090] In some embodiments, the firmware transmission process also includes block transmission and verification. For example, the system divides the firmware file into multiple data blocks, transmits one data block at a time, and calculates the checksum after the target device receives it to ensure the integrity of each data block. If the verification of a data block fails, the system will resend the data block.

[0091] Generally, after the firmware file is successfully transferred to the target device, the system will start the burning process. The burning process writes the firmware file from the temporary storage area to the permanent storage of the target device, such as Flash memory. In one possible implementation, the system writes the parts of the firmware file to the specified addresses according to the partition layout of the device memory. For example: The startup code is written to the first address of the memory; The data segment is written to a fixed offset address; Configuration parameters are written to specific areas of memory.

[0092] During the programming process, the system monitors the status of the storage operation to ensure that each byte written is stored correctly. After the programming is completed, the system verifies the memory contents, for example by reading and comparing the data to confirm the correctness of the written content.

[0093] As an option, after the flashing is completed, the target device may need to perform a self-test procedure to verify the functionality of the firmware. For example, the device will load the boot code and initialize the hardware modules. If any abnormalities are found, the system will record error information and prompt the user to repair it.

[0094] In another possible implementation, after the flashing is completed, the system will restart the target device to load the new firmware. At this time, the device's firmware loader will decompress or decode the new firmware into the running memory and start executing the adapted functional logic. For example, the device will start the sensor data acquisition module and transmit data through the communication interface.

[0095] In some embodiments, the system will also perform functional verification after the burning is completed to ensure that each module of the target device works properly. For example: Verify the accuracy of data through the sensor data acquisition module; Verify the integrity and timeliness of data transmission through the communication protocol module; Verify correct display of device status through the user interface module.

[0096] Generally, after the burning is completed, the system will generate an operation log, recording the detailed process of firmware transfer, burning and function verification. This log can be used for troubleshooting and equipment maintenance.

[0097] Through the above operations, this embodiment can ensure that the firmware file is correctly transmitted and burned to the target device, ensure that the device can normally load and run the adapted functional module, and provide technical support for the actual use of the device.

[0098] In a preferred embodiment of the present invention, the method can dynamically generate different firmware according to different configuration files of the target device model.

[0099] In a preferred embodiment of the present invention, the method can dynamically generate adaptive firmware according to different configuration files of target device models, thereby meeting the functional requirements of various device models. This embodiment realizes automatic cutting, reorganization and compilation of firmware by combining configuration files with modular code libraries.

[0100] Generally speaking, different target devices have different functional requirements, such as the supported sensor types, communication protocols, and hardware interfaces. Therefore, each target device requires a matching firmware to ensure the functionality is achieved.

[0101] Specifically, the method in this embodiment first loads the complete code base, which contains all possible functional modules. For example: Sensor module: including control logic and data processing algorithms of carbon dioxide sensor, carbon monoxide sensor and ozone sensor; Communication module: support Modbus, MQTT, HTTP and other protocols; Hardware interface module: support RS485, Wi-Fi, Bluetooth and other interfaces.

[0102] In one possible implementation, the system obtains the functional requirements of the target device by reading its configuration file. The configuration file defines the model and functions of the target device in a standardized format (such as JSON or XML). For example: Model "MSD-A" requires carbon dioxide and carbon monoxide sensors, as well as support for Modbus protocol and RS485 interface; Model "MSD-B" requires CO2 and Ozone sensors, as well as support for the MQTT protocol and Wi-Fi interface.

[0103] As an option, the system selects the corresponding modules based on the functional requirements in the configuration file. For example: For the "MSD-A" device, the CO2 and CO2 sensor modules, as well as the Modbus protocol and RS485 interface modules are retained; For the "MSD-B" device, the CO2 and Ozone sensor modules are retained, as well as the MQTT protocol and Wi-Fi interface modules.

[0104] After the module screening is completed, the system will trim the functional modules that are not related to the target device. For example, for the "MSD-A" device, the ozone sensor module and other unnecessary protocol logic will be removed, thereby reducing the firmware's storage usage and operating load.

[0105] After the tailoring is completed, the system will reorganize the tailored code modules to form an adaptation project. Generally, the reorganization process will handle the dependencies between modules to ensure that the tailoring operation does not destroy the functional logic of the code. For example, if the CO2 sensor module depends on a shared calibration algorithm, the system will retain the calibration module to support functional integrity.

[0106] In one possible implementation, the system generates compilation options based on the hardware architecture and storage layout of the target device. For example: For low-power devices, enable code compression and optimization options; For high-performance devices, retain debugging information to facilitate subsequent maintenance.

[0107] Finally, the system compiles and links the reorganized code to generate firmware files specific to the target device. For example, the firmware generated for the "MSD-A" device contains the logic for the CO2 and CO sensors, while the firmware generated for the "MSD-B" device contains the logic for the CO2 and Ozone sensors.

[0108] As an extension, this method also supports dynamic expansion of configuration file contents. For example, when a new sensor type or communication protocol is added to the target device, new adapter firmware can be generated by simply updating the configuration file contents without modifying the logic of the entire code base.

[0109] Through the above embodiments, the method can dynamically generate firmware according to different configuration files of the target device model, thereby reducing development and maintenance costs and improving the functional adaptability and deployment efficiency of the device.

[0110] In general, the present invention loads the complete source code, dynamically analyzes and cuts the functional modules that are not related to the device according to the configuration file of the target device, and repairs and reorganizes the dependencies between the modules, generates the adapted streamlined code, compiles it into firmware, and burns it to the target device. This method can dynamically adapt to the functional requirements of multiple device models without the need for additional customized firmware development, significantly reducing development costs and complexity, while improving equipment production efficiency and the flexibility of functional deployment.

[0111] The code writing device adapted to multiple models of air monitors described below and the code writing method adapted to multiple models of air monitors described above can be referenced to each other.

[0112] Please refer to the attached Figure 2 The present invention also provides a code writing device adapted to multiple models of air monitors, including: Storage module 10, used to store complete source code adapted to multiple models of air monitors; The processing module 20 is used to load the complete source code, parse the configuration file, cut the functional modules irrelevant to the target device, and reorganize the cut code; A compiling module 30, used for compiling the reorganized code to generate an adaptation firmware for a target device; The communication module 40 is used to write the generated firmware into the target device.

[0113] The device of this embodiment can be used to execute the above method embodiment, and its principles and technical effects are similar, which will not be repeated here.

[0114] In order to better understand the present invention, the above method is described in detail below in conjunction with specific embodiments.

[0115] Example: Please refer to the attached Figure 3 The embodiment of the present invention provides a code writing method for adapting multiple models of air monitors, which is used to quickly generate and deploy embedded firmware adapted to different target device models. This specific embodiment takes the adaptation of two device models MSD-A and MSD-B as an example to describe its implementation process in detail. The MSD-A device is used to monitor carbon dioxide and carbon monoxide levels, and the MSD-B device is used to monitor carbon dioxide and ozone levels.

[0116] Step 1: Load the full source code In this embodiment, the complete source code containing all functional modules is first loaded. The code library includes the following modules: Sensor module: includes control logic and data calculation functions for three sensors: carbon dioxide, carbon monoxide and ozone.

[0117] Communication protocol module: supports multiple protocols such as Modbus, MQTT, HTTP, etc.

[0118] Hardware interface module: supports RS485, Wi-Fi, Bluetooth and other interfaces.

[0119] The complete source code is divided into different sub-modules according to their functions, organized in folders or module units, and contains a global configuration file that defines the basic relationship between modules.

[0120] Step 2: Analyze the configuration file In this embodiment, the functional requirements are parsed according to the configuration file of the target device. The configuration file defines the model of the target device and the functional modules it needs. For example: MSD-A configuration file definition: contains carbon dioxide and carbon monoxide sensors, and supports RS485 interface and Modbus protocol; The MSD-B profile defines: contains carbon dioxide and ozone sensors, and supports Wi-Fi interface and MQTT protocol.

[0121] During parsing of the configuration file: The system identifies the device model and module variables by traversing the configuration files, and extracts the definitions corresponding to the variables from the global configuration files.

[0122] The system marks the native functions of the C language and the functional modules of the embedded development framework (such as IDF) to ensure that the generated code meets the functional requirements of the device.

[0123] Step 3: Analyze the macro definitions in the code According to the functional requirements defined in the configuration file, the system analyzes and filters the macro definitions in the complete source code. The processing of macro definitions includes: Search the code for macro definitions related to sensors, protocols, and interfaces.

[0124] Determine the validity condition of each macro definition, for example, #ifdef SUPPORT_CO2 means activating the carbon dioxide sensor function.

[0125] Remove invalid macro definitions and their corresponding code blocks, such as deleting ozone sensor logic that is not related to MSD-A.

[0126] Step 4: Organize effective macro definitions and module relationships In this embodiment, after completing the macro definition analysis, the system will sort out the mapping relationship between the configuration file and the code module: According to the definition of modules in the configuration file, the system splits the source code into different functional modules.

[0127] The system further determines the validity of the modules and marks the valid and invalid modules. For example, the valid modules of MSD-A include carbon dioxide and carbon monoxide modules, while MSD-B includes carbon dioxide and ozone modules.

[0128] Step 5: Analyze the coupling and dependencies between modules After trimming the modules, the system will analyze the function call relationships and data sharing dependencies between modules. If a broken dependency is found between modules, the system will take the following measures: Add alternative logic to the pruned code to solve the dependency break problem; Adjust the calling paths between modules to ensure the functional independence of each module.

[0129] Step 6: Split and block invalid code In this embodiment, the system will split the complete source code into multiple small modules and shield irrelevant code according to the module validity. For example: For MSD-A, implementation file for shielded ozone sensor; For MSD-B, block the code for the carbon monoxide sensor.

[0130] Step 7: Reorganize the trimmed code After the module splitting is completed, the system reassembles the valid modules according to the target device requirements and generates a temporary code project. For example: The MSD-A project includes carbon dioxide and carbon monoxide modules; The MSD-B project includes carbon dioxide and ozone modules.

[0131] During the reorganization process, the system ensures that the module call logic is complete and generates a module call relationship diagram.

[0132] Step 8: Compile the reorganized code The system compiles the reorganized code project and generates a firmware file that adapts to the target device. During the compilation process: Set optimization options based on target device hardware configuration (such as storage capacity and processor architecture); Check the syntax, dependency, and logic errors of the code to ensure that the generated firmware file meets the device operation requirements.

[0133] After the compilation is complete, the generated firmware files are adapted to the MSD-A and MSD-B devices respectively.

[0134] Step 9: Firmware Burning and Functional Verification In this embodiment, the system burns the firmware file into the device memory through an interface supported by the target device (such as USB or Bluetooth). After the burning is completed, the device will automatically restart and load the new firmware.

[0135] During device operation, the system performs functional verification to ensure that the device meets the design requirements. For example: The sensor module of the MSD-A device will correctly collect carbon dioxide and carbon monoxide data; The communication module of the MSD-B device will send MQTT protocol data through the Wi-Fi interface.

[0136] Through the above steps, the present invention realizes rapid firmware generation and deployment of multiple models of equipment, reduces development costs and maintenance complexity, and improves equipment production and adaptation efficiency.

[0137] Although embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions and variations may be made to the embodiments without departing from the principles and spirit of the present invention, and that the scope of the present invention is defined by the appended claims and their equivalents.

Claims

1. A code writing method adapted to multiple models of air monitors, characterized in that: The following steps are involved: Load the complete source code for multiple models of air monitors; Analyze the complete source code according to the configuration files of the target device; Cut out functional modules irrelevant to the target device based on configuration files and code logic; Reorganize the trimmed code by analyzing the coupling and dependency relationships between modules; Compile the reorganized code to generate the adapter firmware for the target device; Write the generated firmware to the target device.

2. The code writing method for adapting multiple models of air monitors according to claim 1 is characterized in that: The step of analyzing the complete source code according to the configuration file of the target device includes: Search the variables and module information defined in the configuration file to determine the functional modules required by the target device; Traverse the complete source code file and locate the code snippet corresponding to the variable or module in the configuration file; Analyze the validity conditions of the function modules according to the macro definition statements and conditional compilation statements in the C language; Filter out valid code modules related to the target device functions and record the validity conditions and their dependencies.

3. The code writing method for adapting multiple models of air monitors according to claim 2 is characterized in that: The step of cutting out functional modules irrelevant to the target device according to the configuration file and the code logic includes: Traverse all macro definitions in the complete source code and mark the effective scope of each macro definition; Based on the target device functional requirements in the configuration file, match the macro definitions and related code modules that need to be retained; The macro definitions and their code modules that do not meet the configuration file requirements are shielded or marked as invalid; According to the logical structure of conditional compilation statements, cut out the code fragments that are irrelevant to the target device; Generate a streamlined code version that only retains the target device functions, and record the code module change relationship before and after trimming.

4. The code writing method for adapting multiple models of air monitors according to claim 1 is characterized in that: The step of reorganizing the tailored code by analyzing the coupling and dependency relationship between modules includes: Traverse the pruned code modules and record the function call relationships, variable dependencies, and data transfer paths between modules; Based on the recorded dependencies, find broken dependencies or undefined calls caused by pruning operations; Repair modules with broken dependencies, including adding alternative logic, relinking functions, or introducing necessary shared variables; Merge modules related to the target device functions to ensure the logical structure of the tailored code is complete; Generate a fixed dependency table and record the adjusted module call path.

5. The code writing method for adapting multiple types of air monitors according to claim 4 is characterized in that: The step of reorganizing the cut code by analyzing the coupling and dependency relationship between modules also includes: Determine the module set that needs to be reorganized based on the functional module requirements defined in the target device configuration file; Build a new module calling sequence according to the dependencies between modules and generate a module logic tree; Rearrange the trimmed valid code modules in the order of the logic tree to build a new code project structure; Identify scenarios where cross-module calls or variable sharing are required, and establish a global sharing mechanism; Save the reorganized code project to ensure that it is functionally consistent with the target device.

6. The code writing method for adapting multiple types of air monitors according to claim 1 is characterized in that: The step of compiling the reorganized code to generate the adaptation firmware of the target device includes: Load the reorganized code project and parse the module definition, variable declaration and macro configuration in the code; Generate a list of compilation options based on the functional requirements of the target device, including the target architecture, optimization level, and hardware resource restrictions; Call the standardized compilation tool chain to compile code modules one by one, parse and optimize function calls and data access paths in the code; Check for syntax errors, undefined variables, or unresolved dependencies that may occur during compilation, and output detailed debugging information if errors occur; After successful compilation, link all modules to generate firmware files, and record the compilation log and version information of the generated files; Perform integrity check on the generated firmware file to ensure that it is compatible with the hardware and functional requirements of the target device.

7. The code writing method for adapting multiple types of air monitors according to claim 1 is characterized in that: The step of writing the generated firmware into the target device comprises: Write the generated firmware file to the target device memory via Bluetooth or USB interface, and verify the device function after the firmware is written.

8. The code writing method for adapting multiple types of air monitors according to claim 1 is characterized in that: The complete source code is a general code base that supports multiple air monitor models, including but not limited to air monitors that monitor carbon dioxide, carbon monoxide, or ozone.

9. The code writing method for adapting multiple types of air monitors according to claim 1 is characterized in that: The method can dynamically generate different firmware according to different configuration files of the target device model.

10. A code writing device adapted to multiple types of air monitors, applied to the method according to any one of claims 1 to 9, characterized in that: include: Storage module, used to store complete source code for multiple models of air monitors; The processing module is used to load the complete source code, parse the configuration file, cut the functional modules that are not related to the target device, and reorganize the cut code; A compiling module, used for compiling the reorganized code to generate the adapter firmware of the target device; Communication module, used to write the generated firmware to the target device.

Images