1 Introduction
The chip data sheet says low power consumption, and those surprisingly small current standards above are just a display of a state of suspended animation that cannot work. The operating power consumption is real. Sometimes in order to reflect low power consumption, a so-called low-power consumption mode must be designed in the application. When the system confirms that there are no tasks, it will sleep. Therefore, the logic of low power consumption, which “needs the horse to run and the horse not to eat grass”, has become a conventional choice to reduce system power consumption in normal working mode.
From a hardware perspective, find all loops that may consume current, determine which ones can be optimized through software control, and which ones are inevitable, and provide software developers with the relationship between the impact of all IO port states on power consumption, using A simple table explains what happens when the level is high or low, and what happens when it is suspended. Configure the driver software in the early stage to verify that the minimum current meets the standards during operation, and it can basically confirm that the hardware is normal. The rest is the space for software developers to play, and software-based power consumption reduction strategies are the focus of this article.
2. Driver software design
(1)Port configuration
First, confirm the default state of the pin after reset, whether there is leakage in this state, whether some clock sources will be turned on, whether it is internal pull-up or pull-down, and then the software will make corresponding configurations in combination with hardware or peripherals. For example, the AD channel disables internal pull-ups, ordinary GPIOs are set to output low or high to avoid leakage, and floating pins avoid interrupt input mode.
For fixed connection control, push-pull output can be used to control peripherals, or open drain can be selected when external pull-up is used; special pins such as UART can be configured in general configuration mode, and the hardware automatically controls the corresponding level; intermittent operation such as ADC is used as input conversion After completion, you can set it to output again or close AD.
Some peripherals are pluggable. For example, when the UART is normally idle, both transceiver and transmitter are high. If the peripheral is turned off or removed and it still remains high, there is leakage. In this case, the pin needs to be set to output low. Focus on one state during work, and switch states in time when work is completed or abnormal to avoid leakage or level mismatch.
If the peripheral supports interrupts, try to enable them instead of periodically polling for communication.
(2)Power management
Chips are often divided into different power domains, and hardware peripherals are also powered by different units. For parts that are not used temporarily, the power domain and clock domain can be turned off immediately. When the hardware cost allows or the power consumption requirements are strict, the peripherals should be powered independently as much as possible, so that the power can be controlled by software when not in use. It should be noted that after turning off the power domain, some ports may need to be reconfigured to avoid leakage. As mentioned in the previous section, after turning off the power supply of the peripheral, the UART port of the peripheral becomes low, and the UART port of the master control cannot continue to maintain a high level. .
(3)System clock
In normal working mode, the higher the frequency, the higher the power consumption, the shorter the time to complete the same work, and the faster it can enter sleep. If the microcontroller is mainly used for control and does not have complex operations, then the frequency reduction can be achieved by switching to a lower frequency. If there are a lot of mathematical calculations, you can exchange space for time, or run it at high frequency first to complete the algorithm as soon as possible, and then dynamically switch to low frequency after running.
Under the same clock, the power supply voltage is low and the power consumption is low; scheduled sampling and screen refresh can also be processed as low-frequency as possible to meet the needs.
(4) Standby bottom current
Consult the data sheet or official SDK documentation to determine the lowest power consumption sleep mode that meets the requirements and can be woken up, write a test case, turn off all possible power-consuming peripherals, enter the sleep state, and verify the power consumption under extreme conditions.
Hardware may also be needed to eliminate the inherent power consumption that cannot be optimized on the circuit board, such as voltage conversion and other fixed current consumption parts. Simply look at the operating current of the main chip to see whether it reaches the theoretical value in the corresponding mode in the data sheet. If it is not satisfied, you need to continue to turn off some functions that are automatically turned on after reset, such as clock enable, etc.; or the hardware engineer can cooperate with the removal of suspicious devices to speed up the investigation. This first step is very critical. It directly determines the best effect that the power consumption of the whole machine can achieve in the later stage. At the same time, during the configuration process, it is very subtle to understand which peripherals and configurations affect power consumption, how they affect it, and how much impact it has.
(5) Sleep and wake-up
After hibernation, some work at a reduced frequency, some are in suspended animation (the software is not running, and the memory can be restored; some cannot be restored, and the wake-up effect is similar to a restart), or they are shut down directly (RTC shutdown alarm clock wakes up). Different hardware solutions and software requirements, the sleep mode behave differently. During the development of the microcontroller, confirm all its sleep modes and which clock sources work or sleep in the corresponding sleep modes. Combined with the needs of specific applications, the system's needs for wake-up sources and wake-up modes are clarified, thus determining the basic sleep mode of the system.
Note that some chips only maintain a wake-up state on a few ports in sleep mode, and only special pins can wake up. This needs to be considered before hardware design.
(6)Power consumption evaluation
Reducing power consumption is a problem that can only be solved by software and hardware working together. For example, if the voltage-dividing resistor during AD sampling is directly connected to the ground, it will continue to consume current. If the voltage-dividing resistor is increased enough, the static current will appear to be small, but because the internal resistance of the AD is shunted, there will be a large deviation in the final result. If the grounding method is controlled through an IO port, and it is only grounded when sampling is needed, and suspended or pulled high after sampling is completed, the static loss can be reduced to the minimum. Although the cost increases a lot, it actually saves money. The electricity is gone. Whether to adopt it depends mainly on the power consumption standard. If the sustained static loss is slightly acceptable, there is no need to increase the hardware cost.
To achieve the lowest power consumption of the system, sometimes it is necessary to make compromises between peripheral performance, hardware cost and power consumption. Whether the CPU can be down-clocked, whether the hardware peripherals support interrupt wake-up, etc., these will affect the final standby power consumption. Reducing power consumption is the key to achieving the lowest power consumption. The result of the cooperation between hardware and software, the software configures the driver, and the hardware confirms one by one whether the current is within expectations. The definition of the theoretical value depends on the original manufacturer's data or experience, and is a compromise with the standby time defined by the product.
3. Business software design
Low power consumption can solve part of the problem through hardware, but relying solely on hardware is definitely not enough. It requires close cooperation with software to achieve the best results. The above is from the hardware driver level, which is generally concerned about, but in fact the software business layer is highly flexible, and the effect of exploring low power consumption is more significant than the effect of hardware low power consumption itself. In layman's terms, the underlying hardware The saving effect of painstakingly optimizing the design is far inferior to the performance of well-designed software.
From the design of software business logic and product requirements, there are even more unexpected effects in terms of power consumption. A simple summary of software power consumption optimization is "sleep when you can."
(1) Task periodization
An embedded product includes many sub-functions and sub-tasks, and an application is implemented by calling several services. The services here can be hardware services, such as AD voltage sampling, UART serial communication, or software services, such as TCP/IP network communication, etc. Simple functions such as CRC check are implemented in pure software, and the results are obtained immediately when the function is run, with no impact on power consumption; complex functions should be implemented in the form of tasks as much as possible, and do not specifically refer to tasks or threads of the operating system, which can be understood as A process is a complete process of running a sub-function. If something has a beginning and an end, it can be repeated as needed. For tasks that run periodically, clearing the start and end time points of the operation and distinguishing between running and non-running states can lead to better optimization, such as reducing the running duration or the period of high current. The effect in terms of power consumption is more obvious.
(2) Sleep self-care and coordination
Divide the entire embedded software system into many small tasks that work periodically, and they may be interleaved or unrelated and parallel. Essentially, each small task only needs to pay attention to its own start and end time points. The power consumption management of the system is to manage the power consumption of each task. Only in an effective coordination method can the overall power consumption be minimized. Task-based power consumption management is actually divided into two parts, the power consumption management of a single task itself from a micro perspective, and the sleep coordination of multi-tasks from a macro perspective.
From a microscopic perspective, a task can independently complete its own functions. All steps in the task are determined and "have the final say." It is a "black box" to the outside world and is a "black box" to low-power users. The requirements are nothing more than the following situations:
(1). Sleeping is not allowed during task execution. Therefore, flags should be set at the beginning and end of the task to inform the coordination system, "As long as I disagree, the system will not be allowed to sleep."
(2) During the execution of the task, sleep is allowed in some stages and not allowed in some stages; during the execution of the task, different sleep levels are allowed in different stages.
(3) During task execution, it does not matter whether it sleeps or not.
Three types of tasks exist in the system at the same time. The first type of task is quite overbearing. As long as it is executing, sleep is not allowed at all. The second type of task not only completes the task, but also takes into account sleep. The third type of task can basically be regarded as The air is ignored. When designing system tasks, the latter two types of tasks should be written as much as possible, and avoid or try to split the first type of tasks.
From a macro perspective, multiple tasks may be executing at the same time at any time, and each task has different sleep requirements. What if we want to set up a coordination mechanism? According to the minimum requirements, each task can come to the sleep coordination mechanism to sign in and vote at any time, indicating the sleep level corresponding to the lowest power consumption it can currently tolerate. The arbiter of the sleep coordination mechanism checks the voting results of all tasks regularly or in polls to find the minimum sleep Level, similar to the shortest ring of the bucket as the "consensus", and then enters the corresponding dormant level.
If someone votes "not to hibernate", the arbitration can only give up hibernation. Therefore, every task should be a responsible task, and each should update its tolerance for dormancy in a timely manner according to its own different steps, so as to ensure that voting can achieve meaningful results.
This mechanism is also easy to implement, such as
uint16_t sleep_enable = 0xFFFF; //0xFFFF表示可以进入休眠
uint16_t sleep_enable=0xFFFF means that the system can enter sleep. Each task operates the corresponding bit independently. It is cleared to 0 when sleep is disabled and set to 1 when sleep is allowed. The sleep coordination mechanism is to regularly query whether sleep_enable is 0xFFFF. It can be queried in main polling or RTOS standby task to enter and exit sleep.
The division of tasks should be reasonable and sleep should be allowed as much as possible. Through this negotiation mechanism, the problem of "sleeping when you can" can be solved.
4. Tasks waiting to be merged
Because of different environments or peripheral combinations, the requirements may not be achieved in certain periods of time, or there is a high probability that it cannot be achieved based on the current information, or part of the hardware fails. After the software detects this abnormality, it needs to stop losses in time to reduce unnecessary consumption. . For example, the attribute of GNSS satellite positioning is that it must be positioned in an open area. If the device turns on GNSS but finds that the signal is very poor, it can be initially judged that the current position may be indoors. Even if it continues to work, it cannot be positioned. You can turn off GNSS immediately to save power; of course, the product Other operations that are not positioned need to be considered at the demand level. Or if it is confirmed during communication that the peripheral device does not exist or is damaged, there is no need to continue the power supply timing interaction and just issue an abnormal alarm.
5. Demand level
When defining requirements, fully consider the start and end requirements of a certain task or peripheral work to avoid long periods of ineffective work. For example, the acceleration sensor can be used to determine whether the device is in motion before monitoring is started, or infrared or voice control can be used to determine if someone is approaching before starting work. This is done through product definition and combination at the demand level. Only when the requirements are met will the work be awakened. If the requirements are not met, it will stop and go to sleep in time. Of course, it may also increase the hardware cost. For some equipment, you can also consider using the site to add solar charging panels to increase revenue and reduce expenditure.
6. If a worker wants to do his job well, he must first sharpen his tools.
Before practicing low-power system design, there must be an effective means to detect or observe the current working mode of the system. You can intuitively know when the system is working, when it is sleeping, the working time and the sleeping time. A high-precision ammeter is essential. Less, it would be better if the current-time curve can be recorded, and the software process or time parameters can be optimized specifically for the current curve.