[riot-notifications] [RIOT-OS/RIOT] RDM: The 802.15.4 Radio HAL (#13943)

José Alamos notifications at github.com
Mon Sep 27 13:52:31 CEST 2021

There's some feedback coming from the OpenDSME port + the refactor of the SubMAC. It would be nice if @maribu, @benpicco, @fjmolinas and @PeterKietzmann could provide some feedback, since they were involved in the design decisions and review.

There are 3 amendments I would like to propose (ordered by priority)

## 1. Add FORCE_TRX_OFF state to `set_trx_state`

The current and upcoming variants of the Radio HAL might wait if a frame is being received. This is a bit counterproductive for slotted MAC layers such as TSCH and the current OpenDSME port. But for the current CSMA-CA senders is required, otherwise there's risk of aborting incoming frames (specially when sending 6LowPAN fragments). A new `IEEE802154_TRX_STATE_FORCE_TRX_OFF` (implemented on software or hardware) would be beneficial in this case.

## 2. Turn off the transceiver on frame reception.

This was already proposed some comments above.

We recently added a CAP to indicate whether the radio stays in RX_ON after reception or not. The idea was to avoid wasting state transitions when not needed.
In practice, it's not a bad practice to turn off the transceiver when reading a frame. This is already done by OpenWSN, upcoming OpenDSME and the SubMAC. This also doesn't affect timings, because the radios are designed to be compliant with the TX-RX turnaround time.

Therefore, We could simple write in the documentation that the transceiver should be set to OFF before reading a frame and we avoid defining special CAPs and dealing with radios that behave differently on reception.

## 3. Simplify TX_ON + request_transmit logic

With the current HAL, the procedure to send a frame is set the radio to TX_ON state and call `request_transmit`. I think we can get rid of the `request_transmit` function if we simply use `set_trx_state(TX_ON)` to start a transmission. This has some advantages:

- For the upper layer is easier to deal with just one function that might return error than 2. It's also easier to implement in the driver.
- For many radios TRX_OFF and TX_ON state are equivalent (kw41z, kw2xrf, cc2538, at86rf215). For radios that are not (nrf52840, at86rf2xx), we can simply define `TRX_OFF` as the previous TX_ON. After all, if the radio needs to save energy the upper layer would call `off()` instead of `set_trx_state(TRX_OFF)`.
- Although I don't think we would need it, it's still possible to send frames while in RX_ON, since **almost** all radios (damn you `at86rf2xx`) have separate RX and TX buffers. As @maribu proposed once, maybe we should consider to treat this one as the exception and just add a separate framebuffer for TX.

### Corolary
If this makes sense, we could also consider to unify `xxx_set_trx_state` and some operations such as `xxx_cca`  with `xxx_set_op`. Then IMO we simplify driver implementation and usage, since we don't need to care about the initial transceiver state of these operations and it's easier to synchronize. We can also add in the future other operations such as Energy Detection.

Please let me know what you think about it. Or simply add thumbs up to this comment if you agree.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20210927/138ccf69/attachment.htm>

More information about the notifications mailing list