Pavel Hübner (from HARDWARIO) will provide a crash course into the Zephyr RTOS. Zephyr is an innovative operating system targeting 32-bit microcontrollers and is suitable for connected IoT products. Such devices are often low-power and provide a multi-year battery lifespan. The ambitious 60-minute live session with be held on a configurable IoT gateway CHESTER - a platform based on Nordic Semiconductor SoCs nRF52840 / nRF9160. Throughout the course, Pavel will go from the key Zephyr fundamentals to connecting a fully-fledged IoT application over the NB-IoT network.
Call Girls in Nagpur Bhavna Call 7001035870 Meet With Nagpur Escorts
Zephyr RTOS in One Hour | HARDWARIO @ IoT North UK
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
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
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