Neither route is the shortest possible.

The black route is way longer. I can’t see any mouse wanting to take that.

]]>first of all thanks for the great idea.

I used your code to measure the execution time of fast functions, by taking the ticks from epoch (micros weren’t fast enough…) at the beginning and ending of a function and subtract the first from the later.

in the progress I found a bug in the code:

at times I got a negative value of ticks per function.

after a research I found that the problem is that it takes time for the interrupt to increase the value of Mills after SysTick->VAL overflowed.

according to my measurements Millis wasn’t updated for 1-6 microseconds (between 257 and 1206 ticks, I’m working with 216MHz…)

I solved my problem by just adding 1 miili to the tick value if it’s negative.

I couldn’t find a way to discover a wrong tick value in the ticksFromEpoch() function though.

here is my code, hope it’ll help someone:

uint64_t STM32TimeProvider::ticksFromEpoch()

{

uint64_t millis = (HAL_GetTick() + 1);

return millis * SystemCoreClock / 1000 – SysTick->VAL;

}

STM32StopWatch::STM32StopWatch(uint64_t& total, uint64_t& times)

: m_total(total), m_times(times)

{

m_start = m_clock.ticksFromEpoch();

++m_times;

}

STM32StopWatch::~STM32StopWatch()

{

int64_t diff = (m_clock.ticksFromEpoch() – m_start);

m_total += diff + ((diff < 0) * SystemCoreClock / 1000);

}

Thanks again.

]]>