[riot-devel] Setting options in an IEEE 802.15.4 driver

Aaron Sowry aeneby at gmail.com
Fri Apr 1 22:17:07 CEST 2016


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

2016-04-02 1:05 GMT+13:00 Martine Lenders <authmillenon at gmail.com>:
> Hi,
> regardless, I opened a PR to fix it:
> https://github.com/RIOT-OS/RIOT/pull/5227
>
> Cheers,
> Martine
>
> 2016-04-01 13:59 GMT+02:00 Martine Lenders <authmillenon at gmail.com>:
>>
>> 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
>>
>> 2016-04-01 6:55 GMT+02:00 Aaron Sowry <aeneby at gmail.com>:
>>>
>>> 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
>>>
>>> 2016-04-01 16:27 GMT+13:00 Aaron Sowry <aeneby at gmail.com>:
>>> > 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
>>> _______________________________________________
>>> devel mailing list
>>> devel at riot-os.org
>>> https://lists.riot-os.org/mailman/listinfo/devel
>>
>>
>
>
> _______________________________________________
> devel mailing list
> devel at riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>


More information about the devel mailing list