Low-power-consumption intelligent hardware control method

By generating device state feature vectors and coprocessor management, refined power consumption control of intelligent hardware devices is achieved, solving the high power consumption problem of traditional solutions and improving the battery life of the device and user experience.

CN120595931AInactive Publication Date: 2025-09-05CHANGZHOU ZHONGTIAN ELECTRIC APPLIANCE CO LTD
View PDF 0 Cites 5 Cited by

Patent Information

Application Number
CN202510642682.4
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-05-19
Publication Date
2025-09-05
Estimated Expiration
Not applicable · inactive patent

Smart Images

  • Figure CN120595931A_ABST
    Figure CN120595931A_ABST
Patent Text Reader

Abstract

The invention belongs to the technical field of intelligent hardware control methods, and discloses a low-power-consumption intelligent hardware control method which comprises the following steps: acquiring working state parameters and user interaction information of intelligent hardware, and generating an equipment state feature vector; judging whether a dormancy condition is met or not according to the equipment state feature vector; when the sleep condition is satisfied, sending a network communication agent instruction; the coprocessor configures an internal timer and awakens signal output after receiving the instruction; the master control stores a system operation state, configures a wake-up source and then enters a deep sleep state; the coprocessor cuts off the power supply of the inactive module; when a timer of the coprocessor reaches a preset network heartbeat cycle, a wake-up signal is sent to the master controller; and the master control recovers the system state, updates the feature vector and re-decides whether to sleep or not. And through multi-dimensional state perception and a master-slave cooperation architecture, and through refined power management and a dynamic reevaluation mechanism, the equipment power consumption is obviously reduced on the premise of ensuring the user experience.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to the technical field of intelligent hardware control methods, and more specifically, to a low-power intelligent hardware control method. Background Art

[0002] With the rapid development and widespread adoption of modern intelligent hardware devices, low-power design has become a key technical bottleneck restricting product performance and user experience. With the diversification of IoT application scenarios and increasing user demands for battery life, traditional power management strategies are no longer able to meet the demands of the new generation of intelligent hardware. This is particularly true in areas such as smart wearables, environmental monitoring terminals, and medical monitoring equipment, where devices must maintain stable operation for extended periods while maximizing battery life.

[0003] Existing power consumption control solutions for intelligent hardware primarily focus on optimizing low-power modes, dynamic frequency adjustment, and selective peripheral shutdown within a single MCU. However, these approaches face significant limitations in practical applications: First, even in a single MCU architecture using deep sleep mode, periodic wake-up to handle network communications still results in high average power consumption. Second, traditional peripheral management strategies often employ coarse-grained control, failing to achieve refined energy allocation for different operating scenarios. Finally, existing solutions lack intelligent sensing of device usage patterns and are unable to adaptively adjust power consumption strategies based on user behavior. These issues are particularly acute in intelligent hardware that operates for extended periods of time, resulting in battery power consumption far exceeding theoretical expectations and failing to meet actual user needs. Summary of the Invention

[0004] In order to overcome the above problems in the prior art, the present invention proposes a low-power intelligent hardware control method to solve the above problems.

[0005] The present invention provides the following technical solutions:

[0006] A low-power intelligent hardware control method, comprising:

[0007] Obtain the working status parameters and user interaction information of the intelligent hardware and generate the device status feature vector;

[0008] According to the device status feature vector, determine whether the main control MCU meets the sleep condition;

[0009] When the sleep condition is met, a network communication agent instruction is sent to the coprocessor, wherein the network communication agent instruction includes a network heartbeat packet period parameter and a wake-up trigger configuration;

[0010] After receiving the network communication agent instruction, the coprocessor configures an internal timer and a wake-up signal output to periodically perform a network status maintenance task;

[0011] The main MCU saves the current system operating status, configures the GPIO connected to the coprocessor as the wake-up source, and then enters the deep sleep state;

[0012] The coprocessor controls the peripheral module power management unit according to the device status feature vector and disconnects the power supply path of the inactive module;

[0013] When the coprocessor timer reaches the preset network heartbeat packet period, it sends a wake-up signal to the main control MCU through GPIO;

[0014] After receiving the wake-up signal, the main control MCU resumes the system operation state and updates the device state feature vector. It decides whether to enter the sleep state according to the updated device state feature vector.

[0015] Preferably, the obtaining of working status parameters and user interaction information of intelligent hardware to generate a device status feature vector includes:

[0016] Collect device screen lighting status, button trigger status, sensor working status, network connection status and task queue status to form a hardware status data set;

[0017] Record the timestamp, interaction type identifier, and duration value of the user's most recent interaction operation to form a user interaction dataset;

[0018] Read the battery power percentage, charging status flag, and battery temperature value to form a power status data set; collect network link quality data and server response time to form a network performance data set;

[0019] The hardware status dataset, user interaction dataset, power status dataset and network performance dataset are standardized to generate a device status feature vector.

[0020] Preferably, judging whether the master MCU meets the sleep condition according to the device state feature vector includes:

[0021] Checking whether the screen state in the device state feature vector is an off state;

[0022] Calculate the difference between the current time and the most recent interaction timestamp in the device state feature vector to determine whether it exceeds a preset user interaction timeout threshold;

[0023] Checking the task queue status in the device status feature vector to determine whether there is no high-priority task;

[0024] Checking the communication queue status in the device status feature vector to determine whether there is no critical data packet to be sent;

[0025] Checking whether the battery level in the device state feature vector is lower than an energy saving threshold;

[0026] Perform weighted calculation on the satisfaction of the above conditions to obtain the degree of satisfaction of the dormancy conditions;

[0027] When the degree of satisfaction of the sleep condition is higher than a system preset threshold, it is determined that the sleep condition is satisfied.

[0028] Preferably, sending the network communication agent instruction to the coprocessor includes:

[0029] Read the heartbeat packet period requirement of the current network protocol from the communication protocol configuration library and obtain the basic heartbeat packet period value;

[0030] Based on the network link quality data and server response time in the network performance dimension of the device status feature vector, the basic heartbeat packet period value is adjusted according to the rule that the lower the network link quality or the longer the server response time, the larger the heartbeat packet period value;

[0031] Based on the battery power data in the power state dimension of the device state feature vector, when the power level is lower than the preset threshold, the heartbeat packet period value is correspondingly extended;

[0032] Generate wake-up trigger configuration based on the wake-up level requirements and response time requirements of the master MCU;

[0033] Construct a communication agent instruction packet containing the adjusted heartbeat packet period value and wake-up trigger configuration;

[0034] The communication agent instruction packet is sent through the communication interface between the main control MCU and the coprocessor.

[0035] Preferably, configuring an internal timer and a wake-up signal output to periodically execute a network status maintenance task includes:

[0036] Parse the received network communication agent instructions and extract the heartbeat packet period value and wake-up trigger configuration;

[0037] According to the heartbeat packet period value, configure the clock source, frequency division coefficient and initial count value of the coprocessor internal timer;

[0038] Based on the wake-up trigger configuration, setting the drive capability, signal level and duration of the GPIO output port;

[0039] Program the timer interrupt service routine to implement the timed triggering of network status maintenance tasks and wake-up signal generation;

[0040] Create a list of network status maintenance tasks, including link keepalives, session refreshes, and heartbeat data preparation;

[0041] Start the timer to count and begin executing periodic network status maintenance tasks.

[0042] Preferably, the main control MCU saves the current system operation state, configures the GPIO connected to the coprocessor as a wake-up source, and then enters the deep sleep state, including:

[0043] Read and save the CPU core register values, program counter values ​​and key peripheral configurations to form a system status data block;

[0044] Extract the active peripheral list and network connection data from the hardware status dimension of the device status feature vector, and save the peripheral status and network status information;

[0045] Stores application execution context, including task state, memory allocation information, and user interface state;

[0046] Writing the system status data block, peripheral status information, network status information, and application execution context into the sleep retention area, which remains powered in the deep sleep state;

[0047] According to the wake-up signal output characteristics configured by the coprocessor, configure the GPIO port connected to the coprocessor as an external interrupt input and set the matching trigger mode and interrupt priority;

[0048] Register the interrupt service function and define the processing flow after wake-up, including state recovery and network communication startup;

[0049] Based on the power state dimension data of the device state feature vector, the power management unit is configured to select the lowest power sleep mode that supports external interrupt wake-up;

[0050] Execute the sleep instruction to switch the main MCU to deep sleep state.

[0051] Preferably, the coprocessor controls the peripheral module power management unit according to the device state feature vector to disconnect the power supply path of the inactive module, including:

[0052] Identify currently inactive hardware modules based on the hardware status dimension data in the device status feature vector;

[0053] The power switch circuit in the power management unit is controlled through the GPIO interface of the coprocessor to turn off the power supply path of the module marked as inactive.

[0054] Preferably, the identification of the currently inactive hardware module includes:

[0055] Get the screen lighting status data. When the screen is off, mark the display module as an inactive module.

[0056] Get the button trigger status. When the button is not triggered, mark the touch module as an inactive module.

[0057] Obtain sensor working status data. When there is no sensor sampling task, mark the corresponding sensor as an inactive module.

[0058] Obtain network connection status data and mark high-power communication modules as inactive when there is no real-time communication demand.

[0059] Preferably, when the coprocessor timer reaches the network heartbeat packet period, sending a wake-up signal to the main control MCU via GPIO includes:

[0060] When the coprocessor timer count value reaches a preset value set according to the heartbeat packet period value, a timer interrupt is triggered;

[0061] Prepare a wake-up data packet, wherein the wake-up data packet includes network status information and events to be processed;

[0062] According to the wake-up trigger configuration, a wake-up signal containing a wake-up data packet is sent.

[0063] Preferably, the main control MCU recovers the system running state after receiving the wake-up signal, updates the device state feature vector, and determines whether to enter the sleep state according to the updated device state feature vector, including:

[0064] Read the system status data block, peripheral status information, network status information and application execution context from the sleep retention area to restore the system operating environment;

[0065] Communicate with the coprocessor to obtain the network status maintenance task execution results and pending events, and process the pending events;

[0066] After the processing is completed, the complete device status feature vector is updated;

[0067] Based on the updated device status feature vector, re-evaluate whether the main control MCU meets the sleep conditions;

[0068] If the sleep conditions are still met, the device will re-enter the deep sleep state; if the sleep conditions are not met, the main control MCU will remain in normal working state and continue to execute device functional tasks.

[0069] The present invention provides a low-power intelligent hardware control method, which has the following beneficial effects:

[0070] By constructing a multi-dimensional device state feature vector, comprehensive perception and accurate description of the device's operating status are achieved. This avoids the blind sleep or unnecessary wake-up issues caused by single-parameter decisions in traditional solutions, and improves the intelligence of power management. By incorporating user interaction information, power consumption optimization is achieved while ensuring a good user experience. A multi-condition weighted decision-making mechanism based on feature vectors enables a refined assessment of sleep conditions. Compared to traditional single-threshold triggering methods, this evaluation method significantly improves the adaptability and accuracy of decisions, effectively avoiding conflicts between functional responsiveness and power savings. By enabling the coprocessor to coordinate, the main MCU can enter a deeper sleep state without frequent wake-ups, further reducing device power consumption. BRIEF DESCRIPTION OF THE DRAWINGS

[0071] Figure 1 The figure is a flow chart of a low-power intelligent hardware control method of the present invention. DETAILED DESCRIPTION

[0072] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0073] Example 1

[0074] See also Figure 1 In this embodiment, a low-power intelligent hardware control method includes:

[0075] S1. Obtain the working status parameters and user interaction information of the intelligent hardware and generate the device status feature vector;

[0076] The step of obtaining the working status parameters of the intelligent hardware and the user interaction information and generating the device status feature vector includes:

[0077] Collect device screen lighting status, button trigger status, sensor working status, network connection status and task queue status to form a hardware status data set;

[0078] Record the timestamp, interaction type identifier, and duration value of the user's most recent interaction operation to form a user interaction dataset;

[0079] Read the battery power percentage, charging status flag, and battery temperature value to form a power status data set; collect network link quality data and server response time to form a network performance data set;

[0080] The hardware status dataset, user interaction dataset, power status dataset and network performance dataset are standardized to generate a device status feature vector.

[0081] In this embodiment, the hardware status dataset is collected by reading the display controller's status register to obtain the screen lighting status; detecting the touch chip's interrupt status to determine the key trigger status; traversing the sensor status table to record the sensor's operating status; reading the coprocessor's connection register to determine the network connection status; and obtaining active task information from the task manager to calculate the task queue status. These data together constitute the hardware status dataset.

[0082] When recording user interaction datasets, a timer is used to record the time of the most recent user action as the interaction timestamp. The interaction type is classified as a click, slide, or keystroke based on the trigger source. The duration value is obtained by calculating the time difference between the start and end of the interaction. This information forms the user interaction dataset.

[0083] When reading the power status data set, the battery charge percentage is obtained through the registers of the battery management chip; the charging status flag is determined by monitoring the status pin of the charging chip; and the battery temperature is obtained by sampling the thermistor using the ADC. These parameters constitute the power status data set.

[0084] Collecting the network performance dataset includes obtaining signal strength values ​​and link quality indicators from the coprocessor as network link quality data and recording the round-trip delay of the most recent communication as server response time. These two parts constitute the network performance dataset.

[0085] Finally, normalization is performed to convert each data set into a device state feature vector. This normalization process uniformly converts various parameters to a range of 0-1. Screen and button states are directly mapped to 0 or 1; the percentage of active sensors indicates sensor activity; user interaction time is normalized based on a timeout threshold; battery charge is normalized by dividing by 100; and network signal strength is mapped to a standard range.

[0086] After these processes, a feature vector reflecting the current state of the device is generated, providing a data basis for subsequent low-power control decisions.

[0087] S2. Determine whether the main control MCU meets the sleep condition based on the device status feature vector;

[0088] The determining, based on the device status feature vector, whether the master MCU meets the sleep condition includes:

[0089] Checking whether the screen state in the device state feature vector is an off state;

[0090] Calculate the difference between the current time and the most recent interaction timestamp in the device state feature vector to determine whether it exceeds a preset user interaction timeout threshold;

[0091] Checking the task queue status in the device status feature vector to determine whether there is no high-priority task;

[0092] Checking the communication queue status in the device status feature vector to determine whether there is no critical data packet to be sent;

[0093] Checking whether the battery level in the device state feature vector is lower than an energy saving threshold;

[0094] Perform weighted calculation on the satisfaction of the above conditions to obtain the degree of satisfaction of the dormancy conditions;

[0095] When the degree of satisfaction of the sleep condition is higher than a system preset threshold, it is determined that the sleep condition is satisfied.

[0096] In this embodiment, after obtaining the device state feature vector, the screen state value in the feature vector is read. When the value is 0, it means that the screen is turned off and is more likely to go into sleep mode.

[0097] Next, the user interaction time difference is calculated. The most recent interaction timestamp is extracted from the feature vector and the difference is calculated with the current system time. When the difference exceeds the preset user interaction timeout threshold (for example, 30 seconds), the user is considered inactive and is more likely to sleep.

[0098] The task queue status is then checked. Task queue information is extracted from the feature vector to determine whether there are any high-priority tasks. High-priority tasks include operations that require timely completion, such as data synchronization and health indicator calculation. If there are no high-priority tasks in the task queue, the system is more likely to sleep.

[0099] The communication queue information is extracted from the feature vector to determine whether there are any critical data packets waiting to be sent, such as emergency health reminders or critical user data. If there are no critical data packets waiting to be sent in the communication queue, the system is more likely to sleep.

[0100] The battery power percentage is obtained from the feature vector. When the battery power is lower than the energy saving threshold (for example, set to 20%), the battery is more inclined to sleep.

[0101] After checking all the above conditions, a weighted calculation is performed to determine the sleep condition satisfaction. Each condition is assigned a weight based on its importance. For example, screen status is weighted 0.3, user interaction time is weighted 0.25, task queue status is weighted 0.2, communication queue status is weighted 0.15, and battery charge status is weighted 0.1. Each condition has a value of 1 if it favors sleep and 0 if it does not. The final sleep condition satisfaction score is calculated by multiplying each condition's value by its corresponding weight and summing the results, ranging from 0 to 1.

[0102] When the calculated sleep condition satisfaction degree is higher than the system preset threshold (eg, 0.7), it is determined that the sleep condition is met and the next step of preparing for sleep can be entered; otherwise, the normal working state is maintained.

[0103] S3. When the sleep condition is met, sending a network communication agent instruction to the coprocessor, wherein the network communication agent instruction includes a network heartbeat packet period parameter and a wake-up trigger configuration;

[0104] The sending of the network communication agent instruction to the coprocessor comprises:

[0105] Read the heartbeat packet period requirement of the current network protocol from the communication protocol configuration library and obtain the basic heartbeat packet period value;

[0106] Based on the network link quality data and server response time in the network performance dimension of the device status feature vector, the basic heartbeat packet period value is adjusted according to the rule that the lower the network link quality or the longer the server response time, the larger the heartbeat packet period value;

[0107] Based on the battery power data in the power state dimension of the device state feature vector, when the power level is lower than the preset threshold, the heartbeat packet period value is correspondingly extended;

[0108] Generate wake-up trigger configuration based on the wake-up level requirements and response time requirements of the master MCU;

[0109] Construct a communication agent instruction packet containing the adjusted heartbeat packet period value and wake-up trigger configuration;

[0110] The communication agent instruction packet is sent through the communication interface between the main control MCU and the coprocessor.

[0111] In this embodiment, when the sleep condition is met, a network communication agent instruction needs to be sent to the coprocessor so as to maintain the necessary network connection during the sleep period of the main control MCU.

[0112] First, the heartbeat packet period requirement for the current network protocol is read from the communication protocol configuration library. The configuration library stores the heartbeat packet period parameters for different connection states. For example, in a normal connection state, the basic heartbeat packet period value is 30 seconds, which is the minimum period requirement for maintaining a stable connection.

[0113] The heartbeat packet period is then adjusted based on the network performance data in the device status feature vector. Network link quality data and server response time are extracted from the feature vector and a dynamic adjustment algorithm is applied. For example, when the network link quality falls below 0.4 (normalized value) or the server response time exceeds 200 milliseconds, the base heartbeat packet period is increased by 50%. When network conditions worsen (link quality falls below 0.2 or response time exceeds 500 milliseconds), the period is increased by 100%. This adjustment mechanism avoids the energy waste caused by frequently sending heartbeat packets when network conditions are poor.

[0114] The heartbeat packet cycle is then further adjusted based on the battery level. For example, the battery level percentage is derived from the feature vector. When the battery level drops below 30%, the heartbeat packet cycle is increased by 25%; when the battery level drops below 15%, the heartbeat packet cycle is increased by 50%; and when the battery level drops below 5%, an emergency level, the heartbeat packet cycle is increased by 100%. This gradient adjustment ensures maximum energy conservation and extended device standby time when the battery is low.

[0115] Generate a wake-up trigger configuration based on the characteristics of the master MCU, such as level triggering and edge triggering. Considering response time requirements and power consumption, configure the coprocessor to use rising-edge triggering with a pulse width of 10 milliseconds to ensure reliable wake-up of the master MCU without false triggering.

[0116] When constructing the communication agent instruction packet, the adjusted heartbeat packet period value, wake-up trigger mode, pulse width and other parameters are packaged according to the predefined data structure.

[0117] Finally, the instruction packet is sent through the communication interface between the main control MCU and the coprocessor.

[0118] S4. After receiving the network communication agent instruction, the coprocessor configures an internal timer and a wake-up signal output to periodically perform network status maintenance tasks;

[0119] Configuring an internal timer and a wake-up signal output to periodically perform network status maintenance tasks includes:

[0120] Parse the received network communication agent instructions and extract the heartbeat packet period value and wake-up trigger configuration;

[0121] According to the heartbeat packet period value, configure the clock source, frequency division coefficient and initial count value of the coprocessor internal timer;

[0122] Based on the wake-up trigger configuration, setting the drive capability, signal level and duration of the GPIO output port;

[0123] Program the timer interrupt service routine to implement the timed triggering of network status maintenance tasks and wake-up signal generation;

[0124] Create a list of network status maintenance tasks, including link keepalives, session refreshes, and heartbeat data preparation;

[0125] Start the timer to count and begin executing periodic network status maintenance tasks.

[0126] In this embodiment, after receiving the network communication agent instruction sent by the master MCU, it is necessary to configure internal resources and perform network status maintenance tasks to ensure that the network connection is maintained during the sleep period of the master MCU.

[0127] The coprocessor first parses the received network communication agent command. It uses a predefined data structure to parse the command packet and extract key parameters. In this embodiment, the extracted heartbeat packet period is the adjusted value described above, for example, 45 seconds. The wake-up trigger configuration includes parameters such as rising edge trigger mode, 10 millisecond pulse width, and 3.3V trigger level. The coprocessor verifies the integrity of the command packet using a checksum to ensure accurate and reliable parsing results.

[0128] Configure the internal timer based on the extracted heartbeat packet period. The coprocessor uses a 16-bit timer and selects the internal 32.768kHz low-power crystal oscillator as the clock source to reduce timer power consumption. Based on the 45-second heartbeat packet period, the frequency division factor is calculated to be 8, and the initial count value is 45 × 32768 ÷ 8 = 184320. These parameters are written to the timer control register to complete the basic timer configuration.

[0129] Create a list of network status maintenance tasks, specifying the specific tasks to be executed periodically. For example, the link keepalive task sends a minimum data packet to maintain an active Bluetooth connection; the session refresh task updates the session token to prevent the server from disconnecting. Finally, start the timer to periodically execute the network status maintenance tasks. The coprocessor activates the timer by writing the start bit in the timer control register.

[0130] S5: The main control MCU saves the current system operation status, configures the GPIO connected to the coprocessor as the wake-up source, and then enters the deep sleep state;

[0131] The main control MCU saves the current system operation status, configures the GPIO connected to the coprocessor as a wake-up source, and then enters the deep sleep state including:

[0132] Read and save the CPU core register values, program counter values ​​and key peripheral configurations to form a system status data block;

[0133] Extract the active peripheral list and network connection data from the hardware status dimension of the device status feature vector, and save the peripheral status and network status information;

[0134] Stores application execution context, including task state, memory allocation information, and user interface state;

[0135] Writing the system status data block, peripheral status information, network status information, and application execution context into the sleep retention area, which remains powered in the deep sleep state;

[0136] According to the wake-up signal output characteristics configured by the coprocessor, configure the GPIO port connected to the coprocessor as an external interrupt input and set the matching trigger mode and interrupt priority;

[0137] Register the interrupt service function and define the processing flow after wake-up, including state recovery and network communication startup;

[0138] Based on the power state dimension data of the device state feature vector, the power management unit is configured to select the lowest power sleep mode that supports external interrupt wake-up;

[0139] Execute the sleep instruction to switch the main MCU to deep sleep state.

[0140] In this embodiment, dedicated instructions are used to read the CPU core register values ​​and the status register simultaneously, recording the current CPU operating mode and interrupt status. For key peripherals such as timers, communication interfaces, and sensor controllers, the values ​​of their control registers and status registers are read. This data is combined to form a system status data block, providing basic information for subsequent system recovery.

[0141] Extract active peripheral information and network connection data from the device state feature vector. Based on the hardware state dimension data, determine which peripherals are currently active, such as the heart rate sensor and accelerometer. Record the operating mode, sampling frequency, and data buffer status of these peripherals. Also extract network connection data, including connection status, connection handle, and security parameters, to form a complete picture of peripheral and network status.

[0142] Stores application execution context to ensure seamless resumption after wakeup. Extracts status information for currently active tasks from the operating system's task manager, including task priority, blocking reason, and wakeup conditions. Records memory allocations, including heap memory usage and addresses of critical memory blocks. For user interfaces, saves information such as the currently displayed interface ID, interaction status, and animation progress to ensure proper UI restoration after wakeup.

[0143] All collected status information is written to the sleep retention area, which remains powered even in deep sleep. According to a predefined data structure, the system status data block, peripheral status information, network status information, and application execution context are written to this area in sequence.

[0144] Configure the GPIO interrupt according to the coprocessor's wake-up signal characteristics. Configure the GPIO port connected to the coprocessor as an external interrupt input and enable the internal pull-up resistor. Set the GPIO interrupt to rising-edge trigger mode according to the coprocessor's configured rising-edge trigger mode. Set the interrupt priority to the highest to ensure a timely response to the wake-up signal.

[0145] Register an interrupt service function and define the post-wakeup processing flow. The interrupt service function first performs necessary hardware initialization and restores the operating status of key peripherals. It then reads the saved status information from the sleep retention area and restores the system operating environment. Finally, it establishes communication with the coprocessor, obtains the wakeup reason and network status, and determines the subsequent processing flow.

[0146] Based on the power status data in the device status feature vector, the power management unit is configured. Deep sleep mode is selected. In this mode, most peripherals stop functioning, the core power supply voltage of the main MCU is reduced, and only the necessary wake-up circuits are powered. Finally, the enter sleep command is executed to switch the main MCU into deep sleep.

[0147] S6. The coprocessor controls the peripheral module power management unit according to the device status feature vector to disconnect the power supply path of the inactive module;

[0148] The coprocessor controls the peripheral module power management unit according to the device state feature vector to disconnect the power supply path of the inactive module, including:

[0149] Identify currently inactive hardware modules based on the hardware status dimension data in the device status feature vector;

[0150] The power switch circuit in the power management unit is controlled through the GPIO interface of the coprocessor to turn off the power supply path of the module marked as inactive.

[0151] The hardware module identified as currently inactive includes:

[0152] Get the screen lighting status data. When the screen is off, mark the display module as an inactive module.

[0153] Get the button trigger status. When the button is not triggered, mark the touch module as an inactive module.

[0154] Obtain sensor working status data. When there is no sensor sampling task, mark the corresponding sensor as an inactive module.

[0155] Obtain network connection status data and mark high-power communication modules as inactive when there is no real-time communication demand.

[0156] In this embodiment, the coprocessor first identifies currently inactive hardware modules based on the hardware status dimension data in the device status feature vector. This process is based on the device status feature vector transmitted by the main MCU before entering sleep mode. The coprocessor stores this vector in internal RAM for subsequent power management decisions.

[0157] The screen status value is read from the feature vector. When the value is 0, it means the screen is off. At this point, the coprocessor marks the display module as an inactive module and prepares to disconnect its power supply.

[0158] Next, the button trigger status is obtained. The button status value is read from the feature vector. A value of 0 indicates that the button is not triggered. At this point, the coprocessor marks the touch module as inactive. Considering that the user may wake the device by pressing a button, the coprocessor maintains a minimum power supply to the button detection circuit but shuts down the main functional modules of the touch controller, achieving partial power outage.

[0159] The operating status of each sensor is read from the feature vector. When a sensor has no sampling tasks, it is marked as an inactive module. For example, when the heart rate monitoring function is not enabled, the heart rate sensor is marked as inactive; when the user remains stationary for a period of time, the accelerometer can be marked as inactive. Different sensors have different sleep strategies; some sensors support complete power off, while others support low-power modes.

[0160] The network connection status and communication requirements are read from the feature vector. When there is no immediate communication requirement, the high-power communication module is marked as inactive.

[0161] After identifying inactive modules, the coprocessor controls the power switch circuit in the power management unit through the GPIO interface, shutting down the power supply path for the modules marked as inactive. The coprocessor selectively shuts down the power supply path for inactive modules by sending control commands to the power management chip.

[0162] S7: When the coprocessor timer reaches the preset network heartbeat packet period, it sends a wake-up signal to the main control MCU through GPIO;

[0163] When the coprocessor timer reaches the network heartbeat packet period, sending a wake-up signal to the main control MCU via GPIO includes:

[0164] When the coprocessor timer count value reaches a preset value set according to the heartbeat packet period value, a timer interrupt is triggered;

[0165] Prepare a wake-up data packet, wherein the wake-up data packet includes network status information and events to be processed;

[0166] According to the wake-up trigger configuration, a wake-up signal containing a wake-up data packet is sent.

[0167] In this embodiment, a timer interrupt is triggered when the coprocessor timer count reaches a preset value. Based on the previously configured heartbeat packet period, for example, 45 seconds, the coprocessor's internal timer continues counting, triggering an interrupt when the count reaches 184,320. After the interrupt is triggered, the interrupt service routine is first executed, pausing the timer count, clearing the interrupt flag, and then entering the wake-up signal preparation process. The timer interrupt priority is set high to ensure a timely response and avoid delays in heartbeat packet transmission due to other tasks.

[0168] The coprocessor first checks for pending events from the server, such as message notifications, alarm reminders, or health alerts. It organizes this information into a structured wake-up packet, including fields such as packet type identifier, network status summary, and event priority. If there are no critical events and the network is healthy, the coprocessor may choose to handle heartbeat maintenance independently without waking up the main MCU, further reducing power consumption.

[0169] Based on the wake-up trigger configuration, a wake-up signal containing a wake-up packet is sent. The coprocessor first prepares the wake-up packet and stores it in a designated shared memory area for the master MCU to read after waking up. It then controls the GPIO output according to the previously configured wake-up trigger method. For example, a rising-edge trigger method can be used. The coprocessor toggles the GPIO pin from low to high, holds it for 10 milliseconds, and then returns it to low, completing a complete wake-up pulse.

[0170] After sending the wake-up signal, the coprocessor enters a waiting state, ready to receive a response from the main MCU. The coprocessor monitors the main MCU's response signal through the communication interface to confirm that the main MCU has successfully woken up and begun processing tasks. If no response is received within a predetermined time, the coprocessor may resend the wake-up signal or take other recovery measures to ensure normal system operation.

[0171] S8. After receiving the wake-up signal, the main control MCU restores the system operation state and updates the device state feature vector. It decides whether to enter the sleep state according to the updated device state feature vector.

[0172] After receiving the wake-up signal, the main control MCU resumes the system operation state and updates the device state feature vector. The decision of whether to enter the sleep state according to the updated device state feature vector includes:

[0173] Read the system status data block, peripheral status information, network status information and application execution context from the sleep retention area to restore the system operating environment;

[0174] Communicate with the coprocessor to obtain the network status maintenance task execution results and pending events, and process the pending events;

[0175] After the processing is completed, the complete device status feature vector is updated;

[0176] Based on the updated device status feature vector, re-evaluate whether the main control MCU meets the sleep conditions;

[0177] If the sleep conditions are still met, the device will re-enter the deep sleep state; if the sleep conditions are not met, the main control MCU will remain in normal working state and continue to execute device functional tasks.

[0178] In this embodiment, the master MCU first reads the saved system status information from the sleep retention area. The sleep retention area is an SRAM area that remains powered during deep sleep and stores critical data saved before entering sleep. The master MCU sequentially reads the system status data block, peripheral status information, network status information, and application execution context according to a predefined data structure.

[0179] The master MCU first restores the values ​​of the CPU core registers and program counter, returning the processor to the execution point before hibernation. It then reinitializes key peripherals such as timers, communication interfaces, and sensor controllers based on the saved peripheral configuration information. For the application execution context, it restores task status, memory allocation information, and user interface state, ensuring seamless application execution.

[0180] The master MCU establishes communication with the coprocessor via the SPI interface, reads the wake-up packet prepared by the coprocessor, and obtains the network status maintenance task execution results and pending events. Network status information includes connection status, signal strength, and data transmission status; pending events may include message notifications, health reminders, or system update requests. The master MCU determines the order and method of processing based on the event priority and type.

[0181] For message notifications, the main MCU might need to illuminate the screen to display the notification content. For health reminders, it might activate a vibration motor to alert the user. Data synchronization requests require collecting relevant data and transmitting it over the network. During processing, the main MCU activates peripherals such as the display, vibration motor, or high-speed communication module as needed, and shuts them down promptly after the task is completed to avoid unnecessary energy consumption.

[0182] After processing is complete, the master MCU updates the complete device state feature vector. During the update process, the system recollects current hardware state parameters, including screen status, button status, sensor status, and network status; records the latest user interaction information; reads the latest battery status; and collects network performance data. This data is standardized to form an updated device state feature vector, reflecting the current real-time status of the device.

[0183] Based on the updated device state feature vector, the main MCU re-evaluates whether the sleep conditions are met. This evaluation process uses the same multi-condition weighted calculation method as previously described, examining the screen state, user interaction time, task queue status, communication queue status, and battery charge level to calculate the degree of sleep condition satisfaction. This evaluation is more dynamic, taking into account that the event just processed may have changed the device state, such as turning on the screen or triggering a new task.

[0184] If the sleep conditions are still met after reassessment, the master MCU prepares to enter deep sleep again. This typically occurs when only simple network heartbeats or low-priority events need to be processed. The master MCU repeats the sleep preparation process described above: saving the system state, configuring the wakeup source, sending the updated network communication agent command to the coprocessor, and then executing the sleep instruction to enter the ultra-low power state again.

[0185] If the sleep conditions are not met, the main MCU remains in normal operation and continues to execute device functions. This may be due to processing events that cause the screen to light up, user interaction, triggering a high-priority task, or a change in battery status. The main MCU will continue to operate normally, executing operating system tasks, processing user input, and updating the display content. At the same time, it will periodically check the sleep conditions and enter sleep again when the conditions are met.

[0186] In the several embodiments provided by the present invention, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of the units is only one type. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0187] The above description is only a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any technician familiar with this technical field can easily think of changes or replacements within the technical scope disclosed by the present invention, which should be covered by the scope of protection of the present invention.

[0188] Finally: The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. A low-power intelligent hardware control method, characterized in that: include: Obtain the working status parameters and user interaction information of the intelligent hardware and generate the device status feature vector; According to the device status feature vector, determine whether the main control MCU meets the sleep condition; When the sleep condition is met, a network communication agent instruction is sent to the coprocessor, wherein the network communication agent instruction includes a network heartbeat packet period parameter and a wake-up trigger configuration; After receiving the network communication agent instruction, the coprocessor configures an internal timer and a wake-up signal output to periodically perform network status maintenance tasks; The main MCU saves the current system operating status, configures the GPIO connected to the coprocessor as the wake-up source, and then enters the deep sleep state; The coprocessor controls the peripheral module power management unit according to the device status feature vector and disconnects the power supply path of the inactive module; When the coprocessor timer reaches the preset network heartbeat packet period, it sends a wake-up signal to the main control MCU through GPIO; After receiving the wake-up signal, the main control MCU resumes the system operation state and updates the device state feature vector. It decides whether to enter the sleep state according to the updated device state feature vector.

2. A low-power intelligent hardware control method according to claim 1, characterized in that: The step of obtaining the working status parameters of the intelligent hardware and the user interaction information and generating the device status feature vector includes: Collect device screen lighting status, button trigger status, sensor working status, network connection status and task queue status to form a hardware status data set; Record the timestamp, interaction type identifier, and duration value of the user's most recent interaction operation to form a user interaction dataset; Read the battery power percentage, charging status flag and battery temperature value to form a power status data set; Collect network link quality data and server response time to form a network performance data set; The hardware status dataset, user interaction dataset, power status dataset and network performance dataset are standardized to generate a device status feature vector.

3. A low-power intelligent hardware control method according to claim 2, characterized in that: The determining, based on the device status feature vector, whether the master MCU meets the sleep condition includes: Checking whether the screen state in the device state feature vector is an off state; Calculate the difference between the current time and the most recent interaction timestamp in the device state feature vector to determine whether it exceeds a preset user interaction timeout threshold; Checking the task queue status in the device status feature vector to determine whether there is no high-priority task; Checking the communication queue status in the device status feature vector to determine whether there is no critical data packet to be sent; Checking whether the battery level in the device state feature vector is lower than an energy saving threshold; Perform weighted calculation on the satisfaction of the above conditions to obtain the degree of satisfaction of the dormancy conditions; When the degree of satisfaction of the sleep condition is higher than a system preset threshold, it is determined that the sleep condition is satisfied.

4. The low-power intelligent hardware control method according to claim 3, characterized in that: The sending of the network communication agent instruction to the coprocessor comprises: Read the heartbeat packet period requirement of the current network protocol from the communication protocol configuration library and obtain the basic heartbeat packet period value; Based on the network link quality data and server response time in the network performance dimension of the device status feature vector, the basic heartbeat packet period value is adjusted according to the rule that the lower the network link quality or the longer the server response time, the larger the heartbeat packet period value; Based on the battery power data in the power state dimension of the device state feature vector, when the power level is lower than the preset threshold, the heartbeat packet period value is correspondingly extended; Generate wake-up trigger configuration based on the wake-up level requirements and response time requirements of the master MCU; Construct a communication agent instruction packet containing the adjusted heartbeat packet period value and wake-up trigger configuration; The communication agent instruction packet is sent through the communication interface between the main control MCU and the coprocessor.

5. The low-power intelligent hardware control method according to claim 4, characterized in that: The configuration of the internal timer and the wake-up signal output to periodically perform the network status maintenance task includes: Parse the received network communication agent instructions and extract the heartbeat packet period value and wake-up trigger configuration; According to the heartbeat packet period value, configure the clock source, frequency division coefficient and initial count value of the coprocessor internal timer; Based on the wake-up trigger configuration, setting the drive capability, signal level and duration of the GPIO output port; Program the timer interrupt service routine to implement the timed triggering of network status maintenance tasks and wake-up signal generation; Create a list of network status maintenance tasks, including link keepalives, session refreshes, and heartbeat data preparation; Start the timer to count and begin executing periodic network status maintenance tasks.

6. A low-power intelligent hardware control method according to claim 5, characterized in that: The main control MCU saves the current system operation status, configures the GPIO connected to the coprocessor as a wake-up source, and then enters the deep sleep state including: Read and save the CPU core register values, program counter values ​​and key peripheral configurations to form a system status data block; Extract the active peripheral list and network connection data from the hardware status dimension of the device status feature vector, and save the peripheral status and network status information; Stores application execution context, including task state, memory allocation information, and user interface state; Writing the system status data block, peripheral status information, network status information, and application execution context into the sleep retention area, which remains powered in the deep sleep state; According to the wake-up signal output characteristics configured by the coprocessor, configure the GPIO port connected to the coprocessor as an external interrupt input and set the matching trigger mode and interrupt priority; Register the interrupt service function and define the processing flow after wake-up, including state recovery and network communication startup; Based on the power state dimension data of the device state feature vector, the power management unit is configured to select the lowest power sleep mode that supports external interrupt wake-up; Execute the sleep instruction to switch the main MCU to deep sleep state.

7. A low-power intelligent hardware control method according to claim 6, characterized in that: The coprocessor controls the peripheral module power management unit according to the device state feature vector to disconnect the power supply path of the inactive module, including: Identify currently inactive hardware modules based on the hardware status dimension data in the device status feature vector; The power switch circuit in the power management unit is controlled through the GPIO interface of the coprocessor to turn off the power supply path of the module marked as inactive.

8. The low-power intelligent hardware control method according to claim 7, characterized in that: The hardware module identified as currently inactive includes: Get the screen lighting status data. When the screen is off, mark the display module as an inactive module. Get the button trigger status. When the button is not triggered, mark the touch module as an inactive module. Obtain sensor working status data. When there is no sensor sampling task, mark the corresponding sensor as an inactive module. Obtain network connection status data and mark high-power communication modules as inactive when there is no real-time communication demand.

9. The low-power intelligent hardware control method according to claim 8, characterized in that: When the coprocessor timer reaches the network heartbeat packet period, sending a wake-up signal to the main control MCU via GPIO includes: When the coprocessor timer count value reaches a preset value set according to the heartbeat packet period value, a timer interrupt is triggered; Prepare a wake-up data packet, wherein the wake-up data packet includes network status information and events to be processed; According to the wake-up trigger configuration, a wake-up signal containing a wake-up data packet is sent.

10. The low-power intelligent hardware control method according to claim 9, characterized in that: After receiving the wake-up signal, the main control MCU resumes the system operation state and updates the device state feature vector. The decision of whether to enter the sleep state according to the updated device state feature vector includes: Read the system status data block, peripheral status information, network status information and application execution context from the sleep retention area to restore the system operating environment; Communicate with the coprocessor to obtain the network status maintenance task execution results and pending events, and process the pending events; After the processing is completed, the complete device status feature vector is updated; Based on the updated device status feature vector, re-evaluate whether the main control MCU meets the sleep conditions; If the sleep conditions are still met, the device will re-enter the deep sleep state; if the sleep conditions are not met, the main control MCU will remain in normal working state and continue to execute device functional tasks.

Citation Information

Cited By

  • Water dispenser intelligent control system based on zigbee and method thereof

    CN121239720A

  • Low-power-consumption control method and device for embedded system

    CN121255007A

  • Low-power control method and device for embedded system

    CN121255007B

  • Environment self-adaptive low-power-consumption management system and method for electronic timer

    CN122018328A

  • Cold standby control method of processing core, cold standby controller and integrated circuit

    CN122044330A