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:[EMAIL PROTECTED] Sent: Friday, September 08, 2006 9:24 AM To: Adam Cc: 'jose m'; tinyos-help@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 _______________________________________________ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
