Custom Board, Custom Zephyr Devicetree (AirTag Session 3)

If you’ve been watching this blog, you’ll know that we have an ongoing webinar series about building a custom “AirTag Clone”, basically a Bluetooth sensor platform/playground that is designed to work with Golioth’s new Bluetooth-to-Cloud capabilities. So far in that series we have done sessions about the background and constraints (session 1) and the hardware design (session 2). We originally thought the next session was going to be about the building of the hardware, but you don’t wait for the hardware to be built in order to start architecting your firmware.

Session 3 of the AirTag series is about constructing the Zephyr devicetree and KConfig files for a brand new ‘product’, and we’re going to bring you along for the ride. Sign up below if you’d like to join the live session or get the recording after the fact.

What is Devicetree

We are no strangers to talking about Zephyr’s devicetree around here, since we use it all the time to create custom configurations of hardware. Overlay files are a way you can change a board configuration at compile time, so it can take an existing product and extend it; say you want to add a new click board sensor to the Aludel Elixir and create a new Reference Design. The overlay file tells the build system to move a pin, enable a new in-tree sensor, or change the default behavior of something like a power regulator. Seriously, we use devicetree all the time.

But because Golioth works with everyone’s custom hardware and doesn’t build and sell our own custom hardware, it’s less common that we need to build a devicetree from the ground up. We’ll be doing that here…and we’ll still model on something like a Nordic Development Kit (like the nRF52840-DK), as a sensible starting point. As in any electronics and embedded project, it’s extremely rare to truly be starting ‘from scratch’.

What is KConfig

KConfig allows you to enable or disable different parts of your system and the capabilities throughout Zephyr. The files containing these directives are another crucial part of any board definition (all of the files required to define a board in Zephyr, see example for nrf52840dk below). Anything with .defconfig or .conf (for the build-specific changes to KConfig symbols) will contain directives to enable different features on the board you’re defining.

In general, we won’t see as much customization needed here, as we will inherit most of this from both the soc element of Zephyr (the files defining the nRF52840 chip), as well as the arch(the files defining the Arm core contained within the soc). The KConfig symbols we need to define are the sensible defaults of this product-level board.

Who should sign up

If you’re a product builder or want to learn more about using Zephyr to create custom hardware, this live session (and the rest of the AirTag Clone series) is probably a good fit for you. It will be live on Friday May 23rd at 2 pm ET, and available on-demand for everyone who is registered.