Dakota Boin on Strategic Firmware Development
Highway1's onboard computing expert talks embedded systems
If you’re a Highway1 startup, you aren’t in the business of making dumb devices: everything you make needs a battery and a circuit board. But how do you design that circuit board, much less write the code for the tiny chips that go on it? Highway1 firmware engineer Dakota Boin gave a talk illuminating some of the finer strategic points of firmware development, after which we sat down to pick his brain.
HWY1: You talked a bit about writing firmware on what basically amount to emulators running on desktop computers; are there any gotchas to doing your development that way?
DB: Yes. You should still be writing code as if it were to run on an embedded system. The final product is going to be resource-constrained, so you can’t just brute-force an algorithm. The PC is just there to speed up the development process; it doesn’t make your IoT device run faster.
You also talked about the value of having a development version of your PCB design fabricated for debugging and testing; given that those tend to be one-offs, how would a startup get them made without running up exorbitant costs?
There are batch and low-cost PCB services that’ll allow you to run as few as three; it might take a week or two, but it’s at a significantly reduced cost. In fact, someone just pointed me to a service that only takes seven days, only charges a dollar per square inch, and can deliver a single board. They put your design with a dozen others and fab them all at once, so for them, it’s not the same cost as making a true one-off, which can be quite expensive. Services like these can help you reduce costs dramatically for making custom boards of that type.
What are the most common problem areas you’ve seen startups run into when it comes to firmware development?
All issues are going to be specific to your application; I just talked to someone who was running out of memory on their device, but power is another common concern. I think the biggest issue people run into is their own expectations of their systems: battery life wouldn’t be a problem if you expected your battery to last a day rather than six months. All the constraints on a system are basically imposed by you, so you either have to be flexible with your expectations or rigorous with your approach to validating them.
Is there a good way to come up with said expectations?
Product requirements documents (PRDs) are something we encourage people to write early and edit often. People will sometimes come to Highway1 with an idea, but they don’t actually document what that idea is — they just have a feeling that, say, the battery should last a long time. Well, how long is that, exactly? If you decide your battery has to last six months, then what else are you flexible on? Is the size of the device something you can mess with? You could just add a really big battery and make your wrist-worn wearable the size of your forearm — that’d solve your battery concerns! You need to be flexible and understand that there are tradeoffs inherent in your requirements, and the best way to find out what they are is to write them down, and do it as early as possible.
Is there a way to estimate the amount of work a device will take to design based on what it is?
[chuckles] That’s a great question: not really. Anybody who’s done even a little bit of engineering can give you one of two different types of estimates:
- “I’ve done that before, and it’ll take me X amount of time.”
- “I’ve not done that before, but I can tell you it won’t take me less than X amount.”
You can take an educated guess, but mostly it comes down to how complex and rigid your requirements are. Most things can be done within the laws of physics; the question is just how much hand tuning and specialized code or hardware it’ll take to make what you want to make, plus it takes a lot of effort to make sure it’ll be developed correctly.