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 ATmega128RFA1 and ATmega256RFR2 contain a version of this IP
on the MCU.
The radio core behaves mostly like a at86rf231, but all registers
are mapped to memory and radio states can directly generate interrupts
on the CPU.
The ATmega256RFR2 adds support for automatic retransmissions.
This has not been implemented yet.
Co-authored-by: Josua Arndt <jarndt@ias.rwth-aachen.de>
This write access is only required when a modification to the PAN ID
happened directly via this function and not via a netdev::set operation.
The only direct call was done in the reset function of the driver
This removes the check if the current configured channel equals the new
channel. This check prevents the at86rf2xx channel to be configured
after a reset which causes the radio to be non-functional after a
NETOPT_STATE_RESET.
The flags from the ieee802154 struct are only used in the radio code.
there is no advantage of having them in the netdev_ieee802154_t struct
if the flags are defined differently per radio driver.
This function was only used once in the initialization procedure.
Inlining the actual state change reduces overhead and lines to
maintain.
If ever needed, undo this commit.
It was pointed out that after a state change to RX_AACK_ON reading back
the state to confirm the transition can fail due to an imidiate change
into BUSY_RX_AACK between the successful change on the transceiver and
querying the state.
For this we exclude the readback of the state for transitions to
RX_AACK_ON.
The rational behind this change is the following:
If the transceiver is in any *_BUSY state when `at86rf2xx_set_state()`
gets called this would bypass the `(state == old_state)` check and
unneeded state transitions could be triggered.
