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

[Aaron Sowry]

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 :
> 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 :
>>
>> 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 :
>>>
>>> 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 :
>>> > 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@riot-os.org
>>> https://lists.riot-os.org/mailman/listinfo/devel
>>
>>
>
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

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

[Martine Lenders]

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 :

> 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 :
>
>> 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 :
>> > 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@riot-os.org
>> https://lists.riot-os.org/mailman/listinfo/devel
>>
>
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

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

[Martine Lenders]

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 :

> 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 :
> > 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@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

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

[Aaron Sowry]

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 :
> 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@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

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

[Aaron Sowry]

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@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel