[En-Nut-Discussion] Common way for exact timing

[Harald Kipp]

Daniel wrote:

> I have 3 Threads where each of them has to be executed every 50 ms. A
> deviation of 3-4 ms is enough here. I had to many situations in the last
> month, where NutSleep(x) did not work as expected (maybe because of my
> code).

NutSleep guarantees a minimal sleep time only. In typical applications
(avoiding CPU intensive loops) the deviation is probably below 1ms.

However, polling device drivers may provide problems. Try to stick with
interrupt driven drivers.


> So, is there a common way of exact timing for those realtime-threads? 

Hard realtime requirements can be fulfilled by timer interrupts only.
Unless you use NutEnterCritical (or avr-lib's cli), this will provide
minimum jitter (less than 200 us on AVR systems). Nut/OS minimizes
critical sections to minimize interrupt latencies and provide hard
realtime behavior on interrupts.

In any case, interrupt latencies caused by the kernel are deterministic.
 That means, that the is a maximum latency, which will never be
exceeded. No matter how many timers, events or threads are active. But
note, that in worst case situations all critical section will sum up.
This is the maximum latency. In reality it is possible, but quite
difficult to determine this time.

As a side note: There are several discussions about whether an RTOS with
cooperative scheduler will be an RTOS. If one refers to task switching,
it won't without strict programmer's discipline. If one refers to
response time in general, it definitely will. Interrupts are the key to
strict timing.

Harald