A if `netdev_driver_t::confirm_send()` is provided, it provides the
new netdev API. However, detecting the API at runtime and handling
both API styles comes at a cost. This can be optimized in case only
new or only old style netdevs are in use.
To do so, this adds the pseudo modules `netdev_legacy_api` and
`netdev_new_api`. As right now no netdev actually implements the new
API, all netdevs pull in `netdev_legacy_api`. If `netdev_legacy_api` is
in used but `netdev_new_api` is not, we can safely assume at compile
time that only legacy netdevs are in use. Similar, if only
`netdev_new_api` is used, only support for the new API is needed. Only
when both are in use, run time checks are needed.
This provides two helper function to check for a netif if the
corresponding netdev implements the old or the new API. (With one
being the inverse of the other.) They are suitable for constant folding
when only new or only legacy devices are in use. Consequently, dead
branches should be eliminated by the optimizer.
- fix wrong return value
- fix wrong size parameter
- note, the behavior is a bit relaxed in that it allows
NETOPT_RANDOM with different size than `sizeof(uint32_t)`
setting NETOPT_ENCRYPTION_KEY in device driver was redundant
because it is also done in the ieee802154 netdev driver
and the key is transfered to the hardware in the ieee802154
security implementation
Do not generate address during reset, but during setup. Otherwise the device
will get a new address after every reset. Also: Use common IEEE 802.15.4
setup function for this.
The assert is reversed. It must check if the config value does not
exceed the maximum address length, not the other way round.
previously this would lead to a crash when setting a short address:
2020-08-23 13:59:56,080 # ifconfig 7 set addr_short 2
2020-08-23 13:59:56,081 # 0xdcad
2020-08-23 13:59:56,083 # *** RIOT kernel panic:
2020-08-23 13:59:56,085 # FAILED ASSERTION.
With this it works as expected
2020-08-23 14:05:07,988 # ifconfig 7 set addr_short 2
2020-08-23 14:05:07,992 # success: set (short) address on interface 7 to 2
AT86RF2xx supports high data rates in O-QPSK mode.
This is a proprietary feature, so data rates > 0 are only supported by
other AT86RF2xx devices.
high_rate 0: 250 kbit/s (IEEE mode)
high_rate 1: 500 kbit/s
high_rate 2: 1000 kbit/s (compatible with at86rf215)
high_rate 3: 2000 kbit/s
The at86rf2xx radio handled a transfer complete condition with the radio
in the BUSY_TX_ARET state as a finished transmission. This condition and
state also occurs when a reception occurs just before switching to
transmitting. This would cause a condition where first a TX_COMPLETE was
signalled and second a RX_COMPLETE was signalled. The network stack
would then read the transmitted frame as a received frame.
The patch fixes the errornous RX callback by only submitting the
TX_COMPLETE condition when there are at least 2 frames pending
(at86rf2xx::pending_tx).
