Power consumption management method and related equipment

Abstract

The embodiment of the invention provides a power consumption management method and related equipment, and the method comprises the steps: executing state polling processing through a polling state machine when an idle task of a slave is started; in response to the state information of all the service modules, determining that a preset condition for entering a low-power-consumption state is met, and triggering a low-power-consumption event task; under the low-power-consumption event task, determining a target power consumption state of the slave according to the constraint information through the event management module, and returning the target power consumption state to the idle task; and executing a corresponding low-power-consumption process according to the target power consumption state through the idle task. By adopting the scheme, the intelligent power consumption decision scheme in the slave computer is constructed, so that the slave computer can autonomously manage the power consumption state of the slave computer, and the low-power consumption management function of the slave computer is still complete even under the condition that the slave computer and the host computer are disconnected from each other; therefore, the degree of dependence on a host is reduced, business logic and power consumption management are decoupled, and good universality and transportability are achieved.

Description

Technical Field

[0001] This disclosure relates to the field of communication technology, and in particular to a power management method and related equipment. Background Technology

[0002] With the widespread application of embedded systems, IoT terminals, and low-power electronic devices, system power management has become one of the key technologies affecting device reliability, battery life, and user experience.

[0003] In existing systems, a master-slave architecture is commonly used to achieve overall power consumption control. This means that the master makes unified decisions and issues power management instructions, and the slave enters the corresponding power consumption state according to the master's instructions.

[0004] However, existing master-slave low-power management solutions have gradually revealed many shortcomings in practical applications and have certain inherent defects. Summary of the Invention

[0005] In view of this, the present disclosure provides a power management method and related device. By constructing an intelligent power consumption decision scheme inside the slave device, the slave device can autonomously manage its own power consumption state. Even when the slave device is disconnected from the host, the low power management function of the slave device remains complete, thereby reducing the dependence on the host, decoupling business logic and power management, and having good versatility and portability.

[0006] To achieve the above objectives, the present disclosure provides the following technical solutions.

[0007] In a first aspect, embodiments of this disclosure provide a power management method applied to a slave device, the power management method comprising: When the idle task of the slave device is started, a state polling process is performed by polling the state machine. The state polling process includes: obtaining the state information and constraint information of each business module in the slave device. In response to the status information of all business modules, determine if the preset conditions for entering a low-power state are met, and trigger a low-power event task; Under the low-power event task, the event management module determines the target power consumption state of the slave device based on the constraint information and returns the target power consumption state to the idle task; The idle task executes the corresponding low-power process based on the target power consumption state.

[0008] Optionally, the constraint information includes at least the next wake-up time and power consumption level constraints corresponding to each service module; The step of determining the target power consumption state of the slave device based on the constraint information through the event management module includes: The allowed sleep time is determined based on the next wake-up time of each of the aforementioned business modules; Based on the sleep time, a candidate low-power state is selected; Based on the power consumption level constraints of each of the service modules, the candidate low-power states are restricted to determine the target low-power state of the slave device; wherein, the power consumption level constraints are used to limit the minimum power consumption state that is allowed to be entered, and the target low-power state is a low-power state that is not higher than the power consumption level constraints and meets the sleep time condition.

[0009] Optionally, determining the allowed sleep time based on the next wake-up time of each of the service modules includes: The earliest wake-up time among all business modules is taken as the allowed sleep time.

[0010] Optionally, the step of determining whether the preset conditions for entering a low-power state are met based on the status information of all service modules includes: In the state polling process, low-power voting results generated by multiple service modules are obtained respectively. The low-power voting results are used to characterize the constraints imposed by the corresponding service module on entering the low-power state. Based on the low-power voting results, determine whether the preset conditions for entering low-power mode are met.

[0011] Optionally, when the slave device is in the target power consumption state, in response to the detection of a wake-up event that meets preset conditions during the state polling process, the wake-up process is triggered; wherein, different wake-up events are configured for different target power consumption states.

[0012] Optionally, during the state polling process, the method further includes: Receive scheduling information from the host, the scheduling information being used to characterize the host's operating status and scheduling constraints; Based on the scheduling information and the local sleep state information of the slave device, a collaborative decision is made on the low-power entry timing and target sleep mode of the slave device.

[0013] Optionally, the host switches between an active state, a suspended state, and a resumed state, and sends a status notification corresponding to the operating state to the slave when the state switches. The power consumption management method includes: Based on the received operating status of the host, the system switches between idle state, suspended waiting state, woken-up idle state, and resumed state. When in the idle state, the state polling process is executed, and when the target power consumption state is determined, a sleep step is executed and a suspend waiting state is entered. When a notification is received that the host has entered the recovery state, a wake-up recovery step is executed, and the host enters the recovery state from the wake-up idle state, and finally returns to the idle state to continue service processing.

[0014] Optionally, the service module includes at least one of a communication unit, a data acquisition unit, a storage unit, and a timing control unit.

[0015] Optionally, the target power consumption state includes at least: The first power consumption state is used to stop the processor core while maintaining the working state of the business module; The second power consumption state is used to enter a low power consumption state when some service modules are turned off; The third power state is used to enter a deep low-power state while retaining only the preset memory cells and the real-time clock.

[0016] Secondly, embodiments of this disclosure provide a power management device, configured in a slave device, the power management device comprising: The startup module is configured to perform state polling processing by polling the state machine when the idle task of the slave device is started. The state polling processing includes: obtaining the state information and constraint information of each service module in the slave device. The triggering module is configured to respond to the status information of all business modules, determine whether the preset conditions for entering the low-power state are met, and trigger the low-power event task. The polling module is configured to, under the low-power event task, determine the target power consumption state of the slave device based on the constraint information through the event management module, and return the target power consumption state to the idle task; The execution module is configured to execute a corresponding low-power process based on the target power consumption state through the idle task.

[0017] Thirdly, embodiments of this disclosure provide a communication device including a memory and a processor. The memory stores a computer program that can run on the processor. When the processor runs the computer program, it performs the steps of the power management method as described in any of the foregoing embodiments.

[0018] Fourthly, this disclosure provides a chip that stores a computer program, which, when executed by the chip, causes the power management method of any of the foregoing embodiments to be executed.

[0019] Fifthly, embodiments of this disclosure provide a computer-readable storage medium including instructions that, when executed by a processor, cause a power management method as described in any of the foregoing embodiments to be performed.

[0020] Sixthly, embodiments of this disclosure provide a computer program product, including a computer program / instructions, which, when executed by a processor, implement the steps of the power management method of any of the foregoing embodiments.

[0021] In a seventh aspect, embodiments of this application provide a chip module on which a computer program is stored. When the computer program is executed by the chip module, the power management method of any of the foregoing embodiments is executed.

[0022] Eighthly, embodiments of this application provide a communication system, the communication system including means for performing the power management method of any of the foregoing embodiments.

[0023] Compared with the prior art, the technical solution of the present disclosure has the following advantages: In the power management method provided in this disclosure, when the idle task of the slave device is started, a state polling process is performed by polling the state machine to obtain the state information and constraint information of each service module in the slave device. Thus, based on the state information of all service modules, a preset condition for entering a low-power state is determined, triggering a low-power event task. This allows the event management module to determine the target power state of the slave device based on the constraint information, and the idle task can then execute the corresponding low-power process according to the target power state. By constructing an intelligent power decision-making scheme within the slave device, the slave device can autonomously manage its own power state. Even when the slave device is disconnected from the master device, the low-power management function of the slave device remains complete, thereby reducing dependence on the master device, decoupling business logic from power management, and possessing good versatility and portability. Attached Figure Description

[0024] To more clearly illustrate the technical solutions of the embodiments of this disclosure, the accompanying drawings used in the description of the embodiments of this disclosure or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0025] Figure 1 A flowchart of a power management method according to an embodiment of this disclosure is shown.

[0026] Figure 2 A flowchart illustrating a method for determining a target power consumption state is shown in an embodiment of this disclosure.

[0027] Figure 3 A schematic diagram of a power management method according to an embodiment of this disclosure is shown.

[0028] Figure 4 A schematic diagram of a master-slave architecture according to an embodiment of this disclosure is shown.

[0029] Figure 5 A schematic diagram illustrating the state changes of a master-slave unit in an embodiment of this disclosure is shown.

[0030] Figure 6 A schematic diagram of a power management device according to an embodiment of the present disclosure is shown.

[0031] Figure 7 A schematic diagram of the hierarchical structure of a power management device according to an embodiment of the present disclosure is shown.

[0032] Figure 8 A schematic diagram of the hardware structure of a communication device according to an embodiment of the present disclosure is shown. Detailed Implementation

[0033] As mentioned in the background section, current low-power management solutions for master-slave architectures have inherent flaws, specifically: The slave device's power consumption status is heavily dependent on the master device's commands, causing the slave device's power consumption management to fail when the master device malfunctions.

[0034] For example, when the master unit fails to work properly due to abnormality, crash, power failure or communication failure, the slave unit lacks independent power management capabilities and often cannot effectively adjust its power consumption according to its own operating status or changes in the external environment, which leads to uncontrolled power consumption of the slave unit and may even cause functional abnormalities or energy waste.

[0035] The high degree of coupling between business logic, power management, and host communication leads to system rigidity and difficulty in debugging.

[0036] For example, business logic, power management logic, and host communication mechanisms are often tightly coupled within the same control flow or state machine. This highly coupled design makes the system structure complex and inflexible, increasing the difficulty of software design and maintenance, and posing significant challenges to system debugging and problem localization. When business requirements or power consumption strategies change, substantial modifications to the overall architecture are often necessary, significantly increasing development costs and risks.

[0037] In addition, existing low-power management solutions are usually custom-designed for specific host platforms or specific application scenarios. Their internal state machines are complex and dependent on host characteristics, lacking good versatility and portability.

[0038] When this type of solution is applied to hostless devices or when the host platform is changed, the original design is difficult to reuse directly. It often requires redesigning the power management logic, resulting in redundant development and reducing system development efficiency.

[0039] Therefore, there is an urgent need for a low-power management technology solution that can reduce the slave device's dependence on the master device, decouple business logic from power management, and has good versatility and portability, so as to overcome the above-mentioned shortcomings of the existing technology.

[0040] Based on this, this disclosure provides a power management method. When the idle task of the slave device starts, a state polling process is performed by polling the state machine to obtain the state information and constraint information of each service module in the slave device. Then, based on the state information of all service modules, a preset condition for entering a low-power state is determined, triggering a low-power event task. This allows the event management module to determine the target power state of the slave device based on the constraint information, and the idle task can then execute the corresponding low-power process according to the target power state. By constructing an intelligent power decision-making scheme within the slave device, the slave device can autonomously manage its own power state. Even when the slave device is disconnected from the master device, its low-power management function remains complete, thereby reducing dependence on the master device, decoupling business logic from power management, and possessing good versatility and portability.

[0041] In other words, this disclosure provides a technical entity that runs independently of the host machine. Its core is a self-closing process triggered by an idle task, which continuously executes an intelligent decision-making loop of "state awareness (voting) → timing judgment (time calculation) → strategy decision (state selection) → instruction execution (hardware control)".

[0042] To enable those skilled in the art to better understand, implement and realize the embodiments of this disclosure, the following exemplary description is provided with reference to the accompanying drawings.

[0043] See Figure 1 The flowchart shown is a power management method according to an embodiment of the present disclosure. This power management method is applied to a slave device, enabling the slave device to autonomously manage its own power consumption state.

[0044] Accordingly, power management methods include: S101, when the idle task of the slave device is started, the state polling process is performed by polling the state machine. The state polling process includes: obtaining the state information and constraint information of each business module in the slave device.

[0045] In some embodiments, an idle task refers to a state of a slave device in which the slave device is not authorized to perform master control functions or provide master service functions, but remains running and has the ability to be switched to an active state.

[0046] In this state, the slave device can automatically start a state polling process, and the polling state machine can obtain state information and constraint information from each business module in the slave set.

[0047] The status information is used to reflect the current operating characteristics of the business module, including one or more of the following: working status, activity level, load level, lifecycle stage, power status, or clock status.

[0048] Constraint information is used to limit the applicable boundaries of power consumption control strategies, including: functional constraints, timing constraints, performance constraints, quality of service constraints, dependency constraints, or security constraints.

[0049] In other words, state information and constraint information are used together to generate low-power control decisions that meet business requirements. When determining a low-power state, the slave device does not only select based on sleep time, but also further combines the business module's restrictions on low-power levels to constrain candidate low-power states, thereby avoiding entering a low-power state that does not meet the operational requirements of the business module.

[0050] In some embodiments, the service module includes at least one of a communication unit, a data acquisition unit, a storage unit, and a timing control unit.

[0051] By acquiring the status and constraint information of each business module, it is determined whether it can enter a low-power mode, and to which specific low-power mode it can enter.

[0052] It should be noted that the business module may also include other modules. This disclosure only discloses a part of the embodiments and does not mean that this solution can only obtain the status information and constraint information of the business module in the above example. It cannot be used to limit this solution.

[0053] S102, responding to the status information of all service modules, determines that the preset conditions for entering the low-power state are met, and triggers the low-power event task.

[0054] In some embodiments, different service modules may have different status information at the same time. For example, in a radio frequency system, the communication unit is the module that carries the vast majority of tasks, and the status information of the communication unit is different from that of other service modules.

[0055] In this way, by combining the status information of all business modules, it can be determined whether the slave device meets the preset conditions for entering a low-power state. Once the preset conditions for entering a low-power state are met, a low-power event task is triggered, and the low-power event processing process begins.

[0056] In some embodiments, the step of determining whether preset conditions for entering a low-power state are met based on the status information of all service modules includes: In the state polling process, low-power voting results generated by multiple service modules are obtained. These low-power voting results characterize the constraints imposed by the corresponding service module on entering the low-power state. Based on the low-power voting results, it is determined whether the preset conditions for entering the low-power state are met.

[0057] Specifically, low-power voting results refer to information generated by a service module based on its current operating state, used to characterize the constraints imposed by the functional module on the device entering a low-power state or sleep mode. Low-power voting results are not limited to simple agreement or disagreement indications, but include information reflecting the restrictions imposed by the service module on sleep mode levels, sleep duration, resource retention conditions, or transaction completion status.

[0058] For example, the low-power voting results include at least one of the following information: information on the low-power state levels that the service module is allowed to enter; information on the limits of the low-power duration of the service module; and information on whether the service module currently has any incomplete operations.

[0059] In this way, by obtaining the low-power voting results of all business modules, it is possible to determine whether the slave device meets the preset conditions for entering low power, which ensures that the slave device can indeed enter the low-power state.

[0060] For example, if all business modules are allowed to enter the low-power state, then it is determined that the slave device meets the preset conditions for entering the low-power state; or, for example, if one of the business modules is in the working state, then it is determined that the slave device does not meet the preset conditions for entering the low-power state, and the status polling processing operation continues.

[0061] In other words, the preset conditions refer to the conditions under which the slave device is allowed to enter the target sleep mode, provided that the low-power constraints imposed by multiple service modules are met. When at least one low-power constraint imposed by a service module cannot be met, it is determined that the preset conditions for entering low-power mode are not met; when the low-power constraints imposed by multiple service modules are all satisfyable, it is determined that the preset conditions for entering low-power mode are met.

[0062] S103, under low-power event task, determines the target power consumption state of the slave device based on the constraint information through the event management module, and returns the target power consumption state to the idle task.

[0063] In some embodiments, when a low-power event task is determined to be triggered, the processing task is transferred from the polling state machine to the event management module. The event management module can determine the target power consumption state of the slave device based on the constraint information of all business modules and return this information to the idle task.

[0064] See Figure 2 The flowchart shown in this embodiment of the present disclosure illustrates a method for determining a target power consumption state, as follows: Figure 2 As shown, the following can be executed: S201, determine the allowed sleep time based on the next wake-up time of each business module.

[0065] Specifically, under normal circumstances, each business module will execute a predetermined task according to a pre-set cycle time. Therefore, after determining that the business module has completed the current task processing, the event management module can obtain or predict the next wake-up time of each business module.

[0066] The next wake-up time can be a preset task trigger time, the arrival time of a periodic task, the expected response time of an external event, or a time point calculated based on historical operating data and scheduling strategies.

[0067] After determining the next wake-up time, the event management module can calculate the allowable sleep time based on the time difference between the current time and the next wake-up time. The allowable sleep time can be represented as the maximum duration required for a slave device or service module to wake up and resume operation before the next wake-up time after entering a low-power state (such as sleep, hibernation, or deep sleep).

[0068] In some embodiments, the earliest wake-up time among all the next wake-up times of all business modules is taken as the allowed sleep time.

[0069] S202 selects candidate low-power states based on sleep time.

[0070] In some embodiments, when determining the allowable sleep time, the wake-up delay time, hardware initialization time, and task preparation time required for each service module to wake up from the sleep state can also be comprehensively considered, so that the low power state of the selected area can ensure that the service module can complete the wake-up before the next wake-up time arrives and execute the corresponding task normally.

[0071] S203, based on the power consumption level constraints of each service module, restricts the candidate low-power states to determine the target low-power state of the slave device; wherein, the power consumption level constraints are used to limit the minimum power consumption state that can be entered, and the target low-power state is a low-power state that is not higher than the power consumption level constraints and meets the sleep time condition.

[0072] In some embodiments, after determining candidate low-power states, the event management module needs to further select the corresponding low-power mode based on the power consumption level constraints of each service module.

[0073] Specifically, candidate low-power states can be screened based on the power consumption level constraints corresponding to each service module. Low-power states with power consumption levels lower than the minimum allowed power consumption level for any service module can be eliminated, thus obtaining a restricted low-power state set. In this way, each low-power state in the restricted low-power state set satisfies the power consumption level constraints of all service modules in the system.

[0074] In this way, different low-power states are suitable for different sleep duration scenarios. If the expected sleep time of the slave device is short, entering a deep low-power state may lead to increased wake-up energy consumption and latency, which is detrimental to overall energy efficiency.

[0075] Therefore, after determining the set of restricted low-power states, the restricted low-power states can be further selected by combining the system's sleep time conditions.

[0076] Specifically, from the set of restricted low-power states, a low-power state whose power consumption level is not higher than the power consumption level constraint and meets the sleep time condition is selected as the target low-power state of the slave device.

[0077] The target low-power state is the low-power state that can achieve the lowest system power consumption under the current sleep time condition, while meeting the power consumption level constraints of all business modules.

[0078] When there are multiple low-power states that meet the conditions, the low-power state with the lowest power consumption can be selected as the target low-power state; or if the energy consumption difference of multiple low-power states under the current conditions is considered to be within a preset range, then any one of them can be selected as the target low-power state.

[0079] As a non-limiting example, the slave device may include multiple low-power states S1, S2 and S3, where S1 is a shallow low-power state, S2 is a medium low-power state and S3 is a deep low-power state, and the power consumption of S1, S2 and S3 decreases in sequence, but the corresponding wake-up time increases in sequence.

[0080] If the power consumption level constraint of service module M1 is S2, it means that the system is not allowed to enter a low power consumption state with a power consumption level lower than S2, that is, it is not allowed to enter the S3 state.

[0081] It should be noted that the number and specific types of the above-mentioned candidate low-power states are merely illustrative examples, and the embodiments disclosed herein are not limited in this regard, as long as multiple low-power states with different power consumption levels can be provided.

[0082] The low-power state determination method described above comprehensively considers the power consumption level constraints of each service module and the sleep time conditions of the system. Compared with low-power management schemes based on only a single power consumption strategy, it can more reasonably select the target low-power state of the slave device, thereby further reducing the overall power consumption of the system and improving energy efficiency while ensuring the performance requirements of the service modules.

[0083] Alternatively, it can be argued that through the above steps, a better balance can be achieved between power consumption and response latency under the current execution strategy. That is, while satisfying the wake-up timing constraints, the sleep time of the system can be made close to the theoretical maximum value, thereby achieving the optimization goal of low-power operation.

[0084] In some embodiments, the target power state includes at least: The first power state is used to stop the processor core while maintaining the operation of the business modules.

[0085] Specifically, the first power state is a low-power operating state of the processor. In this power state, the processor core stops instruction execution and enters a stop or sleep state to reduce the overall power consumption of the processor. At the same time, the business modules related to the business remain in operation to maintain the continuity of the current business.

[0086] By entering the first power consumption state, processor power consumption can be effectively reduced without affecting the normal operation of business modules, thereby improving the overall energy efficiency of the system.

[0087] In this embodiment, the first power consumption state refers to the CPU in a light sleep state, which enables extremely fast response and transparent power consumption optimization.

[0088] The second power consumption state is used to enter a low-power state when some service modules are turned off.

[0089] Specifically, the second power consumption state is a low-power operating state for a service module. In this power consumption state, some service modules are shut down according to current business needs to reduce the system's power consumption; at the same time, the remaining service modules remain operational to meet the basic functional requirements of the device.

[0090] In the low-power state, the service modules that are turned off stop receiving power and / or stop receiving clock signals, thus ceasing to perform their corresponding service functions; while the service modules that are not turned off still maintain the necessary power supply and clock to ensure the normal operation of the device in the low-power state.

[0091] In this embodiment, the second power consumption state corresponds to service sleep, achieving module-level energy saving and maintaining rapid recovery capability. By entering this power consumption state, while ensuring its basic operating capabilities, the overall power consumption can be effectively reduced, thereby improving the energy efficiency of the device.

[0092] The third power state is used to enter a deep low-power state while retaining only the preset memory cells and the real-time clock.

[0093] Specifically, under this power consumption state, all functional modules except the preset storage unit and real-time clock are turned off or put into a power-off state to minimize the power consumption of the system.

[0094] In the third power consumption state, the preset storage unit is kept powered to store the critical data required for system operation; the real-time clock is kept working to maintain time counting and time synchronization functions; the remaining modules stop being powered and / or stop the clock signal, so they no longer perform the corresponding functions.

[0095] By entering a deep low-power state, the system power consumption can be further reduced while ensuring that critical data and time information are not lost, making it suitable for long-term standby or hibernation scenarios.

[0096] It should be noted that the three power consumption states listed in this solution are merely illustrative examples, used to indicate that the slave device can have different sleep states. In practical applications, more power consumption states can be set according to the application requirements of the slave device.

[0097] S104 executes the corresponding low-power process based on the target power consumption state through the idle task.

[0098] In some embodiments, by executing steps S101 to S103, the target power consumption state can be returned to the idle task, so that the idle task can set the slave device to a low power consumption state according to the target power consumption state.

[0099] Specifically, after determining that the device has entered a target power consumption state, a set of corresponding low-power procedures can be pre-defined for that target power consumption state. These low-power procedures are used to reduce power consumption through the orderly control of hardware resources and software functions, while ensuring the operation of basic functions or necessary services.

[0100] When executing the target power state, the working mode, start state, and execution order of each service module in the slave device can be determined. Therefore, by executing the low-power process, the slave device can have one of the first power state, the second power state, and the third power state.

[0101] As can be seen from the above, the slave device has at least three different power consumption states, and different power consumption states correspond to different levels of sleep states, thus requiring different wake-up processes to be configured.

[0102] For example, when the slave device is in the target power consumption state, in response to the state polling process, when a wake-up event that meets the preset conditions is detected, the wake-up process is triggered; different wake-up events are configured for different target power consumption states.

[0103] Specifically, when the slave device is in a low-power operating state, a state polling process is performed to periodically or event-drivenly check the current system state to determine whether a wake-up event that meets preset conditions exists. When a wake-up event that meets preset conditions is detected during the state polling process, the system is triggered to enter the wake-up process from the current target power state.

[0104] In this embodiment, the target power consumption state can include multiple different power consumption levels. The system's functionality and power requirements differ under different target power consumption states. For each different target power consumption state, a corresponding set of wake-up events is pre-configured, enabling the wake-up process to be triggered by different types of wake-up events under varying power consumption states.

[0105] As a non-limiting example, when the slave device is in a first power state, the wake-up event set includes at least one of the following: an interrupt event and / or a timing event; when the slave device is in a second power state, the wake-up event set includes at least one of the following: a low-power timing event, an external trigger event, or a sensor event; when the slave device is in a third power state, the wake-up event set includes at least one of the following: a real-time clock wake-up event, a power-triggered event, or a dedicated wake-up pin event.

[0106] In other words, by configuring different wake-up events for different target power consumption states, the slave device can flexibly enter the wake-up process according to the actual operating state while ensuring low power consumption operation.

[0107] To better understand and illustrate the power management scheme for the slave device in this disclosure embodiment, specific examples are provided.

[0108] See Figure 3 The diagram shown below illustrates a power management method in an embodiment of this disclosure. Figure 3 As shown, the following steps can be performed: S301, Idle task started.

[0109] S302, the polling state machine performs state polling processing.

[0110] S303: Check whether the low-power voting result meets the preset conditions. If it does (i.e., Y), proceed to the low-power event task; if it does not (i.e., N), return to S302.

[0111] In some embodiments, when performing a low-power event task, the following steps may be performed: S304, Notification Event Management Module.

[0112] S305, calculates sleep time.

[0113] S306, decide on sleep state and return to idle task start.

[0114] S307 is a low-power process corresponding to idle task execution and decision sleep state.

[0115] In the above implementation, the slave device can make intelligent decisions based on its internal state, starting from an idle task, so that the low-power process of the slave device will not be interrupted due to external system anomalies, thereby achieving adaptive entry into a low-power state.

[0116] However, in practical applications, depending on different application scenarios or system requirements, the cooperation or association between the master and slave machines can also be considered to achieve better implementation results.

[0117] More specifically, during the execution of the state polling process, the method also includes: receiving scheduling information from the host, which is used to characterize the host's operating state and scheduling constraints; and making collaborative decisions on the low-power entry timing and target sleep mode of the slave based on the scheduling information and the slave's local sleep state information.

[0118] In some embodiments, during the operation of a master-slave system, the master is responsible for managing the overall operating status of the system and periodically or event-triggeredly sending scheduling information to the slave. The scheduling information is used to characterize the current operating status of the master and the scheduling constraints on the slave.

[0119] In this embodiment, the scheduling information may include, but is not limited to, at least one of the following: the current workload state of the host; the task scheduling cycle of the host; the host's response latency requirements to the slave; the time window during which the host allows the slave to enter a low-power state; and the constraints on the wake-up time of the slave.

[0120] It should be noted that different combinations of scheduling information will correspond to different scheduling constraints. In this embodiment, as long as the scheduling information can be used to reflect the host's operating status and constrain the slave's power consumption behavior, it falls within the scope of protection of this invention.

[0121] After receiving the scheduling information sent by the host, the slave device obtains its own local sleep state information as the basis for subsequent low-power collaborative decisions.

[0122] In this embodiment, the local sleep state information of the slave device may include, but is not limited to, at least one of the following: the current power consumption state; the power consumption parameters of each selectable sleep mode; the entry latency and wake-up latency corresponding to each sleep mode; the current task execution progress, etc.

[0123] Furthermore, after determining the scheduling constraints of the master and the local sleep state information of the slave, the slave makes a collaborative decision on the low-power entry timing and the target sleep mode.

[0124] In this embodiment, collaborative decision-making may include at least one of the following: determining whether the slave device enters a low-power state; determining the specific time when it enters a low-power state; and selecting a target sleep mode from multiple selectable sleep modes.

[0125] As a non-limiting example, when the scheduling information indicates that the master does not need the slave to participate in the calculation within a preset time period, and the local state of the slave meets the conditions for entering deep sleep mode, the slave can choose to enter the target sleep mode at the beginning of that time period.

[0126] In some embodiments, the timing of entering the low-power state can be adjusted according to the host's constraints on response latency, such as entering the low-power state earlier or later, to ensure that the slave device can meet the host's timing requirements when it is scheduled.

[0127] It should be noted that different combinations of scheduling information and local sleep state information will correspond to different collaborative decision-making results, and there may be multiple decision results that satisfy scheduling constraints.

[0128] In this embodiment, after the slave device enters the low-power state, it can continuously monitor changes in the host scheduling information or changes in the local state. When any change is detected to meet the preset adjustment conditions, the low-power strategy is dynamically adjusted.

[0129] As a non-limiting example, when the master sends new scheduling information in advance, indicating that the slave needs to participate in the calculation in advance, the slave can exit the current sleep mode in advance, or switch to a sleep mode with a shorter wake-up latency.

[0130] It should be noted that, through the above-mentioned collaborative decision-making and dynamic adjustment mechanism, the overall power consumption of the slave devices can be reduced while meeting the host scheduling constraints, thereby improving the energy efficiency of the system.

[0131] Combination Figures 1 to 3 See Figure 4 The diagram shown below illustrates a master-slave architecture in an embodiment of this disclosure, as follows: Figure 4 As shown, when the idle task starts, it can obtain status information and constraint information from the business module.

[0132] By executing a voting arbitration, the event management module can be notified when preset conditions are met. The event management module can then return the corresponding target power consumption state to the idle task, i.e., the corresponding return status.

[0133] At the same time, through the collaborative function of the cooperative state machine, the idle task can also determine the scheduling information of the host through polling operations, so that the idle task can execute hardware control based on the scheduling information and the return status, thereby controlling the corresponding control domain and enabling the slave to enter the corresponding sleep state.

[0134] In some embodiments, the host switches between an active state, a suspend state, and a resume state, and sends a status notification corresponding to the active state to the slave device when the state switches.

[0135] Accordingly, power management methods include: Based on the received host operating status, it switches between idle state (IDEL), suspend-wait state (SUSPEN-WAIT), wake-up idle state (WAKE-IDEL), and resume state (RESUME).

[0136] In some embodiments, the slave device continuously receives operating status information from the master device during operation. The operating status is used to characterize whether the master device is currently in the service execution phase, low power consumption phase, or recovery phase.

[0137] Accordingly, the host switches between multiple states based on the received host operating status, thereby achieving unified scheduling and management of the workflow.

[0138] It should be noted that the above states are logical states used to describe the processing behavior of the device at different operating stages, and do not constitute a limitation on the specific hardware structure or implementation method.

[0139] When in the idle state (IDEL), a state polling process is performed, and when the target power consumption state is determined, a sleep step is performed and a suspend waiting state is entered.

[0140] In some embodiments, when the slave device is in an idle state, it means that it has not received a service processing instruction from the master device. At this time, the slave device periodically detects its own power consumption status or operating requirements by performing status polling.

[0141] During the polling process, if the requirements for entering the target power consumption state are met, the slave device will execute preset sleep steps, including but not limited to shutting down some functional modules, reducing the operating frequency, or entering a low-power mode.

[0142] After completing the sleep step, the slave device switches from idle state to suspended waiting state to wait for subsequent status change notifications from the master device.

[0143] For details regarding the state polling process, please refer to the examples mentioned above.

[0144] When a notification is received that the host has entered the recovery state, the wake-up recovery steps are executed, and the system transitions from the wake-up idle state to the recovery state, and finally returns to the idle state to continue business processing.

[0145] In some embodiments, when the slave device is in a suspended waiting state, it will continuously monitor the status change information of the master device.

[0146] Upon receiving a notification that the slave device has entered recovery mode, the slave device executes a wake-up recovery procedure, which may include: restoring disabled functional modules, reinitializing hardware resources, and restoring system operating parameters.

[0147] During the wake-up and recovery process, the slave device first switches from the suspended waiting state to the wake-up idle state, and after the wake-up process is completed, it further enters the recovery state to cooperate with the host to complete the relevant operations of the recovery phase.

[0148] Once the slave device has completed all processing operations corresponding to the master device's recovery state, the slave device's current state switches from the recovery state back to the idle state.

[0149] By implementing the above state switching process, the power consumption during idle periods can be effectively reduced while ensuring the normal business processing capabilities of the slave device, thereby improving the overall operating efficiency and stability of the slave device.

[0150] See Figure 5 The diagram shown below illustrates a master-slave state change in an embodiment of this disclosure, as follows: Figure 5 As shown, the master timeline, slave timeline, and slave process line are displayed respectively.

[0151] The host's state includes: host Active, host Suspend / Shutdown, and host Resume, and the host switches between states in the order of Active → Suspend / Shutdown → Resume → Active.

[0152] The slave device's states include: RESUME, IDLE, SUSPEN-WAIT, and WAKE-IDEL, and the slave device switches between states in the order of IDLE→SUSPEN-WAIT→WAKE-IDEL→RESUME.

[0153] Furthermore, when the slave device is in the IDLE state, it enters the slave process line and sequentially executes the voting arbitration, time calculation, wake-up recovery, business processing, and then the voting arbitration loop.

[0154] Specifically, during the time calculation and wake-up recovery phases, it can be triggered to return to SUSPEN-WAIT, and during wake-up recovery and business processing, it can be triggered to return to WAKE-IDEL.

[0155] More specifically, the slave device responds in an orderly manner to the master device's Suspend / Shutdown and Resume behaviors through an explicit state machine.

[0156] When the master is in the Active state, the slave works in the IDLE state and performs normal business processing. When the master enters the Suspend / Shutdown phase, the slave does not immediately enter low power mode, but first switches to the SUSPEND_WAIT state. In this state, the sleep condition is determined, voting arbitration is carried out, and the sleep duration is calculated. Only after ensuring that there are no incomplete transactions and the low power entry condition is met will the actual sleep operation be performed.

[0157] When the master initiates a Resume, the slave first enters the WAKE_IDLE state, only performing necessary wake-up and environment recovery processes, including clock, resource, and context recovery. During this stage, it does not provide full business capabilities to the outside world.

[0158] Once the recovery process is complete, the slave device enters the RESUME state and eventually returns to the IDLE state, regaining its normal business processing capabilities.

[0159] In other words, when the host is in the Active state, the slave is in the IDLE state and performs normal business processing.

[0160] When the slave device receives a Suspend / Shutdown command initiated by the host, it switches from the IDLE state to the SUSPEND_WAIT state.

[0161] In the SUSPEND_WAIT state, the slave device will switch from the SUSPEND_WAIT state to the SLEEP state only after the preset sleep entry conditions are met.

[0162] When the slave device receives a recovery command initiated by the host, it switches from the SLEEP state or SUSPEND_WAIT state to the WAKE_IDLE state.

[0163] After the slave device completes the necessary resource recovery related to wake-up in the WAKE_IDLE state, it enters the RESUME state and eventually switches back to the IDLE state.

[0164] By decoupling the master control timing, slave state machine, and slave internal processing flow, and by clearly constraining the operations allowed to be executed in different states, state confusion or erroneous execution of services can be avoided during power switching, thereby ensuring the consistency and reliability of the system during sleep and wake-up processes.

[0165] It is understood that the above embodiments provide multiple implementation schemes, and these implementation schemes can be combined and cross-referenced with each other without conflict, thereby extending to multiple possible implementation schemes. These can all be considered as the implementation schemes disclosed and made public in this application.

[0166] This disclosure also provides an apparatus corresponding to the power management method described above, which will be described in detail below with reference to the accompanying drawings and specific embodiments.

[0167] See Figure 6 The schematic diagram shown below illustrates the structure of a power management device in an embodiment of this disclosure, as follows: Figure 6 As shown, the power management device 600 is located on the slave device.

[0168] Accordingly, the power management device 600 may include: The startup module 610 is configured to perform state polling processing by polling a state machine when the idle task of the slave device is started. The state polling processing includes: obtaining the state information and constraint information of each service module in the slave device. Trigger module 620 is configured to respond to the status information of all service modules, determine that the preset conditions for entering the low-power state are met, and trigger a low-power event task. The polling module 630 is configured to, under the low-power event task, determine the target power consumption state of the slave device according to the constraint information through the event management module, and return the target power consumption state to the idle task; The execution module 640 is configured to execute a corresponding low-power process based on the target power consumption state through the idle task.

[0169] Among them, regarding Figure 6 For more information on the working principle, operation method, and beneficial effects of the RF transmit power calibration device shown, please refer to the preceding text and... Figures 1 to 5 The specific details will not be repeated here.

[0170] It is understandable that the above division of modules is only a logical functional division. In actual implementation, they can be fully or partially integrated into a single physical entity, or they can be physically separated. Furthermore, the above modules can be implemented by the processor calling software.

[0171] See Figure 7The diagram shown below illustrates the hierarchical structure of a power management device in an embodiment of this disclosure, as follows: Figure 7 As shown, the power management device is divided into four layers, from bottom to top: driver layer, operating system layer, middleware layer and application layer.

[0172] The layers interact with each other through interfaces, which decouples hardware-related logic from business logic and improves the system's portability, maintainability, and low-power management capabilities.

[0173] The driver layer is located at the lowest level of the software and is responsible for interacting directly with hardware resources and providing a unified hardware access interface to the upper layers.

[0174] This layer mainly includes modules such as the Hardware Abstraction Layer (HAL), timer drivers (e.g., 32K timer drivers), power management unit (PMU) drivers, and RF / MAC / PHY drivers.

[0175] By abstracting the underlying hardware through the HAL layer, the upper-layer software does not need to care about the specific chip implementation details, thereby enhancing the portability of the system.

[0176] The operating system layer is implemented based on a real-time operating system (RTOS) and is mainly responsible for the creation, scheduling and management of system tasks.

[0177] This layer contains a task scheduling module and control tasks, which are used to trigger low-power strategies when the slave device is idle.

[0178] The operating system layer provides support for multi-task concurrency, time management, and basic synchronization mechanisms for upper-layer middleware and applications.

[0179] The middleware layer is located between the operating system layer and the application layer. It is used to encapsulate common system capabilities and provide a unified and easy-to-use service interface to the application layer.

[0180] This layer mainly includes power management services, voting arbitration interface, time management services, and state machine interface.

[0181] The middleware layer manages system resources and status centrally, avoiding direct access to operating system or hardware resources by the application layer, thereby reducing system complexity.

[0182] The application layer is used to implement specific product functions and business logic, and it is the top layer of the system software.

[0183] This layer includes a business logic processing module, an interrupt handling module, and a low-power event task (LP EventTask).

[0184] The application layer adopts an event-driven design approach, responding to interrupts, timers, and wireless events through interfaces provided by middleware, thereby achieving efficient and low-power business processing.

[0185] By adopting a layered design, the responsibilities of each layer are clear and the interface boundaries are well-defined, so that hardware-related logic is concentrated in the driver layer and business logic exists only in the application layer, thus reducing the coupling between modules.

[0186] More specifically, it supports low-power design at the architecture level. Through the coordinated work of idle tasks, timers and power management services, the slave device can automatically enter low-power mode when idle and be woken up in time when an event is triggered.

[0187] In one embodiment, after the system is powered on, it first enters the startup phase, where it sequentially completes the initialization of hardware and software resources.

[0188] The system completes basic hardware initialization, including: clock, memory and necessary peripheral configuration; initialization of hardware abstraction layer and underlying driver modules; startup of real-time operating system and completion of kernel initialization; creation of system tasks, including application tasks, low-power event tasks and idle tasks; initialization of middleware service modules, including power management service, time management service and state machine interface; after system initialization is completed, task scheduling is started and the system enters normal operation.

[0189] The system primarily employs an event-driven mechanism for processing during operation. When external or internal events occur, the operational flow is as follows: External interrupts (such as timers, GPIO, or wireless events) trigger interrupt service routines (ISRs); the interrupt service routines only perform the necessary status recording or event encapsulation and post the events to low-power event tasks; the low-power event tasks are scheduled and executed by the operating system and retrieve pending events from the event queue.

[0190] Application layer business logic processes events according to their type and accesses system resources through middleware interfaces. If timed events or state transitions need to be initiated during business processing, they are managed uniformly through time management services or state machine interfaces.

[0191] When the slave device has no pending tasks and meets the low-power entry conditions, the slave device will automatically enter the low-power state.

[0192] This disclosure also provides a communication device, including a memory and a processor. The memory stores a computer program that can run on the processor. When the processor runs the computer program, it performs the steps of the power management method as described in any of the foregoing embodiments.

[0193] See Figure 8 , Figure 8This is a schematic diagram of the hardware structure of a communication device according to an embodiment of the present disclosure.

[0194] The communication device can be a radio frequency system.

[0195] Figure 8 The illustrated communication device includes a memory 81, a processor 82, and a transceiver 83. The processor 82 is coupled to the memory 81 and the transceiver 83. The memory 81 can be located inside or outside the terminal. The memory 81, processor 82, and transceiver 83 can be connected via a communication bus. The transceiver 83 is used to communicate with other devices or communication networks.

[0196] Optionally, transceiver 83 can be a transmitter. A computer program that can run on processor 82 is stored on memory 81. When processor 82 runs the computer program, transceiver 83 performs the steps in the power management method provided in the above embodiments.

[0197] This disclosure also provides a chip that stores a computer program, which, when executed by the chip, causes the steps of any of the power management methods in the foregoing embodiments to be performed.

[0198] The chip has the same or similar architecture as the communication device.

[0199] This disclosure also provides a computer-readable storage medium storing a computer program thereon, which, when run by a processor, causes the power management method of any of the foregoing embodiments to be executed.

[0200] This disclosure also provides a computer program product, which includes a computer program / instructions that, when run on a computer, cause the computer to perform the steps of the power management method as described in any of the foregoing embodiments.

[0201] Storage media can include read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks. Storage media can also include non-volatile or non-transitory memory.

[0202] It should be understood that in the embodiments of this disclosure, the processor can be a central processing unit (CPU), but it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0203] It should also be understood that the memory in the embodiments of this disclosure may be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. Non-volatile memory may be ROM, programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory may be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DRRAM).

[0204] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions according to the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer program can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another. For example, a computer program can be transferred from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means.

[0205] While the embodiments disclosed herein are as described above, this disclosure is not limited thereto. Any person skilled in the art can make various alterations and modifications without departing from the spirit and scope of this disclosure; therefore, the scope of protection of this disclosure should be determined by the scope defined in the claims.

Claims

1. A power consumption management method applied to a slave device, characterized in that, Power management methods include: When the idle task of the slave device is started, a state polling process is performed by polling the state machine. The state polling process includes: obtaining the state information and constraint information of each business module in the slave device. In response to the status information of all business modules, determine if the preset conditions for entering a low-power state are met, and trigger a low-power event task; Under the low-power event task, the event management module determines the target power consumption state of the slave device based on the constraint information and returns the target power consumption state to the idle task; The idle task executes the corresponding low-power process based on the target power consumption state.

2. The power management method according to claim 1, characterized in that, The constraint information includes at least the next wake-up time and power consumption level constraints for each service module. The step of determining the target power consumption state of the slave device based on the constraint information through the event management module includes: The allowed sleep time is determined based on the next wake-up time of each of the aforementioned business modules; Based on the sleep time, a candidate low-power state is selected; Based on the power consumption level constraints of each of the service modules, the candidate low-power states are restricted to determine the target low-power state of the slave device; wherein, the power consumption level constraints are used to limit the minimum power consumption state that is allowed to be entered, and the target low-power state is a low-power state that is not higher than the power consumption level constraints and meets the sleep time condition.

3. The power consumption management method according to claim 2, characterized in that, The step of determining the allowable sleep time based on the next wake-up time of each of the business modules includes: The earliest wake-up time among all business modules is taken as the allowed sleep time.

4. The power management method according to claim 1, characterized in that, Based on the status information of all business modules, the steps to determine whether the preset conditions for entering a low-power state are met include: In the state polling process, low-power voting results generated by multiple service modules are obtained respectively. The low-power voting results are used to characterize the constraints imposed by the corresponding service module on entering the low-power state. Based on the low-power voting results, determine whether the preset conditions for entering low-power mode are met.

5. The power management method according to claim 1, characterized in that, When the slave device is in the target power consumption state, in response to the detection of a wake-up event that meets preset conditions during the state polling process, the wake-up process is triggered; wherein, different wake-up events are configured for different target power consumption states.

6. The power consumption management method according to claim 1, characterized in that, During the state polling process, the method further includes: Receive scheduling information from the host, the scheduling information being used to characterize the host's operating status and scheduling constraints; Based on the scheduling information and the local sleep state information of the slave device, a collaborative decision is made on the low-power entry timing and target sleep mode of the slave device.

7. The power consumption management method according to claim 6, characterized in that, The host switches between active, suspended, and resumed states, and sends a status notification corresponding to the operating state to the slave device when the state switches. The power consumption management method includes: Based on the received operating status of the host, the system switches between idle state, suspended waiting state, woken-up idle state, and resumed state. When in the idle state, the state polling process is executed, and when the target power consumption state is determined, a sleep step is executed and a suspend waiting state is entered. When a notification is received that the host has entered the recovery state, a wake-up recovery step is executed, and the host enters the recovery state from the wake-up idle state, and finally returns to the idle state to continue service processing.

8. The power management method according to claim 1, characterized in that, The business module includes at least one of the following: a communication unit, a data acquisition unit, a storage unit, and a timing control unit.

9. The power management method according to claim 1, characterized in that, The target power consumption state includes at least: The first power consumption state is used to stop the processor core while maintaining the working state of the business module; The second power consumption state is used to enter a low power consumption state when some service modules are turned off; The third power state is used to enter a deep low-power state while retaining only the preset memory cells and the real-time clock.

10. A power management device, configured in a slave device, characterized in that, The power management device includes: The startup module is configured to perform state polling processing by polling the state machine when the idle task of the slave device is started. The state polling processing includes: obtaining the state information and constraint information of each service module in the slave device. The triggering module is configured to respond to the status information of all business modules, determine whether the preset conditions for entering the low-power state are met, and trigger the low-power event task. The polling module is configured to, under the low-power event task, determine the target power consumption state of the slave device based on the constraint information through the event management module, and return the target power consumption state to the idle task; The execution module is configured to execute a corresponding low-power process based on the target power consumption state through the idle task.

11. A communication device comprising a memory and a processor, wherein the memory stores a computer program executable on the processor, characterized in that, When the processor runs the computer program, it performs the steps of the power management method according to any one of claims 1 to 9.

12. A chip storing a computer program, characterized in that, When the computer program is executed by the chip, the power management method according to any one of claims 1 to 9 is executed.

13. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is run by the processor, the power management method according to any one of claims 1 to 9 is executed.

14. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the power management method according to any one of claims 1 to 9.

Images