Rv: Re: [Tinyos-help] Interrupts and async events question

[Adam]

Thank you for explaining this, does this apply to other platforms
(telosb/micaZ) too?  

I personally think that it is better for TinyOS to unify that: the routine
inside "async command/event" should be same as routine in "atomic" ---
interrupt is disabled. So that user can develop a predictable system. If an
event/command is interrupt-enabled, let's not use "async" keyword. 

Otherwise, probably very few people know such difference -- not good for
this community

-----Original Message-----
From: Philip Levis [mailto:pal at cs.stanford.edu] 
Sent: Friday, September 08, 2006 9:24 AM
To: Adam
Cc: 'jose m'; tinyos-help at Millennium.Berkeley.EDU
Subject: Re: Rv: Re: [Tinyos-help] Interrupts and async events question

On Sep 8, 2006, at 9:16 AM, Adam wrote:

> Thanks for pointing out this. But I have traced UARTReceive.receive 
> up, the original interrupt is defined as this:

I was talking about the 2.x code.

Regardless, look at the 1.x UART code:

tos/platform/mica2/HPLUART0M.nc:

   TOSH_INTERRUPT(SIG_UART0_TRANS) {
     signal UART.putDone();
   }

   TOSH_SIGNAL(SIG_UART0_RECV) {
     if (inp(UCSR0A) & (1 << RXC))
       signal UART.get(inp(UDR0));
   }

Note that the receive interrupt is a SIGNAL, so has interrupts disabled
while it executes. In contrast, the transmit interrupt is an INTERRUPT, so
has interrupts enabled while it executes. The reason being that a reentrant
RX interrupt could cause bytes to be reordered (rate controlled by external
source), but as the TX interrupt handler is generally what triggers the next
interrupt to occur, making it reentrant isn't a big deal.

All of this is completely independent of tasks.

Phil