The cc110x driver has been re-written from scratch to overcome the limitations
of the old driver. The main motivation of the rewrite was to achieve better
maintainability by a detailed documentation, reduce the complexity and the
overhead of the SPI communication with the device, and to allow to
simultaneously use transceivers with different configuration regarding the used
base band, the channel bandwidth, the modulation rate, and the channel map.
Features of this driver include:
- Support for the CC1100, CC1101, and the CC1100e sub-gigahertz transceivers.
- Detailed documentation of every aspect of this driver.
- An easy to use configuration API that allows setting the transceiver
configuration (modulation rate, channel bandwidth, base frequency) and the
channel map.
- Fast channel hopping by pre-calibration of the channels during device
configuration (so that no calibration is needed during hopping).
- Simplified SPI communication: Only during start-up the MCU has to wait
for the transceiver to be ready (for the power regulators and the crystal
to stabilize). The old driver did this for every SPI transfer, which
resulted in complex communication code. This driver will wait on start up
for the transceiver to power up and then use RIOT's SPI API like every other
driver. (Not only the data sheet states that this is fine, it also proved to
be reliable in practise.)
- Greatly reduced latency: The RTT on the old driver (@150 kbps data rate) was
about 16ms, the new driver (@250 kbps data rate) has as RTT of ~3ms
(depending on SPI clock and on CPU performance) (measured with ping6).
- Increased reliability: The preamble size and the sync word size have been
doubled compared to the old driver (preamble: 8 bytes instead of 4,
sync word: 4 byte instead of 2). The new values are the once recommended by
the data sheet for reliable communication.
- Basic diagnostic during driver initialization to detect common issues as
SPI communication issues and GDO pin configuration/wiring issues.
- TX power configuration with netdev_driver_t::set() API-integration
- Calls to netdev_driver_t::send() block until the transmission has completed
to ease the use of the API (implemented without busy waiting, so that the
MCU can enter lower power states or other threads can be executed).
The softdevice is only verified to be working on nrf52832-based
boards. This feature prevents the softdevice from being build for
other, similar targets (e.g. nrf52840-based boards).
Prepare for when boards define `CPU` in `BOARD/Makefile.features`.
Include '$(RIOTCPU)/$(CPU)/Makefile.features' directly when it is
defined. This will allow removing the file inclusion from the
`BOARD/Makefile.dep`. The board must then not include it directly.
Transitional change to allow migrating part by parts.
Part of moving CPU/CPU_MODEL definition to Makefile.features to have it
available before Makefile.include.
This can currently trigger including two times the cpu/CPU/Makefile.dep
but allows a by board complete migration.
Rational: the periph_common module is required by (most) other periph drivers
and also during startup of the CPU/MCU to run periph_init. The latter is only
required if other periph drivers are used, hence periph_common should be a
depency of periph_* modules and *not* of the CPU/MCU. This PR fixes that
by making periph_common a depency of periph_* and removing the explicit
include in the CPU/MCU implementation.
Put the definition of `FEATURES_USED` in common and use the variable
instead of duplicating code.
This required defining 'FEATURES_OPTIONAL_ONLY|USED' to not overwrite
the value of 'FEATURES_OPTIONAL' as was done before.
Also add 'FEATURES_OPTIONAL_MISSING' to list optional features that were
not included as not provided.
This removes the need to print FEATURES_MISSING with the optional
features too.
Update the FEATURES_OPTIONAL meaning to be more in line since
FEATURES_USED is defined. Handle FEATURES_OPTIONAL as a configuration from
the BSP/build that should not be changed anymore after.
`FEATURES_OPTIONAL` are by definition optional so are not supposed to
cause a build to fail.
Only the 'REQUIRED' ones that are not 'PROVIDED' are 'MISSING'.
* Do not change FEATURES_OPTIONAL to remove REQUIRED features
* Prepare for having a different variable for the previous value
* Update dependency resolution/info-build as FEATURES_OPTIONAL cannot be missing
This defines a new 'isrpipe_read_timeout' module that should be used when using
the timeout based function of isrpipe.
This fix the implicit dependency to 'xtimer' that is only needed for the
'_timeout' functions.
It prevents 'stdio_uart' that uses 'isrpipe' to need to depend on xtimer.
This was silently solved at link time for most platforms but not for the
'esp32' for example.
'drivers/at' needed to be updated at the same time to follow the api change.
The build system contains several instances of
INCLUDES += -I$(RIOTBASE)/sys/posix/include
This is bypassing the module management system, by directly accesing
headers without depending on a module. The module is the posix module.
That line is also added when one of the posix_* modules is requested.
According to the docs, the posix module provides headers only, but in
reality there is also inet.c.
This patch:
- Moves `inet.c` into `posix_inet`, leaving `posix` as a headers-only
module.
- Rename `posix` as `posix_headers` to make it clear the module only
includes headers.
- Makes `posix_*` modules depend on `posix_headers`, thus removing the
explicit `INCLUDES+=...` in `sys/Makefile.include`.
- Ocurrences of `INCLUDES+=...` are replaced by an explicit dependency
on `posix_headers`.
Cenk and I put some effort into making 6LoWPAN work without IPv6; except
for when used with the IPv6 header compression of course. This is why
`gnrc_ipv6` is only really *required* by `gnrc_sixlowpan_iphc` now.
With this change the `gnrc_ipv6` dependency is moved from the
`gnrc_sixlowpan` module to the `gnrc_sixlowpan_iphc` module.
riotboot_hdr enables to partition the internal flash memory
into "slots", each one with a header providing information
about the partition. The concept for now is limited to
firmware partitions, which are recognised by the riotboot
bootloader. In the future the concept might be extended to
represent other content.
Co-authored-by: Kaspar Schleiser <kaspar@schleiser.de>
