Data transmission method, wearable device and readable storage medium

Abstract

This application discloses a data transmission method, a wearable device, and a readable storage medium, relating to the field of wearable device technology. The method is applied to a wearable device, which includes a first type of sensor, a second type of sensor, and a processor. The method includes: responding to a data transmission trigger event of the first type of sensor, initiating data transmission of first data collected by the first type of sensor, and releasing the processor after initiating data transmission; monitoring whether the data transmission of the first data is complete; if the data transmission of the first data is complete and the second type of sensor has pending data transmission needs, then initiating data transmission of second data collected by the second type of sensor during the dead time period of the first type of sensor. This application simultaneously achieves real-time transmission guarantee for high-frequency sensors and fair acquisition of low-frequency sensors without interruption.

Description

Technical Field

[0001] This application relates to the field of wearable device technology, and in particular to a data transmission method, a wearable device, and a readable storage medium. Background Technology

[0002] As smart wearable devices evolve towards miniaturization, low power consumption, and high integration, they need to incorporate multiple sensors with different sampling frequencies to achieve complex functions such as environmental perception, human-computer interaction, and status detection. Due to limitations in structural space and cost, multiple sensors typically employ a single-bus shared architecture for data transmission. Therefore, ensuring both the real-time performance of high-frequency sensors and the data acquisition effectiveness of low-frequency sensors under conditions of limited bus resources has become a core technical challenge in the design of embedded systems for wearable devices.

[0003] Currently, multi-sensor data transmission commonly employs traditional methods such as synchronous blocking acquisition, interrupt-triggered acquisition, fixed-priority polling, or time-slice polling. In the synchronous blocking method, the processor initiates bus transmission and waits until completion; the interrupt-triggered method relies on the sensor's hardware interrupt pin; and the polling method allocates bus access permissions through preset scheduling rules.

[0004] However, the aforementioned traditional methods all have drawbacks in scenarios involving shared buses for different frequency sensors: the real-time transmission requirements of high-frequency sensors are difficult to guarantee stably, low-frequency sensors are prone to data starvation, and processor resources are continuously occupied during bus transmission, preventing the parallel processing of other tasks. Therefore, how to balance the real-time transmission of high-frequency sensors and the fair scheduling of low-frequency sensors on a shared bus under uninterrupted conditions is a pressing issue that needs to be addressed. Summary of the Invention

[0005] The main objective of this application is to provide a data transmission method, a wearable device, and a readable storage medium, aiming to solve the technical problem of how to balance the real-time transmission of high-frequency sensors on a shared bus and the fair scheduling of low-frequency sensors under uninterrupted conditions.

[0006] To achieve the above objectives, this application provides a data transmission method applied to a wearable device. The wearable device includes a first type of sensor, a second type of sensor, and a processor. The data transmission frequency of the first type of sensor is higher than that of the second type of sensor, and the first type of sensor and the second type of sensor share the same bus for data transmission. The data transmission method includes the following steps: In response to a data transmission trigger event of the first type of sensor, data transmission of the first data collected by the first type of sensor is initiated, and the processor is released after the data transmission is initiated; Monitor whether the data transmission of the first data is complete; If the data transmission of the first data has been completed and the second type of sensor has a data transmission requirement to be processed, then the data transmission of the second data collected by the second type of sensor is started during the dead zone of the first type of sensor. The dead zone period refers to the time interval between the completion time of the current data transmission of the first type of sensor and the occurrence time of the next data transmission trigger event.

[0007] In one embodiment, the step of monitoring whether the data transmission of the first data is complete includes: The processor polls to see if the data transmission of the first data is complete.

[0008] In one embodiment, after the step of monitoring whether the data transmission of the first data is complete, the method further includes: If the data transmission of the first data is not completed, the processor is released, and the process returns to the step of polling the processor to check whether the data transmission of the first data is completed. If the data transmission of the first data has been completed and there is no pending data transmission requirement for the second type of sensor, the processor is released until the next data transmission trigger event of the first type of sensor occurs.

[0009] In one embodiment, after the step of initiating data transmission of the second data acquired by the second type of sensor during the dead zone of the first type of sensor, the method further includes: Release the processor; Until the next data transmission trigger event of the first type of sensor occurs, the process returns to the step of initiating data transmission of the first data collected by the first type of sensor in response to the data transmission trigger event of the first type of sensor.

[0010] In one embodiment, the data transmission period of the first type of sensor is a first duration, and the data transmission period of the second type of sensor is a second duration. The method further includes: The data transmission trigger event of the first type of sensor is triggered every first duration, and the counting cycle is incremented once. When the cumulative duration corresponding to the accumulated counting cycles reaches an integer multiple of the second duration, the data transmission requirement of the second type of sensor is triggered.

[0011] In one embodiment, the wearable device includes a plurality of second-type sensors. The step of initiating data transmission of the second data collected by the second-type sensors during the dead zone of the first-type sensors, if the data transmission of the first data has been completed and the second-type sensors have pending data transmission needs, includes: If the data transmission of the first data has been completed, then the second type of sensor with unprocessed data transmission needs among the second type of sensors is identified as the target sensor; If there is only one target sensor, then data transmission of the second data collected by the target sensor is initiated during the dead zone of the first type of sensor. If there are multiple target sensors, the data transmission of the second data collected by each target sensor is initiated sequentially during the dead zone of the first type of sensor in a preset order.

[0012] In one embodiment, after the step of sequentially initiating the data transmission of the second data collected by each of the target sensors in a preset order during the dead zone period of the first type of sensor, the method further includes: After each second data transmission of a target sensor is initiated, the processor is released, and the data transmission of the target sensor currently transmitting data is monitored to see if it is complete. If completed, the data transmission of the second data of the next target sensor is started in the preset order, and the process returns to the step of releasing the processor and monitoring whether the current data transmission is completed, until the data transmission of all the target sensors is completed; If not completed, the processor is released, and the process returns to the step of monitoring whether the data transmission of the target sensor currently transmitting data is complete.

[0013] In one embodiment, the first type of sensor is an ambient light sensor, and after the step of monitoring whether the data transmission of the first data is completed, the method further includes: If it is detected that the data transmission of the first data has been completed, the processor reads the first data that has been transmitted. Brightness adjustment processing is performed based on the first data read.

[0014] In addition, to achieve the above objectives, this application also provides a wearable device, which includes a first type of sensor, a second type of sensor, and a processor. The data transmission frequency of the first type of sensor is higher than that of the second type of sensor, and the first type of sensor and the second type of sensor share the same bus for data transmission. The processor is used to execute the steps of the data transmission method described above.

[0015] In addition, to achieve the above objectives, this application also provides a readable storage medium, which is a computer-readable storage medium, on which a computer program is stored, and the computer program is executed by a processor to implement the steps of the data transmission method described above.

[0016] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the data transmission method described above.

[0017] One or more technical solutions proposed in this application have at least the following technical effects: This embodiment of the application initiates data transmission of the first type of sensor in response to a high-frequency acquisition trigger event and immediately releases the processor after transmission begins. This avoids continuous occupation of processor resources during bus transmission, allowing the processor to execute other tasks in parallel, improving hardware resource utilization efficiency, and solving the defects of processor idling and inability to process tasks in parallel under the traditional synchronous blocking method. Furthermore, it monitors whether the data transmission of the first type of sensor is complete. Once the transmission is complete and the second type of sensor has pending data transmission needs, it initiates data transmission of the second type of sensor during the dead time of the first type of sensor. This mechanism allows the low-frequency second type of sensor to obtain a definite scheduling opportunity during the dead time, preventing it from preempting the bus access rights of the high-frequency sensor when the trigger event arrives, thus ensuring the stability of real-time transmission of the high-frequency sensor. It also avoids the acquisition starvation problem of low-frequency sensors due to bus contention or unreasonable scheduling rules under the traditional fixed-priority polling or time-slice polling methods. Therefore, sensors of different frequencies on the shared bus can achieve orderly and coordinated acquisition. Moreover, the entire coordination process does not rely on the sensor's hardware interrupt pins; it only utilizes differentiated scheduling during the dead time to complete the bus access management of multiple sensors, which can well adapt to the compact hardware design constraints of miniaturized, low-cost wearable devices. In summary, this solution simultaneously achieves real-time transmission assurance for high-frequency sensors, fair acquisition of low-frequency sensors, and low processor resource consumption under uninterrupted conditions, systematically solving the technical challenges in scenarios where different frequency sensors share a bus. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0019] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a flowchart illustrating the first embodiment of the data transmission method of this application; Figure 2 This is a timing diagram of a 20-millisecond window data transmission method according to an embodiment of the data transmission method of this application; Figure 3 This is a schematic diagram of CPU time allocation involved in an embodiment of the data transmission method of this application; Figure 4 This is a schematic diagram of an uninterrupted sensor topology involved in an embodiment of the data transmission method of this application; Figure 5 This is a comparative schematic diagram of the synchronous blocking scheme and the asynchronous coordination scheme involved in an embodiment of the data transmission method of this application.

[0021] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0022] To make the above-mentioned objects, features, and advantages of the present invention more apparent and understandable, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0023] Currently, data transmission on a multi-sensor shared bus mainly employs the following schemes: The first is synchronous blocking acquisition, where the CPU (Central Processing Unit) initiates I²C (Inter-Integrated Circuit) transmission and then blocks until completion. Its key drawback is a CPU idle rate of up to 100%, making it unable to process other tasks in parallel. The second is interrupt-triggered acquisition, relying on the sensor's INT (Interrupt) pin to trigger an interrupt, but this consumes GPIO (General-purpose Input / Output) resources, which is unsuitable due to space constraints in the temples of smart glasses. The third is DMA (Direct Memory Access) asynchronous transmission, which completes data transfer by configuring DMA for the I²C peripheral. However, this scheme limits the selection of the MCU (Microcontroller Unit), increases hardware costs, and the temple PCB area is insufficient to accommodate DMA-related circuitry. The fourth is fixed-priority polling, where high-priority devices monopolize the bus, causing low-priority devices to be unable to acquire data for extended periods, resulting in a "starvation" phenomenon. The fifth method is time-slice polling, where each device is allocated a time slice equally; however, the real-time performance of high-frequency devices cannot be guaranteed.

[0024] Furthermore, the temple space of smart glasses presents stringent uninterruptible hardware constraints: ALS (Ambient Light Sensor), CAP (Capacitive Sensor), and PSensen (Proximity Sensor) lack interrupt pins, making data acquisition impossible to trigger via hardware interrupts and relying entirely on software polling. Simultaneously, multiple sensors with different frequencies need to coexist: ALS, with a sampling rate of 200Hz and a period of 5ms, is used for automatic brightness adjustment, requiring constant bus access for zero-latency acquisition; CAP, with a sampling rate of 50Hz and a period of 20ms, is used for gesture recognition, allowing some delay but not allowing it to become idle; PSensen, with a sampling rate of 10Hz and a period of 100ms, is used for wear detection and screen-off detection, also allowing delay but not allowing it to become idle. This creates a core contradiction: the 5ms period of ALS must be strictly guaranteed; missing it will lead to data overflow, and the lag in brightness adjustment will be noticeably perceived by the user; while if CAP and PSensen randomly initiate transmission, they might occupy the bus, thus blocking ALS acquisition at the designated time points. Therefore, the technical challenge is: how to enable ALS to preempt the bus at any time under uninterrupted conditions through pure software, while ensuring that CAP and PSenser are not starved.

[0025] To address the aforementioned issues, the main solution of this application is as follows: in response to a data transmission trigger event of the first type of sensor, data transmission of the first data collected by the first type of sensor is initiated, and the processor is released after the data transmission is initiated; the completion of the data transmission of the first data is monitored; if the data transmission of the first data has been completed and the second type of sensor has pending data transmission requirements, data transmission of the second data collected by the second type of sensor is initiated during the dead time of the first type of sensor; wherein, the dead time refers to the time period from the completion time of the current data transmission of the first type of sensor to the occurrence time of the next data transmission trigger event.

[0026] This application initiates data transmission for the first type of sensor in response to a high-frequency acquisition trigger event and immediately releases the processor after transmission begins. This avoids continuous occupation of processor resources during bus transmission, allowing the processor to execute other tasks in parallel, improving hardware resource utilization efficiency, and solving the shortcomings of traditional synchronous blocking methods where the processor idles and cannot process tasks in parallel. Furthermore, it monitors whether the first data transmission is complete. Once this transmission is complete and the second type of sensor has pending data transmission needs, it initiates data transmission for the second type of sensor during the dead time of the first type of sensor. This mechanism allows the low-frequency second type of sensor to obtain a definite scheduling opportunity during the dead time, preventing it from preempting the bus access rights of the high-frequency sensor when the trigger event arrives, thus ensuring the stability of real-time transmission of the high-frequency sensor. It also avoids the acquisition starvation problem of low-frequency sensors due to bus contention or unreasonable scheduling rules under traditional fixed-priority polling or time-slice polling methods. Therefore, sensors of different frequencies on the shared bus can achieve orderly and coordinated acquisition. Moreover, the entire coordination process does not rely on the sensor's hardware interrupt pins; it only utilizes differentiated scheduling during the dead time to complete the bus access management of multiple sensors, making it well-suited to the compact hardware design constraints of miniaturized, low-cost wearable devices. In summary, this solution simultaneously achieves real-time transmission assurance for high-frequency sensors, fair acquisition of low-frequency sensors, and low processor resource consumption under uninterrupted conditions, systematically solving the technical challenges in scenarios where different frequency sensors share a bus.

[0027] Based on this, this application proposes a data transmission method according to a first embodiment. In this embodiment, the data transmission method is applied to a wearable device, which includes a first type of sensor, a second type of sensor, and a processor. The data transmission frequency of the first type of sensor is higher than that of the second type of sensor, and the first type of sensor and the second type of sensor share the same bus for data transmission. Figure 1 As shown, the data transmission method includes the following steps S10~S30: Step S10: In response to the data transmission trigger event of the first type of sensor, start the data transmission of the first data collected by the first type of sensor, and release the processor after starting the data transmission; Wearable devices refer to smart electronic devices that can be worn on the human body or attached to clothing, such as smartwatches, smart bracelets, and smart glasses.

[0028] In this embodiment, the first type of sensor is a sensor with a high data transmission frequency, such as, but not limited to, an ambient light sensor (ALS) with a frequency of up to 100Hz, used to detect ambient brightness in real time to automatically adjust the screen backlight; the second type of sensor is a sensor with a lower frequency, such as, but not limited to, a capacitive sensor (CAP) and a proximity sensor (Psensor), with a frequency of around 10Hz, used for touch detection and wearing status recognition, respectively.

[0029] The data transmission trigger event for the first type of sensor can be generated by an internal timer overflow, a change in the data ready flag, or a periodic acquisition task set by the software. When the processor detects this trigger event, it immediately initiates a transmission operation on the first data acquired by the first type of sensor through a shared bus (e.g., a single I²C bus), such as sending a read command and starting to receive data.

[0030] The system can adopt a multi-threaded scheduling architecture: the acquisition thread of the first type of sensor is configured with the highest priority and is responsible for responding to its data transmission trigger events; the acquisition logic of the second type of sensor does not occupy a thread independently, but is embedded in the acquisition thread of the first type of sensor and is triggered to execute during its dead time; other background processing tasks (such as data management of other non-real-time sensors) are configured with lower priority.

[0031] When the data transmission trigger event of the first type of sensor arrives, the highest priority acquisition thread immediately gains processor execution rights. This thread first checks the bus status, and after confirming that the bus is idle, it initiates the transmission operation of the first data acquired by the first type of sensor (such as sending a read command and starting to receive data) through a shared bus (e.g., a single bus).

[0032] At the moment the transmission is initiated (i.e., after the transmission start command is sent to the bus controller), the thread actively calls a release operation (such as Yield) to immediately relinquish processor resources, allowing the processor to execute lower-priority background tasks, such as head tracking, display refresh, or wireless communication. If there are no such background tasks to process at the moment, the thread can enter an idle waiting state. The description of the processor state after the release operation in the following text is the same as here and will not be repeated.

[0033] After the processor initiates the data transfer, the bus controller independently completes the subsequent data transfer process, enabling the processor and bus transfer to work in parallel.

[0034] The scheduling logic for the second type of sensor does not independently preempt the processor; instead, it is embedded within the subsequent process of the first type of sensor acquisition thread. This avoids the additional context switching overhead caused by a separate thread for low-frequency sensors. Simultaneously, during the period when the first type of sensor acquisition thread releases the processor, lower-priority background tasks can run. Therefore, without affecting the real-time performance of high-frequency sensors, the bus transmission waiting window is fully utilized for processing other tasks, achieving efficient use of processor resources and overcoming the time and power waste caused by processor idling in traditional synchronous blocking methods.

[0035] Step S20: Monitor whether the data transmission of the first data is complete; The processor periodically or on an event-triggered basis checks whether the current data transmission of the first type of sensor has been completed by querying the status flags of the bus controller through software or by using other means.

[0036] Specifically, the processor can call a lightweight monitoring function during gaps in the execution of other tasks (such as at the end of an iteration of the main loop or in the system tick timer interrupt service routine). This function only needs to read the "transfer complete" status flag of the bus controller, which is automatically set when the bus hardware completes data transmission or reception.

[0037] In systems that support DMA (Direct Memory Access), DMA can be configured to automatically receive the first data, and the end time of the transfer can be notified by a DMA transfer completion interrupt (this interrupt comes from the DMA controller, not the sensor hardware pin). Without DMA, the processor can set a very short polling window (e.g., polling every few microseconds). Since a single data transfer typically takes tens of microseconds, this polling overhead is far less than the traditional blocking wait method.

[0038] Step S30: If the data transmission of the first data has been completed and the second type of sensor has a data transmission requirement to be processed, then the data transmission of the second data collected by the second type of sensor is started during the dead zone of the first type of sensor; wherein, the dead zone refers to the time period from the time when the current data transmission of the first type of sensor is completed to the time when the next data transmission trigger event occurs.

[0039] After the processor confirms the completion of the first data transmission, it determines whether the second type of sensor has any pending processing needs. This determination can be made using various software methods, such as checking the data readiness flag, the status of the circular buffer, or a frequency reduction determination based on cycle counting. Taking the cycle counting method as an example: a counter is maintained to record the number of transmissions from the first type of sensor, and modulo operations are used to determine when to activate the low-frequency sensor. For example, if it is desired that the acquisition frequency of CAP be reduced to 1 / 4 of ALS, then the modulus is set to 4, and the remainder is selected as 1 (CAP is activated during the dead zone when the count value %4 == 1); if it is desired that the Psensor be reduced to 1 / 20, then the modulus is set to 20, and the remainder is selected as 4. The modulus corresponds to the frequency reduction ratio, and the remainder is used to stagger the scheduling times of different sensors.

[0040] Once a pending request is confirmed, the processor immediately initiates data transmission for the second type of sensor upon completion of the first data transmission. At this point, the bus is idle and only the low-frequency sensor requests access, eliminating the need for bus arbitration. Thus, the low-frequency sensor obtains a guaranteed bus access opportunity without interfering with the next real-time transmission from the high-frequency sensor.

[0041] Through the above mechanism—which initiates transmission immediately based on the processing needs of low-frequency sensors during the dead zone of the first type of sensor without arbitration—orderly, fair, and low-overhead acquisition of low-frequency sensors is achieved without relying on hardware interrupt pins or preempting the real-time performance of high-frequency sensors. This effectively solves the acquisition starvation problem that is prone to occur in low-frequency sensors under traditional polling or time-slice methods.

[0042] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description and will not be repeated hereafter. Based on this, the step of monitoring whether the data transmission of the first data is completed includes: Step A10: The processor polls to see if the data transmission of the first data is complete.

[0043] After the processor initiates and releases the data transmission of the first type of sensor, it does not enter a waiting state. Instead, it actively initiates a polling query on the bus controller's transmission completion status flag at appropriate times (such as after each other short-term task is completed, or at a specific checkpoint when entering the main loop).

[0044] Each polling operation has minimal overhead, typically involving only a few instructions such as reading registers and performing bit comparisons with the completion flag. The processor can execute other application tasks (such as sensor data fusion, user interface responses, etc.) between two polls, thereby achieving coarse-grained parallelism between bus transfers and computational tasks.

[0045] The timing of polling can be dynamically adjusted based on system load, for example, by checking before each context switch of the task scheduler, or by being triggered by a timer at non-fixed intervals.

[0046] In a preferred embodiment, the processor periodically polls to determine whether the data transmission of the first data is complete. The polling period is set to one-fifth to one-third of the expected time for a single data transmission from the first type of sensor. For example, if the expected transmission time is 100 microseconds, the polling period is set to 20 microseconds. Alternatively, a variable-period polling strategy can be employed: a longer polling interval is used initially after transmission begins, switching to a shorter interval as the expected completion time approaches, to balance efficiency and timeliness. By periodically polling instead of blocking and waiting, the completion time of the first data transmission can be accurately determined with low processor resource overhead even on simplified hardware platforms lacking DMA or transmission completion interrupt support.

[0047] In one possible implementation, after the step of monitoring whether the data transmission of the first data is complete, the method further includes: Step B10: If the data transmission of the first data is not completed, release the processor and return to the step of polling the processor to check whether the data transmission of the first data is completed. During the polling process, if the processor detects that the data transmission of the first data has not yet been completed (i.e., the transmission completion flag of the bus controller is not set), the processor will not block and wait.

[0048] At this point, the processor actively releases its resources and continues executing other background tasks. After the release, the system returns to step A10, which means that at some later time, it will again initiate a polling query to check the completion status of the first data transmission.

[0049] This process repeats until a complete transfer is detected at a certain polling point. This "polling-incomplete-release-return" mechanism ensures that the processor remains in a state where it can perform other tasks while waiting for a bus transfer, allowing it to promptly detect when the transfer is complete without wasting computing resources by idling.

[0050] Step B20: If the data transmission of the first data has been completed and the second type of sensor does not have any pending data transmission requirements, then the processor is released until the next data transmission trigger event of the first type of sensor occurs.

[0051] During polling, if the processor detects that the data transmission of the first data has been completed, but after judgment (such as checking the data ready flag, the state of the ring buffer, or the frequency reduction judgment based on cycle count) confirms that there is no pending data transmission requirement for any of the second type of sensors, the processor will not initiate the transmission of any second type of sensor.

[0052] At this point, the processor releases its resources and continues executing other background tasks until the next data transmission trigger event from the first type of sensor arrives. During this period, the processor can execute other lower-priority background tasks or enter a low-power sleep mode to conserve power.

[0053] This step ensures that the dead time is not wasted when there is no need for low-frequency acquisition, and the processor can wait for the next high-frequency transmission cycle to be triggered with minimal overhead, thereby further optimizing the overall system energy efficiency.

[0054] In one possible implementation, after the step of initiating data transmission of the second data acquired by the second type of sensor during the dead zone of the first type of sensor, the method further includes: Step C10: Release the processor; After initiating the data transmission of the second type of data collected by the second type of sensor, the processor does not wait for the transmission to complete but immediately releases processor resources. At this point, the processor can switch to executing other background tasks.

[0055] This design continues the "boot-and-release" philosophy, ensuring that the processor's computing power is fully utilized throughout the entire bus transmission process, avoiding wasted resources while waiting for low-frequency sensor transmissions.

[0056] Step C20: Until the next data transmission trigger event of the first type of sensor occurs, return to the step of initiating data transmission of the first data collected by the first type of sensor in response to the data transmission trigger event of the first type of sensor.

[0057] After being released, the processor continues to run other background tasks or remains idle until the next data transmission trigger event from the Type 1 sensor occurs. This trigger event can be generated by an internal timer, a data ready flag, or a periodic software task.

[0058] When an event occurs, the process returns to step S10, whereby the highest-priority first-type sensor acquisition thread regains processor execution rights and initiates a new round of first data transmission. This cycle repeats continuously, forming a stable acquisition loop dominated by high-frequency sensors and with low-frequency sensors interspersed during dead zones. This ensures that the real-time performance of high-frequency sensors is not disturbed, while also achieving reasonable reuse of bus resources.

[0059] Based on the first and / or second embodiments of this application, in the third embodiment of this application, the content that is the same as or similar to that in embodiments one and two above can be referred to the above description and will not be repeated hereafter. On this basis, the data transmission period of the first type of sensor is a first duration, the data transmission period of the second type of sensor is a second duration, and the method further includes: Step D10: Trigger the data transmission trigger event of the first type of sensor every first duration, and increment the count cycle by one. The data transmission period for the first type of sensor is configured to a first duration. A data transmission trigger event for the first type of sensor can be triggered once every first duration via a timer or periodic interrupt.

[0060] Each time this event occurs, a count cycle variable is incremented. This variable records the number of data transmissions initiated by the first type of sensor. The count cycle can be incremented either at the arrival of each trigger event or after each first data transmission is completed, as long as it remains synchronized with the first duration.

[0061] Step D20: When the cumulative duration corresponding to the accumulated counting cycle reaches an integer multiple of the second duration, the data transmission requirement of the second type of sensor is triggered.

[0062] A data transmission period, denoted as the second duration, is preset for each type II sensor. The second duration is typically an integer multiple of the first duration, indicating the rate of downsampling of the desired acquisition frequency of the type II sensor relative to that of the type I sensor.

[0063] After each counting cycle, the system calculates the cumulative duration elapsed since the start time, which is the counting cycle value multiplied by the first duration. When the cumulative duration is exactly an integer multiple of the second duration (e.g., one, two, three, etc.), it is determined that the second type of sensor has a data transmission requirement to be processed, and its data transmission is initiated during the subsequent dead zone of the first type of sensor.

[0064] If multiple second-type sensors exist with different second durations, they are triggered independently according to their respective multiples. This mechanism requires no additional hardware interrupts; it precisely controls the acquisition timing of low-frequency sensors solely through timing and counting, ensuring a stable periodic collaborative relationship between them and high-frequency sensors.

[0065] In one possible implementation, the wearable device includes a plurality of second-type sensors. The step of initiating data transmission of the second data collected by the second-type sensors during the dead zone of the first-type sensors, if the data transmission of the first data has been completed and the second-type sensors have pending data transmission needs, includes: Step E10: If the data transmission of the first data has been completed, then the second type of sensor with unprocessed data transmission requirements among the second type of sensors is identified as the target sensor. Once the processor detects that the first data transmission is complete, it immediately performs a requirement check on all second-class sensors.

[0066] Each second-class sensor can independently determine whether it has a data transmission requirement to be processed based on its own scheduling rules (such as data ready flag, non-empty state of the circular buffer, frequency reduction judgment based on period count, or multiple relationship between cumulative duration and second duration, etc.).

[0067] Those second-category sensors identified as having pending processing needs are selected and marked as target sensors. If no second-category sensor has a need, the processor is released until the next trigger event of a first-category sensor.

[0068] Step E20: If there is only one target sensor, then data transmission of the second data collected by the target sensor is initiated during the dead zone of the first type of sensor. If, after screening, the number of target sensors is exactly one, the processor does not need to make a sequential decision.

[0069] Immediately following the completion of the first data transmission, the processor initiates the transmission of the second data to the single target sensor. At this point, the bus is idle and only one sensor is requesting access; no bus arbitration is required, and a read command is sent directly to begin receiving the second data.

[0070] After the transmission is initiated, processor resources are released, freeing up the CPU for other background tasks, thus enabling parallel transmission and computation.

[0071] Step E30: If there are multiple target sensors, the data transmission of the second data collected by each target sensor is initiated sequentially during the dead zone of the first type of sensor in a preset order.

[0072] If, after screening, multiple Type II sensors simultaneously have data transmission needs to be processed, the processor needs to determine their transmission order.

[0073] A preset scheduling order is provided, which can be determined based on factors such as the priority of each type of sensor, its required transmission time, or the desired data acquisition balance. For example, the sensors can be scheduled in ascending order by type number or in ascending order of frequency reduction factor.

[0074] During the dead time, the processor initiates data transmission for each target sensor sequentially according to a preset order. After initiating the transmission for the first target sensor, the processor can choose to release and wait for it to complete before initiating the next one; or it can issue multiple transmission commands sequentially within a continuous time window, which are then executed sequentially by the bus controller. Since the duration of the dead time is fixed, and the transmission time for each type of second sensor is usually much shorter than the dead time, this sequential scheduling can successfully complete the transmission of all the second data in most cases.

[0075] Throughout the sequential scheduling process, the processor continuously monitors the remaining time during the dead zone to ensure that all transmissions from the second type of sensor end before the next trigger event from the first type of sensor, thus not interfering with the real-time performance of the high-frequency sensor.

[0076] In one possible implementation, after the step of sequentially initiating the data transmission of the second data collected by each of the target sensors in a preset order during the dead zone of the first type of sensor, the method further includes: Step F10: After each second data transmission of a target sensor is initiated, the processor is released, and the data transmission of the target sensor currently transmitting data is monitored to see if it is complete. During the dead zone, whenever the processor initiates the transmission of second data from a target sensor (e.g., sending a read command and starting to receive data), the processor does not wait for the transmission to complete, but immediately releases processor resources and executes other background tasks.

[0077] Simultaneously, the processor needs to monitor the completion status of this transmission. Monitoring can be achieved by polling the transmission completion flag on the bus controller, or by utilizing other lightweight checking mechanisms. This step extends the "start-and-release" principle to the sequential transmission of multiple Type II sensors, ensuring that the processor is effectively utilized during each transmission.

[0078] If step F20 has been completed, the data transmission of the second data of the next target sensor is started in the preset order, and the process returns to the step of releasing the processor and monitoring whether the current data transmission is completed, until the data transmission of all the target sensors is completed. Once the processor detects that the second data of the target sensor currently being transmitted has been completed, if there are other target sensors that have not yet been transmitted, the next target sensor will be selected according to a preset order.

[0079] The processor immediately initiates the data transmission of the second data from the next target sensor, then releases the processor again after initiation and returns to step F10, which releases the processor and monitors whether the transmission is complete.

[0080] This process repeats until the second data from all target sensors has been transmitted. Throughout the entire process, the processor maintains an alternating busy and idle state, avoiding continuous blocking and waiting caused by sequential transmission.

[0081] If step F30 is not completed, the processor is released and the process returns to the step of monitoring whether the data transmission of the target sensor currently transmitting data is complete.

[0082] During the monitoring process, if the processor finds that the second data from the current target sensor has not yet been transmitted, it will not enter a waiting or blocking state.

[0083] The processor then proactively releases its resources to execute other background tasks, and then returns to the monitoring step, that is, to confirm whether the transmission is complete again during the next polling or checking.

[0084] This "incomplete-release-return monitoring" loop will continue until the data transmission of the current target sensor is complete. This mechanism ensures that the processor is not idle during the transmission of a single Type II sensor, consuming minimal overhead only at each monitoring moment, thereby maximizing the system's parallel processing capabilities.

[0085] In one possible implementation, the first type of sensor is an ambient light sensor; after the step of monitoring whether the data transmission of the first data is completed, the method further includes: Step G10: If it is detected that the data transmission of the first data has been completed, then the processor reads the first data that has been transmitted. Once the processor confirms through polling or other monitoring methods that the first data from the first type of sensor (ambient light sensor in this example) has been fully received by the bus controller, the processor reads the first data from the bus controller or the receive buffer.

[0086] Read operations typically involve retrieving the raw light intensity value from the data register and may include byte concatenation, format conversion, or verification. Since the initial data has already been transmitted at the hardware level, this read operation is merely a memory copy or register access operation, which is extremely short and will not significantly impact subsequent scheduling.

[0087] Step G20: Perform brightness adjustment processing based on the read first data.

[0088] The processor calculates or looks up a table to determine the display backlight level that is appropriate for the current ambient brightness based on the first data read (i.e., the ambient light intensity value).

[0089] Subsequently, the processor performs brightness adjustment operations, such as adjusting the output duty cycle of the backlight driver circuit through pulse width modulation, or writing a new brightness register value to the display controller, so that the screen brightness of the wearable device adapts to the ambient light and realizes the automatic brightness adjustment function.

[0090] The brightness adjustment process is performed during the dead zone after the current data transmission of the first type of sensor is completed and before the next trigger event arrives, or in a background task. It will not delay subsequent high-frequency sensor acquisition, nor will it occupy the critical window of bus transmission.

[0091] For example, to aid in understanding the technical concept or principle of the data transmission method combined with the first and second embodiments described above, a specific embodiment is now provided. In this specific embodiment, data transmission is applied to a wearable device, which includes a shared I... 2 The ALS sensor, CAP sensor, and PSenser transmit data via the C-bus. The ALS sensor operates at 200Hz with a period of 5ms and is used for automatic brightness adjustment. It needs to preempt the bus at any time and has zero latency. The CAP sensor operates at 50Hz with a period of 20ms and is used for gesture recognition. It can be delayed but cannot be idle. The PSenser operates at 10Hz with a period of 100ms and is used for wear detection and screen off. It can be delayed but cannot be idle.

[0092] The core mechanism of Asynchronous Coordinated Collection (ACC) is adopted, following the design principles of high priority of ALS, fully asynchronous non-blocking, cycle dead zone utilization, and low-frequency device coordination. The ALS acquisition thread is set to the highest priority, which can preempt the CPU at any time and start acquisition immediately when the bus is idle. After any sensor I²C is started, it immediately yields to free up the CPU to handle other tasks. The data transmission of CAP and PSenser is completed immediately within the dead zone between the completion of ALS and the start of the next cycle. Moreover, CAP and PSenser are only started in the ALS dead zone and do not block the next cycle.

[0093] In terms of thread coordination, the ALS acquisition thread is responsible for 200Hz light sensing transmission. It accesses the bus according to the strategy of checking bus idle, starting immediately, yielding, polling, and then starting the CAP / PSensor immediately afterward. The CAP / PSensor logic is embedded in the ALS thread and transmits at a reduced frequency of 50Hz and 10Hz. It starts immediately during the ALS dead zone without independently preempting the CPU. The SensorManager thread has a lower priority and is responsible for handling other sensors such as IMU and TOF. It runs during the ALS, CAP, and PSensor Yield periods.

[0094] Reference Figure 2 As shown, this is the timing sequence for the 20ms window acquisition in this specific embodiment. The time axis is in ms, and the key time nodes are 0, 5, 10, 20, and 25. The ALS cycle is divided into P1, P2, P3, P4, and P5 in sequence. The bus must be kept idle at each cycle point to ensure that the ALS can acquire the bus immediately. P1 corresponds to 0ms-5ms, including ALS and CAP acquisition. From 0ms-0.8ms, ALS is transmitted asynchronously and the CPU yields to the SM. From 0.8ms-2.6ms, CAP is transmitted asynchronously and the CPU yields to the SM. From 2.6ms-5ms, it is an idle period and the CPU yields to the SM to wait for the next cycle. After ALS is completed, CAP is started immediately without bus arbitration. P2 corresponds to 5ms-10ms, only performing ALS acquisition. From 5ms-5.8ms, ALS is transmitted asynchronously and the CPU yields to the SM. From 5.8ms-10ms, it is an idle period and the CPU yields to the SM. P4 corresponds to 15ms-20ms, a special cycle that sequentially performs ALS, CAP, and PSenser acquisition. After ALS is completed, CAP is started immediately, and after CAP is completed, PSenser is started immediately. There is no bus arbitration throughout the process.

[0095] Reference Figure 3 The diagram shows the CPU time allocation within the P1 cycle. Key time nodes are 0ms, 0.1ms, 0.8ms, 0.9ms, 2.1ms, 2.6ms, and 5ms. ALS startup is completed and immediately yielded within 0.1ms. ALS transfer is completed at 0.8ms, followed by CAP startup and yielding. CAP transfer is completed at 2.6ms. The ALS thread only occupies CPU during the startup, immediate startup, and read phases, totaling 0.3ms. The SM thread runs for 4.7ms, accounting for 94% of the cycle. Bus occupancy is 2.0ms (0.8ms for ALS + 1.2ms for CAP), accounting for 40% of the cycle. Bus idle time is 3.0ms, accounting for 60%, ensuring normal ALS startup at the 5ms cycle point. During the yielding phase, the SM thread handles tasks such as IMU, head tracking, TOF depth detection, button presses, and touch input.

[0096] Reference Figure 4The diagram shows the uninterrupted sensor topology of the smart glasses temple. The MCU within the temple connects to three types of uninterrupted pin sensors: ALS, CAP, and PSenser, via an I²C bus. These three sensors share the bus and rely on pure software coordination. ALS operates on a strict 200Hz, 5ms cycle, has no INT pin, and has the highest priority, allowing it to preempt the bus at any time for zero-latency data acquisition. CAP operates on a 50Hz, 20ms cycle, has no INT pin, and transmits immediately after the ALS dead zone. PSenser operates on a 10Hz, 100ms cycle, has no INT pin, and transmits immediately after the ALS dead zone. An IMU is used for 1kHz head tracking, and a TOF is used for 20Hz depth detection; both processes occur during the ALS, CAP, and PSenser yield periods. The overall hardware meets the constraints of no INT pins, no DMA, compact structure, and low cost. This solution is implemented through pure software asynchronous coordination, requiring no additional hardware modifications.

[0097] Reference Figure 5 As shown, this is a comparison between asynchronous coordinated acquisition and synchronous blocking acquisition. In the synchronous blocking scheme, under uninterrupted conditions, the CPU continuously blocks after initiating I²C, waiting for the transmission to complete. The CPU idles 100% throughout the process, the SM (Smart Monitor) cannot run, leading to lost head tracking and delayed brightness adjustment, with a total time of 3.2ms. In contrast, this ACC (Adaptive Acquisition) scheme, within the same timeframe, allows the CPU to continuously yield during I²C transmission, and the SM can run normally, achieving a CPU utilization of 94%. It achieves equivalent DMA performance under uninterrupted pure software conditions, with real-time head tracking and zero-latency brightness adjustment.

[0098] It should be noted that the above examples are only used to help understand this embodiment and do not constitute a limitation on the data transmission process of this embodiment. Any simple modifications based on this technical concept are within the protection scope of this application.

[0099] Furthermore, this application also proposes a wearable device, which includes a first type of sensor, a second type of sensor, and a processor. The data transmission frequency of the first type of sensor is higher than that of the second type of sensor, and the first type of sensor and the second type of sensor share the same bus for data transmission. The processor is used to execute the steps of the data transmission method described above.

[0100] The wearable device provided in this application, employing the data transmission method described in the above embodiments, can solve the technical problem of balancing real-time transmission of high-frequency sensors and fair scheduling of low-frequency sensors on a shared bus under uninterrupted conditions. Compared with the prior art, the beneficial effects of the wearable device provided in this application are the same as those of the data transmission method provided in the above embodiments, and other technical features of the wearable device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0101] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0102] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0103] In addition, to achieve the above objectives, embodiments of this application also provide a readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the data transmission method in the above embodiments.

[0104] The computer-readable storage medium provided in this application embodiment may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections with one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0105] The aforementioned computer-readable storage medium may be included in the wearable device; or it may exist independently and not assembled into the wearable device.

[0106] The aforementioned computer-readable storage medium carries one or more programs, which, when executed by a wearable device, cause the wearable device to perform the process steps of any embodiment of the aforementioned data transmission method.

[0107] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0108] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0109] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the modules themselves.

[0110] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described data transmission method. This solves the technical problem of balancing real-time transmission of high-frequency sensors and fair scheduling of low-frequency sensors on a shared bus under uninterrupted conditions. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the data transmission method provided in the above embodiments, and will not be repeated here.

[0111] Furthermore, embodiments of this application also propose a computer program product, including a computer program that, when executed by a processor, implements the steps of the data transmission method described above.

[0112] The specific implementation of the computer program product in this application is basically the same as the embodiments of the data transmission method described above, and will not be repeated here.

[0113] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element.

[0114] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0115] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software sensor. This computer software sensor is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a wearable device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0116] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A data transmission method, characterized in that, This method is applied to wearable devices, which include a first type of sensor, a second type of sensor, and a processor. The first type of sensor has a higher data transmission frequency than the second type of sensor, and the first type of sensor and the second type of sensor share the same bus for data transmission. The data transmission method includes the following steps: In response to a data transmission trigger event of the first type of sensor, data transmission of the first data collected by the first type of sensor is initiated, and the processor is released after the data transmission is initiated; Monitor whether the data transmission of the first data is complete; If the data transmission of the first data has been completed and the second type of sensor has a data transmission requirement to be processed, then the data transmission of the second data collected by the second type of sensor is started during the dead zone of the first type of sensor. The dead zone period refers to the time interval between the completion time of the current data transmission of the first type of sensor and the occurrence time of the next data transmission trigger event.

2. The data transmission method as described in claim 1, characterized in that, The step of monitoring whether the data transmission of the first data is complete includes: The processor polls to see if the data transmission of the first data is complete.

3. The data transmission method as described in claim 2, characterized in that, After the step of monitoring whether the data transmission of the first data is complete, the method further includes: If the data transmission of the first data is not completed, the processor is released, and the process returns to the step of polling the processor to check whether the data transmission of the first data is completed. If the data transmission of the first data has been completed and there is no pending data transmission requirement for the second type of sensor, the processor is released until the next data transmission trigger event of the first type of sensor occurs.

4. The data transmission method as described in claim 2, characterized in that, After the step of initiating data transmission of the second data collected by the second type of sensor during the dead zone period of the first type of sensor, the method further includes: Release the processor; Until the next data transmission trigger event of the first type of sensor occurs, the process returns to the step of initiating data transmission of the first data collected by the first type of sensor in response to the data transmission trigger event of the first type of sensor.

5. The data transmission method as described in claim 1, characterized in that, The data transmission period of the first type of sensor is a first duration, and the data transmission period of the second type of sensor is a second duration. The method further includes: The data transmission trigger event of the first type of sensor is triggered every first duration, and the counting cycle is incremented once. When the cumulative duration corresponding to the accumulated counting cycles reaches an integer multiple of the second duration, the data transmission requirement of the second type of sensor is triggered.

6. The data transmission method as described in claim 1, characterized in that, The wearable device includes multiple second-type sensors. The step of initiating data transmission of the second data collected by the second-type sensors during the dead zone of the first-type sensors, if the data transmission of the first data has been completed and the second-type sensors have pending data transmission needs, includes: If the data transmission of the first data has been completed, then the second type of sensor with unprocessed data transmission needs among the second type of sensors is identified as the target sensor; If there is only one target sensor, then data transmission of the second data collected by the target sensor is initiated during the dead zone of the first type of sensor. If there are multiple target sensors, the data transmission of the second data collected by each target sensor is initiated sequentially during the dead zone of the first type of sensor in a preset order.

7. The data transmission method as described in claim 6, characterized in that, After the step of sequentially initiating the data transmission of the second data collected by each of the target sensors in a preset order during the dead zone period of the first type of sensor, the method further includes: After each second data transmission of a target sensor is initiated, the processor is released, and the data transmission of the target sensor currently transmitting data is monitored to see if it is complete. If completed, the data transmission of the second data of the next target sensor is started in the preset order, and the process returns to the step of releasing the processor and monitoring whether the current data transmission is completed, until the data transmission of all the target sensors is completed; If not completed, the processor is released, and the process returns to the step of monitoring whether the data transmission of the target sensor currently transmitting data is complete.

8. The data transmission method according to any one of claims 1 to 7, characterized in that, The first type of sensor is an ambient light sensor. After the step of monitoring whether the data transmission of the first data is completed, the method further includes: If it is detected that the data transmission of the first data has been completed, the processor reads the first data that has been transmitted. Brightness adjustment processing is performed based on the first data read.

9. A wearable device, the wearable device comprising a first type of sensor, a second type of sensor, and a processor, wherein the data transmission frequency of the first type of sensor is higher than that of the second type of sensor, and the first type of sensor and the second type of sensor share the same bus for data transmission, and the processor is configured to execute the steps of the data transmission method as described in any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a device control program, which, when executed by a processor, implements the steps of the data transmission method as described in any one of claims 1 to 8.

Images