[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