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

[Philip Levis]

On Jun 25, 2009, at 6:46 PM, Razvan Musaloiu-E. wrote:

> Hi!
>
> On Thu, 25 Jun 2009, Philip Levis wrote:
>
>>
>> On Jun 19, 2009, at 3:13 PM, Razvan Musaloiu-E. wrote:
>>
>>> Hi!
>>> On Thu, 18 Jun 2009, Philip Levis wrote:
>>>> On Jun 18, 2009, at 3:26 PM, Razvan Musaloiu-E. wrote:
>>>>> Hi!
>>>>> On Thu, 18 Jun 2009, Philip Levis wrote:
>>>>>> On Jun 17, 2009, at 5:41 PM, Razvan Musaloiu-E. wrote:
>>>>>>> Actually, I implemented a default behavior for LPL some time  
>>>>>>> ago:
>>>>>>> 	http://hinrg.cs.jhu.edu/git/?p=razvanm/tinyos-2.x.git
>>>>>> Can you point me at where in the tree it is?
>>>>> The name of the branch is "default-lpl". Getting it by cloning  
>>>>> the whole repository can be done using the following commands:
>>>>> 	git clone git://hinrg.cs.jhu.edu/git/razvanm/tinyos-2.x.git
>>>>> 	cd tinyos-2.x
>>>>> 	git checkout -b default-lpl origin/default-lpl
>>>>> In an already existing git tree the default-lpl can be imported  
>>>>> using these commands:
>>>>> 	git fetch git://hinrg.cs.jhu.edu/git/razvanm/tinyos-2.x.git  
>>>>> default-lpl:refs/remotes/razvanm/default-lpl
>>>>> 	git checkout -b default-lpl razvanm/default-lpl
>>>> Razvan,
>>>> 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.
>>> Quick q: what should this ADT be? Should it be something like this:
>>> 	http://tinyos.cvs.sourceforge.net/viewvc/tinyos/tinyos-2.x/tos/chips/msp430/usart/Msp430UartConfigure.nc?revision=1.4&view=markup
>>> Another option is to be offer a modified LowPowerListening  
>>> interface.
>>
>> No -- this isn't an ADT, it's a callback for per-client  
>> configuration. That's the opposite of what we want here, which is a  
>> uniform LPL setting across clients.
>>
>> I think ActiveMessageAddressC is a better example.
>>
>
> Here is an attempt: to configure the default lpl settings an  
> application needs to shadow a component called DefaultLplSettingsC  
> that looks like this:
>
> 	configuration DefaultLplSettingsC
> 	{
> 	  provides interface DefaultLplSettings;
> 	}
>
> 	implementation
> 	{
> 	  // The parameters are: local sleep, rx sleep, delay after receive
> 	  components new DefaultLplSettingsP(512, 512, 20);
>
> 	  DefaultLplSettings = DefaultLplSettingsP;
> 	}
>
> Is this ok? :-)
>
> This is already committed in the defaul-lpl-new branch of my tree:
> 	http://hinrg.cs.jhu.edu/git/?p=razvanm/tinyos-2.x.git;a=shortlog;h=default-lpl-new

Why does this wire directly to the CC2420? Shouldn't it wire to  
ActiveMessageC? More than one radio chip provides the  
LowPowerListening interface[1].

I think that a command call in the top-level application Boot event  
might be simpler than having to shadow a component. I was assuming it  
would look like this:

event Boot.booted() {
   call SystemLowPowerListening.setInterval(xyz);
}

This call does two things: it sets the receiver LPL check interval,  
and makes it so that all packets are sent with this check interval. If  
we wanted to be super fancy, we could also have separate RX and TX  
interval calls; the former is just a call through to the  
LowPowerListening set check interval, while the latter stores the  
value for a call to LowPowerListening.setRxSleepInterval.

Does that make sense?

Phil

[1] Looking through some platforms, it looks like the mica2 doesn't  
provide it, and the CC1000 is stuck with a shadowed version of the  
LowPowerListening interface, we should fix this for 2.1.1.