1.
Zephyr RTOS in
One Hour
Pavel Hübner <pavel.hubner@hardwario.com>
CTO & Co-founder at HARDWARIO

2.
Zephyr RTOS I.
❏ Scalable, secure & safe
❏ Friendly for low-power applications
❏ Designed with IoT projects in mind
❏ Vast range of connectivity options
❏ Integrates with MCUboot bootloader
❏ Encourages portability & code re-usability
❏ Protects investments to your code by
imposing low-maintenance requirements
❏ But there is a learning curve…

3.
Zephyr RTOS II.
❏ Operating system for microcontrollers (minimum = 32 bits)
❏ Inspired by Linux kernel, backed by Linux Foundation
❏ Big vendors: Intel, Facebook, Google, NXP, Nordic Semiconductor, …
❏ Homepage: https://www.zephyrproject.org/
❏ Documentation: https://docs.zephyrproject.org/latest/
❏ GitHub: https://github.com/zephyrproject-rtos/zephyr
❏ 74,000+ commits

4.
nRF Connect SDK
❏ Additional layer on top of the Zephyr RTOS
❏ Provides extra support for nRF5x / nRF91 SOCs
❏ BLE (SoftDevice) stack support, Thread, Matter, …
❏ Maintained only by Nordic Semiconductor
❏ Homepage: https://bit.ly/33pdPT1
❏ Documentation: https://bit.ly/3ndUDyv
❏ GitHub: https://github.com/nrfconnect/sdk-nrf
❏ 13,000+ commits

5.
CHESTER Platform
❏ Configurable IoT gateway for industrial IoT applications
❏ Connectivity (NB-IoT, LTE-M, LoRaWAN, Astrocast, BLE, GNSS)
❏ Extensibility (CHESTER-X, CHESTER-Z, CHESTER-A, …)
❏ Power supply flexibility (LiSoCl2
3.6 V, Li-Ion, 24 VDC
, 230 VAC
, PV panels)
❏ Introduction video: https://youtu.be/YvKjCou68jw
❏ Product homepage: https://www.hardwario.com/chester/
❏ Product manual: https://docs.hardwario.com/chester/
❏ Open platform for HARDWARIO partners with full OEM customization
❏ Applications: Industrial IoT projects

6.
Firmware landscape
BLE
nRF52840
Application
LTE
nRF9160
Serial modem
LoRaWAN
Murata
Serial modem
CHESTER SDK
is for this part
SWD
connector
SWD
connector
SWD
connector

7.
Software stack
Onion-like layering but in a flat folder structure…
Zephyr RTOS
nRF Connect SDK
CHESTER SDK
Your application

8.
Requirements
❏ Basic software development skills
❏ Operating system: Linux, macOS , Windows 10/11
❏ Reasonably fast machine (SSD, CPU, RAM)
❏ CHESTER (developer's edition)
❏ SEGGER J-Link (flashing + debugging)
❏ Recommended: Power Profiler Kit II
❏ Recommended: Visual Studio Code
(though any editor will work)

9.
Software tools
❏ Compiler toolchain - Zephyr SDK 0.15.1
❏ CMake build generator (default build system = Ninja)
❏ Zephyr meta-tool West:
❏ Git repository management (multirepository)
❏ Build invocation
❏ Target flashing
❏ Target debugging
❏ nRF Command Line Tools (nrfjprog + SEGGER tools)
❏ nRF Connect for Desktop - Programmer, Power Profiler,
Toochain Manager, Bluetooth Low Energy, …
❏ nRF Device Manager - Bluetooth scanner + DFU firmware updates over BLE
❏ Bluefruit Connect (iOS / Android) - Shell interaction (through emulated UART)
❏ HARDWARIO Manager (iOS / Android) - Mobile app for CHESTER management
❏ HARDWARIO Monitor (cross-platform desktop app; implementation Qt 6 / C++)
❏ HARDWARIO Command Line Tools

10.
West workspace
❏ Top-most folder contains .west directory
❏ File .west/config points to top-most manifest file
❏ Manifest file defines Git remote, Git projects + their path
❏ Recursive manifest file importing
❏ Definition of project self-placement
in West workspace

11.
Workspace setup
❏ Initialize West workspace: west init
❏ Exploring workspace folder structure…
❏ All top-level folder are Git repositories
❏ Folder chester (SDK repo content):
❏ Folder applications - reference fully-fledged projects
❏ Folder boards - board definitions + DTS
❏ Folder drivers - device drivers following Device Driver Model
❏ Folder dts - Device Tree bindings + overlays
❏ Folder include - include headers (public interfaces)
❏ Folder lib - generic libraries
❏ Folder samples - minimalistic applications for various functions
❏ Folder scripts - helper scripts (also extensions to West)
❏ Folder subsys - independent subsystems (i.e. LTE, LoRaWAN, etc.)
❏ Folder zephyr - contains module.yaml defining basic paths in project

12.
Basic workflow
❏ Define application requirements
❏ Repeat until the state of pure happiness:
❏ Edit source code
❏ Build application: west build (all output is in the build folder)
❏ Flash application: west flash
❏ Interact with the application in HARDWARIO Console / Monitor
❏ Eventually, debug the application: west debug / west attach
❏ Usually access to logging and shell
is very sufficient and traditional debugging is not needed
❏ Deploy application (create Git tag)
❏ Use continuous integration (nRF Connect SDK Docker image)

13.
Build system
❏ Build system generator = CMake
❏ Default build system = ninja
❏ Everything is defined in a
human-friendly CMakeLists.txt
❏ No direct invocation is needed
❏ Execution is handled by west
❏ New directories with CMakeLists.txt
can be conditionally added via:
add_subdirectory_ifdef(CONFIG_SERIAL serial)

14.
Kconfig system
❏ Heritage from Linux kernel
❏ Domain-specific language
❏ Defines existence and relationships
between build-time options
❏ Preprocessing before build
❏ Option selection via <board>_defconfig + prj.conf + optional overlays
❏ Result: autoconf.h full of #define CONFIG_<option> <value>
❏ Force-included into each file in the build
❏ Options should be checked in code via:
❏ #if CONFIG_<option>
❏ if (IS_ENABLED(CONFIG_<option>))

15.
Device Tree system
❏ Heritage from Linux kernel
❏ Domain-specific language
❏ Describes hardware model in a tree-like structure
❏ Zero overhead in target environment
❏ Result: devicetree_unfixed.h
❏ Included via #include <kernel/devicetree.h>
❏ Binding example 1:
const struct device *dev = DEVICE_DT_GET(
DT_PARENT(DT_NODELABEL(node_label)));
❏ Binding example 2:
const struct device *dev = device_get_binding("LABEL");

16.
Zephyr fundamentals I.
❏ Thread manipulation:
❏ Thread object - k_thread
❏ k_thread_init() or K_THREAD_DEFINE()
❏ k_sleep() - mostly used with macros:
❏ K_MSEC(n), K_SECONDS(n), K_FOREVER, …
❏ k_yield()
❏ Workqueue threads
❏ System or dedicated workqueue
❏ k_work_submit()
❏ Atomic services:
❏ atomic_t
❏ atomic_set()
❏ atomic_get()

17.
Zephyr fundamentals II.
❏ Synchronization objects:
❏ Mutex object - k_mutex
❏ Semaphore object - k_sem
❏ Signal object - k_signal
❏ Data passing objects:
❏ FIFO object - k_fifo
❏ Pipe object - k_pipe
❏ Message queue object - k_msgq
❏ Ring buffer object - ringbuf
❏ Object polling:
❏ Wait on event from 1 or more sources
❏ k_poll()

18.
Zephyr fundamentals III.
❏ Mutex services:
❏ K_MUTEX_DEFINE() or k_mutex_init()
❏ k_mutex_lock()
❏ k_mutex_unlock() - never forget…
❏ Pitfall = deadlock
❏ Timer control:
❏ k_timer_init() or K_TIMER_DEFINE()
❏ k_timer_start()
❏ Interrupt context
❏ Critical error:
❏ k_oops()
❏ Watchdog timer is advised to be enabled

19.
Useful tips & tricks
❏ Pristine build: west build -t pristine
❏ Start from clean table: rm -rf build
❏ Start Kconfig wizard (terminal): west build -t menuconfig
❏ Start Kconfig wizard (GUI): west build -t guiconfig
❏ Processed Device Tree: devicetree_unfixed.h
❏ Processed Kconfig output: autoconf.h
❏ Output artifacts: zephyr.hex / zephyr.bin / zephyr.elf
❏ With bootloader: merged.hex / app_update.bin
❏ Build errors from compiler → start from top
❏ Build errors from linker → start from bottom

20.
Logging subsystem
❏ Zero to N backend architecture
❏ Backends: UART, RTT, BLE, …
❏ Logger definition per module
❏ Individual log level - should be passed via Kconfig
❏ Logger module registration:
LOG_MODULE_REGISTER(ctr_lte_if, CONFIG_CTR_LTE_IF_LOG_LEVEL);
❏ Four basic log levels:
❏ Error - LOG_ERR("...")
❏ Warning - LOG_WRN("...")
❏ Info - LOG_INF("...")
❏ Debug - LOG_DBG("...")
❏ Logging macros support full printf-style formatting

21.
Shell subsystem
❏ Zero to N backend architecture
❏ Backends: UART, RTT, BLE, …
❏ Shell-alike interaction with a microcontroller
❏ Command definition in a tree structure
❏ Help navigation is provided
❏ Commands are defined per module
❏ Allows definitions without module cross-dependencies
❏ Several useful built-in commands:
❏ help
❏ kernel threads
❏ kernel stacks
❏ kernel uptime
❏ kernel reboot cold

22.
Settings subsystem
❏ Multiple storage formats:
❏ NVS, LittleFS, FAT, …
❏ Multiple storage media:
❏ Internal flash, NOR flash, eMMC, …
❏ Today: NVS in internal flash
❏ Future: LittleFS + possibility to download file over BLE
❏ No need to change implementation,
just a matter of configuration
❏ Settings handler registered per module
❏ Settings = simple key/value storage
❏ A bit of boilerplate code to enable it on module
❏ Penalty for robustness

23.
Demo

24.
CHESTER DevKit
https://shop.hardwario.com/chester-devkit/
❏ 20% discount - use voucher iotnorth
❏ Voucher valid only until Feb 12, 2023
Meet us in person:
1. Zephyr booth at Embedded World
March 14-16, 2023 in Nuremberg
2. Zephyr Developer Summit
June 27-30, 2023 in Prague