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

[Razvan Musaloiu-E.]

Hi!

On Sun, 28 Jun 2009, Philip Levis wrote:

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

Now I'm completely in the dark. In my first proposal the settings were 
defines in the Makefile and you said about it:

> This implementation looks great, with one exception: it would be nice if 
> the LPL setting were stored in a component, rather than being an 
> enum/define. That way, it is possible to write such a component so that 
> the setting could change at runtime. The standard one might just be a 
> function wrapper around the enum, but an ADT would be better.

My understanding of this was that you want the defines replaced with an 
ADT and not that you want both of them. To some extend I would say it 
doesn't make much sense to give run time control to the default LPL 
settings because you can always achieve whatever behavior you want by 
using the normal LowPowerListening interface.

--
Razvan ME

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