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

Razvan Musaloiu-E. razvanm at cs.jhu.edu
Fri Jun 26 15:19:56 PDT 2009


Hi!

On Fri, 26 Jun 2009, Philip Levis wrote:

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

Good point. I'll fix that.

> I think that a command call in the top-level application Boot event might be 
> simpler than having to shadow a component.

I use the shadowing to allow the user app to be unchanged.

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

Yes. I'm implementing this right now. :-)

--
Razvan ME

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


More information about the Tinyos-devel mailing list