Dear RIOT community,
we are delighted to announce that version 2022.10 of RIOT has been released. A detailed log of changes, as well as a short introduction to the project, can be found in the release notes , and downloads are available through GitHub .
Given that no of the API changes are breaking user facing API changes and that some bug fixes relevant for security or correct operation have accumulated, an update is highly recommended.
Below you find a the list of highlights from the release copied verbatim from the release notes.
Leandro, Marian and the RIOT developer community
The GNRC network stack has received a number of security fixes. All users of GNRC are advised to update to the new release. Given that no user facing breaking API changes are included, we are hopeful that the update is painless and quickly possible.
RIOT has been ported to the ESP32-C3, ESP32-S2, and the ESP32-S3 MCUs. In addition driver support for the integrated BLE transceiver of the ESP32 MCUs has been added.
While the CI is developed in an independent repository, it is still a noteworthy change that our CI software, Murdock, was updated since the last release. In addition to changes under the hood the web front end got a major revamp. You will directly notice the improvements in page load time and clarity/structure of the interface. If you haven’t already, please check out https://ci.riot-os.org to take a look.
If a shared resource guarded by a mutex is used by a high priority and a low priority thread, the high priority thread may end up waiting on the low priority thread to return the resource. If medium priority threads now interrupt the low priority thread while working with the shared resource, the high priority thread ends up waiting on both medium and low priority threads. This effect is called priority inversion.
Priority inversion can in most cases be solved by carefully assigning priorities
and resources. In some cases however, this cannot be avoided: Let’s consider
a scenario in which an I2C temperature sensor and an I2C IMU are used. Since
temperature changes are slow in frequency, the temperature readings are
assigned the lowest priority, while the IMU readings are assigned the highest
priority. The sensible approach here is to have both sensors on distinct I2C
buses. However, if e.g. only a single I2C bus is available by the hardware
priority inversion cannot be prevented by careful resource and priority
assignment alone. In these cases the module
can be used to lend the low priority thread the priority of the high priority
thread while the high priority thread is waiting for the mutex hold by the
low priority thread.
While RIOT has longstanding USB support for many STM32 MCU families, the F1 family was not supported due to some peculiarities in the memory layout. The driver has now been extended to handle them correctly. With this, the popular STM32F103 bluepill board now supports stdio via USB, which however still has to be manually enabled e.g. by:
USEMODULE=stdio_cdc_acm BOARD=bluepill make -C examples/default
Just add an
export DOCKER=podman to your
~/.bashrc, or …)
make BUILD_IN_DOCKER=1 will use podman instead of
docker to run the RIOT build container. Two major advantages of using
docker is the support of rootless containers and not depending on a
central background daemon.
The nRF52 MCUs have a limited number of combined I2C/SPI peripherals. Previously, each such peripheral could either provide a single I2C or a single SPI bus. A board configuration that used the same combined peripheral to provide both an SPI and an I2C bus previously resulted in bad surprises at run-time.
The I2C/SPI drivers have now been reworked so that they can be shared in round-robin fashion between multiple I2C and SPI buses. This is especially useful for the upcoming support of the Bangle.js 2 watch that uses more I2C buses than combined I2C/SPI peripherals available on the used nRF52840 MCU.
Thanks to the sharing of peripherals, all I2C buses can now be provided by a single peripheral.
Many fixes for compilation and runtime issues that only started to surface with GCC 12.2.0 have been fixed. This allows our users to confidentially choose the current release with little to no fear that toolchain updates in the near future will break the precious projects. In addition, we hope that the next CI update will also cause less friction.