With demand for IoT devices continuing to soar, there is a real danger of running out of the talented people required to design, test and build them.
So many IoT articles begin with the prediction that there will be tens of billions of connected devices in the world within the next five years or so.
While that might be true from a market potential perspective, there are some elephants in the room that may prevent us getting there.
Proper security is one, but we’ll take that another day. What I'll focus on today is whether there is a sufficient supply of engineers and, as is most in demand today, software and firmware developers to meet this anticipated growth.
Embedded software development in general is pretty hard, but doing it well takes years of learning and experience. Specific skills in the dominant languages of the field, C/C++, are required.
C/C++ give you the ability to get as ‘deep and dirty’ into the hardware as you like, allowing almost complete freedom on how you construct your system and its relation to the hardware.
With this freedom comes risk. If you can bend it any which way, you can also break it. That’s why true embedded skillsets take years of experience to avoid potentially catastrophic, but not uncommon, mistakes such as race conditions and memory leaks.
New graduates can enter the world of app development and other web industries much more easily and usually become productive in a shorter period of time. This is largely because the technologies and frameworks in those industries are more ‘sandboxed’ and sit atop operating systems that make catastrophic error less likely.
Additionally, embedded development does not sit at the top of the tree salary-wise. Unless students of Computer Science have a real passion for making things that work tangibly, chances are they will head for the bigger bucks in the world of web-based and mobile app development.
University courses in Computer Science and Engineering are steadily having fewer and fewer specialist embedded courses. In fact, some Computer Science courses no longer teach C/C++ at all.
It is a real shame as building systems that enable real things to work is incredibly rewarding. But not only is it a shame, it is potentially a real problem for the entire IoT industry.
While there are a number of solutions, none of them will offer a quick fix.
Firstly, the industry could do a better PR job along with a salary hike to attract more talent. That’s going to take time, and even if it does happen, there’s a delay period in turning the ship around.
A second option, which may happen naturally, is that embedded moves more in the direction of the web industries.
This would mean languages such as Python (and its constrained derivatives such as MicroPython, Java and Javascript and their associated frameworks) start to be used more in constrained embedded systems.
The arrival of node.js in more recent times has seen a boost for Javascript use with embedded, as has Web Bluetooth with support in most current browsers.
This often means certain compromises at an engineering and performance level. But there is the implicit assumption that embedded development in C is superior. That's true if it is implemented correctly, and that's not always the case.
The higher level languages have well-known and thoroughly tested frameworks for many functions, including security, memory management and housekeeping, as standard. This can mean a bit more bloat, but conversely offers a well-proven foundation for the system.
MCUs in embedded systems are getting more powerful and sophisticated at the same, or at lower, cost year-on-year, and the use of operating systems and interpreters becomes more feasible. It may mean you don’t have a lean, mean fighting machine, but you may have a device with so much weaponry you can tolerate the hit.
This table shows a general, and arguably subjective, comparison of languages for embedded development:
| Node | Java | Android | Perl | Python | C | C++ | PHP | |
|---|---|---|---|---|---|---|---|---|
| Learning curve | Low | Medium | Medium | High | Medium | Low(*) | Medium | Low |
| Build speed | Fast | Slow | Slow | Fast | Fast | Medium | Medium | Fast |
| Execution speed | Fast(**) | Fast | Fast | Slow | Slow | Very Fast | Very Fast | Slow |
| Development speeed | Fast | Medium | Medium | Fast | Fast | Low | Medium | Fast |
| Package support | Very high | High | High | High | High | Low | Medium | Medium |
(*)This is somewhat subjective, and a low learning curve is assumed due to prior knowledge by an embedded developer.
(**)Benchmarks typically rate javascript execution as "fastish" below java, but still above what would be considered "medium".
Embedded taking a lead from the world of web development could be the answer. There will always be a need for engineers who can create the highly efficient firmware modules that wrap around core hardware elements, but the general application usage of hardware may be in a higher-level language.
Maybe the onus will fall more and more on the shoulders of the MCU suppliers to deliver the lean modules for the device and higher level APIs for alternative programming languages. There is much of this happening already in silicon providers' SDKs, only most of the APIs still support only C/C++.
What we do know is that many more embedded systems will be designed in the coming years. Right now there are way more developers skilled in languages such as javascript in the market, and we need a way to meet the demand.
There’s much more to delve into on this subject, and I’ll do another blog on some of those aspects soon.
If you want to try out the higher-level approach to embedded, try out espruino javascript and/or node.js on the nRF52832 DK and for the Nordic Thingy:52.
Espruino isn’t the only option out there, but in addition to running a javascript interpreter on the device, it supports inline C for those really fiddly bits, should you feel the need. Try it out and tell me what you think.