The tech industry is constantly changing. New languages come in and out of style, and new WYSIWYG editors make GUI design easier than ever. Unlike app development and IoT, the embedded world has been largely isolated from these changes until now. Code for embedded devices is still written in C or occasionally C++, and the embedded software development cycle is still heavily integrated with the hardware development cycle. However, new tools are starting to surface that seem to change the embedded paradigm with “do-it-all” solutions, but do they really do it all?
Contents
Proliferation of DIY Solutions
Arduino, RaspberryPi, BeagleBoneBlack, and others have made it easier than ever to develop your own plug-and-play hardware solutions, and now I’m seeing a rise in plug-and-play software solutions, as well. Chip manufacturers like Cypress and CSR are offering ready-made software development kits for their hardware like the PSoc Creator IDE and the Bluetooth(R) Smart SDK.For the record, I think these tools are great. They reduce barrier to entry for hobbyists, startups, and hardware-focused companies to get a prototype running quickly and with very little effort. As one chip rep recently told me, “you never have to look at registers again!” Rather than share in his excitement, this made me a little sad. As a professional software engineer, if I don’t look at registers, comb through source code, or hook up a logic analyzer, do I really understand the project I’m working on?
Product Development is Hard
There’s a difference between creating a prototype and creating a product. In my experience of taking multiple products to market, I believe that the Paretto Principle holds more often than not. No matter how well a project goes at the beginning, 80% of the work is getting the last 20% of the features, including the reliability necessary to launch a successful product. That 20% is typically missing from a prototype, and it gives false expectations about the size and scope of a project.
As projects move forward, each new feature, tweak, and bug fix gets more difficult to fix. The code base gets larger and more complicated. Each small change has the potential to break something else, and at the last minute, many companies will do almost anything to fix a bug in software if it means not having to modify the hardware. This includes bending do-it-all software in ways that the vendors never intended. It is for this reason that it would be beneficial to develop and progress your own technology skills in case a small change causes something you have no knowledge on. You can learn these skills through sites like Pluralsight that teach new skills all online. But before you invest, ask is pluralsight worth it? Does it give you the necessary resources and information to help you.
All of these situations require us to delve deep into the code, disassemble the executables, hook up the oscilloscope, and do whatever else has to be done to solve the problem at hand. If that doesn’t sound exciting to you, that’s fine. Let me take a look at your project, I’ll decode the registers for you.