About the CPU usage of STM32 ~ bare metal without system

1. If you don't run the operating system, the CPU will definitely be 100% used all the time. Even if you are waiting for a delay, the CPU will always execute the empty statement nop, because there is a CPU in the STM32.

2. For stm32, it is always 100%. It just depends on how much free time you have and how much time you spend working!

3.

What the OP means is the proportion of the actual CPU time used to do work in the entire time. For example, if it works for 50mS and then waits for 200mS to complete a large cycle, then the CPU utilization rate is 20%.

If the OP's program is done in a large loop, then pull an IO port low before entering the waiting state, wait until the end, start working, and pull the IO port high, then the duty cycle is the utilization rate. Of course, this is useful when various interrupts are not very frequent and there are few things to be processed in the interrupts. I often estimate the MCU's rate redundancy in this way, and then set a suitable MCU operating frequency accordingly, to reduce not only the CPU's power consumption, but if it is a linear step-down, the overall power consumption will drop a lot, the heat will be lower, and the operating frequency will drop, and the CPU stability will also be enhanced.

4. First of all, we know that Cortex has several low-power working states of the core, Sleep, Stop, Standby

Here I use the Sleep state, that is, when designing a program, when the program's tasks are completed, the microcontroller enters the Sleep state of WFE or WFI:

When using the operating system, simply add __WFI(); or __WFE(); to the idle task

When programming bare metal, the program structure is designed in the form of a large main loop that is triggered by an interrupt or event, that is, the main loop waits for tasks in the queue, and when the queue is empty, it executes __WFI(); or __WFE();. The operation of adding a queue is performed in the serial port, key, timer interrupt, etc.

Then, we use the low-power state of the peripherals, that is, the STM32 peripherals can manually or automatically stop the clock of the peripherals after the core enters the low-power state, and manually or automatically restore the peripherals when exiting the low-power state.

Since my method is implemented on F4, it will appear a bit bloated when implemented using F1. Just understand what I mean. It will be much more convenient when using F4.

This is the peripheral low-power feature of F1. It can be seen that when the core enters the low-power state, the peripheral clock can only be turned on and off manually.

This is the peripheral low power consumption feature of F4. It can be seen that when the core enters the low power consumption state, the peripheral clock can be automatically turned off.

When using F4, we can use two timers such as TIM6 and TIM7

The configuration is as follows

void tim6_init(void)

{

        TIM_TimeBaseInitTypeDef TIM_InitStructure;

        RCC_APB1PeriphClockCmd (RCC_APB1Periph_TIM6, ENABLE );

        RCC_APB1PeriphClockLPModeCmd(RCC_APB1Periph_TIM6, DISABLE);

        TIM_DeInit(TIM6);

        TIM_InitStructure.TIM_Prescaler = 180;

        TIM_InitStructure.TIM_CounterMode = TIM_CounterMode_Up;

        TIM_InitStructure.TIM_Period = 65535;

        TIM_InitStructure.TIM_ClockDivision = TIM_CKD_DIV1;

        TIM_InitStructure.TIM_RepetitionCounter = 0;

        TIM_TimeBaseInit(TIM6, &TIM_InitStructure);

        TIM_SetCounter(TIM6, 0);

        TIM_ITConfig(TIM6, TIM_IT_Update, DISABLE);

        TIM_Cmd(TIM6, ENABLE);

}

void tim7_init(void)

{

        TIM_TimeBaseInitTypeDef TIM_InitStructure;

        NVIC_InitTypeDef NVIC_InitStructure;

        RCC_APB2PeriphClockCmd (RCC_APB2Periph_SYSCFG, ENABLE);

        RCC_APB1PeriphClockCmd (RCC_APB1Periph_TIM7, ENABLE);

        RCC_APB1PeriphClockLPModeCmd(RCC_APB1Periph_TIM7, ENABLE);

        TIM_DeInit(TIM7);

        TIM_InitStructure.TIM_Prescaler = 180;

        TIM_InitStructure.TIM_CounterMode = TIM_CounterMode_Up;

        TIM_InitStructure.TIM_Period = 65535;

        TIM_InitStructure.TIM_ClockDivision = TIM_CKD_DIV1;

        TIM_InitStructure.TIM_RepetitionCounter = 0;

        TIM_TimeBaseInit(TIM7, &TIM_InitStructure);

        TIM_SetCounter(TIM7, 0);

        TIM_ITConfig(TIM7, TIM_IT_Update, ENABLE);

        NVIC_InitStructure.NVIC_IRQChannel = TIM7_IRQn;

        NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 0x03;

        NVIC_InitStructure.NVIC_IRQChannelSubPriority = 0x03;

        NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;

        NVIC_Init(&NVIC_InitStructure);

        TIM_Cmd(TIM7, ENABLE);

}

The TIM7 interrupt code is as follows:

void TIM7_IRQHandler(void)

{

        TIM7->SR = ~TIM_IT_Update;

        CPU_TICK_USAGE = TIM6->CNT;

        TIM6->CNT = 0;

}

Calculate the CPU usage (%) as follows:

CPULoad = (float)CPU_TICK_USAGE*100.0f/65535.0f

When using F1, you need to manually add code at the entrance of each interrupt to enable the TIM6 clock

And manually add code before each __WFE(); or __WFI(); to turn off the TIM6 clock

Manually add code after each __WFE(); or __WFI(); to enable the TIM6 clock

Of course, when using F1, it is the same if you only use a while loop without using __WFE(); or __WFI();.

5.

Watching, I personally think that since it is a bare metal machine, there is no need to consider the CPU usage rate

6.

dwiller_ARM posted on 2014-2-20 13:58

Watching, I personally think that since it is a bare metal machine, there is no need to consider the CPU usage rate

It can still be used in general applications, such as the inverter project I am working on now. I can consider the complexity of the algorithm by checking the CPU usage, and determine the highest sampling frequency and PWM period based on the CPU usage, and at the same time determine whether the CPU main frequency is appropriate. In my opinion, the most appropriate CPU usage is 75~85%.