[riot-devel] MRF24J40 radio module driver

Alexander Aring aar at pengutronix.de
Tue Sep 6 10:26:03 CEST 2016


Hi,

On 09/06/2016 10:00 AM, Oleg Hahm wrote:
> Hey Alex!
> 
> On Tue, Sep 06, 2016 at 08:48:13AM +0200, Alexander Aring wrote:
>>> 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


More information about the devel mailing list