Embedded device flashing methods and related equipment

Abstract

This application discloses an embedded device flashing method and related equipment, relating to the field of embedded device technology. The method includes: acquiring the environmental context information of the target device and the path to the flashing package provided by the user; determining a target flashing strategy from a preset strategy matrix based on the environmental context information; parsing the flashing package according to the target flashing strategy to extract the device identifier and platform configuration; establishing a device link based on the device identifier and platform configuration to generate a target flashing channel; and scheduling a target flashing tool matching the target flashing strategy to perform the flashing operation through the target flashing channel. This application achieves multi-platform adaptive flashing tool scheduling through environmental awareness, strategy matrix decision-making, automatic parsing, and channel establishment, thereby improving the automation, versatility, stability, and efficiency of the flashing process.

Description

Technical Field

[0001] This application relates to the field of embedded device technology, and more specifically, to an embedded device flashing method and related equipment. Background Technology

[0002] With the rapid development of embedded technology and smart terminal devices, embedded devices have been widely used in smart homes, industrial control, automotive electronics, and communication equipment. During device factory testing, firmware upgrades, and maintenance, flashing is a crucial step in ensuring stable system operation and functional updates. However, with the increasing variety of devices and hardware platforms, the complexity and diversity of the flashing environment for embedded devices have become increasingly prominent. Significant differences in flashing tools, interface protocols, and packet structures between different manufacturers and platforms often necessitate manual selection of tools, parameter settings, and port identification, making the process cumbersome and prone to errors.

[0003] In related technologies, flashing methods for embedded devices typically rely on manual execution or single-layer script tools, lacking awareness of the device environment and connection status. Before flashing, users need to manually determine the device model, port type, and flashing package compatibility, resulting in low automation and susceptibility to issues such as incorrect parameter configuration or inaccurate device identification. Furthermore, traditional solutions mostly employ fixed processes and single logic, failing to dynamically adjust flashing strategies based on actual device status and lacking flexible adaptation to different platforms and environmental conditions. In other words, related technologies suffer from low flashing efficiency, high error rates, and poor device compatibility. Summary of the Invention

[0004] The summary section of this application introduces a series of simplified concepts, which will be further explained in detail in the detailed description section. The summary section of this application is not intended to limit the key features and essential technical features of the claimed technical solution, nor is it intended to determine the scope of protection of the claimed technical solution.

[0005] The embedded device flashing method and related equipment provided in this application can achieve multi-platform adaptive flashing tool scheduling through environmental perception, strategy matrix decision-making, automatic parsing and channel establishment, thereby improving the automation, versatility, stability and efficiency of the flashing process.

[0006] In a first aspect, this application provides a method for flashing an embedded device, comprising: obtaining environmental context information of the target device and a flashing package path provided by the user; determining a target flashing strategy from a preset strategy matrix based on the environmental context information; parsing the flashing package according to the target flashing strategy to extract a device identifier and platform configuration; establishing a device link based on the device identifier and the platform configuration to generate a target flashing channel; and scheduling a target flashing tool matching the target flashing strategy to perform a flashing operation through the target flashing channel.

[0007] In some implementations, the environmental context information includes system load, number of concurrent devices, and available system tool versions; determining the target flashing strategy from a preset strategy matrix based on the environmental context information includes: quantifying and analyzing the system load, number of concurrent devices, and available system tool versions to obtain a target environmental state vector; and selecting the flashing strategy with the highest matching degree as the target flashing strategy based on the matching degree between the target environmental state vector and each flashing strategy in the preset strategy matrix, wherein the strategy matrix defines a mapping relationship between different environmental state vectors and flashing strategies.

[0008] In some implementations, the step of parsing the flashing package according to the target flashing strategy to extract the device identifier and platform configuration includes: determining the number of parallel processing threads for decompressing the flashing package based on the resource allocation strategy in the target flashing strategy; performing parallel decompression of the flashing package based on the determined number of parallel processing threads to obtain a decompressed file; verifying the integrity of the file structure of the decompressed file based on a preset verification algorithm specified in the target flashing strategy; after the integrity verification is passed, extracting the device identifier from the decompressed file using a parsing engine specified in the target flashing strategy; and querying a preset configuration mapping library based on the device identifier to obtain the corresponding platform configuration, wherein the platform configuration includes the device communication protocol type and configuration parameters.

[0009] In some implementations, establishing a device link based on the device identifier and the platform configuration to generate a target flashing channel includes: initializing a corresponding device communication protocol stack based on the device communication protocol type in the platform configuration; sending a device discovery request through the bus of the device communication protocol stack and listening to the device response signal on the bus, wherein the device discovery request includes the device identifier; determining a target device port from multiple candidate ports based on the strength and timing characteristics of the device response signal; and establishing a communication link with the target device on the target device port as the target flashing channel.

[0010] In some implementations, sending a device discovery request via the bus of the device communication protocol stack includes: determining a preset set of ports connected to the target device based on historical flashing record data, wherein the ports in the preset set are arranged in priority order; and sending the device discovery request sequentially to the devices corresponding to the preset port set via the bus of the device communication protocol stack.

[0011] In some implementations, scheduling a target flashing tool matching the target flashing strategy to perform a flashing operation through the target flashing channel includes: selecting the target flashing tool from a preset tool library based on the execution mode defined in the target flashing strategy, wherein the execution mode includes a fast flashing mode, a secure flashing mode, and a debug flashing mode; configuring the target flashing tool according to the device communication parameters in the platform configuration to obtain a flashing session adapted to the platform configuration; establishing a data bridge with the target flashing channel based on the flashing session to form a real-time data stream interface supporting bidirectional communication; performing the flashing operation through the real-time data stream interface, and during the execution process, verifying and adjusting the data transmission integrity in real time based on the preset monitoring rules in the target flashing strategy.

[0012] In some implementations, the step of performing the flashing operation through the real-time data stream interface, and verifying and adjusting the data transmission integrity in real time based on the preset monitoring rules in the target flashing strategy, includes: capturing flashing data packets transmitted via the real-time data stream interface through a data acquisition agent deployed in the flashing session; performing cyclic redundancy check on the flashing data packets based on the preset verification rules in the target flashing strategy to generate a verification result; when the verification result indicates a transmission anomaly, reconstructing the transmission configuration of the real-time data stream interface based on the adjustment parameters corresponding to the verification result; and performing the flashing operation through the real-time data stream interface based on the reconstructed transmission configuration.

[0013] Secondly, this application also provides an embedded device flashing apparatus, comprising: a data acquisition unit for acquiring environmental context information of a target device and a flashing package path provided by a user; a strategy determination unit for determining a target flashing strategy from a preset strategy matrix based on the environmental context information; a flashing parsing unit for parsing the flashing package according to the target flashing strategy to extract a device identifier and platform configuration; a channel establishment unit for establishing a device link based on the device identifier and the platform configuration to generate a target flashing channel; and a flashing execution unit for scheduling a target flashing tool matching the target flashing strategy to perform a flashing operation through the target flashing channel.

[0014] Thirdly, this application also provides an electronic device, including: a memory and a processor, wherein the processor is configured to execute a computer program stored in the memory to implement the steps of the embedded device flashing method described in the first aspect.

[0015] Fourthly, this application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the embedded device flashing method described in the first aspect.

[0016] Fifthly, this application also provides a computer program product, including a computer program or computer executable instructions, wherein when the computer program or computer executable instructions are executed by a processor, the steps of the embedded device flashing method provided in the embodiments of this application are implemented.

[0017] In summary, this application can automatically obtain the environmental context information of the target device and determine the appropriate flashing strategy based on a preset strategy matrix, thereby eliminating the need for manual selection of device type, tools, and parameters. This allows the flashing process to adapt to the actual environment, reducing the possibility of human error. By parsing the flashing package, it automatically extracts device identification and platform configuration information, enabling the identification of embedded devices of different brands, models, or platforms. This allows the same process to adapt to the flashing needs of multiple devices, reducing the repetitive development of scripts or tools. Before performing the flashing operation, a stable device link is established based on the device identification and platform configuration, generating... A dedicated flashing channel ensures the correctness and consistency of the communication link, thereby reducing the risks of flashing interruptions, identification errors, or data corruption. The flashing process is automatically determined through preset strategies, and flashing tools matching the target strategy are scheduled for execution. The entire process is intelligent and automated, reducing manual intervention time, shortening the flashing preparation and execution cycle, and improving efficiency when flashing batch devices. By combining a strategy matrix with a tool scheduling mechanism, the optimal flashing strategy and tools can be flexibly selected based on different device environments, interface states, and platform characteristics, enabling the system to maintain high efficiency, security, and stability even when facing complex and diverse device scenarios. In summary, the embedded device flashing method provided in this application achieves multi-platform adaptive flashing tool scheduling through environmental awareness, strategy matrix decision-making, automatic parsing, and channel establishment, thereby improving the automation, versatility, stability, and efficiency of the flashing process. Attached Figure Description

[0018] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit this specification. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0019] Figure 1 A flowchart illustrating an embedded device flashing method provided in an embodiment of this application;

[0020] Figure 2 This is a schematic diagram of the composition structure of an embedded device flashing device provided in an embodiment of this application;

[0021] Figure 3 This is a schematic diagram of the composition structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0022] The terms used in the specification, claims, and drawings of this application, such as "first," "second," "third," "fourth," etc. (if any), are used to distinguish similar objects and not to describe a specific order or sequence. Therefore, it is to be understood that these terms can be used interchangeably where appropriate, allowing the described embodiments to be used in different orders, unless specifically required by the illustrations or description. Furthermore, the terms "is" and "has," and any variations thereof, are intended to cover, non-exclusively, all possible constituent elements. For example, a process, method, system, product, or apparatus comprising several steps or units is not necessarily limited to the steps or units explicitly listed, but may also include other steps or units not explicitly listed, or steps or units inherent to the process, method, product, or apparatus.

[0023] In this application, a "module" or "unit" refers to a computer program or part of a computer program that has a specific function and works in conjunction with other related parts to achieve a predetermined goal. These modules or units can be implemented by software, hardware (e.g., processing circuitry or memory), or a combination of both. One or more processors or memories can implement one or more modules or units. Furthermore, each module or unit can also be part of a larger module or unit.

[0024] The technical solutions of this application will be described in detail below with reference to the accompanying drawings of the embodiments. It should be noted that the described embodiments are only a part of this application, and not all embodiments. In the following description, the "some embodiments" mentioned are only a subset of all possible embodiments, which may be the same or different subsets, and different embodiments can be combined with each other without conflict.

[0025] Figure 1 This is a flowchart illustrating an embedded device flashing method provided in an embodiment of this application. For example, see [link to example]. Figure 1 The embedded device flashing method provided in this application embodiment may include the following steps 101 to 105:

[0026] Step 101: Obtain the environmental context information of the target device and the path to the flashing package provided by the user.

[0027] In some examples, the target device is an embedded device that needs to be flashed. It is usually equipped with a specific hardware platform, such as an embedded development board based on a chip from brand A or a smart terminal based on a chip from brand B. After being connected to the flashing host via a Universal Serial Bus (USB) interface, the device management module of the flashing host scans the bus device list, identifies the device in the flashing state, and thus determines the target device. The environment context information refers to the real-time status data of the target device and the flashing host that affects the flashing process, including system load, number of concurrent devices, and available system tool versions. System load refers to the resource usage of the flashing host, such as CPU utilization and RAM usage. The number of concurrent devices refers to the total number of devices currently connected to the flashing host and awaiting flashing. Available system tool versions refer to the version information of flashing-related tools installed on the flashing host. System load can be obtained by executing the `top` command or parsing the ` / proc / loadavg` file. The number of concurrent devices can be obtained by traversing the USB device list using the `lsusb` command and counting the number of devices matching the flashing status characteristics. Available system tool versions can be obtained by parsing the returned results of executing the tool with the `--version` parameter in the command line. The flashing package path is the storage location of the compressed package containing the target device firmware files provided by the user in the local file system of the flashing host. It is usually represented in the form of an absolute path or a relative path. For example, when the user executes the flashing script, the flashing package path is passed in through the command line parameters. When executing . / initshuaji.sh / home / user / roms / rom_865.zip, / home / user / roms / rom_865.zip is the flashing package path. The script extracts this path information by parsing the command line parameters.

[0028] For example, the user connects the target device to the flashing host via a USB cable, ensuring the target device is in flashing mode. Then, the user enters an execution command containing the flashing package path into the command-line terminal of the flashing host. After the flashing script starts, it first scans the USB bus through the device management module, identifies the target device, and records its hardware identifier. Simultaneously, the script calls system commands to collect system load data such as CPU usage and memory usage, counts the number of currently connected concurrent devices, queries version information for tools such as MG_flash_tool, and integrates this information to obtain the environment context. Finally, the script parses the command-line parameters entered by the user, extracts and stores the flashing package path, completing the information acquisition process for this step.

[0029] By implementing step 101, we can fully grasp the key information such as the current device's connection status, communication interface, and operation permissions, and accurately locate the source of the firmware to be flashed. This provides a reliable input basis for the subsequent flashing process, avoids tool selection errors or device recognition failures due to incomplete environmental information, and thus improves the accuracy and controllability of the flashing process.

[0030] Step 102: Determine the target flashing strategy from the preset strategy matrix based on the environmental context information.

[0031] In some examples, the preset strategy matrix is ​​a pre-configured structured data set that stores the mapping relationship between different environmental states and corresponding flashing strategies. Its function is to establish the association between environmental context information and flashing execution rules. The row dimension of the matrix usually corresponds to the quantitative feature combination of environmental states, such as system load range, concurrent device number range, and tool version compatibility identifier. The column dimension corresponds to the key parameters of the flashing strategy, such as resource allocation rules, tool selection priority, and process execution mode. Each matrix cell stores a complete strategy entry adapted to a specific environmental state. The preset strategy matrix can be pre-configured, for example, stored in the strategy library of the flashing system through configuration files in Extensible Markup Language (XML) or JavaScript Object Notation (JSON) format, and defined and updated by developers based on historical flashing data and device characteristics. For example, in a preset strategy matrix, when the system load is below 30%, the number of concurrent devices is less than 5, and the MG_flash_tool (MG flashing tool) version is 2.0 or above, the corresponding strategy entry is "4 parallel decompression threads, prioritize using MG_flash_tool, and execute fast flashing mode". The target flashing strategy is a set of specific flashing execution rules matched from the preset strategy matrix and adapted to the current environment context information. It may include key parameters such as resource allocation (e.g., number of threads, memory ratio), tool selection (e.g., the flashing tool to be used first), and process control (e.g., execution mode, verification frequency) to guide subsequent steps such as flashing package parsing, link establishment, and tool scheduling.

[0032] For example, after obtaining the environment context information, the flashing script first calls the quantization module to convert information such as system load, number of concurrent devices, and tool version into standardized labels (such as "low load", "medium concurrency", "high version compatible") to form an environment state vector. Then, the script reads the preset policy matrix in the policy library, traverses all policy entries in the matrix through a matching algorithm, and calculates the matching degree between the current environment state vector and the environment features of each entry. Finally, the script selects the policy entry with the highest matching degree as the target flashing policy and stores the key parameters of the policy (such as the number of threads, tool identifier, and execution mode) in memory variables to provide the execution basis for subsequent steps. For example, when the environment state vector is "low load, low concurrency, tool version compatible", the target flashing policy determined after matching may include specific rules such as "parallel thread count 4, priority call to MG_flash_tool, and use fast flashing mode".

[0033] By implementing step 102, the target flashing strategy is determined from the preset strategy matrix based on the environmental context information. The most suitable flashing method and execution logic can be automatically matched, realizing intelligent flashing decision-making. This avoids errors caused by manual strategy selection and enables the flashing process to adapt to different device types, interface modes, or operating system environments, thereby improving the flexibility and execution efficiency of the flashing process.

[0034] Step 103: According to the target flashing strategy, the flashing package is parsed and processed to extract the device identifier and platform configuration.

[0035] In some examples, the flashing package is a compressed data package containing the target device's firmware files and related configuration information. It can be in formats such as .tar.gz, .zip, or .tar, and contains key content such as the firmware image to be flashed, version description files, and hardware configuration scripts. Parsing processing is a series of preprocessing operations performed on the flashing package according to the target flashing strategy. This includes decompressing the compressed package, verifying file integrity, and extracting key information. Its core purpose is to obtain the device characteristics and configuration data required for subsequent flashing from the flashing package. This can be executed automatically according to the rules in the target flashing strategy. For example, if the strategy defines "4 parallel decompression threads, using Cyclic Redundancy Check (CRC) algorithm to verify integrity," the corresponding tool will be called to perform decompression according to this rule, and the file structure will be verified using the CRC algorithm. The device identifier is characteristic information used to uniquely identify the target device model or hardware platform, and it usually exists as a string in the flashing package's version description file (such as version.txt). Platform configuration is a set of communication and flashing parameters corresponding to the target device's hardware platform, including device communication protocol type, data transmission baud rate, firmware partition table, etc. Its function is to ensure compatibility of subsequent link establishment and flashing operations. The platform configuration can be obtained by querying the preset configuration mapping library based on the device identifier. This preset configuration mapping library stores the correspondence between device identifier and platform configuration in the form of key-value pairs. For example, querying the platform configuration corresponding to "865" will show "Communication protocol: USB debugging mode (Universal Serial Bus Debugging, USB Debug), baud rate: 115200, partition table: rawprogram.xml".

[0036] For example, the flashing script, based on the "4 parallel decompression threads" rule in the target flashing strategy, calls the pigz tool to perform parallel decompression of the flashing package (e.g., rom_865.zip) with 4 threads, obtaining a decompressed directory containing files such as version.txt and firmware.img. Subsequently, the script compares the directory structure of the decompressed files with the preset checksum using the CRC algorithm specified in the strategy to verify integrity. After successful verification, the script uses the awk tool to parse version.txt and extract the device identifier "865" from "device_model:865". Finally, the script queries the configuration mapping library to obtain the platform configuration corresponding to "865" (e.g., communication protocol is USB debug mode, baud rate is 115200), completes the parsing process, and stores the device identifier and platform configuration.

[0037] By implementing step 103, embedded devices of different models, platforms, or manufacturers can be accurately identified. This process ensures the compatibility of the flashing package with the target device, preventing device damage due to firmware or configuration errors. It also supports multi-platform adaptation under a unified process, reducing redundant script development and manual verification work.

[0038] Step 104: Based on the device identifier and platform configuration, establish the device link to generate the target flashing channel.

[0039] In some examples, device link establishment is a process of establishing a stable communication connection between the flashing host and the target device based on device identifiers and platform configurations. Its core includes communication protocol stack initialization, device discovery, target port determination, and link activation, aiming to provide basic connection support for subsequent flashing data transmission. The acquisition of device link establishment is automated: first, the corresponding protocol stack is initialized according to the communication protocol type in the platform configuration; then, a discovery request containing the device identifier is sent through the protocol stack; the target port is filtered based on the device response characteristics; and finally, the communication link is activated on that port. For example, for the device identifier "865" and the platform configuration "Communication Protocol: Universal Serial Bus Debugging (USB Debug)," the device link establishment process includes initializing the USBDebug protocol stack, sending a discovery request containing "865," identifying a matching port, and activating the connection. The target flashing channel is a dedicated communication link generated during the device link establishment process, used for transmitting firmware data and control commands between the flashing host and the target device. It possesses stability, bidirectionality, and adaptability characteristics, directly determining the transmission efficiency and reliability of flashing data.

[0040] For example, the flashing script first reads the "Communication Protocol Type: Universal Serial Bus Debug Mode" in the platform configuration, calls the system driver interface to initialize the corresponding USB Debug protocol stack; then, it sends a discovery request containing the device identifier "865" to all connected devices through the bus of this protocol stack, and listens for the response signal returned on the bus; based on the strength characteristics (such as signal stability of 98%) and timing characteristics (such as response delay of 50 milliseconds) of the response signal, it determines / dev / ttyUSB0 as the target device port from the candidate ports (such as / dev / ttyUSB0, / dev / ttyUSB1); finally, the script activates the communication link based on the USB Debug protocol on the / dev / ttyUSB0 port, generates the target flashing channel, and records the interface parameters of the channel (such as baud rate of 115200) to prepare for subsequent flashing data transmission.

[0041] By implementing step 104, a device link is established based on the device identifier and platform configuration, and a target flashing channel is generated. This ensures that the device maintains a stable and reliable communication connection during the flashing process. By establishing and verifying the channel status in advance, problems such as interruption, timeout, or identification abnormality during the flashing process can be effectively prevented, thereby improving the stability and success rate of the flashing operation.

[0042] Step 105: Through the target flashing channel, schedule the target flashing tool that matches the target flashing strategy to perform the flashing operation.

[0043] In some examples, the target flashing tool matched to the target flashing strategy is a dedicated firmware flashing tool selected from a preset tool library based on the execution mode, device platform characteristics, and other rules defined in the target flashing strategy. The target flashing tool must be compatible with the target device's hardware platform and the execution requirements (such as fast flashing or secure flashing) in the flashing strategy. The process of scheduling the target flashing tool matched to the target flashing strategy to perform the flashing operation through the target flashing channel involves using the target flashing channel as the data transmission carrier, calling the selected target flashing tool, and completing the transmission and flashing of firmware data from the flashing host to the target device according to the strategy rules. This process includes tool parameter configuration, data transmission link binding, and firmware flashing execution. The core is to ensure the compatibility between the tool and the channel and the accuracy of data transmission.

[0044] For example, the flashing script first extracts "Execution Mode: Fast Flash Mode" and "Device Platform: Brand A 865" from the target flashing strategy, and queries the preset tool library to find the corresponding target flashing tool, which is the MG flashing tool (MG_flash_tool). Then, the script configures the parameters of MG_flash_tool according to the "Communication Parameters: Baud Rate 115200, Protocol Type Universal Serial Bus Debug Mode" in the platform configuration, specifying that it communicates through the target flashing channel (such as the / dev / ttyUSB0 port). After the configuration is completed, the script calls the flashing interface of MG_flash_tool to transfer the decompressed firmware image to the target device through the target flashing channel. The tool performs firmware partition writing operations according to the rules of the fast flash mode until the entire flashing process is completed.

[0045] By implementing step 105, the flashing operation is performed by using a flashing tool that matches the target flashing channel scheduling and the target flashing strategy. This achieves automation and closed-loop control of the flashing process. The optimal tool combination can be automatically called according to the strategy, reducing manual intervention and configuration errors, improving flashing speed and consistency, and ensuring that the flashing process is completed smoothly in an efficient and safe environment.

[0046] In summary, the embodiments of this application can automatically obtain the environmental context information of the target device and determine a suitable flashing strategy based on a preset strategy matrix, thereby eliminating the need for manual selection of device type, tools, and parameters. This allows the flashing process to adapt to the actual environment, reducing the possibility of human error. By parsing the flashing package, the device identifier and platform configuration information are automatically extracted, enabling the identification of embedded devices of different brands, models, or platforms. This allows the same process to adapt to the flashing needs of multiple devices, reducing the repetitive development of scripts or tools. Before performing the flashing operation, a stable device link is established based on the device identifier and platform configuration. A dedicated flashing channel is established to ensure the correctness and consistency of the communication link, thereby reducing the risks of flashing interruption, identification errors, or data corruption. The flashing process is automatically determined through preset strategies, and flashing tools matching the target strategy are scheduled for execution. The entire process is intelligent and automated, reducing manual intervention time, shortening the flashing preparation and execution cycle, and improving efficiency when flashing batch devices. By combining a strategy matrix with a tool scheduling mechanism, the optimal flashing strategy and tools can be flexibly selected based on different device environments, interface states, and platform characteristics, enabling the system to maintain high efficiency, security, and stability even when facing complex and diverse device scenarios. In summary, the embedded device flashing method provided in this application, through environmental awareness, strategy matrix decision-making, automatic parsing, and channel establishment, achieves multi-platform adaptive flashing tool scheduling, thereby improving the automation, versatility, stability, and efficiency of the flashing process.

[0047] In some embodiments, the aforementioned environmental context information may include system load, number of concurrent devices, and available system tool versions; the aforementioned step 102 may include: quantifying and analyzing the system load, number of concurrent devices, and available system tool versions to obtain a target environment state vector; and selecting the flashing strategy with the highest matching degree as the target flashing strategy based on the matching degree between the target environment state vector and each flashing strategy in the preset strategy matrix, wherein the strategy matrix defines the mapping relationship between different environment state vectors and flashing strategies.

[0048] In some examples, system load refers to the resource usage status of the flashing host during the flashing process, mainly including indicators such as CPU utilization, memory usage, and I / O read / write speeds, reflecting the host's remaining processing capacity. It is obtained in real-time through system interfaces; for example, executing the `top` command to analyze CPU utilization (e.g., 25%), reading the ` / proc / meminfo` file to obtain memory usage (e.g., 30%), and using the `iostat` command to obtain I / O read / write speeds (e.g., 50MB / s). The number of concurrent devices is the total number of embedded devices currently physically connected to the flashing host and in a ready-to-flash state, used to assess the resource allocation requirements when multiple devices are flashed simultaneously. It is obtained by scanning the bus device list and counting using device management tools; for example, using the `lsusb` command to traverse USB devices, filtering out devices that meet the "ready-to-flash" characteristics, and counting the number (e.g., 3 devices). Available system tool versions are the version identifiers of the flashing-related tools already installed on the flashing host, used to determine the compatibility of the tools with the target device and the current environment. They can be obtained through the tool's built-in version query command; for example, executing "MG_flash_tool -- version" yields the version number (e.g., 2.1.0), and executing "upgrade_tool -v" yields the version number (e.g., 1.5.3). The target environment state vector is a standardized feature vector formed after quantifying and analyzing system load, number of concurrent devices, and available system tool versions, used to uniformly describe the current environment state. The quantification and analysis rules are preset by the system; for example, system load is divided into "≤30% low load (marked as L), 31%-70% medium load (marked as M), ≥71% high load (marked as H)"; the number of concurrent devices is divided into "≤5 devices few (marked as S), 6-10 devices medium (marked as M), ≥11 devices many (marked as L)"; and available system tool versions are marked as "compatible with the target device (C) (compatible), incompatible (N) (incompatible)". Based on this, if the system load is 25% (L), there are 3 concurrent devices (S), and MG_flash_tool version 2.1.0 (compatible, C), then the target environment state vector is (L, S, C). The strategy matrix defines the mapping relationship between different environment state vectors and flashing strategies. It is a structured data set, where the row dimension represents all possible combinations of environment state vectors, and the column dimension represents the key parameters of the flashing strategy (such as the number of parallel threads, tool selection priority, and execution mode). Each cell stores the optimal strategy for the corresponding environment.The process of selecting the flashing strategy with the highest matching degree based on the matching degree between the target environment state vector and each flashing strategy in the preset strategy matrix is ​​to calculate the similarity between the target vector and each entry of the environment vector in the strategy matrix using a preset algorithm, and select the strategy corresponding to the entry with the highest similarity. The matching degree calculation can use algorithms such as rule matching (e.g., a perfect match results in a matching degree of 100%, and partial matches are calculated according to weight) or cosine similarity. For example, if the matching degree between the target vector (L, S, C) and the vector (L, S, C) in the matrix is ​​100%, and the matching degree with (L, M, C) is 80%, then the strategy corresponding to the former is selected.

[0049] For example, the flashing script first calls the quantization module to convert the collected system load of 25% (mapped to L), concurrent devices of 3 (mapped to S), and MG_flash_tool version 2.1.0 (mapped to C) into a target environment state vector (L, S, C). Then, the script reads the XML file of the preset strategy matrix and iterates through the environment vectors corresponding to all strategy entries. It calculates the matching degree between the target vector and each entry vector through a rule matching algorithm and finds that a certain entry vector is (L, S, C) with a matching degree of 100%. Finally, the script determines the strategy corresponding to this entry (such as "parallel thread count 4, prioritize using MG_flash_tool, execute fast flashing mode") as the target flashing strategy and stores it in a system variable for subsequent steps to call.

[0050] By implementing the above embodiments, environmental context information is introduced and quantified to form an environmental state vector. This enables the dynamic selection of the optimal flashing strategy under different production or testing environments. It has environmental awareness and adaptive capabilities and can automatically adjust the strategy under high load, multiple device parallelism, or tool version differences, thereby improving the overall stability and execution efficiency of the system. It can effectively reduce task conflicts, timeouts, or abnormal interruptions caused by environmental changes.

[0051] In some embodiments, step 103 may include: determining the number of parallel processing threads for decompressing the flashing package based on the resource allocation strategy in the target flashing strategy; performing parallel decompression processing on the flashing package based on the determined number of parallel processing threads to obtain a decompressed file; performing integrity verification on the file structure of the decompressed file based on the preset verification algorithm specified in the target flashing strategy; after the integrity verification is passed, extracting the device identifier from the decompressed file using the parsing engine specified in the target flashing strategy; querying the preset configuration mapping library based on the device identifier to obtain the corresponding platform configuration, wherein the platform configuration may include the device communication protocol type and configuration parameters.

[0052] In some examples, the resource allocation strategy in the target flashing policy is a set of rules defined within the target flashing policy to guide the system in allocating hardware resources (such as CPU threads and memory space). Its core is to determine the resource allocation ratio based on the current environmental state (such as system load and the number of concurrent devices) to balance flashing efficiency and system stability. It is obtained by extracting from the target flashing policy; for example, if the policy specifies that "when the system load is ≤30%, allocate 4 CPU threads for decompressing the flashing package; when the system load is 31%-70%, allocate 2 CPU threads," this rule belongs to the resource allocation strategy. The number of parallel processing threads used for decompressing the flashing package is the number of CPU threads used for parallel decompression of the flashing package, determined based on the resource allocation strategy. Its purpose is to improve decompression efficiency through multi-threaded parallel processing. Based on a predetermined number of parallel processing threads, the flashing package is decompressed in parallel to obtain the decompressed files. This process involves calling a multi-threaded decompression tool to perform the decompression operation on the flashing package according to the predetermined number of threads, ultimately resulting in a decompressed directory containing firmware files, configuration files, and other content. For example, for the rom_865.zip flashing package, the pigz tool is called with 4 threads to execute the command "pigz -d -p 4 rom_865.zip", resulting in a decompressed directory "rom_865" containing version.txt and firmware.img. The preset verification algorithm specified in the target flashing strategy is a predefined algorithm used to verify the integrity of the decompressed files. Its function is to ensure that the decompressed files are not corrupted or tampered with, and may include cyclic redundancy check, Secure Hash Algorithm 256 (SHA256), etc.

[0053] The process of verifying the integrity of the decompressed file structure based on the preset verification algorithm specified in the target flashing strategy involves calculating the checksum (such as CRC value or hash value) of the decompressed file using the preset verification algorithm and comparing it with the preset checksum stored in the flashing package. If they match, the verification passes; otherwise, the file is considered corrupted. For example, for the decompressed "firmware.img", the checksum calculated using the CRC32 algorithm is "0x123456", which matches "firmware.img:0x123456" recorded in checksum.txt, meaning the verification passes. The parsing engine specified in the target flashing strategy is the tool or program used to extract the device identifier from the decompressed file, as defined in the strategy. It must support parsing key fields of specific format files (such as the text file version.txt). Common parsing engines include text processing tools (awk) and script parsers (such as Python script parsing). For example, if the strategy specifies "use awk tool to parse version.txt to obtain the device identifier", then the parsing engine is awk.

[0054] After integrity verification is passed, the process of extracting the device identifier from the decompressed file using the parsing engine specified in the target flashing strategy involves calling the parsing engine to read the characteristic file (such as version.txt) within the decompressed file and extracting the key field identifying the device model. This is achieved by the parsing engine performing the extraction operation; for example, executing the command "awk ' / device_model / {print $2}' version.txt" using the awk tool will extract the device identifier "865" from the entry "device_model:865". The process of querying the preset configuration mapping library based on the device identifier to obtain the corresponding platform configuration involves using the extracted device identifier as the query key to search the preset configuration mapping library (a structured database storing the correspondence between device identifiers and platform configurations) to obtain the platform configuration matching the device. This is achieved through a database query; for example, if "865" in the preset configuration mapping library corresponds to "Brand A 865 platform configuration", then querying "865" will retrieve that configuration. The device communication protocol type is the communication standard followed when the target device and the flashing host transmit data. Common types include Universal Serial Bus debug mode and Universal Asynchronous Receiver / Transmitter (UART) protocol. Configuration parameters are the specific parameters that support the normal operation of the communication protocol, including baud rate (e.g., 115200), data bits (e.g., 8 bits), and parity bits (e.g., no parity).

[0055] For example, the flashing script reads the resource allocation policy "4 threads for low system load" from the target flashing policy, determines the number of parallel processing threads to be 4; calls the pigz tool to perform parallel decompression of rom_865.zip with 4 threads, obtaining a decompressed directory containing version.txt and firmware.img; calculates the checksum value of the decompressed file according to the CRC32 algorithm specified by the policy and compares it with checksum.txt. After verification, it uses the awk tool to parse version.txt to extract the device identifier "865"; finally, it queries the preset configuration mapping library to obtain the platform configuration corresponding to "865" (device communication protocol type is USBDebug, configuration parameter is baud rate 115200), and completes the parsing process.

[0056] Through the implementation of the above embodiments, the parallel decompression, integrity verification, and automatic parsing mechanism guided by the standard flashing strategy achieves a balance between high efficiency and high reliability in the flashing package parsing stage; parallel processing improves the decompression speed and shortens the preparation time; a preset verification algorithm ensures the integrity of the decompressed file, effectively preventing flashing failures caused by firmware corruption or content loss; at the same time, automatic extraction of device identifiers and matching of platform configurations can accurately identify embedded devices of different models and platforms, thereby improving device compatibility, reducing manual configuration errors, and further improving flashing accuracy and success rate.

[0057] In some embodiments, step 104 may include: initializing the corresponding device communication protocol stack based on the device communication protocol type in the platform configuration; sending a device discovery request through the bus of the device communication protocol stack and listening to the device response signal on the bus, wherein the device discovery request includes a device identifier; determining the target device port from multiple candidate ports based on the strength and timing characteristics of the device response signal; and establishing a communication link with the target device on the target device port as the target flashing channel.

[0058] In some examples, the device communication protocol type in the platform configuration is a standardized communication rule type defined in the platform configuration, which determines the data transmission format, timing, and error correction mechanism when the target device and the flashing host interact with data. The device communication protocol stack is a collection of software modules that implement a specific device communication protocol. It is functionally layered (e.g., physical layer, data link layer, application layer) to jointly complete the communication process specified by the protocol. For example, the USB Debug protocol stack includes a driver module responsible for physical layer signal processing, a protocol module for data encapsulation at the data link layer, and an interface module for application layer instruction parsing. Initializing the corresponding device communication protocol stack is the process of activating the device communication protocol stack from a dormant state to an available state. This includes loading the drivers that the protocol stack depends on, allocating memory resources, and initializing port parameters to ensure that the protocol stack can send and receive data normally. The bus of the device communication protocol stack is the physical transmission medium or logical channel used by the device communication protocol stack to connect the flashing host and external devices. It provides the underlying carrier for data transmission for the protocol stack. For example, the bus of the USB Debug protocol stack is a Universal Serial Bus, and the bus of the UART protocol stack is a Serial Bus. The acquisition method is automatic binding during protocol stack initialization; for example, after the USB Debug protocol stack is initialized, it is bound to the USB physical bus of the flashing host by default. The device discovery request is a signal data packet sent by the flashing host through the device communication protocol stack bus to find the target device. It contains a device identifier (such as "865") to ensure that only the target device responds. The device discovery request packet can contain a header (identifying the request type), a data segment (device identifier), and a checksum segment (ensuring correct transmission). The device response signal is an acknowledgment signal data packet returned by the target device through the device communication protocol stack bus after receiving the device discovery request. It contains a matching result for the device identifier (such as "ack:865") to inform the flashing host that it matches the characteristics of the target device. The format of the response signal corresponds to the device discovery request to ensure that the flashing host can parse it. The strength characteristics of the device's response signal are indicators of the stability of the response signal; for example, the bit error rate (e.g., 0.1%) and the fluctuation range of the signal amplitude (e.g., ±5%) during signal transmission reflect the reliability of signal transmission; the timing characteristics are time-related indicators of the response signal; for example, the delay time from sending a request to receiving a response (e.g., 50 milliseconds) and the jitter value of signal transmission (e.g., ±2 milliseconds) reflect the real-time performance of signal transmission.

[0059] The process of determining the target device port from multiple candidate ports based on the strength and timing characteristics of the device's response signals involves comparing the strength and timing characteristics of the response signals from all candidate ports that return response signals (such as / dev / ttyUSB0 and / dev / ttyUSB1), and selecting the port with the optimal characteristics (such as the lowest bit error rate and the lowest latency) as the port for communication with the target device. For example, if the response signal bit error rate of candidate port / dev / ttyUSB0 is 0.1% and the latency is 50 milliseconds, which is better than the bit error rate of / dev / ttyUSB1 (1%) and the latency is 100 milliseconds, then / dev / ttyUSB0 is determined as the target device port. The process of establishing a communication link with the target device on the target device port, serving as the target flashing channel, involves establishing a continuous bidirectional data transmission connection on the determined target device port through the device communication protocol stack, and encapsulating this connection into a standardized interface (such as a stream interface) for subsequent flashing operations to transmit firmware data and control commands. The method of obtaining it is to execute the link activation command through the protocol stack; for example, on the / dev / ttyUSB0 port, the "link_activate" command is sent through the USB Debug protocol stack, and after handshaking with the target device, a target flashing channel based on that port is generated.

[0060] For example, the flashing script reads the device communication protocol type as USB Debug from the platform configuration, calls the "modprobeusb_debug" command to initialize the corresponding USB Debug protocol stack, which is automatically bound to the flashing host's USB bus; then, the script generates a device discovery request containing the device identifier "865" and sends it to all connected devices via the USB bus; after listening to the response signal on the bus, it parses the response characteristics of candidate ports / dev / ttyUSB0 and / dev / ttyUSB1, among which / dev / ttyUSB0 has a bit error rate of 0.1% and a latency of 50 milliseconds, and its characteristics are better; finally, the script activates the communication link on the / dev / ttyUSB0 port through the USB Debug protocol stack, generating the target flashing channel for subsequent firmware data transmission.

[0061] Through the implementation of the above embodiments, communication links are automatically established and flashing channels are generated based on device identification and platform configuration, which can ensure the reliability and stability of device connection during the flashing process; the corresponding communication protocol stack can be automatically initialized according to the platform protocol type, and the target device port can be intelligently identified, thereby avoiding the risk of manual port selection or connection errors; especially in multi-port parallel or complex bus structure environments, the target device can be accurately located through signal strength and timing characteristics, which can reduce flashing interruption problems caused by link abnormalities or identification errors, and improve the overall execution continuity and reliability.

[0062] In some embodiments, the aforementioned sending of device discovery requests via the bus of the device communication protocol stack may include: determining a preset set of ports connected to the target device based on historical flashing record data, wherein the ports in the preset set are arranged in priority order; and sending device discovery requests sequentially to the devices corresponding to the preset set of ports via the bus of the device communication protocol stack.

[0063] In some examples, historical flashing records are a collection of historical information related to the connection with the target device recorded during past flashing operations. This includes the target device identifier, successfully connected port names, connection times, and connection success rates, reflecting the port connection patterns of the target device. The preset port set is a list of ports that may connect to the target device, filtered from historical flashing records. The ports are arranged in priority order; priority can be determined based on historical connection success rates (e.g., percentage of successful connections) or recent connection times (e.g., higher priority for closer connections). This set is generated by the system after statistical analysis of historical flashing records. For example, for device identifier "865," statistics show that the historical connection success rate of / dev / ttyUSB0 is 90% (higher than / dev / ttyUSB1's 60%), then the preset port set is { / dev / ttyUSB0 (priority 1), / dev / ttyUSB1 (priority 2)}. The system can send discovery requests containing device identifiers to the devices corresponding to a predefined port set, starting with the highest priority port, through the device communication protocol stack bus (such as a Universal Serial Bus). If a device at a given port returns a valid response, subsequent transmissions stop; otherwise, transmissions continue to the next lower priority port. This is achieved by a system script calling the protocol stack's transmission interface in priority order. For example, for the predefined port set { / dev / ttyUSB0 (priority 1), / dev / ttyUSB1 (priority 2)}, a discovery request containing "865" is first sent to the device corresponding to / dev / ttyUSB0 via the USB bus. If no response is received, the same request is then sent to the device corresponding to / dev / ttyUSB1.

[0064] For example, the flashing script first reads historical flashing records for device identifier "865" from the history database, calculates the connection success rate of / dev / ttyUSB0 to be 90% and the connection success rate of / dev / ttyUSB1 to be 60%, and generates a preset port set { / dev / ttyUSB0 (priority 1), / dev / ttyUSB1 (priority 2)} arranged by priority; then, the script sends a device discovery request containing "865" to the device corresponding to / dev / ttyUSB0 through the USB bus of the USB Debug protocol stack, listens for 1 second and receives a matching response signal from the device; the script stops sending requests to subsequent ports, confirms / dev / ttyUSB0 as a candidate port to be verified, and continues to execute the subsequent port determination process.

[0065] By implementing the above embodiments, the priority port set for device connection is determined by combining historical flashing record data, which further optimizes the search efficiency and connection success rate during the device discovery phase. This historical data-driven port priority mechanism can significantly reduce the number of invalid port probes, shorten the device identification time, and effectively improve the overall system throughput in batch device flashing or automated testing scenarios. It can also adapt to the differences in different production lines or hardware environments, making the device discovery process more efficient and intelligent.

[0066] In some embodiments, step 105 may include: selecting a target flashing tool from a preset tool library based on the execution mode defined in the target flashing strategy, wherein the execution mode may include a fast flashing mode, a secure flashing mode, and a debug flashing mode; configuring the target flashing tool to run according to the device communication parameters in the platform configuration to obtain a flashing session adapted to the platform configuration; establishing a data bridge with the target flashing channel based on the flashing session to form a real-time data stream interface that supports bidirectional communication; performing the flashing operation through the real-time data stream interface, and verifying and adjusting the data transmission integrity in real time based on the preset monitoring rules in the target flashing strategy during the execution process.

[0067] In some examples, the execution mode defined in the target flashing strategy is the operating method of the flashing operation specified in the target flashing strategy. It determines the tool's behavior logic based on the needs of the flashing scenario (such as efficiency, security, and debugging requirements), and is the core basis for selecting the target flashing tool; it can be extracted from the target flashing strategy. For example, in the target flashing strategy for a Brand A 865 device, the execution mode might be defined as "fast flashing mode." The preset tool library is a collection of pre-integrated embedded device flashing tools stored in the system. Tools are categorized by device platform and supported execution modes, and include the tool's executable file, configuration template, and version information. Tools that support the execution mode and are compatible with the target device platform can be selected from the preset tool library based on the characteristics of the execution mode (such as speed and security). For example, if the execution mode is "fast flashing mode" and the device platform is Brand A 865, MG_flash_tool, which supports this mode and platform, can be selected from the preset tool library as the target flashing tool. The fast flashing mode is an execution mode focused on improving flashing speed. It achieves efficient flashing by reducing unnecessary verification steps (such as simplifying partition verification) and using high-speed data transmission protocols, making it suitable for mass production scenarios. The secure flashing mode prioritizes flashing security, adding multiple verifications (such as partition integrity verification and firmware signature verification) and fault tolerance mechanisms, making it suitable for production device deployment. The debug flashing mode focuses on supporting troubleshooting, retaining detailed log output (such as return codes for each operation) and allowing breakpoint resumption, making it suitable for R&D debugging scenarios. The device communication parameters in the platform configuration are specific parameters defined in the platform configuration that support the normal operation of the device communication protocol, including baud rate (such as 115200 bits per second), data bits (such as 8 bits), stop bits (such as 1 bit), and parity method (such as no parity), ensuring communication compatibility between the flashing tool and the target device. A platform-compatible flashing session is a running instance of the target flashing tool that matches the communication parameters in the platform configuration after parameter configuration. It includes the tool's startup parameters, communication interface binding information, etc., ensuring the tool can function correctly through the target device's communication protocol. For example, executing the command "MG_flash_tool --baud115200 –data -bits8" on MG_flash_tool generates a platform-compatible flashing session. The real-time data stream interface is a bidirectional data transmission interface connecting the flashing session and the target flashing channel. It supports the transmission of firmware data from the flashing host to the target device, as well as feedback on flashing status (such as progress and error codes) from the target device to the flashing host, ensuring real-time and bidirectional data transmission. Data bridging can be established through system calls. For example, binding the output stream of the flashing session to the input stream of the target flashing channel (such as / dev / ttyUSB0), and simultaneously binding the channel's output stream to the session's input stream, forms a real-time data stream interface.The process of establishing a data bridge with the target flashing channel based on the flashing session, forming a real-time data stream interface supporting bidirectional communication, is achieved through a system-level data stream redirection mechanism. This binds the input and output of the flashing session with the port of the target flashing channel, allowing tool commands and data to be transmitted to the target device through the channel, while the device's response is fed back to the tool in real time. This is achieved by executing a data stream binding command; for example, after configuring the port using "stty -F / dev / ttyUSB0115200", the "tee" command directs the flashing session's output to that port, while simultaneously feeding back the port's input to the session, forming a bidirectional interface. Firmware data can be sent to the target device through the real-time data stream interface, while simultaneously checking the data integrity according to preset monitoring rules (such as performing a check every 1MB of data transmitted). If an anomaly is detected (such as a check failure), the transmission parameters are adjusted according to the rules (such as reducing the baud rate) to ensure a stable flashing process. The acquisition method is that the tool automatically executes according to the rules; for example, when MG_flash_tool transmits firmware.img through the real-time data stream interface, it triggers cyclic redundancy check every 1MB transmitted. If the check fails, the baud rate is adjusted from 115200 to 57600 and then retried.

[0068] Through the implementation of the above embodiments, by utilizing flashing tools that match the target flashing strategy and platform configuration, deep adaptation between flashing tools and device characteristics is achieved. The optimal tool can be flexibly selected based on the execution mode (e.g., fast, safe, debug), and automatic configuration is performed based on communication parameters, forming a highly adaptable flashing session. Two-way communication and status synchronization are achieved through a real-time data stream interface, allowing dynamic monitoring and real-time feedback of data transmission during the flashing process. This mechanism effectively improves flashing stability and process transparency, reducing the error rate caused by tool incompatibility or transmission anomalies in batch flashing or remote control environments.

[0069] In some embodiments, the aforementioned flashing operation performed via a real-time data stream interface, and the real-time verification and feedback adjustment of data transmission integrity based on preset monitoring rules in the target flashing strategy during execution, may include: capturing flashing data packets transmitted via the real-time data stream interface through a data acquisition agent deployed in the flashing session; performing cyclic redundancy check on the flashing data packets based on preset verification rules in the target flashing strategy to generate a verification result; when the verification result indicates a transmission anomaly, reconstructing the transmission configuration of the real-time data stream interface based on adjustment parameters corresponding to the verification result; and performing the flashing operation via the real-time data stream interface based on the reconstructed transmission configuration.

[0070] In some examples, the data acquisition agent deployed in the flashing session is a lightweight data capture program integrated within the flashing session. Its role is to monitor and record all data transmitted via the real-time data stream interface in real time, including firmware data packets sent from the flashing host to the target device, and status feedback packets returned from the target device. The flashing data packets transmitted via the real-time data stream interface are structured data blocks containing firmware content transmitted between the flashing host and the target device through the real-time data stream interface. They typically consist of a data header (containing data packet number and length), a data body (firmware fragment data), and a checksum field (temporary checksum value), which can be captured by the data acquisition agent during transmission in the real-time data stream interface; for example, for the firmware file firmware.img, after being fragmented into 1MB pieces, they form "Data Packet 1 (Number 001, Length 1MB, Data Body is the first 1MB of firmware content)" and "Data Packet 2 (Number 002, Length 1MB, Data Body is the 1st-2nd MB of firmware content)", etc. The preset verification rules in the target flashing strategy are predefined conditions and standards used to determine the integrity of data transmission. These include the timing of verification triggering (e.g., triggering verification once every 1MB of data transmitted), the verification algorithm (e.g., cyclic redundancy check), and the anomaly judgment threshold (e.g., considering two consecutive verification failures as a transmission anomaly). The verification result is the judgment result obtained after performing the preset verification rules (e.g., CRC check) on the flashing data packet, used to indicate whether the data packet transmission is complete. It usually includes two states: "verification passed" (data complete) and "verification failed" (data corrupted or lost). According to the requirements of the preset verification rules, the CRC algorithm can be called to calculate the verification value of the flashing data packet captured by the data acquisition agent. The obtained verification value is compared with the preset verification value carried in the data packet, and finally the result of "verification passed" or "verification failed" is output. For example, according to the rule "verify once every 1MB", when the data acquisition agent captures a 1MB data packet, it calls the CRC32 algorithm to calculate the verification value of the data packet and compares it with the "preset CRC32 value: 0xABC123" in the data packet header. If they match, the result of "verification passed" is generated. When the verification result is "verification failed" and the anomaly threshold is reached (e.g., two consecutive failures), the system queries the target flashing strategy for the adjustment parameters corresponding to this anomaly (e.g., reducing the baud rate, increasing the number of retries, adjusting the data packet size), and reconfigures the transmission attributes of the real-time data stream interface according to the parameters (e.g., adjusting the baud rate from 115200 to 57600). This is obtained by querying the anomaly handling rules in the strategy; for example, if the strategy specifies that "when two consecutive CRC checks fail, the baud rate is reduced to 50% of its original value, and the data packet size is adjusted to 512KB," then the interface configuration is reconfigured according to these parameters.After the transmission configuration (such as baud rate and data packet size) of the real-time data stream interface is updated, the remaining flashing data packets will continue to be transmitted through this interface to ensure more stable data transmission under the adjusted configuration. For example, if the reconstructed configuration is "baud rate 57600, data packet size 512KB", then the data packets that failed to be verified will be resent according to this configuration, and subsequent data will continue to be transmitted.

[0071] For example, the flashing script deploys a data acquisition agent in the flashing session of MG_flash_tool. This agent captures flashing data packets transmitted via the / dev / ttyUSB0 interface in real time. When a 1MB data packet is captured, the system calls the CRC32 algorithm for verification according to preset verification rules. If the first verification fails, it will retry. If it fails again, it is determined to be a transmission anomaly. Subsequently, the system queries the corresponding adjustment parameters in the strategy, "baud rate adjusted to 57600, data packet size 512KB", and reconstructs the transmission configuration of the real-time data stream interface. Finally, the data packet is resent based on the new configuration. The data acquisition agent continues to capture and verify the subsequent 512KB data packets until all firmware data transmission is completed.

[0072] By implementing the above embodiments, deploying a data acquisition agent and performing real-time cyclic redundancy checks during the flashing session enables dynamic quality monitoring and adaptive adjustment of flashing data transmission. When transmission anomalies are detected, the transmission configuration of the data stream interface can be automatically reconstructed to ensure data integrity and flashing continuity. This real-time verification and feedback mechanism not only prevents flashing failures caused by communication jitter or link instability but also guarantees transmission quality in complex network or multi-device environments, thereby significantly improving the flashing success rate and overall system reliability.

[0073] Furthermore, as an implementation of the foregoing method embodiments, this application also provides an embedded device flashing apparatus for implementing the foregoing method embodiments. This apparatus embodiment corresponds to the foregoing method embodiments. For ease of reading, this embedded device flashing apparatus embodiment will not repeat the details of the foregoing method embodiments one by one, but it should be understood that the apparatus in this application embodiment can correspondingly implement all the contents of the foregoing method embodiments. For example... Figure 2As shown, the embedded device flashing device 20 includes: a data acquisition unit 201, a strategy determination unit 202, a flashing parsing unit 203, a channel establishment unit 204, and a flashing execution unit 205. The data acquisition unit 201 acquires the environmental context information of the target device and the flashing package path provided by the user. The strategy determination unit 202 determines the target flashing strategy from a preset strategy matrix based on the environmental context information. The flashing parsing unit 203 parses the flashing package according to the target flashing strategy to extract the device identifier and platform configuration. The channel establishment unit 204 establishes a device link based on the device identifier and platform configuration to generate a target flashing channel. The flashing execution unit 205 schedules a target flashing tool matching the target flashing strategy to perform the flashing operation through the target flashing channel.

[0074] This application also provides a computer-readable storage medium storing computer-executable instructions or computer programs that, when executed by a processor, will cause the processor to perform any step of the embedded device flashing method provided in this application.

[0075] In some embodiments, the computer-readable storage medium may be a memory such as an access memory, a read-only memory (ROM), flash memory, a magnetic surface memory, an optical disc, or a compact disc read-only memory (CD-ROM); or it may be a variety of devices including one or any combination of the above-mentioned memories.

[0076] In some embodiments, computer-executable instructions may take the form of programs, software, software modules, scripts, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as stand-alone programs or as modules, components, subroutines, or other units suitable for use in a computing environment.

[0077] In some embodiments, computer-executable instructions may, but do not necessarily, correspond to files in a file system, and may be stored as part of a file that holds other programs or data; for example, stored in one or more scripts in a HyperText Markup Language (HTML) document, stored in a single file dedicated to the program in question, or stored in multiple co-located files (e.g., files that store one or more modules, subroutines, or code sections).

[0078] In some embodiments, computer-executable instructions may be deployed to execute on an electronic device, or on multiple electronic devices located at one location, or on multiple electronic devices distributed across multiple locations and interconnected via a communication network.

[0079] like Figure 3 As shown, this application also provides an electronic device 30, including a memory 310, a processor 320, and a computer program 311 stored in the memory 310 and executable on the processor. When the processor 320 executes the computer program 311, it implements any step of the above-described embedded device flashing method.

[0080] This application also provides a computer program product comprising a computer program or computer-executable instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer program or computer-executable instructions from the computer-readable storage medium and executes the computer program or computer-executable instructions, causing the electronic device to perform any step of the embedded device flashing method described above.

[0081] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for flashing an embedded device, characterized in that, include: Obtain the target device's environmental context information and the path to the flashing package provided by the user; The environmental context information includes system load, number of concurrent devices, and available system tool versions; Based on the environmental context information, the target flashing strategy is determined from the preset strategy matrix; According to the target flashing strategy, the flashing package is parsed to extract the device identifier and platform configuration; Based on the device identifier and the platform configuration, a device link is established to generate a target flashing channel; Through the target flashing channel, a target flashing tool that matches the target flashing strategy is scheduled to perform the flashing operation; The step of determining the target flashing strategy from the preset strategy matrix based on the environmental context information includes: The system load, the number of concurrent devices, and the available system tool versions are quantified and analyzed to obtain the target environment state vector; Based on the matching degree between the target environment state vector and each flashing strategy in the preset strategy matrix, the flashing strategy with the highest matching degree is selected as the target flashing strategy. The strategy matrix defines the mapping relationship between different environment state vectors and flashing strategies. The step of scheduling a target flashing tool that matches the target flashing strategy to perform the flashing operation through the target flashing channel includes: Based on the execution mode defined in the target flashing strategy, the target flashing tool is selected from the preset tool library, wherein the execution mode includes fast flashing mode, safe flashing mode and debug flashing mode; Based on the device communication parameters in the platform configuration, the target flashing tool is configured to run, resulting in a flashing session that is compatible with the platform configuration. Based on the flashing session, a data bridge is established with the target flashing channel to form a real-time data stream interface that supports bidirectional communication; The flashing operation is performed through the real-time data stream interface, and during the execution process, the integrity of data transmission is verified and adjusted in real time based on the preset monitoring rules in the target flashing strategy.

2. The embedded device flashing method according to claim 1, characterized in that, The step of parsing the flashing package according to the target flashing strategy to extract the device identifier and platform configuration includes: Based on the resource allocation strategy in the target flashing strategy, determine the number of parallel processing threads used for decompressing the flashing package; Based on the determined number of parallel processing threads, the flashing package is decompressed in parallel to obtain a decompressed file; Based on the preset verification algorithm specified in the target flashing strategy, the integrity of the file structure of the decompressed file is verified. After the integrity verification is passed, the device identifier is extracted from the decompressed file using the parsing engine specified in the target flashing strategy; Based on the device identifier, a preset configuration mapping library is queried to obtain the corresponding platform configuration, wherein the platform configuration includes the device communication protocol type and configuration parameters.

3. The embedded device flashing method according to claim 1, characterized in that, The step of establishing a device link based on the device identifier and the platform configuration to generate a target flashing channel includes: Initialize the corresponding device communication protocol stack based on the device communication protocol type in the platform configuration; A device discovery request is sent through the bus of the device communication protocol stack, and the device response signal on the bus is listened for, wherein the device discovery request contains the device identifier; Based on the strength and timing characteristics of the device response signal, the target device port is determined from multiple candidate ports; A communication link is established with the target device on the target device port, serving as the target flashing channel.

4. The embedded device flashing method according to claim 3, characterized in that, Sending a device discovery request via the bus of the device communication protocol stack includes: Based on historical flashing record data, a preset set of ports connected to the target device is determined, wherein the ports in the preset set are arranged in order of priority; The device discovery request is sent sequentially to the devices corresponding to the preset port set via the bus of the device communication protocol stack.

5. The embedded device flashing method according to any one of claims 1-4, characterized in that, The process of performing the flashing operation through the real-time data stream interface, and during the execution, verifying and adjusting the integrity of data transmission in real time based on the preset monitoring rules in the target flashing strategy, includes: The flashing data packets transmitted via the real-time data stream interface are captured by the data acquisition agent deployed in the flashing session; Based on the preset verification rules in the target flashing strategy, a cyclic redundancy check is performed on the flashing data packet to generate a verification result. When the verification result indicates a transmission anomaly, the transmission configuration of the real-time data stream interface is reconstructed based on the adjustment parameters corresponding to the verification result. Based on the reconstructed transmission configuration, the flashing operation is performed through the real-time data stream interface.

6. An embedded device flashing device, characterized in that, include: The data acquisition unit is used to acquire the environmental context information of the target device and the path to the flashing package provided by the user; The environmental context information includes system load, number of concurrent devices, and available system tool versions; The strategy determination unit is used to determine the target flashing strategy from the preset strategy matrix based on the environmental context information; The flashing parsing unit is used to parse the flashing package according to the target flashing strategy and extract the device identifier and platform configuration. The channel establishment unit is used to establish a device link based on the device identifier and the platform configuration in order to generate a target flashing channel; The flashing execution unit is used to schedule a target flashing tool that matches the target flashing strategy to perform a flashing operation through the target flashing channel; The step of determining the target flashing strategy from the preset strategy matrix based on the environmental context information includes: The system load, the number of concurrent devices, and the available system tool versions are quantified and analyzed to obtain the target environment state vector; Based on the matching degree between the target environment state vector and each flashing strategy in the preset strategy matrix, the flashing strategy with the highest matching degree is selected as the target flashing strategy. The strategy matrix defines the mapping relationship between different environment state vectors and flashing strategies. The step of scheduling a target flashing tool that matches the target flashing strategy to perform the flashing operation through the target flashing channel includes: Based on the execution mode defined in the target flashing strategy, the target flashing tool is selected from the preset tool library, wherein the execution mode includes fast flashing mode, safe flashing mode and debug flashing mode; Based on the device communication parameters in the platform configuration, the target flashing tool is configured to run, resulting in a flashing session that is compatible with the platform configuration. Based on the flashing session, a data bridge is established with the target flashing channel to form a real-time data stream interface that supports bidirectional communication; The flashing operation is performed through the real-time data stream interface, and during the execution process, the integrity of data transmission is verified and adjusted in real time based on the preset monitoring rules in the target flashing strategy.

7. An electronic device, comprising: A memory and a processor, characterized in that the processor, when executing a computer program stored in the memory, implements the steps of the embedded device flashing method as described in any one of claims 1 to 5.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the embedded device flashing method as described in any one of claims 1 to 5.

Images