In the previous articles, we used freestanding applications and relied on a global Zephyr installation. In this article, we’ll see how we can use West to resolve global dependencies by using workspace applications. We first explore West without even including Zephyr and then recreate the modified Blinky application from the previous article in a West workspace.

April marked the return of the Embedded Open-Source Summit, this year in Seattle. I was lucky enough to be able to attend and split my time between the Memfault booth in the exposition hall and many of the captivating presentations. Since the videos have just been published on the the Linux Foundation’s YouTube account, we thought it would be a good time to highlight some of the talks and give you a quick summary which will, hopefully, inspire you to go watch them!

Earlier this month, I had the pleasure of traveling to Nuremberg, Germany to attend Embedded World. If you have not heard about it before, Embedded World1 is the largest trade show in the embedded systems industry. This year, over 35,000 people attended and 1,100 businesses exhibited at the Nuremberg Messe.

In the previous articles, we covered Devicetree in great detail: We’ve seen how we can create our own nodes, we’ve seen the supported property types, we know what bindings are, and we’ve seen how to access the Devicetree using Zephyr’s devicetree.h API. In this fifth article of the Practical Zephyr series, we’ll look at how Devicetree is used in practice by dissecting the Blinky application.

In the previous article of this series, we briefly touched on how.bsd files written in Boundary Scan Description Language (BSDL) describe the structure of the boundary scan chain and the instruction set. In this article, we will examine this language’s syntax more closely before seeing how.bsd files are leveraged in JTAG testing in the next article.

In the third installment of this JTAG deep dive series, we will talk in-depth about JTAG Boundary-Scan, a method used to test interconnects on PCBs and internal IC sub-blocks. It is defined in the IEEE 1149.1 standard. I recommend reading Part 1 & Part 2 of the series to get a good background on debugging with JTAG before jumping into this one!

Have you ever wondered if ELF is portable between 32-bit and 64-bit targets? Probably not, but this might be a common scenario for you if you work on 32-bit embedded devices but use a 64-bit host. Or maybe you’ve developed tooling for 32-bit MCUs and are transitioning to working on 64-bit targets. The ELF object file format is one of the most commonly used today. Most build systems provide an output to this format, and ELF is commonly used to output coredumps.

As noted in my previous article Diving into JTAG protocol. Part 1 — Overview, JTAG was initially developed for testing integrated circuits and printed circuit boards. However, its potential for debugging was realized over time, and now JTAG has become the standard protocol for microcontroller debugging. Many Firmware and Embedded engineers first encountered it in this particular context.

With the number of wireless SoCs on the market, “Just add connectivity” is finally a reality! “Just” does a lot of lifting in that phrase. Connectivity, whether wired or wireless, adds numerous layers of complexity to your device. Treating your connectivity as a black box early in development is easy, but this strategy will implode when thousands of devices enter the field - trust me, I know. It’s not enough to test from end to end a few times in the office.

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.