I believe the cross-platform abstraction provided by ZephyrRTOS is a very important feature. Of course, the abstraction itself also brings a more complex software architecture and a steeper learning curve.
Recently, I tried to use the nRF52840 to create a low-power Bluetooth + LTE + GNSS board. Initially, the distributor lent me an nRF52840 DK, which I used for a while before returning it. Now I only have an nRF5340 DK along with a shield I developed. Recently, I made a new sample, still using the nRF52840 + LTE module.
Therefore, my application needs to support three boards. Thanks to Zephyr RTOS’s cross-platform abstraction capability, the code of my application itself remains unchanged; I only modified the overlay layer for different boards. Let’s see how I did it.
During the development phase, I used three peripherals: debug UART for log output; LTE UART for communication with the LTE module; SPI for operating and reading the IMU.
DEBUG UART
For nRF52840DK and nRF5340DK, since they are officially supported boards, I set up a serial connection to the onboard JLink’s virtual serial port:
# zephyr/boards/arm/nrf52840dk_nrf52840/nrf52840dk_nrf52840.dts
# zephyr/boards/arm/nrf5340dk_nrf5340/nrf5340_cpuapp_common.dts
Thus, after configuring printk or logging in Kconfig, these outputs will be sent through uart0.
LTE UART
For both nRF52840DK and nRF5340 DK, I use uart1 as the LTE UART. By creating a directory named boards in the application root directory and placing a file with the board name and overlay as the extension in the boards directory, I can override/add new configurations to the original board’s devicetree definitions.
My extended board interface definitions
Corresponding modification of the nRF5340 DK overlay
# lte_tracker/boards/nrf5340dk_nrf5340.overlay
Here, by defining
aliases { uart-lte = &uart1}we can directly access this device in the Zephyr program through the