[Tinyos-devel] Proposed change to the serial stack in TinyOS 2

[Vlado Handziski]

On 12/15/06, Philip Levis <pal at cs.stanford.edu> wrote:
>
> On Dec 14, 2006, at 4:06 PM, Matt Welsh wrote:
>
> > Ben,
> >
> >> 3) One could add a parameter to the HAL-level put() that signifies
> >> that putDone shouldn't come until the UART is idle. This has the
> >> benefit of only incurring the cost of spinning when needed, but is
> >> confusing, as no one aside from the user of put() can check for
> >> idleness.
> >>
> >> Our proposed solution is the following:
> >>
> >> 4) Add a split-phase query interface to the HAL with the command
> >> wait(). This interface would implement a task-level spin (so that it
> >> is interruptable) and would signal waitDone() when the idle flag is
> >> asserted. The downside of this interface is that it still relies on a
> >> spin, which consumes extra energy as the processor will not enter a
> >> sleep state while waiting.
> >
> > I like it. I would suggest not using a new interface for this
> > (unless one is strictly necessary - why not add the command/event
> > to the existing UART interface?). And, perhaps to be consistent
> > with more commonly used terminology you could call it flush() /
> > flushDone(). "wait" is a little ambiguous unless you make it clear
> > what you are waiting for.
> >
> > Overall I think this is the right approach as it means you can do
> > the 'flush' only when needed.
> > It would be good to document under what specific conditions flush
> > should be used.
>
> The tradeoff is whether all users of the interface have to implement
> waitDone/flushDone whether they need it or not, or whether everyone
> who uses it has to wire a new interface. I think it's hard to tell
> which is the dominant case. My guess would be former (put in same
> interface), given that it's necessary for correct operation when
> you're trying to achieve low-power operation. But that's just a
> guess. Developers who are doing UART stuff, what are your thoughts?
>
>
I would like them to be in the same interface with put/putDone. Semantically
they belong together. I also like the flush/flushDone naming much better
then wait. I mentioned to Ben previously that I was thinking along
drain/drainDone but this can be easily confused with the Drain protocol.

Vlado
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20061215/ba0a6a1d/attachment.html