[Tinyos-devel] Nested interrupts
Philip Levis
pal at cs.stanford.edu
Tue Aug 14 10:33:33 PDT 2007
On Aug 14, 2007, at 7:46 AM, Michael Newman wrote:
>
> These are hugely expensive operations (compared to fielding an
> interrupt).
> Your latency guarantee will be ten times the reentrant interrupt or
> more.
>
For high performance architectures, you have register windows or
other optimizing mechanisms; on a microcontroller, you don't. Posting
and executing a task is 80 cycles in TinyOS; with the typical 4 cycle
interrupt overhead and a two-cycle memory write, spilling a half-
dozen registers, adjusting the stack pointer, etc., makes a factor of
ten unlikely. So yeah, of course an interrupt is almost certainly
going to be much lower latency, but not by a factor of 10.
>
> No amount of refactoring can make even close to the same guarantee.
> With
> queuing for later processing you might get the overheads down to a
> small
> number of hundreds of instructions. Note that in addition to the
> refactored
> handling the interrupt exit and unwinding is part of the overhead.
> This is
> probably the largest part of the overhead. At the cost of stack
> space I
> think I can deliver a minimum latency between events that is
> between one
> third and one tenth the best I could do with fast refactored code
> to queue
> the event.
>
1/3 to 1/10 seems reasonable.
> The fastest queuing I can think of is to copy the timestamp and the
> rest of
> the event information into a dedicated ring buffer, check for
> overflow of
> the ring buffer and update the buffer pointers. Then unwind the
> interrupt.
> Note that unwinding the interrupt is probably the big part of this!
> Difference in the minimum latency of this minimal queuing scheme is
> roughly
> TWICE that of the reentrant interrupt.
Why is unwinding the principal part of the overhead? Generally
postamble costs are merely the inverse of preamble operations:
register->memory operations become memory->register, etc.
Phil
More information about the Tinyos-devel
mailing list