MRF24J40 radio module driver

Development archive
1

Hello alltogether, I'm using actually the AT86RF2XX driver as a template for the development of the MRF24J40 radio module driver.

At the moment I'm comparing the netdev2 flags of the AT86RF2XX driver and the MRF24J40 when using the gnrc_networking example and I see a difference. If I take a look onto the AT86RF2XX setup the flags show me a value of 0x5164 whereas myone shows 0x5160. I can't find the any place where the missing flag 0x0004 is set in the AT86RF2XX driver. In the ../drivers/include/net/netdev2/ieee80154.h file the define for this flag is NETDEV2_IEEE802154_SRC_MODE_LONG meaning the usage of long source addresses.

Can anyone tell me where the driver is set up to use long source addresses?

Thanks a lot!

Best regards, Neo

2

Hi Neo,

if I see it correctly, the procedure is as follows:

gnrc_networking uses the the gnrc_ipv6 module which automatically pulls in it's dependencies. This is, among others, gnrc_ipv6_netif.

https://github.com/RIOT-OS/RIOT/blob/master/Makefile.dep#L280

Once this was defined, auto_init will call the "init by netif device" function.

https://github.com/RIOT-OS/RIOT/blob/master/sys/auto_init/auto_init.c#L227

This function will set the net option "NETOPT_SRC_LEN" to 8 Byte, which is the length for long hardware addresses.

https://github.com/RIOT-OS/RIOT/blob/master/sys/net/gnrc/network_layer/ipv6/netif/gnrc_ipv6_netif.c#L833

The at86rf2xx driver does not implement this option itself and passes it to the netdev2_ieee802154 module.

https://github.com/RIOT-OS/RIOT/blob/master/drivers/at86rf2xx/at86rf2xx_netdev.c#L580

In case netopt is "NETOPT_SRC_LEN" and the value is "IEEE802154_LONG_ADDRESS_LEN" (which is defined as 8U), this module sets the "NETDEV2_IEEE802154_SRC_MODE_LONG" flag.

https://github.com/RIOT-OS/RIOT/blob/master/drivers/netdev2_ieee802154/netdev2_ieee802154.c#L173

Didn't check it until know. Hope it already helped.

Best Peter

PS: Independent from upper layers and the flag field, the driver itself sets a short and a long hardware address on initialization.

https://github.com/RIOT-OS/RIOT/blob/master/drivers/at86rf2xx/at86rf2xx.c#L90

3

Hi,

not sure if I should open this discussion in this thread. :-/

Hi Neo,

if I see it correctly, the procedure is as follows:

gnrc_networking uses the the gnrc_ipv6 module which automatically pulls in it's dependencies. This is, among others, gnrc_ipv6_netif.

RIOT/Makefile.dep at master · RIOT-OS/RIOT · GitHub

Once this was defined, auto_init will call the "init by netif device" function.

RIOT/sys/auto_init/auto_init.c at master · RIOT-OS/RIOT · GitHub

This function will set the net option "NETOPT_SRC_LEN" to 8 Byte, which is the length for long hardware addresses.

https://github.com/RIOT-OS/RIOT/blob/master/sys/net/gnrc/network_layer/ipv6/netif/gnrc_ipv6_netif.c#L833

The at86rf2xx driver does not implement this option itself and passes it to the netdev2_ieee802154 module.

RIOT/drivers/at86rf2xx/at86rf2xx_netdev.c at master · RIOT-OS/RIOT · GitHub

In case netopt is "NETOPT_SRC_LEN" and the value is "IEEE802154_LONG_ADDRESS_LEN" (which is defined as 8U), this module sets the "NETDEV2_IEEE802154_SRC_MODE_LONG" flag.

https://github.com/RIOT-OS/RIOT/blob/master/drivers/netdev2_ieee802154/netdev2_ieee802154.c#L173

I don't know why this goes down through the driver layer. The address filter doesn't need such information if you use as source address long or short.

For me it's unclear for what this sourc_len really is made for. I would suggest to use the best address setting which do the most smallest payload. Sure, there exists situation to overwrite such setting - but this should be done not as an interface setting.

This is the way what I have in my mind to do in Linux.

side note: interessting is that, in 6LoWPAN it depends on L3 address and fragmentation if you use short or long address to produce the smallest payload.

- Alex

4

Hey Alex!

5

Hi,

Hey Alex!

In case netopt is "NETOPT_SRC_LEN" and the value is "IEEE802154_LONG_ADDRESS_LEN" (which is defined as 8U), this module sets the "NETDEV2_IEEE802154_SRC_MODE_LONG" flag.

https://github.com/RIOT-OS/RIOT/blob/master/drivers/netdev2_ieee802154/netdev2_ieee802154.c#L173

I don't know why this goes down through the driver layer. The address filter doesn't need such information if you use as source address long or short.

For me it's unclear for what this sourc_len really is made for. I would suggest to use the best address setting which do the most smallest payload. Sure, there exists situation to overwrite such setting - but this should be done not as an interface setting.

Maybe I miss something, but how should the driver know which L2 address format is expected at the receiver's side?

Why the driver needs to know about that? The driver doesn't build mac frames. Well, there exists hardmac transceivers which do building mac frames on transceiver side. I never had some hardmac transceiver so I am unsure how they really work and which API they offer.

I know that neighbour discovery knows if neighbour has short and extended address. For purely L2 solution you might need to have coordinator support etc. It's job of some upper-layer to provide such mapping, or you do some force setting like NETOPT_SRC_LEN which I suggest what it is.

I can understand that this goes to the driver layer for some hardmac transceivers which accepts mac payload data only and builds the mac frame on transceivers side.

- Alex