The Zephyr RTOS (Real-Time Operating System) with its hardware abstraction layer is designed for portability between various MCU (Micro-Controller Units) including, but by no means limited too, the Nordic nRF51, nRF91, STM32, ESP32.
The source repository for Zephyr can be found at https://github.com/zephyrproject-rtos/zephyr.
The Zephyr RTOS has good support for the STM32 family, but every now and again you need to access something that is not supported. In my most recent experience, I needed to set the Brown-Out Reset (BOR) thresholds on a STM32WLE5CC. Adding vendor or device specific functions can break Zephyr’s code portability between devices and should only be done as a last resort. Where possible, use Zephyr’s supported API. Documentation The STM32 HAL (Hardware Abstraction Layer) and STM32 LL (Low-Level Drivers) comes bundled as a module with Zephyr. The source can be found on Github at https://github.com/zephyrproject-rtos/hal_stm32 with some basic …
After 18 months developing with the Zephyr RTOS, I’m starting to become a strong proponent. In my opinion, one of the key advantages of the Zephyr RTOS is the hardware abstraction. It allows applications to be written for Zephyr that are platform independent and can be moved between different boards including different manufacturers of microcontrollers. In a world still suffering from chip shortages, it has been a breath of fresh air. The Zephyr application (project) contains the application source code while the board files detail the hardware and GPIO assignment, or essentially, how the printed circuit board is wired. This …
Copyright 2018 - 2025 • Craig Peacock • Adelaide, Australia • Privacy Policy • Cookie Policy