Having covered the Devicetree basics in the previous article, we now add semantics to our Devicetree using so-called bindings: For each supported type, we’ll create a corresponding binding and look at the generated output to understand how it can be used with Zephyr’s Devicetree API. Notice that we’ll only look at Zephyr’s basic Devicetree API and won’t analyze specific subsystems such as gpio in detail.

In the previous article, we configured software using the kernel configuration tool Kconfig, and we’ve silently assumed that there’s a UART interface on our board that is configurable and used for logging. In this third article of the “Practical Zephyr” series, we’ll see how we configure and use hardware. For this, Zephyr borrows another tool from the Linux kernel: Devicetree.

In this second article of the “Practical Zephyr” series, we’ll explore the kernel configuration system Kconfig by looking at the printk logging option in Zephyr. We won’t explore the logging service as such in detail but instead use it as an excuse to dive deep into Kconfig. Finally, we’ll create our own little application-specific Kconfig configuration. Like Interrupt? Subscribe to get our latest posts straight to your inbox.

Recently we ran through a re-vamp of our CI builds targeting the Nordic nRF-Connect SDK, and I wanted to share some of the things we learned along the way! This article walks through setting up a GitHub Actions workflow for building nRF-Connect SDK projects. Like Interrupt? Subscribe to get our latest posts straight to your inbox.

This is the start of a new article series about Zephyr’s basics: It will walk you through Zephyr’s build and configuration systems West, Kconfig and devicetree.

Logging on embedded devices comes with a host of interesting and unique challenges that aren’t found on servers — devices are generally more memory, bandwidth, space, and CPU constrained, and devices often take weeks, months, or years to update, rather than days or hours.

Cellular devices and networks have come a long way, from brick phones and Blackberrys to iPhones and Google Pixels. In addition to being the ubiquitous connectivity protocol that keeps the Internet at our fingertips at all times, LTE is appearing in IoT products across all industries.

As the first segment of a three-part series on JTAG, this post will give an overview of JTAG to set up some more in-depth discussions on debugging and JTAG Boundary-Scan. We will dive into the intricacies of the interface, such as the Test Access Port (TAP), key registers, instructions, and JTAG’s finite state machine. Like Interrupt? Subscribe to get our latest posts straight to your inbox.

If you’ve ever wanted to plot data acquired on your embedded target, this article is for you. It explores common use cases for real-time data visualization using STMViewer. Say goodbye to manual, time-consuming, and error-prone data collection and display methods to speed up your debugging process.

The first step to making reliable IoT devices is understanding that they are inherently unreliable. They will never work 100% of the time. This is partially because we firmware engineers will never write perfect code. Even if we did, our devices need to operate through various networks and gateways, such as cellular modems, mobile phone Bluetooth applications, Wi-Fi routers, cloud backends, and more, and each of these may introduce unreliability.