This change marks each instance of the 'api' as 'static const'.
The rationale is that 'api' is used for declaring internal
module interfaces and is not intended to be modified at runtime.
By using 'static const', we ensure immutability, leading to usage of only
.rodata and a reduction in the .data area.
Signed-off-by: Pisit Sawangvonganan <pisit@ndrsolution.com>
rand32.h does not make much sense, since the random subsystem
provides more APIs than just getting a random 32 bits value.
Rename it to random.h and get consistently with other
subsystems.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
Replaces the previous approach to define bands via hardware capabilities
by the standard conforming concept of channel pages.
In the short term this allows us to correctly calculate the PHY specific
symbol rate and several parameters that directly depend from the symbol
rate and were previously not being correctly calculated for some of the
drivers whose channel pages could not be represented previously:
* We now support sub-nanosecond precision symbol rates for UWB. Rounding
errors are being minimized by switching from a divide-then-multiply
approach to a multiply-then-divide approach.
* UWB HRP: symbol rate depends on channel page specific preamble symbol
rate which again requires the pulse repetition value to be known
* Several MAC timings are being corrected based on the now correctly
calculated symbol rates, namely aTurnaroundTime, aUnitBackoffPeriod,
aBaseSuperframeDuration.
In the long term, this change unlocks such highly promising functional
areas as UWB ranging and SUN-PHY channel hopping in the SubG area (plus
of course any other PHY specific feature).
Signed-off-by: Florian Grandel <fgrandel@code-for-humans.de>
Aligns the name of the return value variable with what is used elsewhere
in the driver and the subsystem for improved readability and
consistency.
Signed-off-by: Florian Grandel <fgrandel@code-for-humans.de>
Based on the 'Technical Reference Manual' for CC13x2/CC26x2 SimpleLink
MCU family, the device contains factory pre-programmed 64-bit IEEE MAC
address for 802.15.4 radio inside two FCFG 32-bit registers:
1. MAC_15_4_0: first 32-bit of the 64-bit IEEE MAC address
2. MAC_15_4_1: last 32-bit of the 64-bit IEEE MAC address
The way current version of the driver setups the address results in
incorrect bytes order (the address is reversed):
uart:~$ ieee802154 get_ext_addr
Extended address: AF:03:B7:25:00:4B:12:00
This fixes the problem in both drivers (also in the Sub-GHz version)
which results in use of proper EUI-64 address:
uart:~$ ieee802154 get_ext_addr
Extended address: 00:12:4B:00:25:B7:03:AF
IEEE MAC address was confirmed with UniFlash, nRF Sniffer for 802.15.4
and IEEE OUI database (00:12:4B is one of registered OUI for Texas
Instruments).
To prevent confusion in future, short notice about bytes order for
'mac' field in driver's data structures was also included.
Signed-off-by: Piotr Dymacz <pepe2k@gmail.com>
The CMD_CLEAR_RX and CMD_SET_TX_POWER commands are declared and
initialized but not used anywhere. They are therefore removed to reduce
RAM/flash footprint.
Signed-off-by: Florian Grandel <fgrandel@code-for-humans.de>
Acknowledgment is mandatory if legitimately requested by the package's
"ACK requested" flag. The L2 layer will have to ensure that compliant
ACK packages will always be sent out automatically as required by the
standard.
For IEEE 802.15.4 compliance, the NET_L2_IEEE802154_ACK_REPLY option is
therefore being deprecated.
Signed-off-by: Florian Grandel <fgrandel@code-for-humans.de>
The existing calls to ieee802154_radio_send() and soft MAC ACK handling
were inconsistent and/or not properly integrated with more recent
radio driver capabilities as CSMA/CA and ACK in hardware.
Signed-off-by: Florian Grandel <fgrandel@code-for-humans.de>
The RSSI value in net_pkt (net_pkt_cb_ieee802154.rssi) was used
inconsistently across drivers. Some drivers did cast a signed dBm value
directly to net_pkt's unsigned byte value. Others were assigning the
negative value of the signed dBm value and again others were offsetting
and stretching the signed dBm value linearly onto the full unsigned byte
range.
This change standardizes net_pkt's rssi attribute to represent RSSI on
the RX path as an unsigned integer ranging from 0 (–174 dBm) to 254 (80
dBm) and lets 255 represent an "unknown RSSI" (IEEE 802.15.4-2020,
section 6.16.2.8). On the TX path the rssi attribute will always be
zero. Out-of-range values will be truncated to max/min values.
The change also introduces conversion functions to and from signed dBm
values and introduces these consistently to all existing call sites. The
"unknown RSSI" value is represented as INT16_MIN in this case.
In some cases drivers had to be changed to calculate dBm values from
internal hardware specific representations.
The conversion functions are fully covered by unit tests.
Fixes: #58494
Signed-off-by: Florian Grandel <fgrandel@code-for-humans.de>
Currently the 2.4G radio driver for CC1352 has few implementations which
prevents both the radios to be used in a single build, thus preventing
applications to have different builds to switch the RF bands even though
the hardware supports dual bands simultaneously.
The following updates are made:
* Remove RF patches from stack.
* Implement if_stop() to stop the interface and yield the interface.
* Use RF_runCmd() instead of RF_runImmediateCmd() so that two RF handles
can work simultaneously.
All the updates are similar to the more recent cc13xx subg driver which
implements all these recommended practices already.
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
Many device pointers are initialized at compile and never changed. This
means that the device pointer can be constified (immutable).
Automated using:
```
perl -i -pe 's/const struct device \*(?!const)(.*)= DEVICE/const struct
device *const $1= DEVICE/g' **/*.c
```
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Use Devicetree to describe the radio and IEEE 802.15.4. This allows to
remove usage of IEEE802154_CC13XX_CC26XX_DRV_NAME in preparation for the
removal of NET_CONFIG_IEEE802154_DEV_NAME. All boards used in testing
have been updated to enable the peripheral in DT as well.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
In order to bring consistency in-tree, migrate all drivers to the new
prefix <zephyr/...>. Note that the conversion has been scripted, refer
to #45388 for more details.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Replace all get_dev_data()/get_dev_config() accessor utilities with
dev->data and dev->config.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Convert drivers to DEVICE_DEFINE instead of DEVICE_AND_API_INIT
so we can deprecate DEVICE_AND_API_INIT in the future.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
This change adds IEEE802154_RAW_MODE support for the
cc1352r.
This allows using the cc1352r 2.4 GHz radio and Sub Ghz
radio as a transceiver (PHY) instead of using L2 networking.
Signed-off-by: Erik Larson <erik@statropy.com>
This change enables the multi-protocol rf patch to be used for
the cc13xx_cc26xx IEEE 802.15.4 2.4 GHz PHY, which allows both
the 2.4 GHz and Sub GHz PHY to be used simultaneously.
Eventually, BLE will also work simultaneously on 2.4 GHz (with
arbitration).
Fixes#29883
Signed-off-by: Christopher Friedt <chrisfriedt@gmail.com>
This change adds IEEE 802.15.4g (Sub GHz) support for the
cc1352r.
The 2.4 GHz radio and the Sub GHz radio are capable of
operating simultaneously.
Fixes#26315
Signed-off-by: Christopher Friedt <chrisfriedt@gmail.com>
This is a temporary workaround for an issue in TI's RF Driver
API. A subsequent release of the SimpleLink SDK will mitigate
the need for it and it can be reverted when hal/ti receives
that update.
Fixes#29418
Signed-off-by: Christopher Friedt <chrisfriedt@gmail.com>
This change reworks the cc13xx_cc26xx IEEE 802.15.4 driver to use
the TI RF driver API that is available in modules/hal/ti.
There are a number of benefits to using TI's API including
- a stable multi-OS vendor library and API
- API compatibility with the rest of the SimpleLink SDK and SoC family
- potential multi-protocol & multi-client radio operation
(e.g. both 15.4 and BLE)
- coexistence support with other chipsets via gpio
- vetted TI RF driver resources, such as
- the radio command queue
- highly tuned / coupled RTC & RAT (RAdio Timer) API
Fixes#26312
Signed-off-by: Christopher Friedt <chrisfriedt@gmail.com>
In all of these drivers, passing the device's data was sufficient as
only the data is being used by thread.
Fixes#27399
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Now that device_api attribute is unmodified at runtime, as well as all
the other attributes, it is possible to switch all device driver
instance to be constant.
A coccinelle rule is used for this:
@r_const_dev_1
disable optional_qualifier
@
@@
-struct device *
+const struct device *
@r_const_dev_2
disable optional_qualifier
@
@@
-struct device * const
+const struct device *
Fixes#27399
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
IRQ_CONNECT() can only be called at one location to connect the irq for
CPE0. This commit modifies the driver to call into the HwiP layer in TI
HAL so that TI's RF driver can do the same when connecting the irq.
Fixes#25216
Signed-off-by: Vincent Wan <vincent.wan@linaro.org>
Even though radio driver can report in its capabilities that it does
support CSMA CA, there's no way in the driver to select how the frame
should be transmitted (with CSMA or without). As layers above radio
driver (Thread, Zigbee) can expect that both TX modes are available, we
need to extend the API to allow either of these modes.
This commits extends the API `tx` function with an extra parameter,
`ieee802154_tx_mode`, which informs the driver how the packet should be
transmitted. Currently, the following modes are specified:
* direct (regular tx, no cca, just how it worked so far),
* CCA before transmission,
* CSMA CA before transmission,
* delayed TX,
* delayed TX with CCA
Assume that radios that reported CSMA CA capability transmit in CSMA CA
mode by default, all others will support direct mode.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
By changing the various *NET_DEVICE* macros. It is up to the device
drivers to either set a proper PM function or, if not supported or PM
disabled, to use device_pm_control_nop relevantly.
All existing macro calls are updated. Since no PM support was added so
far, device_pm_control_nop is used as the default everywhere.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
