Summary
This year at NervesConf I covered three key topics that people should have in mind when developing a product with Nerves:
- What Nerves firmware is and how it is architected
- Helpful tooling for building Nerves firmware
- How to resource a Nerves firmware development team
First, I explained the typical structure of a Nerves product, focusing on the dual-layer architecture involving the Nerves application and the Nerves system. The Nerves application encompasses business logic and cloud connectivity, leveraging Elixir's strengths of fault tolerance and reliability. Meanwhile, the Nerves system deals with the hardware layer, involving Linux, the bootloader, and drivers. Official Nerves systems are available as a starting point for hobby and small-scale commercial projects. One drawback for some is that the official Nerves systems are very raspberry-flavored, which doesn't scale well for the products we build at Redwire Labs. I recommended alternatives like the BeagleBone Black (TI AM335), Microchip SAMA5D27, and Texas Instruments AM62. These processors are available in a wider range of options, including single board computer (SBC), system on module (SOM), system on chip (SOC), and discrete microprocessors. These options offer more flexibility when going from prototype to production, allowing you to fine-tune the tradeoff between BOM (bill of materials) cost and NRE (non-recurring engineering) cost.
Second, I covered practical tools and strategies for Nerves development. One key tool is Resolve, which streamlines dependency injection and enables flexible testing and deployment across different hardware configurations. This flexibility is crucial for shortening development cycles and decoupling from any specific hardware target, allowing the firmware to run on the development computer, development kit, prototype PCB, and production device. The firmware can move across hardware platforms throughout the development cycle. This also allows a CI server like CircleCI or GitHub Actions to run automated unit tests without hardware being present.
Speck is a library for input validation, designed to be lightweight and document protocols. This is particularly useful for embedded systems. The protocol description language, although written in Elixir, is for engineers from other languages to understand. This happens when the firmware and web development teams can't share the same programming language throughout the stack. Speck's architecture is thin and minimal, inserting itself only between the system's raw input and the business logic. This simplifies the system and avoids lock-in to how the system stores data.
I also discussed several storage solutions for Nerves embedded systems, outlining a progression from simple file system storage to more complex options like Property Table, CubDB's no-SQL database for embedded systems, and the lightweight relational database SQLite. Each storage solution has its tradeoffs and is suitable for varying levels of complexity and performance requirements. Rather than jumping straight to a relational database, I recommend developers prefer the options on the left, moving to the right only as they determine the capabilities of a storage solution doesn't meet their needs.
Finally, I discussed how to resource a Nerves firmware team. I wrote about this a few years ago in Cross-Cutting Elixir In Teams, and have learned an important lesson since then. It is tempting to resource Elixir web developers on a Nerves firmware project because the language is the same. However, this overlooks domain knowledge: the frontend engineer doesn't know how to read a datasheet.
Now I look for true "full stack" engineers when resourcing: someone who can span the stack from web to firmware. The catch is these people are few and far between, so it can't be the only resourcing strategy. At GridPoint I trained their team of C++ firmware developers into Elixir & Nerves, and the programming language learning curve was easier to overcome than the domain knowledge learning curve. Cross-training C/C++ engineers can be a viable way to build a Nerves firmware development team. And finally, getting help from a product development firm can be a great way to avoid the common mistakes in developing a product with Nerves, without having to rush to build your team in-house.
Strategies for success:
- Resource “full stack” engineers
- Cross-train C/C++ engineers to Elixir
- Hire a product development firm
SHARE