upgrading rfxlink Tasklet and Neighborhood to generic

[mszczodrak]

To enable rfxlink support for simultaneous operation of two radios on a single mote, the TaskletC and NeighborhoodC must be generic; otherwise we need to create separate modules for these two and per-radio copies of the rfxlink layers that are wiring to these modules (see example of ucprotonb/chips/doubleradio ).

This fix;

• makes TaskletC and NeighborhoodC generic
• removes NeighborhoodFlagC since NeighborhoodC is already generic
• MessageBufferLayerC and RadioAlarmC instead to having their own TaskletC, they use the one provided by the radio driver, at RadioC.nc
• upgrades all affected radios: atm128rfa1, cc2420x, cc2520, rf212, and rf230

[mmaroti]

I have merged your Tasklet changes, they work as advertised. The NeighborhoodC changes are not correct. We need two create two instance of the NeighborhoodC component (make it generic is fine), but each NeighborhoodC needs to service different number of NeighborhoodFlag interfaces. In your change, with every NeighborhoodC you provide a single neighborhoodflag interface, which is not good. I do not know what would be the best way forward, maybe the NeighboorhoodC needs to provide an array of beighboorhoodflag interfaces and the users need to use unique qualifiers in their RadioC setup. What do you think? Can you implement this? I will then pull that.

[mszczodrak]

Interesting point about the NeighborhoodC.

To clarify fundamentals, do we agree that each radio should have a single,
unique Neighborhood?

From the code it looks like every radio has its own Neighborhood, since
every radio has its own UniqueLayer that uses Neighborhood service.

Thus, before coding, I would like to propose the following changes:

1. make Neighborhood generic
2. the consequence of (1) is that every UniqueLayer (and thus every radio
   rfxlink stack) has unique Neighborhood
3. consequence of (2); we do not need to parameterize the NeighborhoodFlag
   interface (since there is only one neighborhood per UniqueLayer) and thus
4. with one unique Neighboorhood per radio, we can simplify the flags
   implementation from

tasklet_norace uint8_t flags[NEIGHBORHOOD_SIZE];

to

tasklet_norace uint8_t flags[NEIGHBORHOOD_SIZE / 8 + 1];

with each bit used as a flag per neighborhood node.

With this design in mind, we would need to upgrade NeighborhoodFlag
functions to use directly idx argument instead of the interface unique
bit value (Note that the bit parameter is gone and flag definition is
changed). The following is the example of the NeighborhoodFlag.get()
change:

inline tasklet_async command bool NeighborhoodFlag.get[uint8_t bit](uint8_t
idx)
{
return flags[idx] & (1 << bit);
}

would become

inline tasklet_async command bool NeighborhoodFlag.get(uint8_t idx)
{
return flags & (1 << idx);
}

In consequence, these changes would establish 1:1 relation between every
instance of a UniqueLayer and Neighborhood, a change that is particularly
useful in the networks running with multiple radios.

Any thoughts or suggestions?

-Marcin

On Fri, Jul 25, 2014 at 6:23 AM, Miklos Maroti notifications@github.com
wrote:

I have merged your Tasklet changes, they work as advertised. The
NeighborhoodC changes are not correct. We need two create two instance of
the NeighborhoodC component (make it generic is fine), but each
NeighborhoodC needs to service different number of NeighborhoodFlag
interfaces. In your change, with every NeighborhoodC you provide a single
neighborhoodflag interface, which is not good. I do not know what would be
the best way forward, maybe the NeighboorhoodC needs to provide an array of
beighboorhoodflag interfaces and the users need to use unique qualifiers in
their RadioC setup. What do you think? Can you implement this? I will then
pull that.

—
Reply to this email directly or view it on GitHub
#273 (comment).

[mszczodrak]

I just pushed the proposed simplest solution to the rfxlink Neighborhood.

In this code change, every instance of UniqueLayer gets new Neighborhood. In each Neighborhood, there is uint8_t flag variable that indicates which nodes are being tracked. This of course limits the neighborhood size to the maximum of 8 nodes, but over the years, the default size of 5 does not seem to be changed at all. This approach simplifies the code and saves few bytes.

The fixed was tested on cc2420x. It will be interesting to test it with motes that have two radios, such as opal and ucprotonb .

[gnawali]

did you get a chance to test the code on opals on twonet? let me know if you need access.

[mszczodrak]

I run a local test on few ucprotonb motes that I have. I don't have opals
on my side, and besides opals are not upgraded wrt the tinyos-main, so at
this point there is no way of using twonet for testing the rfxlink-related
upgrades.

On Fri, Sep 5, 2014 at 12:18 PM, gnawali notifications@github.com wrote:

did you get a chance to test the code on opals on twonet? let me know if
you need access.

—
Reply to this email directly or view it on GitHub
#273 (comment).

[andrasbiro]

FYI, using multiple rfxlink stacks still can be problematic: There are a lot of defined settings, like the RadioAlarm precision, or the top level interface (AM / ieee154 / Bare) settings.