[Tinyos-devel] Patches to FTSP and CC2420 for 32kHz sync and LPL functionality

[Philip Levis]

On Jun 28, 2009, at 11:39 AM, Omprakash Gnawali wrote:

> On Sat, Jun 27, 2009 at 12:27 PM, Razvan Musaloiu-E.<razvanm at cs.jhu.edu 
> > wrote:
>> Hi!
>>
>> On Sat, 27 Jun 2009, Omprakash Gnawali wrote:
>>
>>> On Sat, Jun 27, 2009 at 10:41 AM, Philip  
>>> Levis<pal at cs.stanford.edu> wrote:
>>>>
>>>> On Jun 26, 2009, at 6:35 PM, Razvan Musaloiu-E. wrote:
>>>>
>>>>> I update the default-lpl-new branch to use a
>>>>> SystemLowPowerListeningC instead of DefaultLplSettingsC. The new
>>>>> interface is like this:
>>>>>
>>>>> interface SystemLowPowerListening
>>>>> {
>>>>>        command void setLocalSleepInterval(uint16_t interval);
>>>>>        command void setRxSleepInterval(uint16_t interval);
>>>>>        command void setDelayAfterReceive(uint16_t interval);
>>>>>
>>>>>        command uint16_t getRxSleepInterval();
>>>>>        command uint16_t getDelayAfterReceive();
>>>>> }
>>>>>
>>>>> The setX calls are used by the user application while the getX are
>>>>> used by LplAMSenderP and DefaulLplP. One drawback of this is the
>>>>> fact that it doesn't prevent the user from calling the setX at the
>>>>> wrong time. :|
>>>>
>>>> This looks good -- I think my one comment would be to change
>>>> RxSleepInterval to DefaultDestinationSleepInterval. That seems  
>>>> clearer
>>>> to me.
>>>>
>>>> I agree on the issues with the set calls. One solution here is that
>>>> you have an error_t return value, with can return FAIL if done at  
>>>> the
>>>> wrong time (e.g., radio is on).
>>>
>>> This might preclude something like NoSE which sets different sleep
>>> intervals at different times. Here is a link:
>>> http://www.tik.ee.ethz.ch/~beutel/pub/MWWBT2009.pdf
>>>
>>
>> An application can still use the normal LowPowerListening interface  
>> to tweek
>> the settings for each packet. So NoSE should still be able to do  
>> its job.
>>
>> My initial idea of a default lpl was to make it very easy for an  
>> application
>> to be compiled either in lpl or non-lpl mode. My initial proposal was
>> exactly that. This SystemLowPowerListening we end up with is more
>> complicated and more open to interpretation and misuse.
>
> Why not making it call-at-most-once type of configuration? That way if
> there are multiple calls from multiple Booted, we would catch that by
> looking at the error value, even when the radio is off.

A better solution would be to do this with wiring checks: it's a  
compile-time error if more than one component wires to the interface.

Phil