This commit updates the srf06-cc26xx platform by adding support for the CC1310EM.
We generalise the way this platform selects CPU/board so that we can easily add more combinations in the future. These changes have implication on how to build for different devices, so make sure to have a look at the updated README
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
read_frame was misuing the packet length in the following ways:
- returning non-zero even if buf_len is too short for the packet
- truncating the length to buf_len if len is too long then using the
truncated (i.e. wrong) length to index into the buffer
- memcpying too many bytes (used buf_len instead of real length)
This commit fixes all of this and adds some code to report
on packet length errors (to match with cc2538 driver).
- moved variable declaration to top of function in accordance with the
Contiki style guide
- made function flatter, reduced nesting to improve readability
phase_wait did not check whether queuebuf_new_from_packetbuf() returns NULL. This potentially causes send_packet to behave incorrectly; the proper packet would not be sent out (because queuebuf_to_packetbuf(NULL) is a no-op). Instead, whatever has been left in the packet buffer by its previous user will be sent out.
Up to now we were using the LibreOffice 4.3 ppa (ppa:libreoffice/libreoffice-4-4) to install doxygen. The LibreOffice Packaging team appear to have removed this ppa, resulting in our doxygen build failing.
This changes the ppa we use to LibreOffice 4.4.x.
The DNS resolver requires 1/4 sec clock resolution. The retro targets had a 1/2 sec clock resolution (optimized for the 1/2 sec TCP timer) resulting in DNS resolver timeouts being 0. Therefore the retro target clock resolution is now increased to 1/4 sec.
When a client sends a CoAP request with no block2 size,
the default one would be set to REST_MAX_CHUNK_SIZE.
However, this is not guaranteed to be a power of 2.
This can lead to clients receiving a bigger payload than expected as
part of the header, and ending up with duplicated content.
Setting the default to COAP_MAX_BLOCK_SIZE,
which is guaranteed to be a power of 2, fixes this.
../..//core/net/mac/contikimac/contikimac.c:503:11: warning: variable
‘seqno’ set but not used [-Wunused-but-set-variable]
../..//core/net/mac/contikimac/contikimac.c:496:7: warning: variable
‘len’ set but not used [-Wunused-but-set-variable]
Both of these variables are only used if RDC_CONF_HARDWARE_ACK is not
true.
Their definitions and use have been moved into #ifdef guards so they do
not appear if RDC_CONF_HARDWARE_ACK is set.
Allow the project / platform to provide values for CCA_SLEEP_TIME and LISTEN_TIME_AFTER_PACKET_DETECTED.
This is useful for sub-ghz operation.
This has been shamelessly stolen from the [Mountain Sensing project](https://github.com/feshie/contiki)
@heliosfa @kmartinez
There are scenarios in which it is beneficial to search for an Etherne chip at several i/o locations. To do so the chip initialization is performed at several i/o locations until it succeeds. In order to allow for that operation model the i/o location fixup needs to be repeatable.
Note: This won't work with the RR-Net because the fixup bits overlap with the chip i/o bits.
Instead of hard coded setting the resend timer to CLOCK_SECOND,
restart it, so that the time between ANY following transmissions will
be as passed to stunicast_send_stubborn.
Enabling this option seems to greatly improve transciever performance with
Contikimac. This seems to happen because Contikimac CCAs are much less likely
to detect false positives (thus screwing up the CCA sequence).
