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

[Matt Welsh]

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