IEEE 802.15.4 driver attribute values. More...

#include <ieee802154_radio.h>

Data Fields
union {

uint32_t phy_supported_channel_pages
	A bit field that represents the supported channel pages, see ieee802154_phy_channel_page. More...

const struct ieee802154_phy_supported_channels * phy_supported_channels
	Pointer to a structure representing channel ranges currently available on the selected channel page. More...

uint32_t phy_hrp_uwb_supported_nominal_prfs
	A bit field representing supported HRP UWB pulse repetition frequencies (PRF), see enum ieee802154_phy_hrp_uwb_nominal_prf. More...

};

Detailed Description

IEEE 802.15.4 driver attribute values.

This structure is reserved to scalar and structured attributes that originate in the driver implementation and can neither be implemented as boolean ieee802154_hw_caps nor be derived directly or indirectly by the MAC (L2) layer. In particular this structure MUST NOT be used to return configuration data that originate from L2.

Note: To keep this union reasonably small, any attribute requiring a large memory area, SHALL be provided pointing to static memory allocated by the driver and valid throughout the lifetime of the driver instance.

Field Documentation

◆ [union]

union { ... } ieee802154_attr_value

◆ phy_hrp_uwb_supported_nominal_prfs

uint32_t ieee802154_attr_value::phy_hrp_uwb_supported_nominal_prfs

A bit field representing supported HRP UWB pulse repetition frequencies (PRF), see enum ieee802154_phy_hrp_uwb_nominal_prf.

Note: Currently none of the Zephyr HRP UWB drivers implements more than one nominal PRF at runtime, therefore only one bit will be set and the current PRF (UwbPrf, MCPS-DATA.request, section 8.3.2, table 8-88) is considered to be read-only, fixed and "well known" via the supported PRF attribute.

◆ phy_supported_channel_pages

uint32_t ieee802154_attr_value::phy_supported_channel_pages

A bit field that represents the supported channel pages, see ieee802154_phy_channel_page.

Note: To keep the API extensible as required by the standard, supported pages are modeled as a bitmap to support drivers that implement runtime switching between multiple channel pages.; Currently none of the Zephyr drivers implements more than one channel page at runtime, therefore only one bit will be set and the current channel page (see the PHY PIB attribute phyCurrentPage, section 11.3, table 11-2) is considered to be read-only, fixed and "well known" via the supported channel pages attribute.

◆ phy_supported_channels

const struct ieee802154_phy_supported_channels* ieee802154_attr_value::phy_supported_channels

Pointer to a structure representing channel ranges currently available on the selected channel page.

Warning: The pointer must be valid and constant throughout the life of the interface.

The selected channel page corresponds to the phyCurrentPage PHY PIB attribute, see the description of phy_supported_channel_pages above. Currently it can be retrieved via the IEEE802154_ATTR_PHY_SUPPORTED_CHANNEL_PAGES attribute.

Most drivers will expose a single channel page with a single, often zero-based, fixed channel range.

Some notable exceptions:

The legacy channel page (zero) exposes ranges in different bands and even PHYs that are usually not implemented by a single driver.
SUN and LECIM PHYs specify a large number of bands and operating modes on a single page with overlapping channel ranges each. Some of these ranges are not zero-based or contain "holes". This explains why several ranges may be necessary to represent all available channels.
UWB PHYs often support partial channel ranges on the same channel page depending on the supported bands.

In these cases, drivers may expose custom configuration attributes (Kconfig, devicetree, runtime, ...) that allow switching between sub-ranges within the same channel page (e.g. switching between SubG and 2.4G bands on channel page zero or switching between multiple operating modes in the SUN or LECIM PHYs.

The documentation for this struct was generated from the following file: