Commit graph

29 commits

Author SHA1 Message Date
George Oikonomou 7b193ee014 Merge pull request #1932 from g-oikonomou/contrib/cc1350/lp-and-st
Add support for the CC1350 LP and Sensortag
2017-04-24 15:34:22 +01:00
George Oikonomou 6a36a398bd Merge pull request #1931 from g-oikonomou/contrib/cc26xx-cc13xx/update-rf-api
Use TI-Provided CC13xx/CC26xx RF API
2017-04-24 15:33:14 +01:00
George Oikonomou b91448dfa4 Merge pull request #1348 from g-oikonomou/bugfix/cc26xx/wait-for-rssi-valid
Wait for a valid RSSI reading in CC13xx/CC26xx RF drivers
2017-03-17 22:52:51 +00:00
George Oikonomou 07de8b238b Easy manipulation of CC13xx Prop Mode RX buffers 2017-01-15 12:25:10 +00:00
George Oikonomou ba12ed2cce Re-initialise RX buffers each time we turn the RF on 2017-01-15 12:24:30 +00:00
George Oikonomou 5756248949 Factor-out CC13xx PROP mode TX power table
The CC13xx PROP mode TX power table can differ between boards as well as across frequency bands. This commit provides defaults for all bands and allows the board to override.
2016-12-11 20:41:00 +00:00
George Oikonomou 6b7681c516 Extend the RF core to support RF switches 2016-12-11 16:54:11 +00:00
George Oikonomou d9ea888323 Delegate RF Front End and Bias settings to board.h 2016-12-11 16:54:10 +00:00
Jonas Olsson 43b9679bcc Move setting of RF mode to correct place, needs to be called on every boot. 2016-12-11 16:51:48 +00:00
George Oikonomou e73ac7d26f Update to latest overrides and patches 2016-12-11 16:51:48 +00:00
George Oikonomou f07ed3fc01 Allow CC13xxware to automatically configure RTRIM for us 2016-12-11 16:51:48 +00:00
George Oikonomou 3a070bd332 Fix typo in TX power settings for prop mode (12.5 dBm) 2016-12-11 16:51:48 +00:00
George Oikonomou 4d0051ad4d Switch to xxware-provided RF API headers 2016-12-11 16:51:47 +00:00
Antonio Lignan 7ddbe640be Merge pull request #1795 from g-oikonomou/contrib/sensniff
Add generic sensniff example and remove legacy sniffers
2016-08-16 14:47:17 +02:00
George Oikonomou 983a618a36 Extend CC13xx PROP mode driver
We now write a dummy LQI in read() and we also add support for `RADIO_PARAM_RX_MODE` in `set_value()`
2016-08-12 01:23:50 +01:00
George Oikonomou dbd4f630fd Remove built-in sniffer support: CC13xx PROP mode 2016-08-12 01:23:49 +01:00
George Oikonomou 8ab0522cec Fix PROP mode channel switching
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.
2016-07-24 03:39:13 +01:00
George Oikonomou 16f56abfad Wait for a valid RSSI reading in CC13xx/CC26xx RF drivers
As discussed in #1341, the current CC13xx/CC26xx IEEE mode driver sends `CMD_GET_RSSI` once and returns the RSSI reading uncondtionally. This happens within the `get_rssi()` function.

This logic is broken if `get_rssi()` is called with the radio off. The function will make sure to turn on the radio first, but it does not make sure the RSSI reading is valid, which only happens a number of symbol periods after the radio enters RX. The outcome is that `NETSTACK_RADIO.get_value(RADIO_PARAM_RSSI, ...)` will always return -128 (meaning that RSSI is unavailable) if the radio was off at the time of calling the function.

The same condition affects the prop mode driver.

This commit changes the logic of `get_rssi()`:
* For PROP mode, if `CMD_GET_RSSI` returns an invalid RSSI, we send it again. For unknown reasons, `CMD_GET_RSSI` on occasion returns 0, so we ignore that value too.
* For IEEE mode, we use `CMD_IEEE_CCA_REQ` and we inspect the value of `ccaInfo.ccaEnergy` of the return structure. If the value is 0x02 (Invalid), we send the command again.

Fixes #1341
2016-07-17 18:20:22 +01:00
Atis Elsts 97c1cfc3b4 cc26xx: return the expected value 0 from prepare() in ieee and prop mode radio 2016-06-14 00:54:33 +03:00
Atis Elsts ac6f8008fd cc26xx: implement poll mode, hardware timestamps, and other minor changes in the IEEE radio driver 2016-06-14 00:54:32 +03:00
Phil Rhinehart 5d5544151f Fixed bug in cc26xx-cc13xx rf-core. When running BLE in conjunction with ContikiMAC, oscillators were modified from an interrupt state causing occasional bus faults and infinite loops. We now check if BLE is active prior to modifiying the oscillators to avoid these conditions. 2016-04-18 17:17:07 +08:00
Benoît Thébaudeau 6166693a11 Merge pull request #1133 from bkozak-scanimetrics/cc-gcc
put gcc specific stuff into seperate .h
2015-12-05 00:39:59 +01:00
George Oikonomou b4393e861f Only set CC13xx prop mode channel if a new channel is being requested 2015-11-14 01:38:24 +01:00
George Oikonomou 320a753666 Turn CC13xx RF back off after prop TX if it was off to start with 2015-11-14 01:38:24 +01:00
George Oikonomou e0e20aa3fd Turn off ENERGEST_TYPE_LISTEN in CC13xx prop mode off() 2015-11-14 01:38:24 +01:00
George Oikonomou 54648591ee Explicitly send CMD_ABORT in prop mode before powering down 2015-11-01 22:53:35 +00:00
Billy Kozak 8e5f0bc36a Defining gcc specific macros in seperate header 2015-09-22 14:17:10 -06:00
Billy Kozak b71353181d CC26xx - enable correct IRQ in rf_core_cmd_done_en
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().
2015-09-02 12:37:33 -06:00
Jonas Olsson 01e36532c2 Add support for the CC13xx CPU
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
2015-08-23 19:54:42 +01:00