Building Custom Device Tree Overlays for Nerves: A BeagleBone Cape Guide
If you’ve ever built a Nerves firmware image for a BeagleBone-family board, you’ve probably run into device tree overlays — the mechanism the kernel uses to describe hardware that isn’t already baked into the base board support. Overlays are how you tell Linux “there’s a device on this SPI bus,” “this pin is now a GPIO instead of a UART,” or “there’s a sensor on this I2C address.” They’re small, they’re declarative, and when they work, you never think about them again.
Structuring Production Nerves Applications with Umbrella Apps
Most Nerves projects start as a single Mix project — a handful of modules, maybe a GenServer or two, one `mix.exs`. That’s the right way to start, and it stays fine for a long time. It stops being fine once the device grows a graphical UI, its own firmware update logic, and a few different hardware interfaces all running at once. At that point, a bug in your UI rendering code shouldn’t be able to take GPIO control down with it, and “how the device boots and recovers” needs to be a different concern from “what the device does once it’s running.” A single flat application makes both of those hard to guarantee.
