during the implementation of the MCR20A driver I missed some functions
of the ieee802154 radio API, which I known by linux kernel and RIOT-OS.
I do not know if a todo already exist, I have not found any, so I try to
The transceivers can have different capabilities (csma, autoack ...).
During the initialization of the driver, the appropriate flags should be
set by the driver. During the initializing of the subsystem, the flags
must be checked and enabled according to the desired behavior.
For example, if the hardware can automatically perform CCA before the TX
sequence (IEEE802154_HW_LBT is set), the linklayer does not have to call
the API function int (*cca)(struct device *dev);
The Flags for the Hardware Capabilities:
(The same identifiers as in Linux kernel)
- IEEE802154_HW_LBT (listen before transmit or CCA before TX)
In addition, I would insert following flags:
- IEEE802154_HW_TX_AUTOACK (can transmit ACK frame after RX)
- IEEE802154_HW_RX_ACKREQ (RX ACK frame is expected after TX)
- IEEE802154_RF_TESTMODE (disabled by default, Modes: RX, CW, PRBS9 ...)
- bit field for supported channels ?
Other suggestions and comments are welcome.
What would be the appropriate place for the flags variable, Network
Then the ieee802154_radio_api could then be extended by the following
int (*set_lbt)(struct device *dev, bool on),
int (*set_csma_params)(struct device *dev, ...),
int (*set_cca_mode)(struct device *dev, ...),
int (*set_cca_threshold)(struct device *dev, int32_t level),
int (*set_promiscuous_mode)(struct device *dev, bool on),
int (*set_frame_retries)(struct device *dev, bool on),
int (*set_hw_addr_filt)(struct device *dev, ...),
int (*set_auto_ack)(struct device *dev, ...),
int (*set_rf_test_mode)(struct device *dev, uint32_t mode),
Is it ok to use the same identifiers as Linux kernel?