A CPU dynamic frequency adjustment method based on multi-level load detection

Abstract

This invention discloses a CPU dynamic frequency adjustment method based on multi-level load detection, comprising the following steps: S1, creating three load detection tasks and setting their priorities among different priority levels of real-time operating system tasks; S2, setting different decision cycles for the business characteristics of tasks with different priorities; S3, obtaining the idle level of the corresponding priority task group by detecting whether the three load detection tasks can be scheduled for execution; S4, adjusting the CPU frequency according to the idle level of different priority task groups. By setting load detection tasks among different priority levels of tasks, fine-grained monitoring is achieved, ensuring timely frequency increase for high-priority tasks when resources are insufficient to guarantee real-time performance. The differentiated decision cycle enables millisecond-level rapid response to sudden business events, and the precise perception of load conditions at each level achieves optimal frequency reduction to maximize energy saving, thus achieving a balance between real-time performance assurance and energy efficiency optimization.

Description

Technical Field

[0001] This invention relates to the field of embedded system power management technology, and specifically to a CPU dynamic frequency adjustment method based on multi-level load detection. Background Technology

[0002] Dynamic Voltage and Frequency Scaling (DVFS) technology achieves a balance between performance and power consumption in embedded real-time systems by adjusting the operating frequency and voltage in real time according to the CPU load. For example, Chinese invention patent CN109117262B proposes a method for dynamic frequency adjustment of a baseband processing chip CPU. This method determines the CPU frequency by comprehensively considering three factors: current CPU utilization, future traffic forecast, and critical timing requirements. To a certain extent, this improves the response lag problem caused by traditional frequency adjustment based solely on historical CPU utilization.

[0003] However, the aforementioned existing technologies still have the following unresolved technical problems: First, they cannot distinguish task priorities, making it difficult to guarantee the real-time performance of critical tasks. Frequency adjustment based on overall CPU utilization and traffic statistics cannot reflect the allocation of CPU resources among tasks of different priorities. In a real-time operating system (RTOS), high-priority tasks may be blocked due to insufficient resources, but the operation of medium and low-priority tasks may make the overall utilization rate appear low, leading to misjudgment of the frequency adjustment strategy and rejection of frequency increase, thus compromising system real-time performance. Second, frequency adjustment response still has a delay, making it unable to quickly adapt to sudden traffic loads. Although existing technologies introduce traffic prediction mechanisms, the prediction relies on historical sliding window statistics, requiring the accumulation of data over a certain time window to make a judgment. For sudden traffic requests in applications such as walkie-talkies (such as suddenly pressing the PTT talk button), the prediction mechanism's response is delayed, which may still lead to slow processing in the initial stage of the service. Third, they cannot accurately perceive the load of non-real-time tasks, resulting in insufficient energy-saving optimization. Existing technologies make frequency reduction decisions based on an overall utilization rate below a threshold. Because they cannot distinguish the actual execution status of low-priority tasks, to avoid affecting system functionality, the frequency reduction strategy tends to be conservative, usually not reducing the frequency to the optimal low point, wasting energy-saving space. There is an urgent need in this field for a dynamic frequency adjustment scheme that can perceive CPU load distribution in a fine-grained manner, respond quickly to ensure the real-time performance of tasks with different priorities, and maximize energy saving. Summary of the Invention

[0004] This invention proposes a CPU dynamic frequency adjustment method based on multi-level load detection. By setting load detection tasks at different priority levels, it achieves fine-grained monitoring, ensuring that high-priority tasks can increase their frequency in time when resources are insufficient to guarantee real-time performance. It achieves millisecond-level rapid response to sudden business events through differentiated decision cycles, and achieves optimal frequency reduction by accurately sensing the load status at each level to maximize energy saving, thus achieving a balance between real-time performance and energy efficiency optimization.

[0005] To achieve the above objectives, the present invention adopts the following technical solution: a CPU dynamic frequency adjustment method based on multi-level load detection, comprising the following steps: S1, create three load detection tasks and set their priorities among different priority levels of the real-time operating system task; S2 sets different decision cycles based on the business characteristics of tasks with different priorities; S3, by detecting whether the three load detection tasks can be scheduled for execution, the idle level of the corresponding priority task group is obtained; S4 adjusts the CPU frequency based on the idle level of different priority task groups.

[0006] Preferably, step S1 includes: classifying real-time operating system tasks into high real-time tasks, medium real-time tasks, and low real-time tasks according to priority; creating a first load detection task and setting its priority between high real-time tasks and medium real-time tasks; creating a second load detection task and setting its priority between medium real-time tasks and low real-time tasks; and creating a third load detection task and setting its priority below all low real-time tasks.

[0007] Preferably, step S2 includes: setting the decision cycle of high real-time tasks to a first set time; setting the decision cycle of medium real-time tasks to a second set time, the second set time being longer than the first set time; setting the decision cycle of low real-time tasks to a third set time, the third set time being longer than the second set time; and setting different decision cycles according to the business characteristics of different priority tasks: high real-time tasks adopt the shortest cycle for fast response, medium real-time tasks adopt medium cycle for smooth processing, and low real-time tasks adopt long cycle for optimized frequency reduction.

[0008] Preferably, the first set time is 1ms, the second set time is 10ms, and the third set time is 100ms.

[0009] Preferably, step S3 includes: configuring a hardware timer to generate periodic interrupts, triggering three load detection tasks in the interrupt service routine; after the first load detection task is triggered, its counter is increased to reflect the idle level of high real-time tasks; after the second load detection task is triggered, its counter is increased to reflect the overall idle level of medium real-time tasks; after the third load detection task is triggered, its counter is increased to reflect the idle level of the entire system.

[0010] Preferably, step S3 includes: calculating the counter increment for each load detection task within the current decision cycle.

[0011] Preferably, the counter increment is obtained by subtracting the historical counter value from the current counter value, and the current counter value is saved as a historical counter value for the next calculation.

[0012] Preferably, step S4 includes: in a first set time period, if the idle level of high real-time tasks is lower than a first threshold, then the CPU clock frequency is increased; in a second set time period, if the overall idle level of medium real-time tasks is lower than a second threshold, then the CPU clock frequency is increased; in a third set time period, if the ratio of the idle level of low real-time tasks to medium real-time tasks is lower than a third threshold, then the CPU clock frequency is increased; if the ratio is higher than or equal to the third threshold, then the CPU clock frequency is decreased. The ratio of the detection counts of low-priority tasks to medium-priority tasks is introduced as an accurate basis for judging the sufficiency of system resources, thereby realizing a more aggressive frequency reduction strategy.

[0013] Preferably, the ratio of the idle time of the low real-time task to that of the medium real-time task is the ratio of the counter increment of the third load detection task to that of the second load detection task within a third set time period.

[0014] Preferably, the CPU clock speed is increased by an immediate increase or by a small, rapid adjustment, while the CPU clock speed is decreased by a gradual reduction.

[0015] The beneficial effects of this invention are: stronger real-time performance assurance, ensuring the processing capability of the highest priority events by independently monitoring high real-time task loads and responding quickly with a 1ms cycle, avoiding real-time failures caused by untimely frequency adjustment; faster response speed, the multi-timescale decision-making mechanism does not rely on historical statistics or predictions, and can immediately perceive and adapt to sudden business loads; better energy saving effect, by making frequency reduction decisions over a long period through low real-time task monitoring indicators, actively maximizing the reduction of CPU frequency while ensuring the real-time performance of high and medium-level tasks, significantly reducing power consumption; better system adaptability, the multi-timescale mechanism matches different business frequencies, which can not only cope with sudden loads, but also maintain operational stability and avoid drastic frequency oscillations; and controllable overhead, implemented based on the original RTOS scheduling framework and hardware timers, without modifying the kernel, with low resource overhead, strong portability, and suitable for resource-constrained embedded MCU platforms. Attached Figure Description

[0016] Figure 1 This is a flowchart of a CPU dynamic frequency adjustment method based on multi-level load detection according to the present invention.

[0017] Figure 2 This is a flowchart of step S4 in Embodiment 1 of the present invention. Detailed Implementation

[0018] This embodiment provides a CPU dynamic frequency adjustment method based on multi-level load detection, suitable for battery-powered embedded real-time systems, such as walkie-talkies, smart wearable devices, and IoT terminals. Figure 1 As shown, the method in this embodiment includes the following steps.

[0019] Step S1: Create three load detection tasks and set their priorities among different priority levels of the real-time operating system task.

[0020] This step aims to establish a multi-level load detection mechanism that matches the task priority hierarchy of the RTOS. Specifically, in an RTOS that supports multiple task priorities, in addition to the user's high, medium, and low priority tasks, three load detection tasks are created: Task_Detect1, Task_Detect2, and Task_Detect3. By inserting their priorities between the existing task priorities, independent awareness of the load status of task groups with different priorities can be achieved.

[0021] Step S1 specifically includes the following sub-steps.

[0022] Real-time operating system tasks are categorized by priority into high real-time tasks, medium real-time tasks, and low real-time tasks. High real-time tasks include interrupt handling and emergency event response; medium real-time tasks include routine business processing; and low real-time tasks include background maintenance and log recording.

[0023] Create a first load detection task, Task_Detect1, and set its priority between high-real-time and medium-real-time tasks. The fact that this task can be executed indicates that all high-real-time tasks have completed in the past cycle, and the CPU has time to run lower-priority tasks.

[0024] Create a second load detection task, Task_Detect2, and set its priority between that of medium and low real-time tasks. The fact that this task can be executed indicates that medium and high real-time tasks have been completed.

[0025] Create a third load detection task, Task_Detect3, and set its priority to be lower than all low real-time tasks. The fact that this task can be executed indicates that all tasks (including low real-time tasks) have had a chance to be executed.

[0026] The above three-level priority insertion mechanism enables independent monitoring of the load of task groups with different priorities.

[0027] Step S2: Set different decision cycles based on the business characteristics of tasks with different priorities.

[0028] This step establishes a multi-timescale frequency adjustment decision-making mechanism. High real-time tasks are characterized by strong suddenness and high response requirements, so the shortest decision cycle is set to achieve rapid response; medium real-time tasks are set with a medium decision cycle for smooth processing; low real-time tasks have lower real-time requirements, so the longest decision cycle is set to fully explore energy-saving potential.

[0029] Step S2 specifically includes the following sub-steps.

[0030] The decision-making cycle for high real-time tasks is set to a first preset time. Because high real-time tasks are characterized by their suddenness and high response requirements, the shortest possible cycle is needed for rapid response; in this embodiment, the first preset time is 1ms.

[0031] The decision cycle for medium real-time tasks is set to a second preset time, which is longer than the first preset time. Medium real-time tasks require a certain amount of smoothing processing time; in this embodiment, the second preset time is 10ms.

[0032] The decision cycle for low real-time tasks is set to a third preset time, which is longer than the second preset time. Low real-time tasks have lower real-time requirements, so a longer cycle is used to fully assess the overall idle level of the system. In this embodiment, the third preset time is 100ms.

[0033] The aforementioned multi-timescale design enables fast-paced services to respond quickly and slow-paced services to be processed smoothly, avoiding drastic frequency oscillations.

[0034] Step S3: By detecting whether the three load detection tasks can be scheduled for execution, the idle level of the corresponding priority task group is obtained.

[0035] This step utilizes the RTOS scheduling mechanism to achieve fine-grained load awareness. Whether the three load detection tasks can be successfully scheduled and executed directly reflects the completion status of the corresponding priority task groups: the execution of the first load detection task indicates that high real-time tasks have been completed; the execution of the second load detection task indicates that medium and higher real-time tasks have been completed; and the execution of the third load detection task indicates that all tasks have had an execution opportunity. By periodically triggering and recording the execution count of each task, the idle level of the corresponding priority task group can be quantified.

[0036] Step S3 specifically includes the following sub-steps.

[0037] Configure a hardware timer to generate an interrupt with a period of 1ms.

[0038] In the hardware timer interrupt service routine, three load detection tasks Task_Detect1, Task_Detect2, and Task_Detect3, as well as the dynamic frequency modulation task Task_DVFS, are synchronously woken up by sending semaphores or messages.

[0039] Upon being woken up, each load monitoring task immediately increments its corresponding global cumulative counter by one. Specifically: After the first load detection task, Task_Detect1, is triggered, its counter, g_TotalCount1, is incremented. This counter value reflects the idle level of the high real-time task group. The higher the counter value, the more idle the high real-time tasks are.

[0040] After the second load detection task Task_Detect2 is triggered, its counter g_TotalCount2 is incremented by one. This counter value reflects the overall idle level of the medium and high priority task groups.

[0041] After the third load detection task Task_Detect3 is triggered, its counter g_TotalCount3 is incremented by one. This counter value reflects the idle level of the entire system.

[0042] In the dynamic frequency adjustment task Task_DVFS, the counter increment for each load detection task within the current decision period is calculated. The specific calculation method is as follows: subtract the locally stored historical counter value from the currently read counter value to obtain the increment within this period; at the same time, the current counter value is saved as a historical counter value for use in the next calculation.

[0043] For example, for the first load detection task, ΔCount1 = CurrentCount1 - PrevCount1 is calculated every 1 ms, and then PrevCount1 is updated to CurrentCount1. Similarly, the increment of the second load detection task is calculated every 10 ms, and the increments of the second and third load detection tasks are calculated every 100 ms.

[0044] Step S4: Adjust the CPU frequency according to the idle level of different priority task groups.

[0045] This step performs frequency adjustment decisions across multiple time scales. Different frequency adjustment strategies are adopted based on the idle levels of each priority task group within different decision cycles: high-priority tasks with low idle levels are immediately frequency-increased to ensure real-time performance; medium-priority tasks experience frequency increases as load accumulates; and low-priority tasks are aggressively frequency-reduced to optimize energy efficiency when resources are relatively abundant.

[0046] By cyclically executing the above four steps, the system can maximize the reduction of CPU frequency while ensuring the real-time performance of high and medium-level tasks, thus achieving the optimal balance between real-time performance and energy efficiency.

[0047] like Figure 2 As shown, step S4 specifically includes the following sub-steps.

[0048] During the first set time period (1ms), check the counter increment of the first load detection task. If the increment is less than the first threshold value Threshold1, it indicates that the high real-time task has been very busy in the past 1ms and CPU resources are scarce. Immediately increase the CPU frequency by one or more levels to ensure the real-time performance of the critical task.

[0049] During the second set time period (10ms), check the counter increment of the second load detection task. If the increment is less than the second threshold Threshold2, it indicates that medium real-time tasks have accumulated a large load in the past 10ms, and the CPU frequency should be increased to handle the accumulated business.

[0050] In the third set time period (100ms), the ratio of the idle level of the low real-time task to that of the medium real-time task is calculated. This ratio is the ratio of the counter increment of the third load detection task to that of the second load detection task within the 100ms period, i.e., R=ΔCount3 / ΔCount2.

[0051] If the ratio R is less than the third threshold Threshold3, it means that the low-priority task has not been fully executed in the past 100ms and needs more resources. In this case, the CPU frequency should be increased.

[0052] If the ratio R is greater than or equal to the third threshold value Threshold3, it indicates that system resources are sufficient and low-priority tasks can be executed smoothly. In this case, the CPU frequency is reduced by one level to save power. This mechanism introduces the ratio of the detection counts of low-priority tasks to medium-priority tasks as an accurate basis for judging the sufficiency of system resources. It can proactively and maximize the search for and operation at a lower frequency while ensuring the integrity of system functions, thus implementing a more aggressive frequency reduction strategy.

[0053] In terms of frequency adjustment methods, increasing the CPU frequency adopts an immediate increase or a small-step fast adjustment method to ensure rapid response to sudden loads; decreasing the CPU frequency adopts a gradual decrease method to avoid performance fluctuations caused by overly aggressive frequency reduction.

[0054] This embodiment provides an embedded real-time system that applies the above method, which can be a walkie-talkie, a smart wearable device, or an Internet of Things terminal, etc.

[0055] The hardware foundation of this invention's system includes a CPU core and a high-precision hardware timer. The software foundation includes an RTOS that supports multi-task prioritization.

[0056] In the RTOS, in addition to the user's high, medium, and low priority tasks, three load monitoring tasks and one dynamic frequency adjustment decision task are also created. The priorities of the three load detection tasks are set between the different task levels. The dynamic frequency adjustment decision task is used to trigger the semaphores or message queues of the three detection tasks and the decision task (released by the 1ms hardware timer interrupt service routine).

[0057] By using the method described in Example 1, the device can achieve rapid response of PTT (Push-to-Talk) button presses, real-time performance guarantee of multi-task parallel processing, and maximum energy saving in idle state under battery power conditions, significantly extending battery life.

[0058] The working principle of the system will be explained in detail below.

[0059] The core idea of ​​this invention is to use hardware timer interrupts to periodically activate detection points located at different task priority levels.

[0060] The detection points record the system status by adding a global cumulative counter.

[0061] The frequency modulation decision task operates on a fixed base frequency (1ms). It calculates the difference between its own historical count values ​​and the current global cumulative count value to obtain statistics within different time windows, and then performs frequency modulation decisions at multiple time scales accordingly.

[0062] Specifically, it can be implemented in several sub-steps.

[0063] The first step is system initialization.

[0064] Configure a hardware timer to generate an interrupt with a period of 1ms.

[0065] Create three load detection tasks (Task_Detect1, Task_Detect2, Task_Detect3) and one dynamic frequency modulation task (Task_DVFS) in the RTOS.

[0066] Set the priority of Task_Detect1 to be between that of high real-time tasks and medium real-time tasks.

[0067] Set the priority of Task_Detect2 to be between that of medium real-time tasks and low real-time tasks.

[0068] Set the priority of Task_Detect3 to be lower than all low real-time tasks.

[0069] Initialize the three global cumulative counters g_TotalCount1, g_TotalCount2, and g_TotalCount3 to zero (usually defined as volatile type variables).

[0070] Inside the Task_DVFS task, four local history counters, l_PrevCount1_1ms, l_PrevCount2_10ms, l_PrevCount2_100ms, and l_PrevCount3_100ms, are initialized to store the previous count value, with an initial value of 0.

[0071] Initialize three threshold values: Threshold1, Threshold2, and Threshold3 (these values ​​can be determined through theoretical calculations or experimental calibration).

[0072] The second step is to trigger it periodically.

[0073] Hardware interrupt: The hardware timer generates an interrupt every 1ms.

[0074] In the interrupt service routine (ISR), the three detection tasks Task_Detect1, Task_Detect2, and Task_Detect3 are woken up / notified by sending a semaphore or a message, and then the interrupt is exited.

[0075] The third step is multi-level load detection.

[0076] Task_Detect1 execution: Once awakened by the semaphore, it immediately increments its counter g_TotalCount1. Successful execution of this task indicates that all high-priority real-time tasks have completed within the past 1ms period, allowing the CPU time to run lower-priority tasks. The value of g_TotalCount1 reflects the idle level of the high-priority task group.

[0077] Task_Detect2 execution: Similarly, this task increments g_TotalCount2 by one. Its execution indicates that medium-to-high priority tasks have been completed. The value of g_TotalCount2 reflects the overall idle time of the medium- and high-priority task groups.

[0078] Task_Detect3 execution: This task increments g_TotalCount3 by one. Its execution indicates that all tasks (including those with low real-time requirements) have had their chance to execute. The value of g_TotalCount3 reflects the overall system idle state.

[0079] The fourth step is multi-scale dynamic frequency modulation decision-making (implemented in Task_DVFS).

[0080] The Task_DVFS task is woken up every 1ms, and it periodically reads the counter and makes decisions according to the following logic: Step A1: Read the current global value.

[0081] Read the current values ​​of the three global cumulative counters and store them into local variables l_CurrentCount1, l_CurrentCount2, and l_CurrentCount3 respectively.

[0082] Step A2: Calculate the difference, calculate the increment of each counter within its respective period, and update the historical value.

[0083] Calculate l_PrevCount1_1ms every 1ms. Since the difference between l_CurrentCount1 and l_PrevCount1_1ms is equal to ΔCount1_1ms, l_CurrentCount1 is l_PrevCount1_1ms.

[0084] l_PrevCount2_10ms is calculated every 10ms. Since the difference between l_CurrentCount2 and l_PrevCount2_10ms is equal to ΔCount2_10ms, l_CurrentCount2 is l_PrevCount2_10ms.

[0085] Every 100ms, l_PrevCount2_100ms and l_PrevCount3_100ms are calculated. Based on the fact that ΔCount2_100ms is equal to the difference between l_CurrentCount2 and l_PrevCount2_100ms, and ΔCount3_100ms is equal to the difference between l_CurrentCount3 and l_PrevCount3_100ms, l_CurrentCount2 is obtained as l_PrevCount2_100ms and l_CurrentCount3 is obtained as l_PrevCount3_100ms.

[0086] Step A3, multi-time scale decision-making, using the differences ΔCount1_1ms, ΔCount2_10ms, ΔCount2_100ms, ΔCount3_100ms obtained from this calculation for judgment.

[0087] Decision-making every 1ms (to ensure high real-time performance): Check ΔCount1_1ms.

[0088] If ΔCount1_1ms < Threshold1, it means that in the past 1ms, high real-time tasks were very busy and CPU resources were strained. Immediately increase the CPU main frequency by one or more levels.

[0089] Decision-making every 10ms (to ensure medium real-time performance): Maintain a 10ms loop counter cycle_10ms. Every 10th execution (i.e., every 10ms), check ΔCount2_10ms.

[0090] If ΔCount2_10ms < Threshold2, it means that in the past 10ms, medium real-time tasks have accumulated more load. Increase the CPU main frequency.

[0091] Decision-making every 100ms (to optimize low real-time performance and reduce frequency): Maintain a 100ms loop counter cycle_100ms. Every 100th execution (i.e., every 100ms), calculate the ratio R of ΔCount3_100ms and ΔCount2_100ms.

[0092] If R < Threshold3, it means that low-priority tasks were not fully executed in the past 100ms and need more resources. Increase the main frequency.

[0093] If R >= Threshold3, it means that system resources are sufficient and low-priority tasks can also be executed smoothly. Reduce the CPU main frequency by one level to save power consumption.

[0094] Step A4, task sleep, waiting for the next 1ms wake-up cycle to arrive.

[0095] The fifth step, loop execution.

[0096] The four steps from the first step to the fourth step above are continuously looped, so that the CPU main frequency can quickly and smoothly adapt to the changes in external business loads, achieving the goal of continuously optimizing energy efficiency while ensuring real-time performance.

[0097] It should be noted that the global cumulative counter g_TotalCountX should be an unsigned 32-bit or 64-bit integer type to ensure that it has a sufficiently large range and will not overflow and wrap around to cause calculation errors during long-term system operation. Even if overflow occurs, because the subtraction operation of unsigned integers in computers follows the modulo operation rule, the calculated difference ΔCountX is still the correct increment value within the two sampling intervals, ensuring the robustness of the algorithm.

[0098] Existing DVFS technology solutions are mostly based on monitoring the overall CPU utilization. The most classic implementation method is the "idle task method". This method indirectly calculates CPU utilization by measuring the running time of the lowest priority task in the RTOS. When the utilization is high, the system will increase the frequency, and when the utilization is low, the frequency will decrease.

[0099] However, this approach has obvious drawbacks. First, the coarse granularity cannot guarantee the real-time performance of critical tasks. This is because the overall utilization rate cannot reflect the allocation of CPU resources among tasks of different priorities. There may be situations where high-priority tasks are blocked or timed out due to insufficient resources, but the large number of low- and medium-priority tasks running makes the overall utilization rate seem low. This will cause the frequency adjustment strategy to misjudge and refuse to increase the frequency, thus seriously damaging the real-time performance of the system.

[0100] Secondly, the response is slow and cannot quickly adapt to sudden business. Because the overall utilization rate changes slowly based on historical statistics, it is difficult to cope with sudden business requests in applications such as walkie-talkies. The delay in frequency modulation response may lead to slow processing in the initial stage of business. Finally, there is insufficient energy efficiency optimization and the frequency reduction strategy is too conservative. Because it is impossible to accurately perceive the load of non-real-time tasks, the frequency is usually not reduced to the optimal low point in order to avoid affecting the system function, thus wasting potential energy-saving space.

[0101] Another approach is the task execution time statistics method, which is a measurement-based precise calculation method. Its core is to accurately record the CPU time occupied by each task and then accumulate the data to directly obtain an accurate CPU utilization value.

[0102] However, this method also has significant drawbacks. Although the measurement results are very accurate, the accounting process itself is cumbersome and costly. In addition, it relies on kernel instrumentation, which requires modifying the RTOS scheduler code to insert hook functions to record time during each task switch. Furthermore, the overhead increases with the number of tasks, and the recording code needs to be executed every time a task switch occurs. The more tasks there are and the more frequent the switches are, the greater the overhead becomes, which has a significant impact on the system. More importantly, executing the recording code on the critical path of task switching increases the task switching time itself, which has a negative impact on real-time performance.

[0103] The present invention can solve the problems existing in the prior art and achieve the following beneficial effects.

[0104] Enhanced real-time performance: By independently monitoring the load of the high real-time task queue (detecting task count 1) and responding in the shortest period (1ms), the system's ability to handle the highest priority events is ensured, completely avoiding real-time failures caused by untimely frequency adjustment.

[0105] Superior energy efficiency: A unique monitoring metric for low real-time tasks (the ratio of task count 3 to count 2) is introduced, and frequency reduction decisions are made over a long period (100ms) based on this. This mechanism can proactively and maximally seek and operate at a lower clock frequency while ensuring the integrity of system functions, significantly reducing dynamic and static power consumption and extending battery life.

[0106] The system exhibits enhanced adaptability: its multi-timescale (1ms, 10ms, 100ms) decision-making mechanism is matched to the frequency of different business operations. Fast-paced business operations respond quickly, while slow-paced business operations are handled smoothly, enabling the system to cope with sudden loads while maintaining overall operational stability and avoiding drastic frequency oscillations.

[0107] Controllable overhead: The entire solution is based on the original task scheduling framework and hardware timer interrupt of the RTOS. It does not require modification of the kernel or use of expensive hardware performance counters. It has low resource overhead, strong portability, and is very suitable for resource-constrained embedded microcontroller (MCU) platforms.

Claims

1. A CPU dynamic frequency adjustment method based on multi-level load detection, characterized in that, Includes the following steps: S1, create three load detection tasks and set their priorities among different priority levels of the real-time operating system task; S2 sets different decision cycles based on the business characteristics of tasks with different priorities; S3, by detecting whether the three load detection tasks can be scheduled for execution, the idle level of the corresponding priority task group is obtained; S4 adjusts the CPU frequency based on the idle level of different priority task groups.

2. The CPU dynamic frequency adjustment method based on multi-level load detection according to claim 1, characterized in that, Step S1 includes: classifying real-time operating system tasks into high real-time tasks, medium real-time tasks, and low real-time tasks according to priority; creating a first load detection task and setting its priority between high real-time tasks and medium real-time tasks; creating a second load detection task and setting its priority between medium real-time tasks and low real-time tasks; and creating a third load detection task and setting its priority below all low real-time tasks.

3. The CPU dynamic frequency adjustment method based on multi-level load detection according to claim 2, characterized in that, Step S2 includes: setting the decision cycle of high real-time tasks to a first set time; setting the decision cycle of medium real-time tasks to a second set time, wherein the second set time is longer than the first set time; and setting the decision cycle of low real-time tasks to a third set time, wherein the third set time is longer than the second set time.

4. The CPU dynamic frequency adjustment method based on multi-level load detection according to claim 3, characterized in that, The first set time is 1ms, the second set time is 10ms, and the third set time is 100ms.

5. A CPU dynamic frequency adjustment method based on multi-level load detection according to claim 1 or 2, characterized in that, Step S3 includes: configuring a hardware timer to generate periodic interrupts, triggering three load detection tasks in the interrupt service routine; after the first load detection task is triggered, its counter is incremented to reflect the idle level of high real-time tasks; after the second load detection task is triggered, its counter is incremented to reflect the overall idle level of medium real-time tasks; after the third load detection task is triggered, its counter is incremented to reflect the idle level of the entire system.

6. The CPU dynamic frequency adjustment method based on multi-level load detection according to claim 5, characterized in that, Step S3 includes: calculating the counter increment for each load detection task within the current decision cycle.

7. The CPU dynamic frequency adjustment method based on multi-level load detection according to claim 6, characterized in that, Subtract the historical count from the current counter value to obtain the counter increment, and save the current counter value as a historical count value for the next calculation.

8. A CPU dynamic frequency adjustment method based on multi-level load detection according to claim 1 or 2, characterized in that, Step S4 includes: in a first set time period, if the idle level of high real-time tasks is lower than a first threshold, then increase the CPU clock frequency; in a second set time period, if the overall idle level of medium real-time tasks is lower than a second threshold, then increase the CPU clock frequency; in a third set time period, if the ratio of the idle level of low real-time tasks to medium real-time tasks is lower than a third threshold, then increase the CPU clock frequency; if the ratio is higher than or equal to the third threshold, then decrease the CPU clock frequency.

9. A CPU dynamic frequency adjustment method based on multi-level load detection according to claim 8, characterized in that, The ratio of the idle time of the low real-time task to that of the medium real-time task is the ratio of the counter increment of the third load detection task to that of the second load detection task within a third set time period.

10. A CPU dynamic frequency adjustment method based on multi-level load detection according to claim 8, characterized in that, The method for increasing the CPU clock speed is to either increase it immediately or adjust it in small steps, while the method for decreasing the CPU clock speed is to decrease it gradually.

Images