A method for multi-sensor data transmission in embedded devices

Abstract

The application provides a multi-sensor data transmission method in an embedded device, which comprises the following steps: when an embedded device system layer is initialized, a global data channel is created, a lightweight process corresponding to each sensor is created, and a channel basic information structure body, a lightweight process binding structure body and a data transmission control structure body are constructed; the channel unique identifier and the process identifier are filled in the lightweight process binding structure body, and a one-way association with the channel basic information structure body is established; each sensor collects data at a preset period, encapsulates the data into a uniform format data block by the corresponding lightweight process, calculates a check code and updates the data transmission control structure body; the lightweight process transmits the data block to a buffer area bound with the data transmission control structure body through the global data channel in a non-blocking mode, a master lightweight process reads the data block from the buffer area, and if the data block passes the check, the data block is classified and processed, and if the data block fails the check, retransmission is triggered, thereby solving the technical problems of resource occupation and the like.

Description

Technical Field

[0001] This application relates to the field of embedded device technology, and more specifically, to a multi-sensor data transmission method in an embedded device. Background Technology

[0002] Embedded devices are widely used in industrial automation, intelligent monitoring, and IoT terminals. These devices typically integrate multiple sensors, such as temperature, humidity, pressure, and position sensors, to collect environmental parameters or equipment operating status data in real time. Efficient data transmission and reliable reception directly impact the accuracy of control decisions and the stability of operation for embedded devices. As application scenarios increasingly demand higher data acquisition frequencies and more sensors, the resource utilization, real-time performance, and integrity of multi-sensor data transmission have become key technical requirements.

[0003] In existing multi-sensor data transmission schemes, a typical implementation is to allocate an independent physical transmission channel to each sensor and adopt a blocking transmission mechanism. After the sensor collects data, it sends it directly to the processing unit in its original format. During the transmission process, it must wait for the previous frame of data to be fully received before the next frame of data can be transmitted. Furthermore, no unified data verification and format specifications are set.

[0004] In this existing solution, the configuration of independent physical channels leads to a high system hardware resource utilization rate, and channel contention is prone to occur when multiple sensors transmit data simultaneously. The blocking transmission mode results in low data transmission efficiency and significant transmission delays in high-frequency acquisition scenarios, failing to meet real-time requirements. The lack of a unified data format and verification mechanism leads to incompatibility between different sensor data formats, and data errors or losses caused by interference during transmission cannot be identified, reducing the reliability of data transmission and making it difficult to adapt to application scenarios where embedded devices have limited resources and high requirements for transmission stability. Summary of the Invention

[0005] To address the aforementioned technical problems, this application provides a multi-sensor data transmission method in an embedded device, which can at least alleviate the aforementioned technical problems.

[0006] The technical solutions provided in this application are as follows:

[0007] A method for transmitting multi-sensor data in an embedded device, comprising:

[0008] Step 1: During the initialization of the embedded device system layer, create a global data channel and a lightweight process corresponding to each sensor, and construct a channel basic information structure, a lightweight process binding structure, and a data transmission control structure.

[0009] Step 2: Fill in the channel unique identifier and process identifier into the lightweight process binding structure and establish a one-way association with the channel basic information structure;

[0010] Step 3: Each sensor collects data according to a preset cycle, which is then encapsulated into a data block of a unified format by the corresponding lightweight process, and the check code is calculated and updated to the data transmission control structure.

[0011] Step 4: The lightweight process transmits the data block to the buffer bound to the data transmission control structure through the global data channel in non-blocking mode. The main control lightweight process reads the data block from the buffer. If the data block passes the verification, it is classified and processed. If it fails, a retransmission is triggered.

[0012] Optionally, step 1 includes:

[0013] Step 11: Create a global data channel. Assign a unique channel identifier through the created channel basic information structure, set the channel type to data channel, and set the initial running state to idle. The unique channel identifier is used for association and binding of lightweight processes.

[0014] Step 12: Create a lightweight process for each sensor and assign a unique process identifier. Initialize the created lightweight process binding structure. The unique process identifier will be associated with the unique channel identifier.

[0015] Step 13: Create a data transmission control structure and bind it to a global data channel. Configure the buffer address and preset buffer size. Initialize the transmission progress flag to "not started" and the checksum to 0. The global data channel bound to the data transmission control structure will synchronize the transmission status.

[0016] Optionally, step 13 includes:

[0017] Step 131: Query the embedded device's storage resources, allocate a dedicated buffer and record its starting address and storage capacity. The dedicated buffer serves as a buffer bound to the created data transmission control structure.

[0018] Step 132: Write the buffer address and preset buffer size into the corresponding fields of the data transmission control structure;

[0019] Step 133: Initialize the transmission progress marker to "not started", assign the checksum field to 0, and establish a bidirectional association between the data transmission control structure and the channel basic information structure to synchronize the transmission status feedback.

[0020] Optionally, step 2 includes:

[0021] Step 21: Fill in the associated channel identifier from the channel basic information structure and the unique process identifier of the corresponding lightweight process into the binding structure of each lightweight process, and set the read and write permissions to write only.

[0022] Step 22: The system layer verifies the uniqueness of the associated information in the structure bound to each lightweight process to avoid channel conflicts. The uniqueness verification ensures that the data is transmitted in the correct direction.

[0023] Step 23: Establish a one-way association between the lightweight process binding structure and the channel basic information structure, update the number of associated lightweight processes in the channel basic information structure to the total number of sensors, change the running status to occupied, and allow data to be written in the occupied status of the channel basic information structure.

[0024] Optionally, step 22 includes:

[0025] Step 221: The system layer traverses all lightweight process binding structures and extracts the combined information of the associated channel identifier and process identifier;

[0026] Step 222: Perform a uniqueness check on the combined information to avoid channel association conflicts. If duplicates are found, trigger a binding failure alarm.

[0027] Step 223: After the verification is passed, record the association mapping table of the binding structure of each lightweight process. The association mapping table will be used for transmission status query and verification.

[0028] Optionally, step 3 includes:

[0029] Step 31: Each sensor collects environmental or status data according to a preset cycle to form raw data, and transmits the raw data to the corresponding lightweight process;

[0030] Step 32: The lightweight process calls the data encapsulation interface to integrate the raw data, sensor number, and acquisition timestamp, and encapsulates them into a data block of a unified format according to the data transmission control structure field requirements.

[0031] Step 33: Calculate the checksum of the data block and update the checksum and data length to the corresponding field of the data transmission control structure.

[0032] Optionally, step 32 includes:

[0033] Step 321: Extract the sensor number and associate it with the unique process identifier of the corresponding lightweight process to ensure the uniqueness of the data block traceability;

[0034] Step 322: Obtain the system time to generate a collection timestamp, and sort and combine it with the raw data according to a preset format;

[0035] Step 323: Add data block header identifiers and tail check field placeholders to the original data after sorting and combining to form data blocks with a uniform format.

[0036] Optionally, step 4 includes:

[0037] Step 41: Each lightweight process initiates a transmission request to the global data channel based on the association between the lightweight process binding structure and the global data channel;

[0038] Step 42: In response to the transmission request, the channel basic information structure feeds back the real-time status of the buffer through bidirectional association with the data transmission control structure. If the buffer is not full, the lightweight process writes data blocks in non-blocking mode, updates the transmission progress mark to "transmission in progress", and marks it as "transmission completed" after the transmission is completed. The transmission progress mark will be synchronized to the channel basic information structure.

[0039] Step 43: After the main control lightweight process detects the transmission completion mark, it reads the data block from the buffer and verifies the integrity through the check code in the data transmission control structure. If the verification passes, it is classified and processed according to the sensor type. If the verification fails, the corresponding lightweight process is triggered to retransmit. At the same time, the system layer monitors the buffer occupancy rate and transmission status.

[0040] Optionally, step 43 includes:

[0041] Step 431: After the main control lightweight process reads the data block, it calculates the checksum and compares it with the checksum recorded in the data transmission control structure.

[0042] Step 432: If the verification is consistent, extract the original data, sensor number and timestamp from the data block, and sort them according to sensor type;

[0043] Step 433: The system layer queries the buffer occupancy rate in real time. When the preset threshold is reached, it notifies each lightweight process to pause the transmission. If the verification fails, the data block is marked as abnormal and an interrupt is triggered. The corresponding lightweight process is notified to retransmit. Pausing the transmission and retransmitting will respectively avoid buffer overflow and data loss.

[0044] The technical solution provided in this application has the following technical advantages:

[0045] During system initialization, a global data channel is created to replace traditional independent physical channels. Combined with lightweight processes corresponding to each sensor, this reduces channel resource consumption. Simultaneously, the constructed channel basic information structure, lightweight process binding structure, and data transmission control structure provide a standardized management framework for data transmission. The channel basic information structure achieves precise association between lightweight processes and the global data channel by assigning unique channel identifiers. The lightweight process binding structure establishes a dedicated association between each sensor process and the channel, avoiding channel conflicts during multi-sensor transmission. The data transmission control structure binds to the global data channel and configures buffer parameters, providing a unified interface for data storage and transmission status monitoring. Compared to the decentralized management of traditional solutions, this structured design improves the efficiency of system resource utilization.

[0046] By filling the lightweight process binding structure with a unique channel identifier and a process identifier and establishing a one-way association, the directional binding relationship between processes and channels is further strengthened. System-level verification of the uniqueness of the association information ensures that each lightweight process can only write data through the global data channel, avoiding channel contention caused by simultaneous transmission from multiple processes. This allows data to be transmitted along a preset path, improving the orderliness of transmission. The records in the association mapping table provide a basis for subsequent transmission status queries and verifications, facilitating the rapid location of processes and channels with transmission anomalies and reducing the difficulty of troubleshooting.

[0047] The raw data collected by each sensor is encapsulated into a unified data block format by a corresponding lightweight process. This integrates the raw data, sensor number, and acquisition timestamp, resolving the incompatibility issue of different sensor data formats in traditional solutions. This allows the main control process to quickly classify and process the data. The calculation and updating of checksums in the data transmission control structure provides a basis for data integrity verification. Checksum comparison effectively identifies data errors or loss caused by interference during transmission, improving data transmission reliability compared to traditional non-checksum transmission methods. The association between sensor number and process identifier ensures the uniqueness of the data block's origin, facilitating subsequent tracing of the data's acquisition source and supporting data anomaly analysis.

[0048] The non-blocking transmission mode employed differs from traditional blocking transmission. The lightweight process can initiate a new transmission request without waiting for the previous data transmission to complete. The channel's basic information structure provides feedback on the buffer status through a bidirectional association with the data transmission control structure. Data blocks can be written as long as the buffer is not full, significantly reducing transmission latency and improving real-time performance in high-frequency acquisition scenarios. The main control lightweight process verifies and classifies data blocks, ensuring that only complete and valid data enters the subsequent processing flow. Verification failure triggers retransmission, preventing data loss. System-level monitoring of buffer occupancy notifies the process to pause transmission when a preset threshold is reached, effectively preventing data loss due to buffer overflow. Compared to traditional solutions lacking overflow protection, this further enhances transmission stability.

[0049] Optionally, the allocation of a dedicated buffer and the establishment of bidirectional association in step 13 enable real-time synchronization of transmission status, improving the accuracy of status monitoring; the uniqueness verification and alarm mechanism in step 22 can promptly detect and handle association conflicts, ensuring the stable startup of the transmission system; the design of data block header identifiers and tail check field placeholders in step 32 further standardizes the data format, facilitating rapid parsing by the main control process; the checksum comparison and anomaly marking in step 43 enable precise location of data errors and trigger retransmission, while the pause transmission mechanism avoids buffer overflow, and multiple safeguards improve the integrity and reliability of data transmission. Attached Figure Description

[0050] Figure 1 This application provides a method for transmitting multi-sensor data in an embedded device.

[0051] Figure 2 This application provides an embodiment of a multi-sensor data transmission device in an embedded device.

[0052] Figure 3 This is an electronic device according to an embodiment of the present application. Detailed Implementation

[0053] like Figure 1 As shown, this application embodiment provides a multi-sensor data transmission method in an embedded device, including:

[0054] Step 1: During the initialization of the embedded device system layer, create a global data channel and a lightweight process corresponding to each sensor, and construct a channel basic information structure, a lightweight process binding structure, and a data transmission control structure.

[0055] Step 2: Fill in the channel unique identifier and process identifier into the lightweight process binding structure and establish a one-way association with the channel basic information structure;

[0056] Step 3: Each sensor collects data according to a preset cycle, which is then encapsulated into a data block of a unified format by the corresponding lightweight process, and the check code is calculated and updated to the data transmission control structure.

[0057] Step 4: The lightweight process transmits the data block to the buffer bound to the data transmission control structure through the global data channel in non-blocking mode. The main control lightweight process reads the data block from the buffer. If the data block passes the verification, it is classified and processed. If it fails, a retransmission is triggered.

[0058] Compared with traditional multi-sensor data transmission solutions, the technical advantages of this application are reflected in three core aspects: In terms of resource consumption, a global data channel replaces independent physical channels, and combined with a lightweight process design, it reduces hardware resource consumption and adapts to the resource-constrained characteristics of embedded devices; in terms of transmission efficiency, the non-blocking transmission mode and real-time feedback of buffer status reduce transmission latency and improve real-time performance in high-frequency acquisition scenarios; in terms of data reliability, unified data format, checksum verification, retransmission mechanism, and buffer overflow protection comprehensively reduce the probability of data errors and loss, resulting in higher transmission stability compared to traditional solutions. Overall, the technical solution of this application, through structured design and standardized processes, achieves efficient, reliable, and orderly multi-sensor data transmission, better meeting the usage needs of embedded devices in complex application scenarios.

[0059] In this embodiment, a lightweight process refers to a process that relies on the kernel or main process scheduling of an embedded device system, consumes very few resources (e.g., only tens of KB of memory, low CPU utilization), and has a single, focused function. For example, a dedicated process corresponding to a temperature sensor is only responsible for receiving raw sensor data according to a preset cycle, performing simple format encapsulation and basic verification, and does not undertake complex calculations or overall planning tasks, which meets the core characteristics of "lightweight". The main control lightweight process is the "overall management process" among lightweight processes. It also has lightweight attributes (no redundant functions, low resource consumption), but its function is focused on global coordination. For example, it is responsible for listening to the buffer status, reading the data blocks transmitted by each sensor lightweight process, performing integrity verification, classifying and organizing data according to sensor type, and triggering the corresponding sensor's lightweight process to retransmit when verification fails. It has a "management-execution" collaborative relationship with other lightweight processes - both belong to the category of lightweight processes. The former focuses on overall scheduling and core processing, while the latter focuses on the data acquisition, encapsulation, and transmission execution of a single sensor, together completing the entire process of multi-sensor data transmission.

[0060] Optionally, step 1 includes:

[0061] Step 11: Create a global data channel. Assign a unique channel identifier through the created channel basic information structure, set the channel type to data channel, and set the initial running state to idle. The unique channel identifier is used for association and binding of lightweight processes.

[0062] Step 12: Create a lightweight process for each sensor and assign a unique process identifier. Initialize the created lightweight process binding structure. The unique process identifier will be associated with the unique channel identifier.

[0063] Step 13: Create a data transmission control structure and bind it to a global data channel. Configure the buffer address and preset buffer size. Initialize the transmission progress flag to "not started" and the checksum to 0. The global data channel bound to the data transmission control structure will synchronize the transmission status.

[0064] In this application, step 1 enables the dynamic adaptation and creation of global data channels and the precise on-demand initialization of lightweight processes, differing from traditional fixed-parameter channel and process designs. By configuring dynamically adjustable core parameters for the global data channels, designing structured identifier generation rules, and initializing lightweight processes to match sensor characteristics, efficient utilization of channel resources and lightweight process operation are achieved, laying the foundation for the orderly transmission of subsequent multi-sensor data. This design not only adapts to the resource-constrained characteristics of embedded devices but also ensures the accuracy and reliability of process-channel binding through a standardized identifier system and association mechanism.

[0065] Preferably, the specific implementation process of step 11 is as follows: taking the system resource information of the embedded device, the total number of sensors, and the preset channel configuration rules as the processing objects, three core operations are performed: global data channel creation, channel basic information structure construction, and unique channel identifier allocation. The system layer first queries the remaining memory, bus bandwidth, and other resource status of the embedded device. Combined with the total number of sensors, it determines the basic configuration parameters of the global data channel. The channel bandwidth is set by multiplying the sum of the average data transmission rates of the sensors by a redundancy coefficient. The redundancy coefficient is dynamically adjusted according to the device's resource margin (set to 1.5 when resource margin is ≥50%, and set to 1.2 when resource margin is between 30% and 50%) to ensure that the channel transmission capacity meets the requirements of concurrent transmission of multiple sensors. A channel basic information structure is created, which includes fields such as channel identifier, channel type, running status, number of associated processes, dynamic bandwidth, and resource occupancy threshold. Each field is initialized with a fixed data type (e.g., the channel identifier is a 32-bit integer). The unique channel identifier is generated using a hierarchical encoding rule. The encoding consists of three parts: the device's inherent ID (first 16 bits), the channel type code (middle 8 bits, data channels are fixed at 0x01), and the sequence number (last 8 bits). The sequence number is assigned incrementally starting from 0x00. After generation, it is written into the channel identifier field of the channel basic information structure. The channel type is set as a data channel, the initial running state is idle, the number of associated processes is initialized to 0, and the resource occupancy threshold is set at 80% of the channel bandwidth. When the actual channel occupancy rate exceeds this threshold, the resource adjustment mechanism is triggered. All fields of the channel basic information structure will serve as the core basis for subsequent process binding and transmission status monitoring.

[0066] Preferably, in the specific technical implementation of step 12, the processing objects are the sensor type, data acquisition frequency, single-frame data volume, and the unique channel identifier in the channel basic information structure. Lightweight process creation, unique process identifier allocation, and lightweight process binding structure initialization operations are performed. Lightweight processes are created one by one for each sensor. The stack size of the process is dynamically set according to the single-frame data volume of the corresponding sensor. When the single-frame data volume is ≤256 bytes, the stack size is set to 512 bytes; when the single-frame data volume is between 256 and 1024 bytes, the stack size is set to 1024 bytes to avoid resource waste due to an excessively large stack or data overflow due to an excessively small stack. A unique process identifier is assigned to each lightweight process. The identifier generation rule is associated with the channel identifier, using a combination encoding method of "channel identifier - sensor serial number" (the first 32 bits are the channel identifier, and the last 8 bits are the sensor serial number, which increments from 1 according to the access order), ensuring that the process identifier and the channel identifier are consistent. Associativity and uniqueness; initialize a lightweight process binding structure, which includes fields such as process identifier, associated channel identifier, sensor number, read / write permissions, and binding status. Write the assigned unique process identifier into the corresponding field. The associated channel identifier is temporarily filled with the unique channel identifier in the channel basic information structure (to be verified in subsequent steps). The binding status is initialized to "unbound". The read / write permissions are set to "to be configured" by default. The sensor number corresponds one-to-one with the sensor number in the process identifier to ensure a unique association between each process and the sensor. The initialization status of the lightweight process binding structure will provide a standardized interface for the association operation in the subsequent step 2.

[0067] Optionally, step 13 includes:

[0068] Step 131: Query the embedded device's storage resources, allocate a dedicated buffer and record its starting address and storage capacity. The dedicated buffer serves as a buffer bound to the created data transmission control structure.

[0069] Step 132: Write the buffer address and preset buffer size into the corresponding fields of the data transmission control structure;

[0070] Step 133: Initialize the transmission progress marker to "not started", assign the checksum field to 0, and establish a bidirectional association between the data transmission control structure and the channel basic information structure to synchronize the transmission status feedback.

[0071] In this application, based on step 13, the problems of resource waste or overflow and transmission status synchronization lag caused by traditional fixed buffers are solved by dynamically adapting the buffer allocation to embedded device resources, standardizing structure field configuration, and establishing a bidirectional association mechanism. The dynamic allocation of dedicated buffers ensures efficient use of storage resources, the precise writing of structure fields provides a standardized basis for transmission parameters, and the bidirectional association design enables real-time communication between the channel and the control module. These three aspects work in a progressive manner, laying a solid foundation for subsequent non-blocking transmission, data verification, and status monitoring, thus adapting to the resource-constrained characteristics of embedded devices and their high requirements for transmission stability.

[0072] Preferably, the specific implementation process of step 131 is as follows: Taking the embedded device's storage resource list (including the starting address, available capacity, address continuity identifier, and read / write rate level of free memory blocks), the total number of sensors, the maximum data volume per frame for each sensor, and the preset acquisition cycle as the processing objects, the system performs storage resource query, dynamic calculation of buffer capacity, and dedicated buffer allocation operations. The system layer calls the storage resource query interface, traverses all free memory blocks of the device, and filters out memory blocks with continuous addresses and read / write rates not lower than a preset threshold (set according to the sensor's highest acquisition frequency; for example, the threshold is 5 megabytes per second when the acquisition frequency is ≥100 Hz). The starting address and available capacity of each eligible memory block are recorded. The required buffer capacity is dynamically calculated according to the rule "total data volume per frame × maximum concurrent transmission frames × redundancy coefficient." The total data volume per frame is the sum of the maximum data volume per frame for all sensors (e.g., the maximum data volume per frame for 3 sensors is 256 bytes, 512 bytes, and 1024 bytes respectively, totaling 1792 bytes). The maximum concurrent transmission frames are calculated as the least common multiple of the sensor acquisition cycles. The number of data points is determined (e.g., the collection periods are 10 milliseconds, 20 milliseconds, and 30 milliseconds, with the least common multiple being 60 milliseconds, corresponding to a maximum concurrent frame count of 6). The redundancy coefficient is dynamically adjusted according to the available free memory (set to 1.3 when the free memory is ≥30%, and set to 1.1 when the free memory is between 10% and 30%). The smallest contiguous memory block with a capacity not less than the calculated value is allocated from the selected free memory blocks as a dedicated buffer to ensure address continuity, improve read and write efficiency, and avoid transmission delays caused by address fragmentation. The starting physical address of this dedicated buffer (e.g., 0x20000000) and the actual storage capacity (e.g., 15 kilobytes) are recorded. The allocation result will be directly used for subsequent structure field configuration and data storage.

[0073] Preferably, in the specific technical implementation of step 132, the starting physical address, actual storage capacity, and field definitions (including field data types, address offsets, and validity verification rules) of the dedicated buffer are used as processing objects to perform field writing and validity verification operations. The buffer address field of the data transmission control structure uses a 32-bit physical address format. The starting physical address of the recorded dedicated buffer is written to this field in big-endian order to ensure the uniqueness of the address identifier and hardware recognizability. The buffer size field uses a 16-bit unsigned integer format, with the unit being bytes. The actual storage capacity is converted to the corresponding value (e.g., 15 kilobytes is converted to 15360) and written. At the same time, the theoretical buffer value calculated in step 131 is recorded in the reserved "theoretical required capacity" field of the structure for subsequent capacity compatibility verification. After writing, the system layer verifies the written value according to the field validity verification rules. The address field must be within the effective memory address range of the device (e.g., 0x20000000-0x200FFFFF), and the size field must be no less than the theoretical required capacity and no more than the maximum allocation limit of a single memory block of the device (e.g., 64 kilobytes). If the verification passes, the field is marked as valid. If the verification fails, the buffer reallocation process is triggered to ensure the accuracy of the field values ​​of the data transmission control structure and to provide reliable parameter basis for subsequent data writing and reading.

[0074] Preferably, in the specific implementation of step 133, the state field definition of the data transmission control structure, the identification information of the channel basic information structure, and the state synchronization rules are taken as the processing objects, and initialization operations and bidirectional association construction are performed. The transmission progress flag field in the data transmission control structure is set to "not started" (enumeration type value is 0x00), and this field will be updated in real time according to the state flow rule of "not started - in transmission - transmission completed - transmission error"; the check code field is assigned a value of 0 (32-bit unsigned integer), and this field will be updated in real time by the lightweight process during the data encapsulation stage as the benchmark for data integrity verification; a bidirectional association between the data transmission control structure and the channel basic information structure is established, and the unique channel identifier and memory address pointer of the channel basic information structure are written into the data transmission control structure. At the same time, a "association control structure identifier" field is added to the channel basic information structure and written into the data transmission control structure. A unique identifier (using the same encoding rules as the channel identifier) ​​and a memory address pointer are used to form a mutual index. The update mechanism of the associated fields is defined according to the status synchronization rules. The status of the data transmission control structure that needs to be synchronized with the status of the channel basic information structure includes buffer occupancy rate, current transmission progress, and verification exception flag. The status of the channel basic information structure that needs to be synchronized with the status of the data transmission control structure includes channel running status (idle / occupied / abnormal) and the number of associated processes. The synchronization period is set to 1 / 10 of the minimum acquisition period of the sensor (e.g., if the minimum acquisition period is 10 milliseconds, the synchronization period is 1 millisecond) to ensure real-time communication of transmission status and provide timely information support for buffer status feedback and transmission adjustment in the subsequent step 4.

[0075] Optionally, step 2 includes:

[0076] Step 21: Fill in the associated channel identifier from the channel basic information structure and the unique process identifier of the corresponding lightweight process into the binding structure of each lightweight process, and set the read and write permissions to write only.

[0077] Step 22: The system layer verifies the uniqueness of the associated information in the structure bound to each lightweight process to avoid channel conflicts. The uniqueness verification ensures that the data is transmitted in the correct direction.

[0078] Step 23: Establish a one-way association between the lightweight process binding structure and the channel basic information structure, update the number of associated lightweight processes in the channel basic information structure to the total number of sensors, change the running status to occupied, and allow data to be written in the occupied status of the channel basic information structure.

[0079] In this application, based on steps 21 and 23, the problems of chaotic identifier matching, coarse permission control, ambiguous association relationships, and lagging channel status updates in the traditional binding process are solved through identifier validity verification, fine-grained permission control, structured unidirectional association, and orderly state flow design. Step 21 ensures the accuracy of identifiers and the security of permissions in the binding structure, while step 23 constructs a clear unidirectional association link and synchronously updates the channel status. The two work together to achieve orderly binding of multi-sensor processes and global data channels, providing a guarantee for subsequent data orientation and conflict-free transmission, and adapting to the fine-grained management needs of multi-process collaboration in embedded devices.

[0080] Preferably, the specific implementation process of step 21 is as follows: taking the field definition of the lightweight process binding structure, the unique channel identifier in the channel basic information structure, the unique process identifier of the lightweight process, the association mapping relationship between the sensor number and the process identifier, and the permission control rules as the processing objects, the identification extraction, validity verification, field filling, and permission configuration operations are performed. The system layer extracts the unique channel identifier from the channel basic information structure, verifies the format legality of the identifier (it must conform to the hierarchical encoding rules defined in step 11, the first 16 bits are the device's inherent ID, and the middle 8 bits are the 0x01 data channel code) and validity (it must exist in the list of channel identifiers already created by the device), and avoids filling in invalid channel identifiers; extracts the unique process identifier from the control block of the corresponding lightweight process, and verifies the association relationship between the identifier and the sensor number (the last 8 bits of the process identifier, the sensor serial number, must be consistent with the corresponding sensor number, such as if the sensor number is 3, the last 8 bits of the process identifier must be 0x03), ensuring the exclusive correspondence between the process and the sensor; and then performs the calibration. The verified associated channel identifier and unique process identifier are filled into the corresponding fields of the lightweight process binding structure according to the field data type (32-bit integer). After filling, the identifier field status is marked as "verified and valid". The read and write permissions are set to "write only" according to the permission control rules. At the same time, a verification code (generated by the channel identifier and process identifier according to a preset algorithm, such as the result of XOR operation) is written into the permission verification bit reserved in the structure. The verification code must be verified during subsequent data transmission to prevent permission tampering and ensure that the lightweight process can only write data to the global data channel and cannot read other process data or channel control information, thus ensuring the security and directionality of data transmission.

[0081] Preferably, in the specific technical implementation of step 23, the memory address of the lightweight process binding structure, the associated process management field of the channel basic information structure, the total number of sensors, and the channel status transition rules are taken as the processing objects, and one-way association construction, process number update, and channel status change operations are performed. A one-way association is established between the lightweight process binding structure and the channel basic information structure. An array of associated process structure pointers is created in the channel basic information structure. The memory address of each lightweight process binding structure is stored in this array in sequence according to the sensor number. The array length is consistent with the total number of sensors, forming a one-way index link of "channel-process". This facilitates quick subsequent lookup of the binding structure corresponding to a specific sensor without traversing all structures. The number of valid addresses in the associated process structure pointer array (i.e., the number of lightweight process binding structures that have completed identifier filling and verification) is counted. This number is updated to the associated lightweight process number field of the channel basic information structure. Simultaneously, it is verified whether this number is consistent with the total number of sensors. If they are inconsistent, the association is triggered. A quantity mismatch alarm indicates that there are processes that have not been fully bound. The channel running status is changed according to the channel status flow rules (idle → associated → occupied). When the number of associated lightweight processes is consistent with the total number of sensors and the status of the identifier field of all bound structures is "verified and valid", the running status is changed from "idle" to "occupied", and the status change timestamp is recorded (accurate to the millisecond level, such as 20240520143000123). The "occupied" status of the channel basic information structure will trigger the data write permission mechanism. Only when the status is "occupied" and the permission verification bit passes will the write request of the lightweight process be responded to by the global data channel, avoiding data write failure when the channel is not ready and ensuring the orderliness and reliability of data transmission.

[0082] Optionally, step 22 includes:

[0083] Step 221: The system layer traverses all lightweight process binding structures and extracts the combined information of the associated channel identifier and process identifier;

[0084] Step 222: Perform a uniqueness check on the combined information to avoid channel association conflicts. If duplicates are found, trigger a binding failure alarm.

[0085] Step 223: After the verification is passed, record the association mapping table of the binding structure of each lightweight process. The association mapping table will be used for transmission status query and verification.

[0086] In this application, based on step 22, structured extraction, hierarchical verification mechanisms, and refined mapping table design address the problems of low efficiency, difficult conflict localization, and cumbersome status queries in traditional verification methods. Step 221 ensures that the extracted combined information is valid and complete; step 222 accurately identifies conflicts and issues graded alarms through hierarchical verification; and the structured mapping table constructed in step 223 provides an efficient interface for subsequent transmission status queries and anomaly localization. These three elements work together to achieve accuracy and reliability in multi-process and channel association, adapting to the refined management needs of multi-sensor collaborative transmission in embedded devices. Compared to traditional single verification methods, verification efficiency and conflict handling capabilities are significantly improved.

[0087] Preferably, the specific implementation process of step 221 is as follows: taking the identifier field status of the lightweight process binding structure, the sensor serial number sorting rule, and the temporary storage list structure as the processing objects, traversal filtering, combined code generation, and ordered storage operations are performed. The system layer traverses all lightweight process binding structures in ascending order of sensor serial numbers (from 1 to N, where N is the total number of sensors, such as 8). Before traversal, it checks whether the identifier field status of each structure is "verified valid" as marked in step 21. If it is not marked or marked as invalid, the sensor number corresponding to the structure is recorded and skipped to avoid invalid data participating in subsequent verification. For structures with valid identifier fields, the associated channel identifier and unique process identifier are extracted and combined in a fixed order of "channel identifier first, process identifier last" to generate a 64-bit combined code (the first 32 bits are 32-bit integer channel identifiers, and the last 32 bits are 32-bit integer process identifiers). Identifiers, such as channel identifier 0x0001A2B3, process identifier 0x0004C5D6, combined code 0x0001A2B30004C5D6); the generated combined code is associated with the corresponding sensor number and the memory address of the lightweight process binding structure, and stored in a preset temporary list. The temporary list adopts a linked storage structure, and each node contains three fields: combined code, sensor number, and structure address. During storage, the nodes are sorted in ascending order according to the value of the combined code, providing an ordered comparison basis for subsequent uniqueness verification. At the same time, the number of valid nodes in the temporary list is counted for comparison with the total number of sensors to ensure that no valid structures are missed.

[0088] Preferably, in the specific technical implementation of step 222, the ordered node data of the temporary list, the unique channel identifier of the global data channel, and the alarm classification rules are used as processing objects to perform hierarchical uniqueness verification and conflict alarm operations. A hierarchical verification mechanism is adopted. First, it verifies whether the first 32 bits of the channel identifier portion of all combined codes in the temporary list are consistent with the unique channel identifier of the global data channel. If there are inconsistent combined codes, it is determined to be a channel association error, the corresponding sensor number and combined code are recorded, and a channel association error alarm is triggered (alarm code is set to 0x01), indicating that there is a lightweight process with a binding error. Under the premise that the channel identifiers are consistent, a uniqueness verification of the combined code is performed. By traversing the ordered temporary list, the combined code values ​​of the current node and the previous node are compared. If the values ​​are the same, it is determined to be an association conflict, and the combined code of the conflicting node and the two conflicting nodes are recorded. The system generates conflict details data by assigning the corresponding sensor number and the memory address of the structure to each conflict point. Based on the number of conflicting nodes, a tiered alarm is triggered. A single conflicting node triggers a Level 1 alarm (alarm code 0x02), recording only the conflict information for subsequent investigation without interrupting the binding process. Two or more conflicting nodes trigger a Level 2 alarm (alarm code 0x03), suspending the binding process and notifying the system layer. Simultaneously, the lightweight process binding structure involved in the conflict is marked as "conflicted," prohibiting it from participating in subsequent data transmission. This avoids transmission anomalies caused by multiple processes competing for channel resources. The tiered alarm mechanism ensures both the fault tolerance of minor conflicts and the timely prevention of risks from severe conflicts.

[0089] Preferably, in the specific implementation of step 223, the effective node data of the temporary list, the mapping table structure definition, and the fast lookup rules are the processing objects, and the operations of creating the association mapping table, structured filling, and index building are performed. An association mapping table is created. This mapping table is an array structure with an array length consistent with the total number of sensors. The array elements are custom mapping structures, which contain six fields: channel identifier, process identifier, sensor number, binding structure address, binding status, and checksum. Each field is defined according to a fixed data type (e.g., the binding status is an enumeration type with values ​​of "bound", "unbound", and "conflict"). The effective nodes of the temporary list are traversed, and the combined encoding is split into 32-bit channel identifiers and 32-bit process identifiers, which are then filled into the corresponding fields of the mapping structure. Simultaneously, the sensor number and the memory address of the lightweight process binding structure are filled in. The binding status is set to "bound", and the cyclic redundancy check value (CRC-32) of the combined encoding is calculated as the checksum and filled into the corresponding field to ensure the integrity of the mapping table data. To improve query efficiency, the sensors based on the mapping structure... A fast lookup index is constructed using the ID field. The index table is a one-dimensional array, and the index table index is consistent with the sensor ID. The index table element stores the array index of the corresponding mapping structure in the association mapping table. For example, if the sensor ID is 3, the value stored at index table index 3 is the position of the mapping structure corresponding to sensor ID 3 in the mapping table. When querying, the mapping structure can be directly located by the sensor ID, reducing the query time complexity to O(1). The starting memory address and array length of the association mapping table are written into the "association mapping table information" field of the channel basic information structure to realize the association between the mapping table and the channel. Subsequent transmission status queries (such as the process binding status corresponding to a certain sensor) and verification anomaly location (such as the binding structure corresponding to a certain data block) can be quickly realized through this mapping table. Compared with the traditional traversal query method, the resource consumption and time delay of status query are greatly reduced.

[0090] Optionally, step 3 includes:

[0091] Step 31: Each sensor collects environmental or status data according to a preset cycle to form raw data, and transmits the raw data to the corresponding lightweight process;

[0092] Step 32: The lightweight process calls the data encapsulation interface to integrate the raw data, sensor number, and acquisition timestamp, and encapsulates them into a data block of a unified format according to the data transmission control structure field requirements.

[0093] Step 33: Calculate the checksum of the data block and update the checksum and data length to the corresponding field of the data transmission control structure.

[0094] In this application, based on steps 31 and 33, the technical problems of resource waste caused by fixed acquisition cycles, transmission efficiency affected by noise in raw data, easy omission of errors due to single check codes, and asynchronous state updates in traditional solutions are solved by using dynamic acquisition cycles, data preprocessing mechanisms, hierarchical check code design, and atomic update operations. Step 31 achieves precise adaptation between sensor acquisition and lightweight processes, ensuring the validity and directional transmission of raw data; Step 33 improves data integrity verification capabilities through hierarchical check and ensures the consistency of control structure states by combining atomic updates. The two work together to provide a high-quality and highly reliable data foundation for subsequent data encapsulation and non-blocking transmission, adapting to the needs of multi-sensor heterogeneous acquisition and high-reliability transmission in embedded devices.

[0095] Preferably, the specific implementation process of step 31 is as follows: taking the sensor type parameters (acquisition accuracy, signal type, maximum sampling rate), the real-time load of the embedded device (CPU utilization, memory utilization), the preset acquisition cycle range, and the unique process identifier of the lightweight process as the processing objects, dynamic acquisition cycle configuration, data acquisition and preprocessing, identifier verification, and directional transmission operations are performed. The system layer determines the basic acquisition cycle range based on the sensor type parameters (e.g., 10-100 milliseconds for temperature sensors, 1-20 milliseconds for accelerometers), and dynamically adjusts the actual acquisition cycle in combination with the real-time load of the device: when the CPU utilization is ≤30% and the memory utilization is ≤40%, the lower limit of the basic cycle range is used to improve data timeliness; when the CPU utilization is between 30% and 60% or the memory utilization is between 40% and 70%, the middle value of the basic cycle is used; when any resource utilization exceeds the threshold, the upper limit of the basic cycle is used to avoid the acquisition process consuming too many resources and affecting system operation; the sensor starts acquisition according to the dynamically adjusted cycle, and hardware filtering is performed on analog signal sensors (e.g., voltage sensors) during the acquisition process (the low-pass filter cutoff frequency is based on the sampling rate). With a 1 / 5 setting (e.g., a cutoff frequency of 20 Hz when the sampling rate is 100 Hz), data format standardization (converting to 32-bit integers) is performed on digital signal sensors (such as infrared sensors), and outliers are filtered (data exceeding ±5% of the sensor's range is marked as invalid and discarded). After acquisition, raw data is generated. The sensor extracts its own number through the built-in process identifier matching module and compares it with the unique identifier of the associated lightweight process. After successful verification, a temporary data transmission link is established, and the raw data is transmitted to the corresponding lightweight process using an interrupt triggering method. After the transmission is completed, the link is released, and the transmission timestamp and data length are recorded in the sensor's local buffer for subsequent transmission anomaly tracing. The identifier verification mechanism ensures that the raw data is not transmitted to the wrong process, improving the accuracy of transmission.

[0096] Preferably, in the specific technical implementation of step 33, the data block in a unified format (including header identifier, sensor number, timestamp, raw data, and tail placeholder), the field definitions of the data transmission control structure, the verification algorithm configuration rules, and the atomic operation mechanism are taken as the processing objects, and the layered check code calculation, data length statistics, and atomic update operations of the control structure are performed. A layered verification mechanism is adopted. First, the cyclic redundancy check value (CRC-16) of the core data area of ​​the data block (raw data + sensor number + timestamp) is calculated as the first-level check code to quickly verify the integrity of the core data; then, the message digest value of the entire data block (including header identifier and tail placeholder) (using a hash algorithm to output a 16-byte digest) is calculated as the second-level check code to deeply verify that the entire data block has not been tampered with. The layered design ensures both verification efficiency and improves the error detection rate. The actual number of bytes in the statistical data block (including all fields) is used as the data length, which is stored in an unsigned 16-bit integer format to ensure that it does not exceed the field range of the embedded device's data processing. An atomic operation mechanism is used to update the data transmission control structure: first, the memory area corresponding to the structure is locked (through a hardware mutex or a system-level critical section). To prevent data contention caused by simultaneous updates from multiple processes, the first-level checksum and the second-level checksum are sequentially written into the corresponding fields of the structure (the checksum field is designed to be 48 bits, with the first 16 bits storing the CRC-16 value and the last 32 bits storing the high 32 bits of the hash digest). Then, the data length is written, and finally, the checksum update flag of the structure is updated to "updated" and the memory is unlocked. If the checksum calculation fails (e.g., the data block length is abnormal), the data block is marked as "invalid checksum", triggering a lightweight process to re-collect data. At the same time, the number of failures is recorded. When the number of consecutive failures reaches a preset threshold (3-5 times, configured according to the importance of the sensor), a sensor fault alarm is triggered, and the system layer is notified to troubleshoot the fault. The atomic update mechanism ensures the consistency of the checksum, data length and update flag status, avoiding the main control process reading incomplete control information.

[0097] Optionally, step 32 includes:

[0098] Step 321: Extract the sensor number and associate it with the unique process identifier of the corresponding lightweight process to ensure the uniqueness of the data block traceability;

[0099] Step 322: Obtain the system time to generate a collection timestamp, and sort and combine it with the raw data according to a preset format;

[0100] Step 323: Add data block header identifiers and tail check field placeholders to the original data after sorting and combining to form data blocks with a uniform format.

[0101] In this application, based on step 32, a structured two-way binding mechanism, timestamp accuracy compensation design, and a dynamically adaptable format encapsulation scheme are used to solve the problems of single traceability identifiers, easy timestamp drift, and fixed and incompatible formats in traditional encapsulation. Step 321 constructs a traceability system with two-way verification of "sensor-process", step 322 realizes the orderly combination of high-precision timestamps and data, and step 323 designs a standardized format that includes device and data characteristics. These three steps are progressively advanced to ensure the traceability, timing accuracy, and parsing compatibility of data blocks throughout the entire process of transmission, verification, and processing. This adapts to the unified management needs of heterogeneous data from multiple sensors in embedded devices. Compared with traditional simple splicing encapsulation, the traceability reliability and format adaptability are significantly improved.

[0102] Preferably, the specific implementation process of step 321 is as follows: taking the unique process identifier of the lightweight process, sensor number, association mapping table, sensor type code, and binding verification rules as the processing objects, the process performs identifier extraction, bidirectional verification, binding code generation, and field embedding operations. The lightweight process extracts the last 8 bits of its unique process identifier's sensor serial number through the process identifier parsing interface and performs a consistency check with the sensor number attached when receiving the original data. If they do not match, an identifier mismatch alarm is triggered, encapsulation is rejected, and a retransmission is requested. The process queries the association mapping table for the sensor type code corresponding to the current process identifier (e.g., 0x01 for temperature sensors, 0x02 for humidity sensors, and 0x03 for accelerometers). The sensor number, process identifier, and type code are combined in the order of "number-identifier-code" to generate a 64-bit binding base code. Cyclic redundancy check is then used. The algorithm (CRC-32) calculates the binding base code to obtain a 32-bit binding check code, which together with the binding base code constitutes the "traceability identifier group" to ensure that the identification information has not been tampered with. The traceability identifier group is embedded in a reserved field of the data encapsulation. This field is located at the front of the original data and is stored in big-endian order. The first 64 bits are the binding base code and the last 32 bits are the binding check code. The subsequent master control process can quickly trace the sensor and corresponding process from which the data originated by parsing this field. The two-way verification mechanism and the combined traceability identifier group ensure the uniqueness and reliability of the data block traceability and avoid traceability failure due to a single identifier error.

[0103] Preferably, in the specific technical implementation of step 322, the system clock module of the embedded device, the hardware timer, the field type of the raw data (integer, floating-point, character), the preset time format, and the sorting rules are taken as the processing objects, and high-precision timestamp generation, data type adaptation, and ordered combination operations are performed. A lightweight process simultaneously calls the system clock module and the hardware timer to obtain time information: the system clock module provides second-level time (e.g., 20240520153000), and the hardware timer provides microsecond-level compensation values ​​(e.g., 123456 microseconds). The two are combined to generate a high-precision acquisition timestamp at the "second-microsecond" level (format: YYYYMMDDHHMMSSssssss, e.g., 20240520153000123456), avoiding the millisecond-level precision deficiency caused by a traditional single system clock; for different types of raw data, format standardization processing is performed: integer data retains the original byte length (16 bits or 32 bits), and floating-point data is uniformly converted. The format is 32-bit single precision, and character data is stored in ASCII code to ensure data consistency. Data is combined according to a preset sorting rule of "timestamp-traceability identifier group-original data". The timestamp field is fixed at 20 bytes (string format), the traceability identifier group is fixed at 12 bytes (64-bit base code + 32-bit check code), and the length of the original data field is dynamically adjusted according to the actual data volume. A 1-byte separator (0x00) is inserted between each field during combination to facilitate rapid field splitting during subsequent parsing and avoid field confusion caused by variable data length. The high-precision timestamp provides accurate data for time-series analysis, and the ordered combination rule ensures the regularity of the encapsulation structure.

[0104] Preferably, in the specific implementation of step 323, the combined data of "timestamp-traceability identifier group-original data", the buffer size in the data transmission control structure, the preset header identifier rules and the dynamic adjustment mechanism of the tail placeholder are the processing objects, and the header identifier addition, tail placeholder filling and format integrity verification operations are performed. A fixed 16-byte header is generated according to preset header identifier rules. This header contains three parts: the first 4 bytes are the device's inherent identifier (e.g., 0x1234ABCD), the middle 4 bytes are the data block type identifier (0x00000001 for unified data blocks), and the last 8 bytes are the data block format version number (e.g., 0x0001000000000000 for V1.0). The header identifier is used to quickly identify the source device, type, and parsing rules of the data block, adapting to data differentiation in multi-device interconnection scenarios. The actual length of the combined data is calculated, and combined with the maximum storage capacity of a single buffer block in the data transmission control structure, the length of the tail placeholder is determined: placeholder length = minimum allocation unit of a single buffer block - (header length + combined data length). The minimum allocation unit of a single buffer block is set according to the device storage management rules (e.g., 512 bytes or 1024 bytes) to ensure the total length of the data block. The length is an integer multiple of the minimum allocation unit, improving buffer read and write efficiency; the tail placeholder uses a fixed padding value (0xFF), and the last 4 bytes of the placeholder embed a length check value of the combined data (CRC-16 value calculated based on the number of bytes of combined data) to verify whether there are any missing fields in the data block during transmission; after adding the header identifier and the tail placeholder, a complete unified format data block is formed. The total length of the data block = header length (16 bytes) + combined data length + placeholder length. Finally, the format of the entire data block is checked to verify the legality of the header identifier, the completeness of the field separator, and the compliance of the total length. If the check passes, the encapsulation is marked as valid; if the check fails, the encapsulation process is re-executed. The dynamically adjusted tail placeholder ensures the uniformity of the format and avoids the resource waste caused by the fixed placeholder. The multi-dimensional information design of the header identifier improves the recognizability and compatibility of the data block.

[0105] Optionally, step 4 includes:

[0106] Step 41: Each lightweight process initiates a transmission request to the global data channel based on the association between the lightweight process binding structure and the global data channel;

[0107] Step 42: In response to the transmission request, the channel basic information structure feeds back the real-time status of the buffer through bidirectional association with the data transmission control structure. If the buffer is not full, the lightweight process writes data blocks in non-blocking mode, updates the transmission progress mark to "transmission in progress", and marks it as "transmission completed" after the transmission is completed. The transmission progress mark will be synchronized to the channel basic information structure.

[0108] Step 43: After the main control lightweight process detects the transmission completion mark, it reads the data block from the buffer and verifies the integrity through the check code in the data transmission control structure. If the verification passes, it is classified and processed according to the sensor type. If the verification fails, the corresponding lightweight process is triggered to retransmit. At the same time, the system layer monitors the buffer occupancy rate and transmission status.

[0109] In this application, based on steps 41 and 42, the technical problems of unordered transmission requests, delayed buffer state feedback, conflict-prone non-blocking writes, and inconsistent state synchronization in traditional solutions are solved through request packet structure verification, dynamic priority scheduling, predictive buffer state feedback, block-based non-blocking writes, and atomic state synchronization design. Step 41 implements the validity verification, priority adaptation, and intelligent retry of transmission requests to ensure the accuracy and resource friendliness of request initiation; Step 42 implements secondary verification of request validity, real-time buffer state feedback, block-based conflict avoidance writes, and atomic state synchronization to ensure the orderliness, reliability, and efficiency of data transmission. The two work together to adapt to the core characteristics of concurrent transmission of multiple sensors and resource constraints in embedded devices. Compared with the traditional simple request-response mode, the transmission efficiency and data reliability are significantly improved.

[0110] Preferably, the specific implementation process of step 41 is as follows: taking the association information of the lightweight process binding structure, the association relationship mapping table, the sensor type encoding, the length information of the unified format data block, the preset request priority mapping rules and retry strategy as the processing objects, the process performs request pre-verification, structured request packet construction, priority dynamic allocation, transmission request initiation and intelligent retry operation. Before a lightweight process initiates a transmission request, it first verifies its binding status through an association mapping table: extracting the process identifier and channel identifier from the binding structure, querying the mapping table to confirm the binding status as "bound," and simultaneously verifying the read / write permission checksum (compared to the permission checksum written in step 21) to prevent processes without permissions or with invalid bindings from initiating invalid requests; constructing a structured transmission request packet containing 6 fields: a 32-bit process identifier, a 32-bit channel identifier, a 16-bit data block length, an 8-bit request priority, a 64-bit request timestamp, and a 32-bit request checksum. The request checksum is generated from the process identifier, channel identifier, and data block length using the CRC-32 algorithm to ensure the request packet has not been tampered with; dynamically allocating request priorities according to preset priority mapping rules: extracting the type code of the corresponding sensor (e.g., 0x01 temperature sensor, 0x03 acceleration sensor) from the association mapping table and mapping it to a 3-level priority (type code 0x0... Priority 1 is assigned to 0-0x1F, priority 2 to 0x20-0x7F, and priority 3 to 0x80-0xFF (priority 3 being the highest). This adapts to the transmission needs of sensors of varying importance, improving the timeliness of critical data transmission. A lightweight process initiates transmission requests through the global data channel's request interface, transmitting structured request packets in big-endian order to the channel control module. Simultaneously, a request response timer is started (timeout thresholds are dynamically set according to priority: 1 millisecond for priority 3, 2 milliseconds for priority 2, and 5 milliseconds for priority 1). If no channel feedback is received within the timeout period, a retry is performed using an exponential backoff strategy (initial retry interval is 1 millisecond, doubling with each retry, up to a maximum of 5 retries). If no response is received after the retry count reaches the threshold, the transmission request is marked as abnormal, triggering a lightweight alarm at the system layer. This avoids unlimited retries consuming system resources. The structured request packet and dynamic priority design ensure that the channel can quickly identify the source and importance of requests, improving request processing efficiency.

[0111] Preferably, in the specific technical implementation of step 42, the request processing module of the global data channel, the structured transmission request packet, the association mapping table, the data transmission control structure, the channel basic information structure, the preset buffer block rules and the conflict detection mechanism are the processing objects, and the request legality verification, real-time feedback of buffer status, block non-blocking writing, transmission progress atomic update and status synchronization operations are performed.Upon receiving a transmission request packet, the channel control module first performs a secondary validity check: it parses the process identifier and channel identifier in the request packet and compares them with records in the association mapping table to verify whether the process is associated with the channel. It also verifies the validity of the request verification code. If the verification fails, it returns an "illegal request" response and rejects subsequent operations. Next, it obtains the current buffer status through the buffer occupancy rate field (real-time updated number of used bytes / total capacity) of the data transmission control structure. Combined with the length of the data block being written (statistically calculated from records marked "transmitting"), it calculates the predicted remaining space (predicted remaining space = total capacity - number of used bytes - number of bytes being written). The system calculates the total write length to avoid misjudgments based solely on the current occupancy rate (e.g., current occupancy is 80%, but 10% is being written, meaning only 10% is actually remaining). It feeds back the buffer status based on the predicted remaining space: if the predicted remaining space is greater than or equal to the data block length, it reports "Writeable"; if the predicted remaining space is less than or equal to 1 / 3 of the data block length, it reports "Writeable in chunks"; if the predicted remaining space is less than 1 / 3 of the data block length, it reports "Wait in queue" and adds the request to a priority waiting queue (ordered in descending order of request priority, and in ascending order of request timestamp for the same priority). The lightweight process receives either a "Writeable" or "Writeable in chunks" response. Then, non-blocking writing is initiated: if "block writable", the data block is split into N equal-sized sub-blocks according to the preset block splitting rules (N is the smallest integer greater than or equal to the data block length / predicted remaining space, and the sub-block size is adjusted according to the minimum allocation unit of the buffer, such as 512 bytes); the target write area of ​​the buffer is locked through the memory mutex mechanism (to avoid data overwriting caused by multiple processes writing simultaneously), and the write operation is performed in the order of sub-blocks. After each sub-block is completed, the transmission progress flag in the data transmission control structure is updated (the status flows according to "transmission in progress - sub-block 1 completed - sub-block 2 completed - ... - transmission completed"). The update operation uses atomic instructions (such as those supported by the hardware). CAS instructions ensure consistent state updates; after all sub-blocks are written, the transmission progress marker is finally updated to "transmission complete" and synchronized to the corresponding field of the channel basic information structure through a bidirectional association mechanism (the "current transmission status" array of the channel basic information structure is updated by process identifier index); if a conflict is detected during the writing process (such as failure to lock the region), the current sub-block writing is abandoned, resources are released, and the writing is retried after waiting according to the backoff strategy to avoid infinitely occupying the channel. The block writing and conflict detection mechanism ensure the reliability of non-blocking transmission, and the predictive buffer status feedback and priority waiting queue improve the utilization efficiency of channel resources.

[0112] Optionally, step 43 includes:

[0113] Step 431: After the main control lightweight process reads the data block, it calculates the checksum and compares it with the checksum recorded in the data transmission control structure.

[0114] Step 432: If the verification is consistent, extract the original data, sensor number and timestamp from the data block, and sort them according to sensor type;

[0115] Step 433: The system layer queries the buffer occupancy rate in real time. When the preset threshold is reached, it notifies each lightweight process to pause the transmission. If the verification fails, the data block is marked as abnormal and an interrupt is triggered. The corresponding lightweight process is notified to retransmit. Pausing the transmission and retransmitting will respectively avoid buffer overflow and data loss.

[0116] In this application, based on step 43, a triple verification mechanism, a multi-level classification system, dynamic threshold scheduling, and intelligent retransmission strategy are used to solve the technical problems of traditional solutions, such as single verification leading to missed detections, coarse classification resulting in low efficiency, fixed buffer thresholds leading to overflow, and disordered retransmission consuming resources. Step 431 achieves dual protection of data integrity and traceability legitimacy, as well as hierarchical fault tolerance; step 432 achieves accurate grouping, temporal sorting, and quality marking of sensor data, improving subsequent processing efficiency; step 433 achieves predictive management of the buffer and anomaly repair. These three steps are progressively enhanced, adapting to the characteristics of heterogeneous multi-sensor data, resource constraints, and high transmission reliability requirements of embedded devices. Compared with the traditional simple verification-classification-retransmission mode, data reliability and system resource utilization are significantly improved.

[0117] Preferably, the specific implementation process of step 431 is as follows: Taking the unified format data block, the hierarchical checksums (first-level CRC-16, second-level hash digest) recorded in the data transmission control structure, the association mapping table, the traceability identifier group verification rules, and the verification failure classification strategy as the processing objects, triple verification, result judgment, and hierarchical fault tolerance operations are performed. After the main control lightweight process reads the data block, it first parses the last 4 bytes of the end placeholder length checksum and compares it with the CRC-16 value calculated based on the actual length of the data block to verify that the data block has no missing fields; secondly, it extracts the first-level checksum (core data area CRC-16) and the second-level checksum (overall data block hash digest) recorded in the data transmission control structure and compares them with the recalculated core data area CRC-16 and overall hash digest of the data block, respectively, to achieve dual verification of data integrity; finally, it parses the traceability identifier group (binding base code + binding checksum) in the data block and queries the corresponding process identifier and sensor code through the association mapping table. The system verifies the consistency of the bound base code and the validity of the bound check code to ensure the legitimacy of data traceability. It processes data according to the verification results: if all three verifications pass, it is marked as "verification valid"; if the length verification fails or the first-level check code does not match, it is determined as "data corrupted"; if the second-level check code does not match, it is determined as "data tampered with"; if the traceability identifier verification fails, it is determined as "traceability invalid". Different priority retransmission requests are triggered for "data corrupted" and "data tampered with", and an exception log is recorded for "traceability invalid" and the data block is stored separately to prevent invalid data from entering the normal processing flow. The triple verification mechanism significantly improves the error detection rate, and the tiered processing ensures the accuracy of fault tolerance.

[0118] Preferably, in the specific technical implementation of step 432, the data blocks that have been verified to be valid, the sensor type encoding mapping table, the preset classification storage rules, the timestamp sorting algorithm, and the data quality marking rules are the processing objects, and field extraction, multi-level classification, time-series sorting, and quality marking operations are performed. The main control process extracts the sensor number, type code, acquisition timestamp, and standardized raw data from the data block, and converts the type code into the specific sensor type (e.g., 0x01 → temperature sensor, 0x03 → accelerometer) through the type encoding mapping table; it processes the data according to the multi-level classification rules of "type grouping - time sorting - quality marking": first, an independent classification cache area is created according to the sensor type (each cache area adopts a linked storage structure and supports dynamic expansion), and the corresponding data block is written into the cache area of ​​its type; second, within each type cache area, the data is sorted in descending order of acquisition timestamp (using the insertion sort algorithm, which utilizes the continuity of timestamps to optimize sorting efficiency, such as when the difference between adjacent data timestamps is less than the acquisition timestamp). (If the collection period is directly inserted at the end), finally, quality marking is performed on the raw data: based on the sensor's measurement range, it is determined whether the data is within the normal range. Normal data is marked as "Quality Level A", data exceeding the range within ±3% is marked as "Quality Level B", data exceeding ±3%-±5% is marked as "Quality Level C", and data exceeding ±5% is marked as "Quality Level D". The quality marking field is stored in association with the data block. After classification, the current data volume, latest timestamp, oldest timestamp, and the proportion of data at each quality level are recorded at the beginning of each type cache area, which facilitates rapid retrieval and batch reading by the application layer. Multi-level classification and quality marking improve the fineness of data management, and time-series sorting ensures the time-series availability of data.

[0119] Preferably, in the specific implementation of step 433, the buffer occupancy rate field of the data transmission control structure, the preset dynamic threshold rules, the lightweight process communication interface, the exception marking mechanism, and the retransmission backoff strategy are the processing objects. Buffer status monitoring, dynamic threshold judgment, transmission control, and exception repair operations are performed. The system layer queries the buffer occupancy rate (number of bytes used / total capacity) at a fixed period (half of the sensor's minimum acquisition period; for example, if the minimum acquisition period is 10 milliseconds, the monitoring period is 5 milliseconds). Combined with the total amount of requested data currently being written, the predicted occupancy rate is calculated (predicted occupancy rate = current occupancy rate + total amount of data to be written / total capacity). The control strategy is adjusted according to the preset dynamic threshold rules: the buffer threshold for sensor type priority 3 (critical sensors) is 85%, priority 2 is 80%, and priority 1 is 75%. When the predicted occupancy rate reaches the corresponding threshold, a "pause transmission" command is sent to all lightweight processes that have not completed transmission through the lightweight process communication interface, and the buffer status at the pause time is recorded. When the predicted occupancy rate drops below the threshold by 20%, a "resume transmission" command is sent. The dynamic threshold adapts to different priorities. To meet the transmission requirements of sensitive data and prevent critical data from being discarded due to buffer overflow, if the verification fails ("data corruption" or "data tampering" as determined in step 431), the corresponding lightweight process is located through the association mapping table, the anomaly type (corruption / tampering) of the data block is marked, and an interrupt signal is triggered to notify the corresponding process to initiate retransmission. The retransmission adopts an exponential backoff strategy: the initial retransmission interval is 1 times the acquisition period (e.g., if the acquisition period is 10 milliseconds, the interval is 10 milliseconds), and the retransmission interval doubles each time, with a maximum of 4 retransmissions. If the retransmission is successful, the anomaly mark is cleared; if the retransmission fails, it is marked as "permanent anomaly" and a secondary alarm (alarm code 0x04) is triggered. At the same time, the abnormal data block is moved to an independent anomaly buffer for storage. The pause transmission mechanism avoids buffer overflow, and the intelligent retransmission strategy balances the data repair success rate and system resource consumption, forming an anomaly handling mechanism.

[0120] like Figure 2 As shown, this is an embodiment of a multi-sensor data transmission device in an embedded device according to this application, comprising:

[0121] The initialization module is used to create a global data channel and a lightweight process corresponding to each sensor during the initialization of the embedded device system layer, and to build a channel basic information structure, a lightweight process binding structure, and a data transmission control structure.

[0122] The binding and association module is used to fill in the channel's unique identifier and process identifier in the lightweight process binding structure and establish a one-way association with the channel's basic information structure.

[0123] The data acquisition and encapsulation module is used to control each sensor to collect environmental or status data at a preset cycle to form raw data. The corresponding lightweight process encapsulates the raw data into data blocks of a unified format, calculates the check code of the data blocks, and updates it to the data transmission control structure.

[0124] The data transmission processing module controls the lightweight process to transmit data blocks to the buffer bound to the data transmission control structure in non-blocking mode through the global data channel. The main control lightweight process reads the data blocks from the buffer. If the data block passes the verification, it is classified and processed. If the verification fails, the corresponding lightweight process is triggered to retransmit the data.

[0125] This application also provides a computer-readable storage medium storing at least one instruction or at least one program segment, which is loaded and executed by a processor to implement the multi-sensor data transmission method in the embedded device described above.

[0126] like Figure 3 As shown, an electronic device according to an embodiment of this application is provided. The electronic device includes a processor and a memory. The memory stores at least one instruction or at least one program. The at least one instruction or the at least one program is loaded and executed by the processor to implement the multi-sensor data transmission method in the embedded device described above.

[0127] This application also provides a computer program product or computer program, which includes computer instructions that, when executed by a processor, implement the multi-sensor data transmission method in the embedded device described above.

[0128] Exemplary explanations of the aforementioned devices, media, electronic devices, computer program products, or computer programs can be found in the above descriptions. Figure 1 The explanation will not be repeated here.

Claims

1. A method for transmitting multi-sensor data in an embedded device, characterized in that, include: Step 1: During the initialization of the embedded device system layer, a global data channel and lightweight processes corresponding to each sensor are created, and a channel basic information structure, a lightweight process binding structure, and a data transmission control structure are constructed. Step 2: The channel unique identifier and process identifier are filled into the lightweight process binding structure, and a one-way association with the channel basic information structure is established. Step 3: Each sensor collects data according to a preset cycle, which is then encapsulated into a unified format data block by the corresponding lightweight process. The checksum is calculated and updated to the data transmission control structure. Step 4: The lightweight process transmits the data block to the buffer bound to the data transmission control structure via the global data channel in non-blocking mode. The main control lightweight process reads the data block from this buffer. If the data block passes the checksum verification, it is classified and processed; otherwise, a retransmission is triggered. Step 4 includes... The process includes the following steps: Step 41: Each lightweight process initiates a transmission request to the global data channel based on the association between the lightweight process binding structure and the global data channel; Step 42: In response to the transmission request, the channel basic information structure provides feedback on the real-time status of the buffer through bidirectional association with the data transmission control structure. If the buffer is not full, the lightweight process writes data blocks in non-blocking mode, updates the transmission progress marker to "transmission in progress," and marks it as "transmission complete" upon completion. The transmission progress marker will be synchronized to the channel basic information structure; Step 43: After the master control lightweight process detects the transmission completion marker, it reads data blocks from the buffer and verifies the integrity using the checksum in the data transmission control structure. If the verification passes, the data is classified and processed according to the sensor type. If the verification fails, the corresponding lightweight process is triggered to retransmit. At the same time, the system layer monitors the buffer occupancy rate and transmission status.

2. The multi-sensor data transmission method in an embedded device according to claim 1, characterized in that, Step 1 includes: Step 11, creating a global data channel, assigning a unique channel identifier through the created channel basic information structure, setting the channel type to data channel, and initially setting the running state to idle. The unique channel identifier is used for the association and binding of lightweight processes; Step 12, creating a lightweight process for each sensor and assigning a unique process identifier, initializing the created lightweight process binding structure, and establishing an association between the unique process identifier and the unique channel identifier; Step 13, creating a data transmission control structure and binding it to the global data channel, configuring the buffer address, preset buffer size, initializing the transmission progress flag to not started and the checksum to 0, and synchronizing the transmission status of the global data channel bound to the data transmission control structure.

3. The multi-sensor data transmission method in an embedded device according to claim 2, characterized in that, Step 13 includes: Step 131, querying the embedded device's storage resources, allocating a dedicated buffer and recording its starting address and storage capacity. The dedicated buffer serves as a buffer bound to the created data transmission control structure. Step 132, writing the buffer address and preset buffer size into the corresponding fields of the data transmission control structure. Step 133, initializing the transmission progress marker to "not started", assigning the checksum field a value of 0, and establishing a bidirectional association between the data transmission control structure and the channel basic information structure for synchronous feedback of the transmission status.

4. The multi-sensor data transmission method in an embedded device according to claim 1, characterized in that, Step 2 includes: Step 21, filling the associated channel identifier and the unique process identifier of the corresponding lightweight process into each lightweight process binding structure, and setting the read / write permission to write only; Step 22, the system layer verifies the uniqueness of the associated information in each lightweight process binding structure to avoid channel conflicts, and the uniqueness verification enables data to be transmitted in a specific direction; Step 23, establishing a one-way association between the lightweight process binding structure and the channel basic information structure, updating the number of associated lightweight processes in the channel basic information structure to the total number of sensors, changing the running status to occupied, and the occupied status of the channel basic information structure will allow data to be written.

5. The multi-sensor data transmission method in an embedded device according to claim 4, characterized in that, Step 22 includes: Step 221, the system layer traverses all lightweight process binding structures and extracts the combination information of the associated channel identifier and process identifier; Step 222, the combination information is checked for uniqueness to avoid channel association conflicts, and if duplicates exist, a binding failure alarm is triggered; Step 223, after the verification is passed, the association mapping table of each lightweight process binding structure is recorded. The association mapping table will be used for transmission status query and verification.

6. The multi-sensor data transmission method in an embedded device according to claim 1, characterized in that, Step 3 includes: Step 31, each sensor collects environmental or status data according to a preset cycle to form raw data, and transmits the raw data to the corresponding lightweight process; Step 32, the lightweight process calls the data encapsulation interface to integrate the raw data, sensor number, and collection timestamp, and encapsulates it into a data block of a unified format according to the data transmission control structure field requirements; Step 33, calculates the checksum of the data block, and updates the checksum and data length to the corresponding field of the data transmission control structure.

7. The multi-sensor data transmission method in an embedded device according to claim 6, characterized in that, Step 32 includes: Step 321, extracting the sensor number and associating it with the unique process identifier of the corresponding lightweight process to ensure the uniqueness of the data block traceability; Step 322, obtaining the system time to generate a collection timestamp, and sorting and combining it with the raw data according to a preset format; Step 323, adding a data block header identifier and a tail check field placeholder to the sorted and combined raw data to form a data block with a unified format.

8. The multi-sensor data transmission method in an embedded device according to claim 1, characterized in that, Step 43 includes: Step 431: After the main control lightweight process reads the data block, it calculates the checksum and compares it with the checksum recorded in the data transmission control structure; Step 432: If the checksum matches, the original data, sensor number, and timestamp are extracted from the data block and sorted according to sensor type; Step 433: The system layer queries the buffer occupancy rate in real time. When the preset threshold is reached, each lightweight process is notified to pause transmission. If the checksum fails, the data block is marked as abnormal and an interrupt is triggered. The corresponding lightweight process is notified to retransmit. Pausing transmission and retransmitting will respectively avoid buffer overflow and data loss.

Images