[Tinyos-devel] Nested interrupts
Michael Newman
mnewman at dragonnorth.com
Mon Aug 13 12:47:32 PDT 2007
A reentrant interrupt is necessary and appropriate when it is important to
capture some real time information at the time the interrupt is triggered. A
good example is capturing the exact time the event occurred. It is fast and
easy to log time to a very fine resolution (from a hardware counter) in a
stack variable and then to allow reentrant interrupts so the time of the
next event can be captured more accurately.
Reentrant interrupts can greatly narrow the possible error in the time
logged with the second interrupt. If reentrant interrupts are not used than
the second event loses the entire duration of the interrupt handler. With
reentrant interrupts only the interval until interrupts are back on is
possible as the error in the logged time.
Be very careful of one thing when using reentrant interrupts. If events are
put on a queue it will appear that the reentrant event occurred first! Be
sure and dequeue them by inspecting the times to understand which occurred
first. Do not dequeue them in the interrupt handler because the later event
could then be dequeued first.
-----Original Message-----
From: tinyos-devel-bounces at Millennium.Berkeley.EDU
[mailto:tinyos-devel-bounces at Millennium.Berkeley.EDU] On Behalf Of David Gay
Sent: Monday, August 13, 2007 11:57 AM
To: John Regehr
Cc: TinyOS-Devel list; Philip Levis
Subject: Re: [Tinyos-devel] Nested interrupts
On 8/12/07, John Regehr <regehr at cs.utah.edu> wrote:
> Small puzzle problem: Is there ever a legitimate (i.e., correct and
> appropriate) use of a reentrant interrupt handler?
That's easy ;-) Temporary overcommitting of the "CPU cycles" resource.
I.e., with nested interrupts you can possibly:
- process two identical interrupts which occur in very close
succession which you couldn't handle w/o allowing reentrancy.
- tolerate more jitter in the execution time of an interrupt handler
(example: every 50th interrupt takes twice as long as usual, such that
the 51st interrupt overlaps with the execution of the 50th - but the
processor "catches" up before the 100th)
In both cases, you do have to be extremely careful in your interrupt handler
;-)
David Gay
_______________________________________________
Tinyos-devel mailing list
Tinyos-devel at Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
More information about the Tinyos-devel
mailing list