xxwares ship these headers now, so we will switch to using those versions. The exceptions are IEEE API headers, which are for not part of xxwares, so we have to keep them locally for now.
If `NETSTACK_CONF_RADIO.set_value(RADIO_PARAM_CHANNEL, ...)` is called when radio is on, it will fail to apply the channel change, because it won't re-send `CMD_PROP_RADIO_DIV_SETUP` and `CMD_PROP_FS`. This commit fixes this condition, by making sure the correct commands are sent to the radio.
When sending a command to the CC13xx/CC25xx RF core, we wait for command completion by checking the LSB of CMDSTA (correctly so). However, in doing so we also zero out the 3 CMDSTA return bytes. For some commands, those bytes contain useful information (e.g. an RSSI value) and are required by the caller.
This problem manifests itself e.g. in PROP mode `channel_clear()`, whereby the caller will always see an RSSI value of 0.
This pull therefore fixes the logic in `rf_core_send_cmd()` to check for command completion by blocking on the CMDSTA result byte without zeroing out the 3 return bytes.
Fixes#1465
The current logic attempts to send `CMD_SET_TX_POWER` before saving the new power setting. If `CMD_SET_TX_POWER` fails the power setting will not get saved. As a result, when the RFC is powered off, all attempts to change TX power will fail.
This commit changes this logic to always save the new TX setting as requested by the user. If the RFC is powered up, we apply it immediately. If it is powered down, the new setting will automatically be applied next time we send `CMD_RADIO_SETUP`.
Fixes#1340
As discussed in #1294, every time a CC13xx/CC26xx RF interrupt fires, we clear all interrupt flags unconditionally. This may result in missed events. This patch fixes this bug by clearing only the flag that triggered the interrupt in the first place.
Fixes#1294
Prior to this patch, the ieee radio driver did not explicitly abort
the rx operation or power down the analog components of the radio
prior to shutting down the rf-core.
The result of this was that the rf-core continued to use a lot of
power even while "off".
This patch fixes this problem.
Fix for #1229
rf_core_cmd_done_en() was enabling the wrong irq for detecting the
completion of foreground operations. This was causing cc26xx devices
to not wake-up on time when calling lpm_sleep() from transmit().
This commit:
* Moves all cpu files from cpu/cc26xx to cpu/cc26xx-cc13xx
* Bumps the CC26xxware submodule to the latest TI release
* Adds CC13xxware as a submodule
* Adds support for sub-ghz mode / IEEE 802.15.4g
* Splits the driver into multiple files for clarity. We now have the following structure:
* A common module that handles access to the RF core, interrupts etc
* A module that takes care of BLE functionality
* A netstack radio driver for IEEE mode (2.4GHz)
* A netstack radio driver for PROP mode (sub-ghz - multiple bands)
This commit also adds tick suppression functionality, applicable to all chips of the CC26xx and CC13xx families. Instead waking up on every clock tick simply to increment our software counter, we now only wake up just in time to service the next scheduled etimer. ContikiMAC-triggered wakeups are unaffected.
Laslty, this commit also applies a number of minor changes:
* Addition of missing includes
* Removal of stub functions
* Removal of a woraround for a CC26xxware bug that has now been fixed
