BITXBIT: Write Once, Run Everywhere, Power Optimization Recommendations, Frog Sensors in the Wild
TOP OF MIND
Write Once, Run Everywhere
Imagine you’re part of a budding young IoT company. You’ve released your first flagship product about 6 months ago, and now it’s time to start work on version 2, which has largely the same feature set, but improved hardware and maybe a new trick or two. How will you approach the firmware? Will you reuse the same code, maybe with a little refactoring? Or will you start from scratch? Reusing code might seem the obvious choice, but I’d bet 5 dollars that more than a few of you chose the latter.
In order to reuse the same code on two different hardware platforms, it needs to be designed and written in a way that enables that - what engineers call “portable”. There are lots of reasons to write firmware that isn’t portable - the most commonly cited being “I need tight coupling to the hardware for maximum efficiency” and “it takes too long”. (I don’t subscribe to either of these views, but refuting them is for another article ??). Whatever the reason, if code isn’t designed from the beginning to be portable, refactoring it to make it so will take almost as long as reimplementing it from scratch. And this is why so many firmware teams reimplement the same thing over and over again - given that the time and effort required are roughly equal, wouldn’t you rather design and build a system from the ground up than refactor somebody else’s code? I definitely would.
You might have noticed I put “portable” in quotation marks above. “Portable” means different things to different people, and too often code called “portable” actually isn’t. Broadly, true portability requires loose coupling between software components and abstractions over parts of the system likely to change. In the case of an embedded device, the parts of the system most likely to change from version to version are hardware components, and so a good driver model is key to achieving truly portable firmware.
This is one of the reasons why we’re such big fans of Zephyr here at Golioth. Zephyr’s driver model has a steep learning curve, but it’s robust and well abstracted. Once you get the hang of it, writing an application that runs on wildly different hardware platforms becomes astonishingly easy. And Zephyr’s build system and IPC mechanisms like Zbus provide facilities for loosely coupled, independent software components that can be composed into a larger application.
But Zephyr isn’t the only RTOS game in town, and our mission at Golioth is to make it easier for all embedded devices to connect to the Internet. To that end, our Firmware SDK was designed from the ground up to be portable, and it has support for ESP-IDF, Infineon’s ModusToolbox, and Linux. Now, we’re hard at work bringing our first-class Zephyr support into our Firmware SDK so we can reap the benefits of code-reuse across all of our supported platforms. By early next year, we’ll have one SDK that runs everywhere.
?
Sam Friedman,
Lead Firmware Engineer
Golioth Changelog
New Feature ??:
UX Improvements ?:
Recent Posts
Authored by Marko Puric
Authored by Mike Szczys
The Design-For-Hire Ecosystem, Nov 21
Authored by Chris Gammell
领英推荐
IoT News
?From the Community?
The October Ribbit Network Frog Sensor winner Phillip Rench installed his frog on the Astronomical Observatory that he and his wife are building in Maine.?
Here’s what he had to say about it: “The Frog Sensor was super easy to setup and the team was very helpful and responsive to any questions I had. We are using the suite of sensors on the frog to monitor realtime conditions for our 100,000+ fruit trees and plants.”
Upcoming Events?
Jan 24 | TRAINING
Most Popular Content
Authored by Jonathan Beri
Authored by Mike Szczys?
Authored by Mike Szczys
Have questions? Chat with us! Join us over on The Golioth Forums!
Golioth, Inc., 548 Market St, PMB 73345, San Francisco, CA 94104, USA, (650) 550-1953