[En-Nut-Discussion] Timing issues on Ethernut 1.3 (AVR)

[Harald Kipp]

Daniel wrote:

> Issue 2, NutGetTickCount()
> ======================

> The only hint i have is that I'm using the _delay_us(x) function, which is
> not from Ethernut. Maybe there`s the problem?

Could be. In my previous example I used DEV_DEBUG, a polling driver,
which will never release the CPU. Thus, each thread is blocked until the
running thread calls NutThreadYield(). The same is true for _delay_us(x).

As long as you are working with resolutions of milliseconds, you should
use Nut/OS events and timers, because they will release the CPU.

If you need higher resolutions, you may use a native timer interrupts
for polling, if possible. If the interrupt routine detects a change, it
calls NutEventPostFromIrq() to wake up a thread. In your example the
status change will be detected by the timer interrupt routine and the
thread will wait for a change in NutEventWait(). The optimal solution
is, of course, if the status change can be detected by a dedicated
interrupt, avoiding timer interrupt polling.

Keep in mind: As long as nothing happens, good application will run the
idle thread. Polling is bad for cooperative systems like Nut/OS.

Harald