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

[Matt Welsh]

Can't we use a default event handler for flushDone?

On Dec 14, 2006, at 9:10 PM, Ben Greenstein wrote:

> 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
>>