Zephyr RTOS adds GNSS satellite support
The latest version of the Zephyr open source real time operating system (RTOS) now includes support for GNSS satellite modems and link time code optimisation.
Zephyr 3.6.0 marks the eighth anniversary of the project with 538 contributors for this release alone.
Zephyr, part of the Linux Foundation, is designed to be small, scalable, and secure. It is used to build products in a wide range of industries, from consumer electronics to industrial automation, and from medical devices to smart agriculture.
Zephyr 3.5 introduced a generic infrastructure for implementing modem drivers to simplify the implementation of the code associated with crafting the commands and parsing the responses when chatting with a modem. This has been the foundation for other devices using similar communication interfaces, such as GNSS (Global Navigation Satellite System) receivers. Zephyr 3.6 introduced a new GNSS subsystem, built on top of the modem subsystem, that provides a way to easily integrate GNSS receivers into your Zephyr application.
Virtually any GNSS receiver using the NMEA 0183 protocol is supported and can easily be configured via Devicetree, with an equally easy way to declare what callbacks in the code should be invoked when a new fix/location is available.
Zephyr also now supports keyboard matrices, with a direct integration with the input subsystem.
A keyboard matrix is a way to connect a large number of keys to a microcontroller using a small number of pins (typically one pin per row and one pin per column in the matrix). A new GPIO keyboard matrix driver has been added and supports a large variety of keyboard matrix hardware configurations, with support for both polling and interrupt-based scanning.
Maureen Helm from Analog Devices and Henrik Brix Andersen from Vestas were the release managers for Zephyr 3.6.
”As my first time serving as release engineer, it was amazing to witness the full community come together, collaborating to provide yet another high-quality release of the Zephyr RTOS.
It never ceases to amaze me that a community as diverse as ours, scattered among a large number of companies and individuals, still manages to work coherently on everything from bug fixes, exciting new features, tooling and documentation improvements,” said Helm.
“One of my personal favorites of this release is the shift from native_posix to native_sim as the default, native test platform. The native_sim platform allows compiling against embedded C-libraries instead of using the host’s C-library, which brings tests much closer to how Zephyr applications are usually built and deployed.”
“Another exciting, new feature is the introduction of a MIPI Display Bus Interface (DBI) driver class. While we’ve only just seen the very first display driver migrated to use this new driver class, I trust we will see much more of these conversions towards v3.7.0 and hopefully even more displays supported by Zephyr in future releases,” she said.
”It’s exciting to see every Zephyr release get bigger than the one before, but with that growth comes additional complexity in coordinating releases. The introduction of an experimental merge queue to identify which pull requests satisfy merge criteria (and which ones don’t) was a game changer for the release team. The documented policy of requiring assigned maintainer approval and minimum time under review has historically been difficult to enforce, but now we can more easily find pull requests that satisfy these requirements and merge them sooner,” said Andersen.
“In this release, we merged almost 3x as many commits compared to my first release serving as release manager!”
Link-Time Optimization (LTO)
While a Zephyr application typically ends up being packaged as a single binary, it is made up of a large number of intermediate object files, from application code, to the Zephyr kernel, HALs, and all other modules the application depends on. Link-Time Optimization (LTO) is a compiler feature that allows the compiler to optimize the entire program at link time, rather than just the object files individually. This can lead to significant performance and code size improvements.
The Linkable Loadable EXTensions (LLEXT) introduced in version 3.5 now adds a CMOAKE instruction. LLEXT is a new way to dynamically load and execute binary code from a Zephyr application. While updates to an embedded application are often done by re-flashing the entire application, LLEXT provides a way to load and unload code modules at runtime, which can come in handy for a variety of use cases. This can be used for updating a TinyML model or deploying updates to a GUI.
Under the hood, an LLEXT extension is nothing more than a relocatable ELF file, which the LLEXT subsystem can parse and load into memory. In order to make the generation of LLEXT extensions easier, a new CMake extension, add_llext_target(), has been introduced. Alongside other helpers and macros, this helps developers expose and package functions in the form of LLEXT modules, and have them built as part of the Zephyr build system they are used to.
When building a Zephyr application, developers can now choose to build it as a user space application, which means that the application will run in a separate memory space from the kernel. This helps to isolate the application from the kernel, and to ensure that a bug in the application—or a malicious application—cannot access or corrupt the kernel objects or memory.
User space mode is already supported on a variety of architectures via the MMU (Memory Management Unit) and MPU (Memory Protection Unit) hardware features. Zephyr 3.6 added support for user space on the Xtensa controller architecture. It is using MMU only at the moment, but MPU support for Xtensa is shaping up.
SBOM
Zephyr’s build system includes a tool to help generate the Software Bill of Materials (SBOM) for a Zephyr application. The SBOM is a list of all the software components that are used in a given application, and is a key part of the software supply chain security.
Ahead of the next Long-Term Support (LTS) release of Zephyr coming out later this year, work has been done in the 3.6 version to augment the SBOM with the list of Zephyr modules making up an application, and they are now properly captured as “packages” during the SPDX generation.
The 3.6 release also adds a new C++ code sample to help developers get started. The Hello C++ World” code sample is a reminder that Zephyr is not just for C developers says the project.
github.com/zephyrproject-rtos/zephyr/releases/tag/v3.6.0
If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :
