A configurable embedded software release system

Abstract

The application provides a configurable embedded software release system, and belongs to the technical field of embedded software development; in view of the problems of version proliferation, maintenance difficulty and low release efficiency of embedded software caused by strong coupling of the embedded software with hardware and customized needs in the prior art, the application proposes to split the embedded software firmware into stable system firmware and variable configuration firmware, and provide a configuration management subsystem on the server side; the configuration management subsystem provides a visual interface for a user to define hardware parameters, function logic and interactive behavior, and automatically generate the configuration firmware; the embedded device is loaded and parsed by the system firmware at startup, and the system is dynamically initialized according to the content; the application realizes the innovation from 'code compilation release' to 'configuration driven release', significantly reduces the number of software versions, and greatly improves the product customization efficiency, software maintenance efficiency and full life cycle management capability.

Description

Technical Field

[0001] This invention belongs to the field of embedded software development and software configuration management technology, specifically relating to a configurable embedded software release system, which is particularly suitable for scenarios that require rapid customization and release of embedded software for different hardware platforms and different customer needs. Background Technology

[0002] Embedded software is the core that drives the operation of various smart hardware and electronic devices. With the rapid development of the Internet of Things, smart terminals and other fields, embedded products are becoming increasingly diverse and complex, and are facing increasingly strong demands for personalization, rapid iteration and low-cost customization.

[0003] In traditional embedded software development models, software (often called "firmware") is deeply coupled with a specific hardware platform, which typically faces the following challenges: The strong binding relationship between hardware and software: Each hardware product, due to differences in its chip model, peripheral circuits, and peripheral devices (such as sensors and displays), usually requires the development and maintenance of an independent firmware version. Even if the hardware differences are minor, it often leads to the need for software to be re-adapted and released.

[0004] Customization-induced "version explosion": When the same hardware platform is targeted at different customers, their customization needs in areas such as function switches, interaction logic (e.g., button response, indicator light effects, and prompt sound effects), user interface, and software identifiers (version number, model number) all require modification of the source code, recompilation, and release of new complete firmware versions. This directly leads to an exponential increase in the number of software versions, forming a massive version matrix.

[0005] Maintenance and upgrade costs are high: When a system's basic functions develop defects (bugs) or require general function upgrades, developers need to modify, compile, and test the code for all relevant firmware branches, tailored to different hardware or customers. This process not only involves enormous repetitive labor but is also highly susceptible to introducing new errors through frequent code modifications. For testers, each new firmware version means almost a complete regression test, resulting in a heavy workload and low efficiency.

[0006] While existing technologies incorporate some modular or parameterized design concepts, they are largely limited to partial decoupling at the code level, failing to fundamentally separate product definition (hardware configuration, behavioral logic, resource binding) from core system logic and achieve data-driven management. Therefore, traditional models exhibit inherent flaws when addressing rapidly changing market demands, including long development cycles, high resource consumption, cumbersome release processes, chaotic version management, and difficulty in ensuring consistent product quality. Summary of the Invention

[0007] To overcome the technical shortcomings of existing embedded software development models, such as numerous versions, difficult maintenance, and low release efficiency caused by the strong coupling between firmware, hardware, and customization requirements, this invention provides a configurable embedded software release system.

[0008] The present invention discloses a configurable embedded software release system, which consists of two parts: an embedded target subsystem (device side) and a configuration management subsystem (server side). The configuration management subsystem can be deployed on a cloud server, a local server, or a private environment.

[0009] Part 1, Embedded Target Subsystem: The embedded software stack (including driver layer, OS layer, and application layer) includes a configuration parsing engine and a configuration access interface.

[0010] The configuration parsing engine is responsible for reading, verifying, decrypting (if enabled), and mapping configuration data to structured variables in memory.

[0011] Configure access interfaces to provide applications with a channel to access and modify configuration items (such as supporting dynamic updates).

[0012] The embedded target subsystem also includes a security fault-tolerance mechanism. In the event of verification failure or version incompatibility, it can enter a safe mode, allowing the re-burning of valid configuration firmware via serial port, USB, or wireless communication.

[0013] After the device is powered on, the system firmware first reads the configuration firmware from a specific location on the storage medium; then it performs integrity verification (such as CRC32, SHA256, etc.) and version compatibility checks; after the verification is successful, it parses the configuration data and initializes the hardware peripherals (such as GPIO levels, communication interfaces), sets function switches, registers event response logic, and loads relevant resources according to the parameters in the data; after initialization is completed, the system enters the main loop and runs according to the configuration driver logic until the power is turned off.

[0014] Part Two, Configuration Management Subsystem: The configuration management subsystem adopts a typical three-tier architecture: The front-end interaction layer provides a visual configuration editor; The backend service layer handles business logic, such as configuration generation, firmware packaging, permission management, and version control. The data layer stores all configuration items, historical versions, and operation logs.

[0015] The system supports advanced features such as configuration reverse lookup (searching for historical configurations by file name, project name, etc.), configuration cloning (copying existing configurations to quickly derive new variants), and customer-level key management (providing different encryption keys for different customers to configure firmware).

[0016] The configuration firmware uses a predefined structured data format (e.g., composed of specific structures, unions, and arrays), and its data structure version corresponds to the system firmware version. Content includes: (1) Hardware abstraction layer: pin definitions, peripheral models and parameters; (2) Behavior description layer: The mapping relationship between function enable flags, events (such as button presses, communication connections) and complex actions (such as specific LED flashing patterns, playing specific audio sequences); (3) Resource binding layer: UI elements, audio and video resource identifiers; (4) Product information layer: software version number, product model, customer identifier; (5) Security verification layer: integrity check code, data structure version number, and optional encryption information.

[0017] The principle of this invention is as follows: 1. Firmware structural separation: The traditional monolithic embedded firmware is decomposed into system firmware and configuration firmware; the system firmware encapsulates all stable driver logic and application logic, and has universality; the configuration firmware describes the hardware resource mapping, function selection, interaction logic, resource binding and version information of the specific product in a structured data form.

[0018] 2. Configure full lifecycle management: Build a cloud (or local) configuration management subsystem to provide visual configuration editing, verification, release, version control and maintenance functions, and realize data-driven management of product definitions.

[0019] 3. Dynamic Collaborative Operation Mechanism: On the embedded device side, a secure and reliable startup and operation collaborative mechanism is designed. The system firmware dynamically loads and parses the configuration firmware at startup, and completes hardware initialization and behavior shaping based on the configuration items, thereby realizing "one system firmware, multiple product forms".

[0020] Compared to traditional embedded development methods, this invention brings the following significant advantages: (1) In response to changes in product definition, such as hardware I / O adjustments, peripheral replacements, interaction logic modifications, interface resource updates, or software identifier changes, the traditional approach requires modifying the source code and recompiling and releasing the complete firmware, which is cumbersome and time-consuming. The present invention only requires engineers to adjust the corresponding parameters through a visual interface in the configuration management system, and the system can automatically generate and release lightweight configuration firmware. This achieves a fundamental shift from "full code compilation and release" to "differentiated configuration-driven release", with finer release granularity and an order-of-magnitude improvement in response speed.

[0021] (2) In terms of handling common requirement changes, such as basic bug fixes or additions / removals of general functions in the system firmware, the traditional approach requires repeated modification, compilation, and testing on all relevant firmware branches customized for different hardware or customers, which is a lot of work and is prone to omissions or new errors. The present invention, through the structural separation of firmware, makes such common changes only require updating a unified "system firmware" once. All devices equipped with the new system firmware can seamlessly obtain function updates or problem fixes by combining their original "configuration firmware". This greatly reduces the complexity and workload of maintenance and improves the reusability of core code and the overall product quality consistency.

[0022] (3) In terms of product definition management capabilities, the core definitions of products such as hardware resource mapping, functional logic, and interaction rules in the traditional model are often scattered in different versions of source code, design documents, and even the experience of engineers, making it difficult to effectively control, trace, and reuse versions. This invention solidifies all these product definitions into a structured "configuration firmware" and performs centralized and visualized data management through the configuration management subsystem. This makes product definitions versionable, traceable, and reusable digital assets, significantly improving the standardization level of product definitions and asset management efficiency.

[0023] Other features and advantages of the invention will be set forth in the following description or may be learned by practicing the invention. Attached Figure Description

[0024] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Throughout the drawings, the same reference numerals denote the same parts.

[0025] Figure 1 This demonstrates the complete boot process of the embedded target subsystem from loading the configuration firmware to completing initialization; Figure 2 It demonstrates the complete user workflow in the configuration management subsystem, from selecting a template to publishing configuration firmware. Figure 3 The module division of the embedded target subsystem is shown, including the configuration read / write interface module and the configuration initialization and management interface module; Figure 4 The three-tier architecture of the configuration management subsystem is demonstrated, including the front-end, back-end, and data layer. Figure 5 and Figure 6 The flowcharts and structural diagrams shown are respectively from existing technologies, used for comparison to highlight the innovativeness of the present invention. Detailed Implementation

[0026] This invention provides a specific implementation of a configurable embedded software distribution system. Logically, the system consists of two main parts: a target subsystem running on an embedded device and a configuration management subsystem deployed on a cloud server or internal network.

[0027] I. Implementation method of embedded target subsystem: 1. Startup and operation process: like Figure 1 As shown, after the device is powered on, perform the following steps: S101: The system firmware loads configuration firmware data into a memory buffer from a predefined non-volatile memory address (such as a specific sector of Flash or an external EEPROM).

[0028] S102: Perform integrity verification of the configuration firmware.

[0029] This embodiment uses the CRC32 algorithm to calculate the checksum and compares it with the checksum pre-stored in the firmware. Simultaneously, it checks the version number of the data structure carried in the configuration firmware header to ensure that it does not exceed the maximum version number supported by the system firmware.

[0030] S103: If both the verification and version check pass, proceed to S104; if either check fails, proceed to S105 to enter safe mode.

[0031] S104: Configuration parsing and system initialization.

[0032] The configuration parsing engine maps the data in the buffer directly to the corresponding global configuration variables according to the structure types defined during pre-compilation. Subsequently, the system dynamically calls the underlying driver interface based on these configuration variable values ​​to complete the initialization of hardware peripherals (such as initializing specific GPIO pins to output mode and setting default levels, configuring UART baud rate, and registering interrupt service routines); at the same time, it enables or disables the corresponding software logic according to the configured software functions, sets the event trigger condition-response action mapping table, and sets the application layer logic and behavior response functions.

[0033] S105: Loading interactive resources during system runtime During system operation, the corresponding interactive resources in the configuration are invoked based on the triggered events.

[0034] S106: Safe Mode.

[0035] In this mode, the system maintains the most basic communication drivers (such as a specific UART debug port or Bluetooth Low Energy broadcast) and waits to receive a valid configuration firmware update command from an external source.

[0036] In this embodiment, a complete and verified configuration firmware data packet can be resent to the device via a dedicated host computer tool (production testing system) through a serial port, Bluetooth GATT service, or other wireless protocols. After receiving the packet, the device writes it to its storage area and restarts.

[0037] 2. Module structure: like Figure 3 As shown, two core modules are introduced in addition to the existing driver layer, operating system layer (optional), and application layer: Configuration Read / Write Interface Module: This module provides a unified set of APIs (such as Config_Read(), Config_Write()) for reading and writing to the underlying storage medium, enabling physical loading and updating of the configuration firmware.

[0038] Configuration Initialization and Management Interface Module: This module is the core of the configuration parsing engine. It provides the `Config_Init()` function, which is responsible for the verification, parsing, and variable mapping work in steps S102 to S104. Simultaneously, it exposes a set of interfaces for getting and setting configuration items to the application (such as `Config_GetLedBlinkPattern()`, `Config_SetVolume()`), allowing the application to read or modify certain dynamically adjustable configuration parameters at runtime.

[0039] The configuration read / write interface module is located between the driver layer and the operating system layer, and is responsible for interacting with the storage medium; the configuration initialization and management interface module is located in the application layer, and provides configuration access interface for the upper layer.

[0040] 3. Example of configuring driver behavior: Taking "Bluetooth connection success event triggers LED indicator" as an example, this illustrates how configuration drives application behavior: In the "Event-Action Table" of the configuration firmware, define a rule: Event ID (corresponding to Bluetooth connection) -> Action ID (trigger LED effect).

[0041] In the "LED Effects Parameters" structure, configure the specific mode (such as breathing light), frequency, color, and duration for the corresponding action ID.

[0042] This rule is registered with the event manager during system initialization.

[0043] During runtime, when the Bluetooth protocol stack detects a successful connection, it triggers the corresponding event ID. The event manager then looks up the table and executes the action ID, calling the LED driver library and passing in the configured effect parameters, thus enabling customized interactive feedback without modifying the application code.

[0044] II. Implementation method of configuration management subsystem: 1. Configure the generation and release process: like Figure 2 As shown, the user (engineer) accesses the system through a browser and performs the following operations: S201: Select a template.

[0045] Based on the target chip model, select a basic configuration template. This template has all available GPIOs, peripherals and other basic hardware frameworks, product function options, user interaction event options and configurable resource list of the chip pre-configured.

[0046] S202: Visual configuration.

[0047] In the web interface, various form components are used for visual configuration: Hardware configuration example: Specify the function of a pin as LED control and select the drive level (active high / active low).

[0048] Example of function configuration: Enable or disable the "timed hibernation" function and set the hibernation duration parameter.

[0049] Example of interactive configuration: In the event editor, select the "Start Network Configuration Mode" action, set the button definition to "Long press button A" event, and the event response prompt is that the LED blue light flashes once and a prompt sound 2 plays. Resource management example: Resource configuration for prompt tone 2. If a buzzer is used, enter the different frequencies and playback durations in the input box. If a speaker is used, upload the audio file and associate it in the interaction configuration.

[0050] Product information example: Fill in the software version number, hardware version number, and custom product model.

[0051] After the visual configuration is completed, the system provides a configuration result summary and confirmation interface. This interface displays all the product definition data configured by the user on a single page, including hardware parameters, functional parameters, interaction logic, resource information, and configuration firmware version information, making it easy for the user to verify. Users can click on this interface to download a PDF configuration summary table file, which can be downloaded and saved separately for record-keeping or filing.

[0052] S203: Saving and Verification.

[0053] Clicking "Save" stores all current configuration items in JSON format in the database. When the user selects to download the configuration file, the system automatically exports the JSON format as a binary configuration firmware. This firmware, combined with existing system firmware, allows verification of the configuration logic's correctness on a real device.

[0054] S204: Officially released.

[0055] After confirming that the configuration is correct, the user can perform the publishing operation. The publishing function provides two packaging methods for users to choose from: Product firmware release package: Used for software release or online upgrade. The system automatically packages the system firmware that the user has uploaded or selected in advance, the newly generated configuration firmware, the online upgrade package (such as a differential upgrade package or a full upgrade package for OTA), and the configuration summary table into a compressed file for the user to download to their local machine for release; the online upgrade package can be generated from the system firmware and configuration firmware and is used for remote device upgrades.

[0056] Product flashing package: Used for production flashing. The system automatically packages the system firmware, configuration firmware, flashing tools (such as programmer drivers), and flashing scripts into a compressed file for users to download for mass production flashing.

[0057] Users can choose the appropriate packaging method according to their needs.

[0058] The system background service will execute: a. Optional Encryption: If the user enables the encryption option, the system will encrypt the configuration data using a key associated with a specific customer, product model, or project. This key can be entered directly by the user or automatically assigned and managed by the system based on customer identification or product model information to achieve secure isolation and targeted distribution of configuration data.

[0059] b. Generate checksum: Calculate the CRC32 checksum of the final configuration data.

[0060] c. Packaging: Assemble the configuration data, checksum, version number, header information, etc. into a standard binary "configuration firmware" file, and generate a human-readable "configuration summary table" (such as CSV or PDF format).

[0061] d. Generate delivery package: Package the current version of the system firmware, the newly generated configuration firmware, and the general burning tool script into a compressed file for download, for mass production or on-site upgrades.

[0062] The configuration management subsystem includes a configuration firmware generation module, which further includes an encryption unit. This module is the core component for implementing the aforementioned configuration firmware packaging and distribution functions. It receives structured configuration data from a visual configuration editor or project management module and performs the following operations: ① According to user settings, the encryption unit is invoked to encrypt the configuration data; ② Calculate the integrity check code of the configuration data (such as CRC32 or SHA256); ③ Package the configuration data, checksum, data structure version number, and header information to generate a binary format configuration firmware file; ④ Optionally, the configuration firmware, system firmware, and flashing tools can be integrated into a delivery package for users to download or directly push to the target device.

[0063] The configuration management subsystem also includes a project management module. This module is responsible for storing configuration projects for different products and their historical version data, and provides a reverse lookup function based on configuration identifiers (such as project name, firmware file name, release status, etc.). Users can quickly retrieve historical configuration projects through this module, and it supports cloning existing configuration projects to create new ones, thereby improving configuration reuse and iteration efficiency.

[0064] 2. System Architecture and Implementation of Key Functions: like Figure 4 As shown, the configuration management subsystem adopts a B / S architecture: Front-end (browser interface, app interface, or mini-program): Implement a rich visual configuration editor.

[0065] Backend services: Provided by: ① Configure project management services (CRUD operations, version history); ② Configure firmware build service (execute encryption, verification, and packaging logic); ③ Access control service (distinguishes between administrators, internal users, and external users, and controls project access and operation permissions); ④ Key management service (secure storage and distribution of client encryption keys); Database: Stores user information, project data, historical versions of configuration items, and operation audit logs.

[0066] III. Implementation details of other key functions: 1. Configure reverse lookup and cloning: The project list page provides an advanced search box that allows users to filter projects by firmware file name, chip name, SDK name, project name, creator, release date, and other parameters.

[0067] For configurations that have already been published or created by others, the interface provides a "Clone" button.

[0068] The cloning operation essentially copies all configuration data records of the latest version of the project in the background, generating a brand new project copy with a "draft" status, which users can then modify, greatly improving the efficiency of configuring similar products.

[0069] 2. Version compatibility management: The system firmware and configuration firmware data structure version numbers are managed together.

[0070] When a system firmware upgrade may lead to changes in the configuration structure, the corresponding template version will be updated synchronously in the configuration management subsystem.

[0071] When generating configuration firmware, the system will specify the minimum system firmware version it depends on, thus avoiding version mismatch issues from the source.

[0072] 3. Encryption key management strategy: To ensure the security and confidentiality of the configuration firmware, the system supports encryption key management based on customer and product dimensions.

[0073] The keys can be pre-configured and stored within the system for different customers or product models.

[0074] When generating configuration firmware for a specific customer or model project, the system can automatically call the associated key for encryption; this mechanism not only prevents unauthorized interpretation and use of configuration data, but also constitutes an important part of software supply chain security management.

[0075] IV. Example of firmware data structure configuration: The following simplified C language structure example provides a detailed explanation of the hardware parameters (such as pin configuration), functional and interactive logic parameters (such as event-action rules, function switches), product information, and other data contained in the configuration firmware.

[0076] / / Configuration file header typedef struct { uint32_t magic_number; / / Magic number, identifies the file type uint16_t struct_version; / / Version number of the data structure uint16_t config_crc32; / / CRC32 checksum of configuration data uint8_t is_encrypted; / / Encryption flag / / ... other header information } config_header_t; / / Hardware pin configuration typedef struct { char func_name

[20] ; / / Function name, such as "LED_MAIN" uint8_t gpio_port; / / GPIO port uint8_t gpio_pin; / / GPIO pin uint8_t active_level; / / Active level } hardware_gpio_cfg_t; / / Event-Action Rule Configuration typedef struct { uint16_t event_id; / / Event ID, such as EVT_BLE_CONNECTED uint16_t action_id; / / Action ID, such as ACT_LED_PATTERN uint32_t action_param; / / Action parameter, which can point to a more complex parameter structure. event_action_rule_t; / / Main configuration structure (mapped in memory) typedef struct { config_header_t header; hardware_gpio_cfg_t gpio_configs

[20] ; event_action_rule_t rules

[50] ; uint8_t feature_flags; / / Feature switch bitmap char product_model

[32] ; / / ... More configuration areas } system_config_t; In the system firmware, a global variable `system_config_t g_sys_cfg` is defined to configure the parsing engine. Essentially, this involves safely filling the binary data from the storage medium into this structure variable.

[0077] Figure 5 This demonstrates the workflow of a traditional embedded system: after the system is powered on, the complete firmware is loaded directly, hardware initialization is performed, and fixed logic is run. There is no configuration separation or dynamic loading mechanism, which means that the entire firmware needs to be recompiled and released for different hardware or customized needs.

[0078] Figure 6 As a typical modular structure of traditional embedded systems, its driver layer, operating system layer and application layer are tightly coupled. Hardware configuration and functional logic are hard-coded in the system firmware, lacking configuration parsing and management interfaces, making it difficult to achieve dynamic configuration and multi-product support.

[0079] Furthermore, in this invention, the "universality" of the system firmware means that the system firmware is compiled for a specific chip platform or hardware series, encapsulating the platform's stable driver framework, operating system kernel, and basic application services, and can support a variety of different peripheral hardware combinations, functional configurations, and interaction logics under that platform.

[0080] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention.

Claims

1. A configurable embedded software distribution system, characterized in that, include: The configuration management subsystem, deployed on the server side, provides a visual interface for editing product definitions and generating configuration firmware based on those product definitions. An embedded target subsystem, deployed on the embedded device side, includes system firmware and configuration firmware generated by the configuration management subsystem; the system firmware contains general driver logic and application logic, and the configuration firmware contains structured configuration data describing the hardware resource mapping, function selection and interaction logic of a specific product. When the embedded target subsystem starts up, the system firmware loads and parses the configuration firmware, and completes hardware initialization and application behavior shaping based on the parsed configuration data, thereby enabling support for multiple product forms based on a single system firmware.

2. The configurable embedded software distribution system according to claim 1, characterized in that, The configuration management subsystem includes: A visual configuration editor is used to receive user input for product definition data configuration. The configuration firmware generation module is used to package the user-configured structured data with integrity check codes and data structure version numbers to generate a binary configuration firmware file that can be loaded by the embedded target subsystem. The project management module stores configuration data for different versions and provides reverse lookup and cloning functions based on configuration identifiers.

3. The configurable embedded software distribution system according to claim 2, characterized in that, The configuration firmware generation module further includes an encryption unit for encrypting configuration data using a key associated with the customer and product model; the system firmware includes a corresponding decryption function for decrypting the encrypted configuration firmware during loading.

4. The configurable embedded software distribution system according to claim 1, characterized in that, The system firmware in the embedded target subsystem is configured to execute at startup: Perform integrity verification and data structure version compatibility checks on the loaded configuration firmware; If the integrity verification fails, the system enters a secure mode and opens the communication interface to receive and update the configuration firmware.

5. The configurable embedded software distribution system according to claim 4, characterized in that, The system firmware in the embedded target subsystem is configured to execute at startup: If the data structure version is incompatible, enter safe mode and open the communication interface to receive and update the configuration firmware.

6. The configurable embedded software distribution system according to any one of claims 1-5, characterized in that, The configuration management methods of the configuration management subsystem include: Responding to user actions, it provides a visual configuration interface for the target embedded product; Receive and configure product definition data through the interface. The product definition data includes product function parameters, hardware peripheral parameters, interaction logic parameters, interaction resource data, and configuration firmware version information. The configured product definition data is packaged together with the pre-generated integrity check code and data structure version information to generate configuration firmware. Provide a download service for the configuration firmware.

7. The configurable embedded software distribution system according to claim 6, characterized in that, The configuration management method of the configuration management subsystem further includes: A query interface is provided, which allows users to query historical configuration projects based on any combination of one or more of the following conditions: configuration firmware file name, chip name, SDK name, project name, creator, and release date. The system provides a cloning operation for the retrieved historical configuration items to generate a new copy of the configuration item. Based on this copy, only differentiated modifications are made according to the new product definition, and the new project configuration firmware is edited and generated.

8. The configurable embedded software distribution system according to claim 6, characterized in that, The configuration management method of the configuration management subsystem further includes: Provides a summary and confirmation interface for configuration results, allowing users to view the current configuration content on a single page; A PDF configuration summary table file is available for download; this file can be downloaded separately.

9. The configurable embedded software distribution system according to claim 6, characterized in that, The configuration management method of the configuration management subsystem further includes: It provides a product firmware release function. Before release, users can upload or select existing system firmware. Then, the release function automatically packages the system firmware, configuration firmware, online upgrade package, and configuration summary table into a compressed file for release and download to the local machine. It provides a product flashing package download function, allowing users to download a compressed file containing system firmware, configuration firmware, flashing tools, and flashing scripts.

10. The configurable embedded software distribution system according to any one of claims 1-5, characterized in that, The software startup and operation mode in the embedded target subsystem is as follows: After the system is powered on, the configuration firmware is loaded from a specified location in the non-volatile memory; Perform integrity verification and data structure version compatibility checks on the configuration firmware; If the verification and check pass, the structured data in the configuration firmware is parsed, and the hardware peripherals are initialized according to the parsed software function modules and hardware parameters, the interactive event response logic is registered, and the corresponding interactive resources in the configuration are loaded when the interactive logic is run. The application runs based on configuration-driven logic until the system loses power.

Images