# Zephyr and SmartMesh IP - Happy Together

Fabian Graf, Michael Villnow, Thomas Watteyne

## ► To cite this version:

Fabian Graf, Michael Villnow, Thomas Watteyne. Zephyr and SmartMesh IP - Happy Together. EWSN 2025 - 22nd International Conference on Embedded Wireless Systems and Networks, ACM, Sep 2025, Leuven, Belgium. hal-05279725

HAL Id: hal-05279725

https://inria.hal.science/hal-05279725v1

Submitted on 23 Sep 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Demo: Zephyr and SmartMesh IP - Happy Together

Fabian Graf

Michael Villnow

Thomas Watteyne

Siemens AG

Siemens AG

Inria

Erlangen, Germany

Erlangen, Germany

Paris, France

fabian.graf@siemens.com

michael.villnow@siemens.com

thomas.watteyne@inria.fr

## ABSTRACT

The Zephyr RTOS has seen significant traction in recent years, particularly in embedded and IoT applications. This paper demonstrates the use of the SmartMesh IP networking functionality in Zephyr through a dedicated networking chip connected via UART. Our analysis across different platforms shows minimal resource requirements, with the complete solution requiring about 30 kB of ROM and 8 kB of RAM.

## CCS CONCEPTS

* Hardware → Wireless devices; Wireless integrated network sensors;

* Networks → Programming interfaces; Software and its engineering → Embedded software.

## KEYWORDS

Zephyr, SmartMesh IP, 6TiSCH, Internet of Things

## 1 INTRODUCTION

The Zephyr Real-time Operating System (RTOS) has seen a heavy increase in popularity in recent years, particularly among developers of embedded systems and Internet of Things (IoT) devices [1]. This interest is largely driven by Zephyr's lightweight, modular design, which allows it to run efficiently on resource-constrained hardware while still offering robust support for networking, security, and real-time performance. Zephyr is developed under the auspices of the Linux Foundation and also relies on the device tree as hardware description format. This allows Zephyr to describe hardware in a standardized, declarative way, enabling portability and simplifying board configuration across many different microcontroller units (MCUs).

When selecting an MCU platform, developers must consider various factors including cost, memory capacity, peripheral options, and connectivity features. In this paper, we demonstrate how to couple the networking aspect from this decision-making process by integrating a dedicated networking chip through a Universal Asynchronous Receiver/Transmitter (UART) interface. As illustrated in Fig. 1, this solution enables a MCUs like the MAX78000, known for its embedded AI features but lacking native wireless capabilities, to be seamlessly integrated into a wireless network. We utilize the LTC5800 networking chip, which implements the SmartMesh IP network stack. SmartMesh IP is an ultra low-power radio protocol that implements IPv6 over the Time-Slotted Channel Hopping (TSCH) mode of IEEE802.15.4e (6TiSCH) [2, 4]. As the de facto standard for Wireless Personal Area Networks (WPANs), IEEE802.15.4's TSCH mode achieves remarkable end-to-end delivery ratios exceeding 99.999% while offering multi-year battery life [5].

<figure><img src="image_2.png" /><figcaption>Figure 1: Setup with MAX78000 and SmartMesh IP Mote.</figcaption></figure>

SmartMesh IP provides comprehensive open-source libraries. The SmartMesh IP C-Library (C-Lib) offers an Application Programming Interface (API), which manages the UART communication between the application and the networking chip. Building upon this foundation, the QuickStart Library (QSL) implements a Finite State Machine (FSM) that simplifies complex operations. This abstraction layer handles the majority of application logic, allowing developers to only utilize a minimal set of APIs for network connectivity and data transmission.

This demo paper demonstrates the implementation of these libraries within the Zephyr ecosystem, highlighting the straightforward portability across all Zephyr-supported platforms in Section 2. Additionally, we present a detailed memory footprint analysis in Section 3, emphasizing the minimal resource requirements of these libraries. The related source code is available on GitHub<fnref n="1" />.

## 2 USING SMARTMESH IP IN ZEPHYR

The complete setup of this demo is shown in Fig. 2. An arbitrary MCU supporting Zephyr is connected as application chip via UART to the networking chip running the SmartMesh IP stack. This networking chip establishes a wireless connection to the SmartMesh IP manager which is connected via USB to a gateway device.

The Zephyr application running on the application chip is relying on the CMake build system. Thus, the QSL and C-Lib need to be included into the top-level CMakeLists.txt. As such, the QSL can be embedded into a dedicated Zephyr thread. Inside this thread, the QSL is initialized and the FSM is kicked off by the dn_qsl_connect function. This function takes arguments allowing to join a specific network ID with a certain join key. Furthermore, the desired bandwidth can be requested. The SmartMesh IP manager can serve about 36 packets/second for receiving data from all motes combined. For instance, in a 6-mote network, each mote should not exceed 6 packets/second. Data transmission is handled through the

<footnote n="1">¹ https://github.com/fabiangraf96/sm_zephyr.git</footnote>
<figure><img src="image_3.png" /><figcaption>Figure 2: Schematic Setup and Software Blocks.</figcaption></figure>

dn_qsl_send() function, which transfers the payload to the net-
working chip for wireless transmission. Due to IEEE 802.15.4 frame
limitations of 128 B and necessary header overhead, the maximum
payload size is restricted to 90 B per transmission.

The payload transfer occurs over UART, requiring modifications to the dn_uart.c file. Zephyr's device tree model significantly simplifies this porting process through its *nodelabels* concept, which allows straightforward UART peripheral selection. Furthermore, customizing the default UART configuration is streamlined through platform-specific device tree overlay files. Payload reception is also handled within dn_uart.c. An interrupt service routine leverages Zephyr's UART API to promptly store incoming bytes into a circular ring buffer. A dedicated UART thread then periodically retrieves these bytes from the ring buffer and forwards them to the High-Level Data Link Control (HDLC) layer.

3 MEMORY FOOTPRINT ANALYSIS

Memory utilization analysis can be performed using Zephyr's west build system by appending the `-t rom_report` target to the build command (analogously for RAM). The results for three different platforms are shown in Fig. 3 and reveal a similar memory footprint of around 30 kB of ROM and 8 kB of RAM. While the Zephyr OS including kernel and drivers and the Hardware Abstraction Layer (HAL) is already very small, the overhead by the QSL and C-Lib is also not large and suggests adoption in memory-constrained MCUs.

A closer inspection of the memory breakdown reveals that the QSL contributes only a modest increase in ROM usage, primarily due to its FSM logic and abstraction layers. The C-Lib, responsible for UART communication and HDLC framing, adds a similarly small footprint. Together, these libraries remain well within the constraints of typical low-power MCUs.

Moreover, the consistent memory usage across heterogeneous platforms demonstrates the portability and scalability of the solution. This uniformity is largely enabled by Zephyr's modular architecture and its device tree system, which abstracts hardware-specific configurations.

4 CONCLUSION AND FUTURE WORK

In this demo paper, we show the integration of SmartMesh IP
into Zephyr, and analyze the resulting memory footprint. A ba-
sic Zephyr OS requires only around 10 kB of ROM and the li-
braries required for SmartMesh IP integration draw another 8 kB.

<figure><img src="image_4.png" /><figcaption>Figure 3: ROM and RAM size of firmware.</figcaption></figure>

This approach enables resource-constrained MCUs to gain robust
wireless networking capabilities. Future work includes evaluat-
ing the MAX32655 as a networking chip, which incorporates the
SmartMesh 2.0 stack [3], utilizing Bluetooth rather than IEEE 802.15.4.

ACKNOWLEDGMENTS

This document is issued within the frame and for the purpose of
the OpenSwarm project. This project has received funding from the
European Union's Horizon Europe Framework Programme under
Grant Agreement No. 101093046. Views and opinions expressed are
however those of the author(s) only and the European Commission
is not responsible for any use that may be made of the information
it contains.

REFERENCES

[1] Eclipse Foundation. 2024. 2024 IoT & Edge Developer Survey. https://iot.eclipse.org/community/resources/iot-surveys/.

[2] IEEE Computer Society. 2024. IEEE Standard for Information technology – Local and metropolitan area networks– Specific requirements– Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low Rate Wireless Personal Area Networks (WPANs). IEEE Std 802.15.4-2024 (Revision of IEEE Std 802.15.4-2020) (2024), 1–967.

[3] Luiz Sampaio, Kate O'Riordan, Dara O'Sullivan, Brian Coffey, Lance Doherty, and Thomas Watteyne. 2024. Running SmartMesh on the MAX32655 with MicroPython. In *Annual Conference of the IEEE Industrial Electronics Society (IECON)*.

[4] Pascal Thubert. 2021. An Architecture for IPv6 over the Time-Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH).

[5] Thomas Watteyne, Lance Doherty, Jonathan Simon, and Kris Pister. 2013. Technical Overview of SmartMesh IP. In *Int. Conference on Innovative Mobile and Internet Services in Ubiquitous Computing*. 547–551.