Setting options in an IEEE 802.15.4 driver

Development archive
1

Hi,

I'm currently working on an 802.15.4 driver, and trying to use all the fancy new boilerplate functionality which was merged recently. I'm using the at86rf2xx driver as inspiration, but the way it sets some options (e.g. the long and short addresses) confuses me a bit.

The at86rf2xx's netdev set() function, when called with NETOPT_ADDRESS, will call at86rf2xx_set_addr_short() which sets the short_addr of the device struct along with some other at86rf2xx-specific stuff. At the end of the case statement, however, it then calls netdev2_ieee802154_set() *as well*, which appears to do the same thing again (minus the chip-specific stuff).

Perhaps I'm getting lost in a forest of extended structs, but is this intentional? It seems like at86rf2xx_set_addr_short() should *only* be doing the chip-specific stuff, and leaving the rest up to netdev2_ieee802154_set()? I hope my description's not too hard to follow.

Cheers, Aaron

2

Actually, I don't think netdev2_ieee802154_set() will ever be called from _set(), since the check to call this is 'if (res == -ENOTSUP)'. 'res' is set to '0' before the case statement and never changed in the case of NETOPT_ADDRESS, so I guess the only reason it works at all is because the device struct's 'short_addr' is being set (incorrectly?) by at86rf2xx_set_addr_short()?

/Aaron

3

Hi, just tested the behavior with examples/default and setting the short address is working, so it might be a bit messy implemented (mostly because netdev2_ieee802154_set() was introduced later in the process), but it IS working.

Cheers, Martine

4

Hi, regardless, I opened a PR to fix it: https://github.com/RIOT-OS/RIOT/pull/5227

Cheers, Martine

5

Yes, it is working, it's just a bit confusing for someone looking at the code. Anyhow let's continue the discussion on the PR.

Thanks, Aaron