Stm32f4 get system time (microsecond)

[mohamad_armoon]

Posted on August 09, 2016 at 10:24

hi every body

recently for developing a realtime system in my stm32f407 micro controller i need to calculate each bus delay(uart , spi , i2c ,..) . for that reason i need to get system time in microsecond unit.i'm using CubeMX in this project. as you know the HAL_GetTcik() gives us the number of  milliseconds since microcontroller

began running the current program

(based on Systick configuration). so is it possible to get this time in microsecond unit ??(for example if you are familiar with arduino platform there is function , micros() that returns 

the number of microseconds since the Arduino board began running the current program

 )any help would be appreciatedthanks MA.

[Tesla DeLorean]

Posted on August 09, 2016 at 17:01

Ok, so you can't interrupt at 1MHz, so you need to use a hardware counter of some sort.

You could use the 32-bit DWT_CYCCNT register which clocks at the core speed.You could use the 32-bit TIM2 counter, prescaled down to 1MHz so ticks were each 1us, you could use the maximal update interrupt to extend to 64-bit, but you'd have to create methods to read both 32-bit portions in an atomic fashion.

[LMI2]

Posted on August 09, 2016 at 20:24

If your clock is 150-200MHz can't you interrupt every us? there is about 150-200 machine instructions in that time.

A few days ago there was a post about short delays by Clive1, I think. The code used DWT_CYCCNT register Clive1 mentioned above. By the way, this Forum SW is useless (using polite words). I could not login and now I can't send this.

[Tesla DeLorean]

Posted on August 09, 2016 at 20:48

If your clock is 150-200MHz can't you interrupt every us? there is about 150-200 machine instructions in that time.

Perhaps, but you're going to be eating at least 15% of your CPU horse-power before you even start doing anything useful, if your actual task takes 75-100 cycles you're already pegged at 65%. Compared to say using a hardware counter, eating 0%. High rate problems that can be solved trivially with hardware should not be done with software burning cycles.It would be like driving down the road at highway speed in your car with the brakes applied 15%, if it didn't catch fire, the garage that keeps replacing your brake/rotors would look at you as if you were nuts.

[mohamad_armoon]

Posted on August 09, 2016 at 21:45

thanks mich and clive.

i suppose the best and easiest approach to get time in microsecond is using a 32bit timer which prescaled down to 1 mhz as clive mentioned.Thank you very much.