Zephyr Alleviates your Firmware Headaches

COMPONENTS Software Apps and online services

zephyr-project - Zephyr RTOS

x 1

PROJECT DESCRIPTION

Zephyr Alleviates your Firmware Headaches

“But wait!” you cry, “won’t someone think of the firmware?”. Indeed, someone has thought of the firmware. The Linux Foundation shepherds an amazing Real-Time Operating System called Zephyr RTOS that focuses on interoperability across a vast array of processor architectures and families. Even better, it handles the networking stack and has a standardized device model that makes it possible to switch peripherals (ie: sensors) without your C code even noticing.

We use Zephyr to maintain one firmware repository for the Aludel hardware that can be compiled for STM32F40, nRF52840, nRF9160, and ESP32 using your choice of Ethernet, WiFi, or Cellular connections. How is that even possible?

devicetree overlay file for nrf52840
&i2c0 {
bme280@76 {
compatible = "bosch,bme280";
reg = <0x76>;
label = "BME280_I2C";
};
};
 
&spi1 {
compatible = "nordic,nrf-spi";
status = "okay";
cs-gpios = <&gpio0 3 GPIO_ACTIVE_LOW>,
<&gpio0 27 GPIO_ACTIVE_LOW>,
<&gpio1 8 GPIO_ACTIVE_LOW>;
test_spi_w5500: w5500@0 {
compatible = "wiznet,w5500";
label = "w5500";
reg = <0x0>;
spi-max-frequency = <10000000>;
int-gpios = <&gpio0 2 GPIO_ACTIVE_LOW>;
reset-gpios = <&gpio0 30 GPIO_ACTIVE_LOW>;
};
};
 
/ {
aliases {
aludeli2c = &i2c0;
pca9539int = &interrupt_pin0;
};
gpio_keys {
compatible = "gpio-keys";
interrupt_pin0: int_pin_0 {
gpios = < &gpio0 26 GPIO_ACTIVE_LOW >;
label = "Port Expander Interrupt Pin";
};
};
};

Zephyr uses the DeviceTree standard to map how all of the hardware is connected. A vast amount of work has already been done for you by the manufacturers who maintain drivers for their chips and supply .dts (DeviceTree Syntax) files that specify pin functions and mappings. When writing firmware for your projects you supply DeviceTree overlay files that indicate sensors, buttons, LEDs, and anything else connected to your design. The C code looks up each device to receive all relevant information like device address, GPIO port/pin assignment and function.

accessing abstracted weather sensor in c
const struct device *weather_dev = DEVICE_DT_GET_ANY(bosch_bme280);
sensor_sample_fetch(weather_dev);
sensor_channel_get(weather_dev, SENSOR_CHAN_AMBIENT_TEMP, &temp);
sensor_channel_get(weather_dev, SENSOR_CHAN_PRESS, &press);
sensor_channel_get(weather_dev, SENSOR_CHAN_HUMIDITY, &humidity);

The hardware abstraction doesn’t stop there. Zephyr also specifies abstraction for sensors. For instance, an IMU will have an X, Y, and Z output — Zephyr makes accessing these the same even if you have to move to an IMU from a different manufacturer due to parts shortages. You update the overlay files for the new build, and use a configuration file to turn on any specific libraries for the change, but the code you’re maintaining can continue on as if nothing happened.

Of course there are caveats which we cover in the talk. There is no one-size-fits-all in embedded engineering so you will eventually need to define your own .dts files for custom boards, and add peripherals that are unsupported in Zephyr. This is not a deal breaker, there is a template example for adding boards (and I highly recommend watching Jared Wolff’s video on the subject). And since Zephyr is open source, your customizations can be contributed upstream so others may also benefit.

Documents

Comments Write