have you got any idea what the minimal CPU-frequency is to use the xtimer_usleep?
Today I tried to configure the xtimer to work with a correct time.
I traced through the code and I think that this jumps throught the functions cost many
CPU-cycles. I guess that it's not possible to get a 1us time if you have a slow MCU.
For example if you have 16MHz clock frequency you have only 16cycles to fire up the
timer. I think all network-drivers use usleeps. Do you agree that this is a problem?
Another thing to consider, which I have been looking at recently, is if you derive xtimer from a low power timer. These are often 32khz. Then these assumptions of 1us resolution may cause problems.
Then these assumptions of 1us resolution may cause problems.
Well, the API works with "natural time" (microseconds) instead of
"system ticks" or "timer ticks". xtimer tries to map those microseconds
to underlying timer hardware.
Of course, if the underlying timer runs with 32768khz, theres no 1us
Even on slow hardware, if a timer is set to run in 1000us, and the
hardware is accurate, a timer callback should trigger after 1000us.
Currently, it might be slightly delayed by xtimer's overhead, but that's
less than 1us on our platforms.
I would like to see an actual application where xtimer's overhead is too