Page History

...

This Wiki page addresses some counter-intuitive properties of using very short time delays. This Wiki page assumes that timing is generated by a system timer "tick" interrupt. In Tickless Mode there is no system timer interrupt. Much of the discussion here would also apply in the Tickless mode, however, the terminology used here assumes system timer interrupts.

...

will not delay for one clock tick! That would be impossible! There is no event exactly one clock tick after usleep() is called; the next timer tick will always occur at some time strictly less than the system timer interval. Rather, usleep() will delay for two clock ticks resulting some actual delay between 10 and 20 microseconds, exclusive. See the following figure:

http://nuttx.org/Images/short-delay.pngImage RemovedImage Added

For the most part, when delays are large – hundreds or thousands of microseconds – this error is not significant. It becomes noticeable only if you are using usleep() for delays very close to the the timer resolution when the error can be relatively significant.

...

The trade-off here is that when you increase the timer interrupt rate, the timer interrupt processing will then take a proportionately larger amount of your CPU bandwidth. The recommended way to get very high timer resolution without increasing the timer interrupt rate (in most use cases) is to use a Tickless Mode OS. For example, in the Tickless configuration, you could have CONFIG_USEC_PER_TICK set to 1 for a 1MHz timer resolution (with no interrupts). If your target periodic processing time is still 1Khz, then this periodic processing could be met with good precision.

...