RFC2131 states on page 36 regarding DHCPREQUEST: " 'xid' from server DHCPOFFER message "
As the DHCPOFFER message uses the 'xid' from the DHCPDISCOVER message this means that the DHCP client is supposed to re-use the 'xid' from its DHCPDISCOVER for the DHCPREQUEST.
For the SPI
* We improve the return semantics of _read() and _write()
* We set speed based on the value returned from ti_lib_sys_ctrl_clock_get() instead of using a hard-coded value
External flash changes:
* Rename macros to match instruction names
* verify_part(): Return a different value when the device is powered down and when communication fails
* Change return value semantics of static functions
* Adjust checks of board_spi_ return values
* Wait for BUSY to clear before attempting to send PD
* Accept two possible flash parts: W25X40CL (4MBit) as well as the W25X20CL (2MBit)
The current version of the CC26xx web demo publishes over MQTT the default parent's IPv6 address and the last observed RSSI of this link. This is collected by active probing (periodic ping).
This commit brings the probing functionality to the example's main code module. The MQTT client keeps publishing as previously, but we now also export the same information through CoAP resources. Configuration is still possible through the example's web server.
This demonstraties how to combine CC13xx tick suppression, RPL leaf mode and turning off ContikiMAC duty cycling to build an extremely low-consuming firmware.
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.
