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

[Ben Greenstein]

I put it in a separate interface for two reasons: (1) so that it is
easier for components that aren't sending bytes to use it and (2) so
that components that are sending bytes don't have to implement
waitDone. That said, I don't think it's a big deal either way, so I'm
happy to merge. Also, I don't like the names wait/waitDone, but
flush/flushDone makes it sound like the call to flush initiates the
flushing. But signalWhenFlushed/flushed seems like a bit much.


On 12/14/06, Kevin Klues <klueska at gmail.com> wrote:
> If the intention of the waitDone event is to be implemented as a
> task-level spin, then why does it need to be async?  Is this to
> preclude defining the way in which it actually has to be implemented?
> If we do what Matt suggests it would obviously have to be async though
> if we want to be able to immediately signal it from inside calls to
> wait.
>
> I also support Matt and Vlado's suggestions to move this interface
> inside the same interface as put/putDone because this allows services
> on top of the UART to be implemented independent of the actual UART
> implementation underneath.
>
> Kevin
>
> On 12/14/06, Matt Welsh <mdw at eecs.harvard.edu> wrote:
> > Why can't an implementation where wait/waitDone (or flush/flushDone)
> > are not needed just provide a null implementation (e.g., signal
> > flushDone immediately)? Seems to me you want to be consistent so that
> > layers on top of the UART don't need to care whether the underlying
> > UART provides guaranteed flush.
> >
> > On Dec 14, 2006, at 7:13 PM, Philip Levis 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?
> > >
> > > Phil
> > >
> > >
> > >
> >
> > _______________________________________________
> > Tinyos-devel mailing list
> > Tinyos-devel at Millennium.Berkeley.EDU
> > https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
> >
>
>
> --
> ~Kevin
> _______________________________________________
> Tinyos-devel mailing list
> Tinyos-devel at Millennium.Berkeley.EDU
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>