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

[Philip Levis]

On Jun 28, 2009, at 3:00 PM, Razvan Musaloiu-E. wrote:

> Hi!
>
> On Sun, 28 Jun 2009, Philip Levis wrote:
>
>>
>> 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 totweek
>>>> 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.
>
> I'm not aware of any way in which you can check at compile time if  
> the call is made from Boot.booted or not. Even if you make one call  
> you can still make at the wrong moment.

Why is Boot.booted the right time? I might have an application that  
boots, waits 5 minutes, the configures the radio and starts it. Sure,  
there are times when the call can be made incorrectly, but I'm not  
sure that we want a draconian enforcement of Boot.booted as the only  
possible time it can be done.

Note that this discussion of the API call is independent of whether  
you can shadow or have a compile-time parameter for the default value.

>
>> 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.
>
> Do you suggest that the setX and getX should be in different  
> interfaces? I can make that change but, as I said above, this  
> doesn't solve the problem.

The problem Om was referring to, if I understood it correctly, was  
when multiple components try to set the interval.

Phil