[Tinyos Core WG] Small gotcha in UartStream interface

[Jonathan Hui]

No race condition here. If a new byte arrives, it's handled when the
interrupt handler executes again (of course, it does assume the
handler is atomic). One idea is that it "suspends" the byte-by-byte
receive, where all it's doing is putting each byte in the receive
buffer rather than passing it up. Implicitly calling
disableReceiveInterrupt() doesn't really do anything. The hardware
still needs to be configured to have receive interrupts enabled,
otherwise UartStream.receive() would not work. We could disable it
logically, meaning that once receiveDone() returns, you have to
explicitly enable interrupts.

-- 
Jonathan W. Hui
jwhui at cs.berkeley.edu
http://www.cs.berkeley.edu/~jwhui/

On 10/20/06, Philip Levis <pal at cs.stanford.edu> wrote:
> On Oct 20, 2006, at 1:36 PM, Phil Buonadonna wrote:
>
> > One of the objective of using UartStream was to enable DMA based data
> > transfers.
> >
> > However the 'receivedByte()' event conflicts with the ability to
> > use DMA
> > based receives.  Specifically, there's no way to grab each
> > individual byte
> > if a DMA is in progress.
> >
> > I think the fix is just to change the 'semantics' of this
> > functionality so
> > that it CAN'T be used in conjuction with the receive() call.
> >
> > Thoughts?
>
> Hm. This interface is weird. I sense a race condition. What if you're
> in a receive() call and a new byte arrives? E.g., is the assumption
> that receive() implicitly calls disableReceiveInterrupt()? I think
> that would work. This means that there should be an accessor, though,
> to tell if there are interrupts enabled.
>
> Phil
> _______________________________________________
> Tinyos-2.0wg mailing list
> Tinyos-2.0wg at Mail.Millennium.Berkeley.EDU
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-2.0wg
>