What is the law of learning embedded systems?

Embedded system is a kind of special computer system, which has certain application in many fields. It is well known that low power consumption is already an important indicator for measuring an embedded system. In fact, real-time clocks can be used to reduce the power consumption of embedded systems. What is the specific method? Today Xiaobian has come to introduce in detail how to use real-time clocks to reduce the power consumption of embedded systems. I hope to help everyone.

1. Embedded CPU Low Power Mode Introduction

As the core of the embedded system, the power consumption of the embedded CPU plays an important role in the entire system. Current popular embedded system CPUs basically provide low power consumption. In general, when the embedded CPU has an operating mode and a low power mode, the low power mode can be further divided into an idle mode, a sleep mode, a sleep mode, and the like. After entering the low power mode, the CPU's power consumption will be reduced significantly. When the external interrupt occurs, the CPU can be woken up. After an embedded system runs, when the system enters the idle state, the CPU can be put into a low-power mode, and when an external interrupt occurs, the CPU is again awakened and returns to the operating mode. Allowing the CPU to be in a low-power mode as much as possible can greatly reduce the power consumption of the system. However, even if the system is idle and there is nothing else to do, the system's real-time clock interrupt will also continuously wake up the CPU, increasing system power consumption. Therefore, you can consider modifying the system real-time clock interrupt to reduce the impact on the system power consumption.

2. Analysis of the relationship between system real-time clock and power consumption

In current embedded systems, the system real-time clock is generally a hardware loop counter. When the hardware counter counts to a certain value, it will send an interrupt to the CPU. The system real-time clock is an important part of the modern multi-tasking embedded operating system, so we need to discuss the relationship between the embedded operating system and the system real-time clock. Today's embedded operating systems generally support multitasking, priority, and time slice scheduling. When the embedded OS is running, it generally has an IDLE task, which has the lowest priority, and other tasks should have higher priority than it. In the priority scheduling mechanism, only when other high-priority tasks in the system are blocked, it will have a chance to run. The time slice scheduling mechanism is only valid for tasks with the same priority. In other words, tasks with different priorities are not rotated by time slice scheduling, but are scheduled by priority. Therefore, when the system enters the IDLE task, it can be considered that there is no work to be done by the CPU in the system, and the system is in the idle state. When the time slice scheduling mechanism is started, the embedded OS will schedule tasks according to the time slice. That is, when a time slice is used up, the scheduler is run to determine the ownership of the next time slice. The basic unit of the time slice is the system tick, and the system tick is based on the system real-time clock. When the system real-time clock interrupt is generated, the CPU will increase the system tick. Whenever the system tick increases n (a time slice), the embedded OS will enable the scheduler for time slice scheduling. Therefore, when the time slice scheduling mechanism is turned on, real-time system tick updates and scheduler timing operations are required, and real-time clock interrupts need to be generated at a very high frequency. If you turn off the time-schedule scheduling mechanism, tasks only need to be scheduled according to their priorities. This eliminates the need for computing time slices. That is, system ticks do not need to be updated in real time. Real-time clock interrupts do not have to be generated at very high frequencies. Do not run regularly. This makes it possible to consider extending the interrupt interval of the real-time clock. At the same time, the scheduler does not need time slice scheduling, which can save system overhead. However, after the schedule is closed, the system only has priority scheduling. This requires that all tasks of the system should be actively blocked, rather than expecting the scheduler to schedule other tasks of the same priority to be out of the CPU and run itself.

In the current popular embedded operating systems, there are generally many active blocking mechanisms, so it is not difficult to do this. Extending the interrupt interval of the real-time clock allows the CPU to remain in a low-power state for a long period of time until a device interrupt wakes up the CPU. This will greatly reduce the power consumption of the system when it is idle. After extending the real-time clock interrupt interval, there are two issues to consider: system tick and system delay. The system tick is the interface between the real-time clock and the operating system. The operating system and time-related modules and APIs are basically based on ticks. In a typical system, the real-time clock is interrupted once per tick. Therefore, tick is the smallest timing unit of the operating system. After extending the real-time clock interruption interval, the system tick will not increase for a long time. Therefore, how to ensure the accuracy of the system tick is the most basic problem. By solving the tick's accuracy, you can isolate the impact of the real-time clock on the operating system. The system delay is an important blocking mechanism of the operating system. It is mainly used to allow a task to actively let out the CPU for a period of time. The general system delay is based on the system real-time clock. The basic unit of the system delay is tick. When the delay is called, the API function will first obtain the current system tick, then add the time needed to delay, form a future delay time point, and then hang the task to the system's delay queue. Therefore, all tasks on the delay queue correspond to one of their own delay time points. When the system tick exceeds the delay time of a task, the task should wake up. This requires a real-time clock interrupt to wake up the CPU and runs the scheduler so that the delay's task re-enters the ready queue. If the real-time clock interrupt interval is extended, the system tick will not increase for a long time, and it is difficult to guarantee the accuracy of the delay. At the same time when the delay time arrives, the task cannot be awakened. To ensure the accuracy of the system tick, it is required to calculate the current system tick through the value of the real-time clock hardware counter each time the system tick is actively obtained. At the same time, synchronization between active acquisition and real-time clock interruption needs to be guaranteed. For the system delay, the count value of the hardware counter needs to be modified so that it is the delay time of the minimum delay time point on the system delay queue. This can use hardware counters to accurately control delay accuracy, and use interrupts to schedule tasks in a timely manner.

3. In I. Solutions on the MX51:

ECOS is an excellent lightweight embedded operating system. Its kernel is small and compact, supports multi-tasking, priority and time slice scheduling mechanism. Freescale's multimedia chip i. The mx51 is based on the ARM Cortex-A8 core and has high performance while supporting the low-power features provided by ARM. ARM offers a low-power mode, sleep mode. ARM executes the instruction WFI and goes to sleep. In sleep mode, the ARM clock is turned off and the ARM only consumes very low power to maintain its own state, ie, the SRPG (State retaining power gate) is enabled. When an interrupt occurs, ARM wakes up, resumes the clock, and restarts execution. The MX51 provides multiple hardware counters. This article uses GPT as the real-time clock. GPT is a loop counter that can set the count value to a maximum of 0xffffffff. Each clock count value is decremented by 1. When the count value is reduced to 0, the interrupt is triggered and the clock is 32KHz. The count value of GPT can be read by ARM at any time, and reading does not affect the count. When the IDLE task runs, IDLE executes the WFI instruction to put ARM into low-power mode. If a device generates an interrupt, the ARM will be awakened, processing the interrupt and the required task scheduling, and the task running.

Based on the previous analysis, this paper has modified the ECOS time slice scheduling and real-time clock system. For the time slice scheduling mechanism, it is turned off in the ECOS configuration file. For real-time clocks, its interrupt interval is extended. The system tick will be updated in two cases. One is when the ECOS API is called to read the system tick, and the other is the GPT interrupt generation. When ECOS starts up, the GPT count value is set to the maximum, so that GPT takes a long time to generate an interrupt. During this period, the system tick will only be updated when the ECOS API actively reads. The tick of the system is calculated by reading the count value of the hardware counter. Add a variable pre_hardware_count to the real-time clock class of the ECOS system to record the value of the last read hardware counter. When each system API reads a tick, the difference between the current hardware counter value and the value of the hardware counter that was last read is the number of ticks that have passed between reads. When the real-time clock generates an interrupt, that is, the hardware counter goes to 0, this variable is cleared. In this way, it is guaranteed that an accurate system tick value can be obtained each time the system tick is read. When there is a task to be proactively delayed for a period of time, the system delay API is called. The ECOS API function calculates the delay time of the task and then hooks the task into the system delay queue. Then it traverses the system delay queue, finds the minimum delay time point in the queue, writes the delay time corresponding to the delay time point into the GPT, and allows the GPT to control the delay time. After the delay time expires, GPT will generate an interrupt. ECOS divides the interrupt handler into two parts, ISR and DSR. The hardware counter is set to its maximum value in the ISR. Then add the system tick in the DSR, re-hung the overtime task into the ready queue, and find the minimum delay time point on the system delay queue again, and write the hardware counter. If the system delay queue is empty, the hardware counter is not operated again, and the maximum value written in the ISR is maintained. Finally, ECOS will run the scheduler. If the timed out task has the highest priority, then it will run, that is, wake up. This will ensure the accuracy and timeliness of the system's delay.

4. Similar methods for other systems

The current popular embedded operating systems Linux and WinCE are also discussing to modify the system real-time clock interrupt mode in order to reduce system power consumption. For Linux systems, there is a Less Watts project that implements tickless idle, ie idle without a tick, in fact, it is to modify the interrupt mode of the real-time clock. WinCE provides a variable system clock tick, the Variable Tick Scheduler, which changes the system clock tick before entering the idle state so that the idle state is not awakened by unnecessary system clock interrupts during the expected time period.

5. in conclusion

It can be seen that by modifying the real-time clock interrupt mode, the CPU can be in a low-power mode for a long time in the idle state, which greatly reduces the system power consumption. And currently popular embedded operating systems are actively exploring this method. I believe that this function will become a necessary function of the embedded operating system in the future.