[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