Many of the developers we talk to are “hardware-curious” – they own a few breadboards, and there’s a soldering iron somewhere in their garage – but they have yet to make something other than a weekend hack or a toy project.
In this post we’ll talk about one of the biggest reasons why hardware projects get stuck in the prototyping process, and how you can completely transform how you produce hardware projects by leaning into the software side of product development.
Physically transferring updates
There are many reasons why hardware projects get stuck in the prototype phase, and a big one is the process of “flashing”: in order to update the software that runs on your hardware (a.k.a. “firmware”), you have to manually plug the board into your computer and transfer the files. Many of the prototyping kits use this workflow, which limits the impact of the end-product.
Flashing is a big reason why updating physical devices is a huge headache: you need to be co-located with the device, physically plugging it in and often pressing a button at the same time as flashing. Unless you want to recall your entire fleet of devices and erode customer trust, your next available option is to publish a list of known bugs until you ship the next version.
For a large fleet of devices, say in agriculture, manufacturing, or facilities management, flashing is an unsustainable workflow.
Enter the world of OTA
“Over the air” updates (“OTA”) offer the ability to update the firmware on embedded devices without having to physically plug them in. Strategically, OTA updates make it possible for hardware folks to monitor and maintain a fleet of devices: it’s critical for scale.
This process looks a lot like installing updates on your computer or phone:
1.) You download the files from the cloud or network
2.) The device can replace the old firmware with the new
3.) and the device automatically Reboot the device
4.) And you start running the new code
This process mirrors the continuous deployment workflow that’s standard for the world’s best software development teams. In fact, deployment frequency is one of Google’s DevOps Research and Assessment metrics for the highest-performing engineering organizations.
End users benefit from up-to-date security patches, bug fixes, and performance enhancements, without waiting for the next generation of software. Everyone wins.
Why doesn’t every device use OTA?
At the moment, setting up and maintaining this workflow still poses a challenge for firmware development teams. We’re working on tooling to make this faster, easier, and in-line with modern software development practices.
While we’re currently in Private Beta, sign up below to be granted access in the future.