Code writing method for compatibility with multiple air quality monitor models

Abstract

This application relates to the field of embedded systems and discloses a method for writing code to adapt to multiple models of air quality monitors, addressing issues such as high development and maintenance costs and complex firmware versions in existing technologies. The method includes the following steps: loading the complete source code; parsing functional requirements based on the target device's configuration file; trimming functional modules irrelevant to the target device; performing dependency analysis and logic repair on the trimmed code; recombining the trimmed code to generate a streamlined code project adapted to the target device; and compiling to generate a firmware file, which is then burned to the target device. This invention can dynamically generate firmware according to different target device models, achieving flexible adaptation to multiple device models, reducing development costs, optimizing code size, and improving device function deployment efficiency. It is suitable for the rapid production and maintenance of multiple models and small batches of air quality monitors.

Description

Technical Field

[0001] This invention relates to the field of embedded system technology, specifically to a code writing method adapted to multiple models of air quality monitors. Background Technology

[0002] Air quality monitors, as crucial equipment in environmental monitoring, are widely used in industrial, agricultural, and civilian sectors to monitor the concentration of pollutants in the air in real time. However, with the increasing complexity of application scenarios, different users have significantly different needs regarding monitoring content, communication protocols, and hardware interfaces. Currently, air quality monitors on the market are typically designed with different models to meet different functional requirements. While this approach can satisfy diverse needs, it also presents numerous problems in development, production, and maintenance.

[0003] In existing technologies, to support different communication protocols or hardware interfaces, firmware typically needs to be designed and developed separately for each device model. This development approach not only increases repetitive workload but also significantly raises development costs. Furthermore, because each model's firmware has specific functional configurations, its code is not universal, leading to complexity in code management and wasted resources. Simultaneously, the hardware platforms of different device models usually require separate design and maintenance, further increasing the difficulty of production and maintenance.

[0004] In the production process, to meet market demand for various equipment models, existing technologies require the manufacture and stockpiling of hardware for multiple models, which increases inventory pressure and the difficulty of production line management. Furthermore, after-sales service requires specific technical support for each equipment model, further increasing after-sales costs and service complexity.

[0005] In summary, existing technologies for the development, production, and maintenance of various air monitoring instruments generally suffer from problems such as low development efficiency, high costs, low code reusability, and complex production and maintenance. These problems are particularly prominent in an environment of diversified demands and intense market competition, urgently requiring a solution that can reduce development costs, improve production efficiency, and enhance equipment flexibility. Summary of the Invention

[0006] To address the shortcomings of existing technologies, this invention provides a code writing method adapted to multiple models of air quality monitors. Through modular code trimming and recombination, it achieves flexible adaptation to multiple models of air quality monitors, reduces development costs and maintenance complexity, and improves equipment production efficiency.

[0007] To achieve the above objectives, the present invention provides the following technical solution: a code writing method for adapting to multiple models of air quality monitors, comprising the following steps:

[0008] Load the complete source code that is compatible with multiple models of air quality monitors;

[0009] Analyze the complete source code based on the target device's configuration file;

[0010] Remove functional modules that are irrelevant to the target device based on the configuration file and code logic;

[0011] By analyzing the coupling and dependencies between modules, the trimmed code is reorganized;

[0012] The compiled and reorganized code generates the firmware adapted for the target device.

[0013] Write the generated firmware to the target device.

[0014] Preferably, the step of analyzing the complete source code based on the target device's configuration file includes:

[0015] Search the variables and module information defined in the configuration file to determine the functional modules required by the target device;

[0016] Traverse the complete source code file and locate the code snippet that corresponds to the variable or module in the configuration file;

[0017] Analyze the conditions under which a functional module takes effect based on macro definition statements and conditional compilation statements in the C language;

[0018] Filter out the valid code modules related to the target device's functions, and record the conditions for their effectiveness and their dependencies.

[0019] Preferably, the step of trimming functional modules unrelated to the target device based on configuration files and code logic includes:

[0020] Iterate through all macro definitions in the complete source code and mark the scope of each macro definition.

[0021] Based on the target device functional requirements in the configuration file, match the macro definitions and related code modules that need to be retained;

[0022] Macro definitions and their code modules that do not meet the configuration file requirements are disabled or marked as invalid;

[0023] Based on the logical structure of the conditional compilation statements, cut out code segments that are irrelevant to the target device;

[0024] Generate a streamlined code version that retains only the functionality of the target device, and record the changes in code modules before and after the trimming.

[0025] Preferably, the step of reorganizing the trimmed code by analyzing the coupling and dependencies between modules includes:

[0026] Traverse the trimmed code modules and record the function call relationships, variable dependencies, and data transfer paths between each module;

[0027] Based on the recorded dependencies, find broken dependencies or undefined calls caused by pruning operations;

[0028] Repair modules with broken dependencies, including adding alternative logic, relinking functions, or introducing necessary shared variables;

[0029] Merge modules related to the target device's functions to ensure the integrity of the cut-down code logic structure;

[0030] Generate the fixed dependency table and record the adjusted module call paths.

[0031] Preferably, the step of reorganizing the trimmed code by analyzing the coupling and dependencies between modules further includes:

[0032] Based on the functional module requirements defined in the target device configuration file, determine the set of modules that need to be reorganized;

[0033] A new module call order is constructed based on the dependencies between modules, and a module logic tree is generated;

[0034] The trimmed, valid code modules are rearranged according to the logical tree order to build a new code project structure;

[0035] Identify scenarios involving cross-module calls or variable sharing, and establish a global sharing mechanism;

[0036] Save the reorganized code project to ensure it is functionally consistent with the target device.

[0037] Preferably, the step of generating the adapted firmware for the target device from the compiled and recombined code includes:

[0038] Load the reorganized code project and parse the module definitions, variable declarations, and macro configurations in the code.

[0039] Based on the functional requirements of the target device, generate a list of compilation options, including the target architecture, optimization level, and hardware resource limitations;

[0040] The standardized compilation toolchain is invoked to compile the code modules one by one, and to parse and optimize the function calls and data access paths in the code.

[0041] Check for syntax errors, undefined variables, or unresolved dependencies that may occur during the compilation process, and output detailed debugging information if errors are found;

[0042] After successful compilation, all modules are linked to generate firmware files, and compilation logs and version information of generated files are recorded.

[0043] Perform integrity verification on the generated firmware file to ensure that it is compatible with the hardware and functional requirements of the target device.

[0044] Preferably, the step of writing the generated firmware to the target device includes:

[0045] The generated firmware file is written to the target device's memory via Bluetooth or USB interface, and the device's functionality is verified after the firmware is written.

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

[0047] Preferably, the method can dynamically generate different firmware based on different configuration files of the target device model.

[0048] This invention also provides a code writing device adapted to multiple models of air quality monitors, including:

[0049] The storage module is used to store the complete source code that is compatible with multiple models of air quality monitors;

[0050] The processing module is used to load the complete source code, parse the configuration file, trim functional modules that are not related to the target device, and reorganize the trimmed code.

[0051] The compilation module is used to compile and reorganize the code to generate the adaptation firmware for the target device.

[0052] The communication module is used to write the generated firmware to the target device.

[0053] This invention provides a code writing method compatible with multiple models of air quality monitors. It offers the following advantages:

[0054] 1. This invention achieves adaptability to multiple target device models through dynamic trimming and modular reconfiguration based on configuration files. The functional requirements of different devices do not need to be redeveloped; only the corresponding configuration file needs to be provided to quickly generate compatible firmware, significantly improving development and production efficiency.

[0055] 2. This invention employs modular design and code reuse technology, avoiding the high costs of developing separate firmware for each device model. By trimming device-independent code, redundant development work is reduced, while the code maintenance and upgrade process is simplified.

[0056] 3. By trimming and optimizing the complete source code, this invention significantly reduces the firmware code size. The streamlined code reduces the device's demand for storage and processor resources, thereby enabling the use of a more economical hardware platform and further reducing device costs.

[0057] 4. This invention supports dynamic firmware generation, enabling rapid generation and deployment of firmware files based on device model requirements, thus shortening device delivery time. It is particularly suitable for multi-model, small-batch device production scenarios, effectively improving product market competitiveness.

[0058] 5. During the module trimming process, this invention ensures the integrity and correctness of the trimmed code through dependency analysis and logic repair techniques. The recombined code runs normally, avoiding functional deficiencies or anomalies caused by dependency breaks.

[0059] 6. Through a unified code framework and modular design, this invention reduces the number of firmware versions and the complexity of management. Only one complete codebase needs to be maintained during production; configuration files can be tailored to meet the functional requirements of different devices, significantly simplifying version management.

[0060] 7. This invention supports rapid adaptation to new features or new device models by updating configuration files, without requiring modification of the complete source code. This high scalability enables devices to quickly respond to market demands, enhancing product flexibility and lifecycle value.

[0061] 8. This invention simplifies the equipment manufacturing process and reduces the types of spare parts and inventory pressure by using a unified hardware platform and a dynamic firmware configuration method. During after-sales service, equipment functionality can be quickly repaired or expanded by updating configuration files, improving service efficiency and user satisfaction. Attached Figure Description

[0062] Figure 1 This is a schematic diagram of the method flow of the present invention;

[0063] Figure 2 This is a schematic diagram of the device structure of the present invention;

[0064] Figure 3 This is a schematic diagram of the method flow according to an embodiment of the present invention.

[0065] Among them, 10 is the storage module; 20 is the processing module; 30 is the compilation module; and 40 is the communication module. Detailed Implementation

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

[0067] Please see the appendix Figure 1This invention provides a code writing method adapted to multiple models of air quality monitors. It aims to achieve efficient adaptation to various air quality monitor models through intelligent cutting and recombining of general-purpose code, reducing development and maintenance costs and improving production efficiency. The method of this invention includes the following specific steps:

[0068] S1. Load the complete source code that is compatible with multiple models of air quality monitors;

[0069] S2. Analyze the complete source code based on the target device's configuration file;

[0070] S3. Based on the configuration file and code logic, remove functional modules that are irrelevant to the target device;

[0071] S4. By analyzing the coupling and dependencies between modules, the trimmed code is reorganized;

[0072] S5. Compile and reorganize the code to generate the firmware adapted for the target device.

[0073] S6. Write the generated firmware to the target device.

[0074] In this embodiment, step S1 is the process of loading the complete source code of multiple air monitoring instruments. The complete source code is the core foundation of this invention and includes all supported sensor modules, communication protocols and hardware interface implementation logic.

[0075] Generally, complete source code consists of multiple functional modules, each developed independently and organized according to specific rules, for example:

[0076] The core logic module includes data acquisition, processing algorithms, and sensor control;

[0077] The communication module supports protocols such as Modbus, MQTT, and HTTP.

[0078] Hardware interface module, compatible with interfaces such as RS485, Wi-Fi, and Bluetooth.

[0079] Specifically, in this embodiment, the process of loading the complete source code includes the following:

[0080] First, the general codebase is organized in a file directory format, with all functional modules categorized by type. For example, sensor-related code is located in one folder, which includes the specific implementation code for carbon dioxide sensors, carbon monoxide sensors, and ozone sensors. Communication protocol implementation code is located in another folder, containing functions for parsing, transmitting, and encrypting various protocols.

[0081] In one possible implementation, when the system loads the complete codebase, it scans the directory structure to obtain the file paths and file type information of each module. This process helps with subsequent module selection and trimming. Alternatively, loading can be achieved by recursively traversing the directory, ensuring that all module files are loaded into memory.

[0082] Typically, complete source code contains several necessary configuration files that define common parameters for code modules. For example:

[0083] The types of sensors supported by the device;

[0084] The default communication protocol;

[0085] Default hardware interface configuration.

[0086] As one implementation approach, these configuration files are parsed first during the loading process to determine the scope of functionality within the complete code. After loading is complete, the system temporarily stores this information in memory for later use in subsequent steps.

[0087] In some embodiments, the complete code also includes test modules for simulating functional implementation under different device environments. For example, the data acquisition function of a carbon dioxide sensor can be tested via a virtual device interface, or the compatibility of communication protocols can be tested via a simulated network. These test modules are marked as "non-essential modules" during loading and are typically not included in subsequent trimming and reorganization processes.

[0088] Specifically, after loading is complete, the system will generate a module list, listing all loaded modules and their functional scope. For example:

[0089] Module name: e.g., "CO2_Sensor";

[0090] Module type: such as "sensor module";

[0091] Module status: such as "can be trimmed" or "necessary module".

[0092] Alternatively, the loading process may include code version verification, such as by verifying the version number of the complete source code and the information recorded in the feature description file, to ensure consistency between the code and the device configuration. This step can effectively avoid trimming and reorganization errors caused by code mismatches.

[0093] In another possible implementation, loading the complete source code can also support dynamic expansion. For example, new sensor modules or protocol modules can be loaded on top of the existing codebase to accommodate the expanded functionalities of the device. In this case, the system will automatically update the module list to ensure that the newly loaded modules can participate in subsequent steps.

[0094] Finally, after loading is complete, the system will generate a loading log, recording the number of modules loaded, file paths, and loading status. This log can be used for follow-up during subsequent trimming and debugging processes.

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

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

[0097] Typically, configuration files use a structured format, such as JSON or XML, to define the target device's model information, supported sensor types, communication protocols, and hardware interface requirements. The configuration file clearly defines the target device's functional scope, facilitating module selection and customization within the system. For example, a configuration file might contain the following:

[0098] Device model: Specify the target device, such as "MSD-A";

[0099] Functional Modules: List the functional modules supported by the target device, such as "Carbon Dioxide Sensor" and "Carbon Monoxide Sensor";

[0100] Communication protocol: Defines the communication methods supported by the device, such as "Modbus" and "MQTT";

[0101] Hardware interface: Describes the device's communication interface, such as "RS485" and "Wi-Fi".

[0102] In one possible implementation, the system first parses the top-level structure of the configuration file to extract the device model and its functional definitions. Next, based on the sensor type and protocol requirements defined in the configuration file, the system matches relevant modules in the complete source code. For example, if the configuration file specifies that the target device requires a carbon dioxide sensor, the system will identify all code snippets related to the carbon dioxide sensor from the complete source code, including data acquisition, calibration algorithms, and data transmission logic.

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

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

[0105] In some embodiments, the configuration file not only contains the functional definitions of the target device, but may also include additional hardware constraints, such as processor performance limitations or storage capacity limits. When parsing the configuration file, the system further optimizes module selection by incorporating these constraints. For example, for devices with limited storage capacity, the system prioritizes lightweight communication protocol modules.

[0106] Typically, 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 combines 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 segment related to #define SUPPORT_CO2, while simultaneously disabling code for undefined modules.

[0107] Alternatively, the system may generate a module dependency table during the analysis process, recording the dependencies between the target module and other modules. For example, if the carbon dioxide sensor module depends on a shared calibration algorithm, the system will mark this dependency in the dependency table. This helps avoid removing necessary dependent modules during subsequent pruning.

[0108] In some embodiments, parsing 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 a non-existent module is found to be referenced in the configuration file, the system will output a warning message so that developers can correct it in a timely manner.

[0109] Finally, after the configuration file is parsed, the system generates a module selection list, recording all the functional modules required by the target device and their dependencies. This list will serve as direct input for subsequent steps of trimming and reorganization, ensuring the integrity and functionality of the trimmed code.

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

[0111] In this embodiment, the purpose of step S3 is to trim functional modules that are 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.

[0112] Typically, complete source code contains various device functional modules and common logic. Some of these modules may be irrelevant to the functional requirements of the target device, thus requiring the removal of these irrelevant modules through a trimming process. The trimming process must ensure code integrity and functional consistency, avoiding functional loss or code structure disruption due to module removal.

[0113] Specifically, the trimming operation is based on a module selection list, which is generated in step S2 through configuration file parsing and records the module information that the target device needs to retain and remove. In one possible implementation, the system first marks each functional module in the complete source code, including "necessary modules," "non-necessary modules," and "dependent modules." Wherein:

[0114] Essential modules are the core functions of the target device, such as sensor driver code;

[0115] Unnecessary modules are code snippets that are irrelevant to the target device, such as unused communication protocols;

[0116] Dependent modules are modules that have logical or data coupling relationships with necessary modules, such as calibration algorithms for sensor data.

[0117] Alternatively, the pruning operation begins 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 a carbon dioxide sensor, the system will directly remove the code files related to the carbon monoxide and ozone sensors.

[0118] In some embodiments, the system performs pruning not only at the file level but also at the code level. For example, in the complete source code, conditional compilation statements (such as #ifdef and #define) may be used to selectively activate functional modules. By parsing these conditional compilation statements and combining them with configuration file information, the system determines which code segments need to be retained and which need to be disabled. Specifically, when a certain sensor type is defined in the configuration file, the system will activate the corresponding macro definition, such as #define SUPPORT_CO2, and remove other inactive macro definition code segments.

[0119] As an implementation method, the pruning process also needs to handle dependencies between code modules. For example, when a module depends on another module marked as "non-essential," 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" to ensure the functional integrity of the code.

[0120] In another possible implementation, the pruning process involves a detailed analysis of the functions and variables within a module. For example, if a module only uses some functions or variables, while other parts are not called by the target device, the system will prune the unused parts, further optimizing the code size. The pruned modules will then be reorganized to fit the functional requirements of the target device.

[0121] Generally, after the pruning process is complete, the system will record the removed code, generating a pruning log. The pruning log includes the name, type, and reason for each removed module. This log can be used for debugging and tracing in subsequent steps.

[0122] Alternatively, the system will also perform preliminary verification of the trimmed code, such as checking the logical integrity and data consistency. If logical errors or broken dependencies are found, the system will log detailed information and prompt the user to fix them.

[0123] Through the above-described trimming operations, this embodiment can effectively remove code modules that are irrelevant to the target device, reduce code complexity and storage usage, and provide an efficient and optimized code foundation for subsequent code reorganization and compilation.

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

[0125] Generally, after code trimming, function calls, variable dependencies, or logical connections between existing modules may be disrupted due to module removal. Therefore, this step reorganizes the trimmed code logic through static analysis and dependency fixing to resolve potential dependency issues.

[0126] Specifically, before performing code refactoring, the system performs dependency analysis on the trimmed code modules. This analysis includes the following aspects:

[0127] Function call dependencies: Check if the retained modules after pruning still call functions of the removed modules. If a call break is found, the system will repair the call path by replacing the logic or adding an adaptation layer.

[0128] Shared dependency: Identify access to global variables in retained modules and ensure that related variables remain available after pruning. For example, if a module depends on a shared sensor data variable, and that variable is defined in a removed module, the system needs to redefine or migrate that variable.

[0129] Logical control dependencies: Analyze the logical paths of the trimmed modules 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 logical control paths to avoid triggering the functions of the missing modules.

[0130] In one possible implementation, the system constructs a dependency graph based on the call relationships between modules. Each node in the graph represents a code module, and edges represent 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 will replace the original function with a simplified version of the initialization logic.

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

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

[0133] As one implementation approach, after code refactoring, the system generates a new code project structure that is reorganized based on the functional requirements of the target device. For example, the modules retained after trimming are grouped according to their functional type, such as "sensor module," "communication module," and "data processing module." This reorganized structure facilitates subsequent compilation and debugging.

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

[0135] Typically, after code refactoring is complete, the system generates a dependency fix report and a module relationship diagram. This report details all dependency fixes, as well as the calls and data flow paths between modules. This information can be used for subsequent debugging and functional verification.

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

[0137] In this embodiment, the purpose of step S5 is to compile the recombined code to generate the compatible firmware for the target device. This step converts the recombined code module into a binary firmware file that can be directly run on the target device hardware, providing a foundation for subsequent device flashing and function implementation.

[0138] Generally, the recompiled code needs to undergo multiple compilation steps, 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 configure the compilation settings according to the target device's hardware configuration and functional requirements.

[0139] Specifically, the system first loads the reorganized code project and extracts hardware-related parameters based on the target device's configuration file. These parameters include, but are not limited to:

[0140] The processor architecture of the target device, such as ARM Cortex-M or RISC-V;

[0141] Memory size and partition layout, such as the capacity and starting address of flash memory and RAM;

[0142] The type of external hardware interface, such as I2C, SPI, or UART.

[0143] In one possible implementation, the system generates a list of compilation options based on the aforementioned hardware parameters. This list includes the compiler's target architecture settings, memory optimization levels, and options for preserving debug information. For example, for low-power devices, the system might enable a higher code compression level; while for high-performance devices, it might prioritize preserving more debug information for functional verification.

[0144] Alternatively, the compilation process can be divided into multiple stages, including code preprocessing, syntax parsing, target code generation, and linking. During the preprocessing stage, the system parses all macro definitions and conditional compilation statements, ensuring that only code modules relevant to the target device are compiled. For example, for devices supporting carbon dioxide sensors, the preprocessing stage activates the code related to that function while masking the implementation logic of other sensors.

[0145] In some embodiments, the system also performs static optimizations on the recombined code, such as merging redundant function calls or removing unused variable definitions. This optimization can further reduce firmware size while improving operational efficiency. For example, if a module contains unused debug functions, the system will remove them during compilation.

[0146] During the target code generation phase, the system converts the high-level language logic in the reconstructed code into machine code adapted to the target device's processor instruction set. For example, for ARM architecture devices, the system generates target code in ARM Thumb instruction set format; while for RISC-V architecture devices, it generates the corresponding instruction set.

[0147] In one possible implementation, after compilation, the system enters the linking phase, linking all object code modules into a complete firmware file. During linking, the system resolves all function calls and global variable references, ensuring their addresses are correctly resolved. If undefined symbols or duplicate definitions are found, the system outputs detailed error messages for developers to fix.

[0148] 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 being located at the beginning of the firmware, while the data segment is located within a fixed address range. In this case, the system will adjust the segmented layout of the firmware file according to the device requirements and generate the corresponding load table.

[0149] Alternatively, the system may also perform 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 firmware loading after the device has been flashed.

[0150] In some embodiments, the system generates a compilation report after compilation and linking are complete. This report contains the following:

[0151] A list of compiled modules;

[0152] Firmware size and segmented layout;

[0153] Warnings or optimization messages that occur during the compilation process.

[0154] 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 operating efficiency and resource consumption to the maximum extent, providing a reliable guarantee for the realization of device functions.

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

[0156] Typically, firmware files need to be transferred to the device's memory via an interface supported by the device. The target device may support multiple interface types, such as USB, UART, Wi-Fi, or Bluetooth, and different interfaces require corresponding transmission protocols and tools for data exchange.

[0157] Specifically, in one possible implementation, the system first detects the target device's interface type and establishes a communication connection. For example, if the target device supports a USB interface, the system will establish communication with the device through standard USB transmission protocols (such as DFU mode); while for devices that support Bluetooth, the system will perform data transmission through the Bluetooth protocol stack (such as BLE GATT). After the connection is established, the system verifies the device's communication status to ensure that the interface is functioning correctly.

[0158] As an alternative, firmware files may need to be encrypted before transmission to prevent unauthorized copying or tampering. For example, the system can use symmetric encryption or sign the firmware file, and restore its integrity by decrypting or verifying the signature upon receipt by the target device. This security measure is particularly suitable for industrial equipment requiring a high degree of confidentiality.

[0159] In some embodiments, firmware transmission is also performed in chunks and with verification. For example, the system divides the firmware file into multiple data blocks, transmits one block at a time, and calculates a checksum after the target device receives the data to ensure the integrity of each data block. If the verification of a data block fails, the system will retransmit that data block.

[0160] Normally, after the firmware file is successfully transferred to the target device, the system will initiate the flashing process. The flashing process writes the firmware file from the temporary storage area to the target device's permanent storage, such as Flash memory. In one possible implementation, the system writes different parts of the firmware file to designated addresses according to the device's memory partition layout. For example:

[0161] The startup code is written to the starting address of memory;

[0162] The data segment is written to a fixed offset address;

[0163] Configuration parameters are written to a specific area of ​​memory.

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

[0165] Alternatively, after flashing, the target device may need to perform a self-test to verify the firmware's functionality. For example, the device may load boot code and initialize hardware modules; if any anomalies are detected, the system will log error messages and prompt the user to fix them.

[0166] In another possible implementation, after the flashing process is complete, the system will reboot 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 begin executing the adapted functional logic. For example, the device will start the sensor data acquisition module and transmit data through the communication interface.

[0167] In some embodiments, the system also performs functional verification after the programming is complete to ensure that all modules of the target device are functioning properly. For example:

[0168] Verify the accuracy of the data using the sensor data acquisition module;

[0169] The integrity and timeliness of data transmission are verified through the communication protocol module;

[0170] Verify the correct display of device status through the user interface module.

[0171] Normally, after the firmware flashing process is complete, the system will generate an operation log, recording the detailed process of firmware transfer, flashing, and functional verification. This log can be used for troubleshooting and equipment maintenance.

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

[0173] 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.

[0174] In a preferred embodiment of the present invention, the method can dynamically generate adapted firmware based on different configuration files of the target device model, thereby meeting the functional requirements of various device models. This embodiment achieves automated firmware trimming, reorganization, and compilation through the combination of configuration files and modular code libraries.

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

[0176] Specifically, the method in this embodiment first loads the complete codebase, which contains all possible functional modules. For example:

[0177] Sensor module: includes control logic and data processing algorithms for carbon dioxide sensor, carbon monoxide sensor, and ozone sensor;

[0178] Communication module: Supports protocols such as Modbus, MQTT, and HTTP;

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

[0180] In one possible implementation, the system obtains the functional requirements of the target device by reading its configuration file. The configuration file defines the target device's model and functions in a standardized format (such as JSON or XML). For example:

[0181] Model "MSD-A" requires carbon dioxide and carbon monoxide sensors, as well as support for Modbus protocol and RS485 interface;

[0182] Model “MSD-B” requires carbon dioxide and ozone sensors, as well as support for the MQTT protocol and a Wi-Fi interface.

[0183] Alternatively, the system can filter for corresponding modules based on the functional requirements in the configuration file. For example:

[0184] For “MSD-A” devices, the carbon dioxide and carbon monoxide sensor modules, as well as the Modbus protocol and RS485 interface modules, are retained;

[0185] For “MSD-B” devices, the carbon dioxide and ozone sensor modules, as well as the MQTT protocol and Wi-Fi interface modules, are retained.

[0186] After the module selection is complete, the system will remove functional modules that are irrelevant 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 firmware storage footprint and operational load.

[0187] After trimming, the system will reorganize the trimmed code modules into a single, compatible project. Generally, the reorganization process handles dependencies between modules to ensure that the trimming operation does not disrupt the code's functional logic. For example, if the carbon dioxide sensor module depends on a shared calibration algorithm, the system will retain that calibration module to maintain functional integrity.

[0188] In one possible implementation, the system generates compilation options based on the target device's hardware architecture and storage layout. For example:

[0189] For low-power devices, enable code compression and optimization options;

[0190] For high-performance equipment, retain debugging information to facilitate subsequent maintenance.

[0191] Finally, the system compiles and links the recombined 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 carbon dioxide and carbon monoxide sensors, while the firmware generated for the "MSD-B" device contains the logic for the carbon dioxide and ozone sensors.

[0192] As an extension, this method also supports dynamically expanding the configuration file content. For example, when the target device adds a new sensor type or communication protocol, only the configuration file content needs to be updated; no modification to the logic of the complete codebase is required to generate new compatible firmware.

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

[0194] In summary, this invention loads the complete source code, dynamically analyzes and trims device-independent functional modules based on the target device's configuration file, repairs and reorganizes dependencies between modules, generates adapted, simplified code, compiles it into firmware, and flashes it to the target device. This method can dynamically adapt to the functional requirements of various device models without requiring additional custom firmware development, significantly reducing development costs and complexity, while improving device production efficiency and the flexibility of functional deployment.

[0195] The code writing device for adapting to multiple models of air quality monitors described below and the code writing method for adapting to multiple models of air quality monitors described above can be referred to in correspondence.

[0196] Please see the appendix Figure 2 The present invention also provides a code writing device adapted to multiple models of air monitoring instruments, including:

[0197] Storage module 10 is used to store the complete source code that is compatible with multiple models of air monitors;

[0198] Processing module 20 is used to load the complete source code, parse the configuration file, trim functional modules that are not related to the target device, and reorganize the trimmed code;

[0199] Compilation module 30 is used to compile and reorganize the code to generate the adaptation firmware for the target device;

[0200] The communication module 40 is used to write the generated firmware to the target device.

[0201] The device in this embodiment can be used to execute the above method embodiments, and its principle and technical effects are similar, so they will not be described again here.

[0202] To better understand the present invention, the above method will be described in detail below with reference to specific embodiments.

[0203] Example:

[0204] Please see the appendix Figure 3 This invention provides a code writing method for adapting to multiple models of air quality monitors, enabling rapid generation and deployment of embedded firmware adapted to different target device models. This specific embodiment uses the adaptation of two device models, MSD-A and MSD-B, as examples to detail the implementation process. The MSD-A device is used to monitor carbon dioxide and carbon monoxide levels, while the MSD-B device is used to monitor carbon dioxide and ozone levels.

[0205] Step 1: Load the complete source code

[0206] In this embodiment, the complete source code containing all functional modules is loaded first. This codebase includes the following modules:

[0207] Sensor module: Includes control logic and data calculation functions for three sensors: carbon dioxide, carbon monoxide, and ozone.

[0208] Communication protocol module: Supports multiple protocols such as Modbus, MQTT, and HTTP.

[0209] Hardware interface module: Supports RS485, Wi-Fi and Bluetooth interfaces.

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

[0211] Step 2: Analyze the configuration file

[0212] In this embodiment, the functional requirements are parsed based on the target device's configuration file. The configuration file defines the target device's model and its required functional modules. For example:

[0213] The MSD-A configuration file defines: it includes carbon dioxide and carbon monoxide sensors and supports RS485 interface and Modbus protocol;

[0214] The MSD-B configuration file defines that it includes carbon dioxide and ozone sensors and supports Wi-Fi interfaces and the MQTT protocol.

[0215] During the configuration file parsing process:

[0216] The system identifies device models and module variables by traversing configuration files and extracts the corresponding definitions from the global configuration file.

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

[0218] Step 3: Analyze macro definitions in the code

[0219] Based on the functional requirements defined in the configuration file, the system analyzes and filters the macro definitions in the complete source code. Macro definition processing includes:

[0220] Search the code for macro definitions related to sensors, protocols, and interfaces.

[0221] Determine the conditions under which each macro definition takes effect. For example, #ifdef SUPPORT_CO2 indicates that the carbon dioxide sensor function is activated.

[0222] Remove invalid macro definitions and their corresponding code blocks, such as deleting ozone sensor logic unrelated to MSD-A.

[0223] Step 4: Organize valid macro definitions and module relationships

[0224] In this embodiment, after completing the macro definition analysis, the system will organize the mapping relationship between configuration files and code modules:

[0225] Based on the module definitions in the configuration file, the system breaks down the source code into different functional modules.

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

[0227] Step 5: Analyze the coupling and dependencies between modules

[0228] After trimming modules, the system analyzes the function call relationships and data sharing dependencies between modules. If broken dependencies are found between modules, the system will take the following measures:

[0229] Add alternative logic to the trimmed code to resolve dependency breakage issues;

[0230] Adjust the call paths between modules to ensure the functional independence of each module.

[0231] Step 6: Split and mask invalid code

[0232] In this embodiment, the system breaks down the complete source code into multiple small modules and masks irrelevant code based on the module's validity. For example:

[0233] For MSD-A, shield the implementation file of the ozone sensor;

[0234] For MSD-B, the code that masks the carbon monoxide sensor.

[0235] Step 7: Reorganize the trimmed code

[0236] After the modules are split, the system reassembles the effective modules according to the requirements of the target device, generating a temporary code project. For example:

[0237] The MSD-A project includes carbon dioxide and carbon monoxide modules;

[0238] The MSD-B project includes carbon dioxide and ozone modules.

[0239] During the reorganization process, the system ensures the integrity of the module call logic and generates a module call relationship diagram.

[0240] Step 8: Compile the recombined code

[0241] The system compiles the reorganized code project to generate firmware files adapted to the target device. During the compilation process:

[0242] Set optimization options based on the target device's hardware configuration (such as storage capacity and processor architecture);

[0243] Check the code for syntax, dependency, and logic errors to ensure that the generated firmware file meets the device's operating requirements.

[0244] After compilation, the generated firmware files are adapted for MSD-A and MSD-B devices respectively.

[0245] Step 9: Firmware flashing and function verification

[0246] In this embodiment, the system burns the firmware file to the device's memory via an interface supported by the target device (such as USB or Bluetooth). After burning is complete, the device will automatically restart and load the new firmware.

[0247] During equipment operation, the system performs functional verification to ensure that the equipment meets design requirements. For example:

[0248] The sensor module of the MSD-A device will correctly collect carbon dioxide and carbon monoxide data;

[0249] The communication module of the MSD-B device sends MQTT protocol data through the Wi-Fi interface.

[0250] Through the above steps, this invention enables rapid firmware generation and deployment for multiple device models, reducing development costs and maintenance complexity, and improving device production and adaptation efficiency.

[0251] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A code writing method adapted to multiple models of air quality monitors, characterized in that, Includes the following steps: Load the complete source code that is compatible with multiple models of air quality monitors; Analyzing the complete source code based on the target device's configuration file, the steps of which include: 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 that corresponds to the variable or module in the configuration file; Analyze the conditions under which a functional module takes effect based on macro definition statements and conditional compilation statements in the C language; Filter out valid code modules related to the target device's functions, and record the conditions for their effectiveness and their dependencies; Remove functional modules that are irrelevant to the target device based on the configuration file and code logic; By analyzing the coupling and dependencies between modules, the trimmed code is reorganized. The steps of reorganizing the trimmed code by analyzing the coupling and dependencies between modules include: Traverse the trimmed code modules and record the function call relationships, variable dependencies, and data transfer paths between each module; 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's functions to ensure the integrity of the cut-down code logic structure; Generate a fixed dependency table and record the adjusted module call paths; The compiled and reorganized code generates the firmware adapted for the target device. Write the generated firmware to the target device; The step of removing functional modules that are irrelevant to the target device based on configuration files and code logic includes: Iterate through all macro definitions in the complete source code and mark the 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; Macro definitions and their code modules that do not meet the configuration file requirements are disabled or marked as invalid; Based on the logical structure of the conditional compilation statements, cut out code segments that are irrelevant to the target device; Generate a streamlined code version that retains only the functionality of the target device, and record the changes in code modules before and after the trimming; The step of reorganizing the trimmed code by analyzing the coupling and dependencies between modules also includes: Based on the functional module requirements defined in the target device configuration file, determine the set of modules that need to be reorganized; A new module call order is constructed based on the dependencies between modules, and a module logic tree is generated; The trimmed, valid code modules are rearranged according to the logical tree order to build a new code project structure; Identify scenarios involving cross-module calls or variable sharing, and establish a global sharing mechanism; Save the reorganized code project and ensure that it is consistent with the functionality of the target device; The steps for generating the adapted firmware for the target device from the compiled and reconstructed code include: Load the reorganized code project and parse the module definitions, variable declarations, and macro configurations in the code. Based on the functional requirements of the target device, generate a list of compilation options, including the target architecture, optimization level, and hardware resource limitations; The standardized compilation toolchain is invoked to compile the code modules one by one, and to parse and optimize the function calls and data access paths in the code. Check for syntax errors, undefined variables, or unresolved dependencies during the compilation process, and output detailed debugging information if errors are found. After successful compilation, all modules are linked to generate firmware files, and compilation logs and version information of generated files are recorded. Perform integrity verification on the generated firmware file to ensure that it is compatible with the hardware and functional requirements of the target device.

2. The code writing method for adapting to multiple models of air quality monitors according to claim 1, characterized in that, The step of writing the generated firmware to the target device includes: The generated firmware file is written to the target device's memory via Bluetooth or USB interface, and the device's functionality is verified after the firmware is written.

3. The code writing method for adapting to multiple models of air quality monitors according to claim 1, characterized in that, The complete source code is a general-purpose code library that supports various air monitor models, including but not limited to air monitors that monitor carbon dioxide, carbon monoxide, or ozone.

4. The code writing method for adapting to multiple models of air quality monitors according to claim 1, characterized in that, The method can dynamically generate different firmware based on different configuration files of the target device model.

5. A code writing device compatible with multiple models of air quality monitors, applied to the method described in any one of claims 1-4, characterized in that, include: The storage module is used to store the complete source code that is compatible with multiple models of air quality monitors; The processing module is used to load the complete source code, parse the configuration file, trim functional modules that are not related to the target device, and reorganize the trimmed code. The compilation module is used to compile and reorganize the code to generate the adaptation firmware for the target device. The communication module is used to write the generated firmware to the target device.

Images