This blog post is written by Giuliano Franchetto, CTO of Intellinium and was originally featured on the Intellinium website.
Today, everything gets more and more complicated. This is of course true for embedded electronics design, both on software and hardware side. More complex boards will be more likely to fail at some point, and a more complex firmware will be more prone to bugs and side effects.
We’ve all had a “I added a simple line of code at the start of my code, and it now fails at the most random place” moment (and let’s be honest, this is not the funniest part of being an embedded engineer). Even if it costs more at the first place, dividing software and hardware functionalities is one of the most effective ways to tackle this problem, and save money in the long run.
So, let’s talk how Zephyr OS can be very efficient on this subject, and use multiple Zephyrs to create a hurricane and to build the best connected worker smart PPE!
Zephyr 1.12 and onwards now supports Asymmetric MultiProcessing (AMP), helping designers to remotely call functions running on another core. In that way, the designer can now choose to divide its code, and host only some parts of the functionality in a single core and use AMP to call the other set of functionalities remotely. The code becomes lighter, faster, predictable and way easier to upgrade later. Another very interesting part is that we can now port software principles easily using multiple core + AMP.
Let’s take our use case at INTELLINIUM, where we have been developing a safety pod (plug-in) to transform traditional leather-based safety shoes into smart and connected safety shoes, a life-saving product that shall work at all time and in all conditions.
The multiple cores + AMP architecture enables the use of the “SOLID” software principle, very famous among Java developers. The SOLID principle is a “Single Responsibility Principle”, or more trivially “just do what you are meant to do and do it well”. In our case, we must manage critical messages, answer a user’s distress call, but also read various sensors or manage a LED. The priority of all functionalities is of course very different, and even if Zephyr manages thread priority, we are polluting life critical processes with “cosmetic” ones. Aware of this potential problem, we chose to add a small M0 MCU from ST, whose job is to manage all the sensors and actuators of our product. That way, our main MCU (a nRF52840 from Nordic Semiconductors) can focus on its “Single Responsibility”, taking care of its user.
Another very powerful possibility is to separate the communication processing power from the main core. That’s why we chose the new nRF9160 from Nordic Semiconductor as our LTE modem, as they were brilliant enough to embed an independent Cortex M33core inside their own component, hosting all our communication related code. No more AT commands parsing with huge static buffers in our main program, no more SIM management nor HTTP packets building. Everything is done is the M33 core, dedicated to communicating with the base modem. And of course, AMP is used between the nRF52840 and the nRF9160 to send or receive messages from example.
I hope that this small talk showed you how powerful can multi-processor be, and not only for pure computing power, but to make firmware development easier, more scalable, and safer. It may cost you a few bucks more when producing your own board, but trust me, you will save dozens if not more on the long run. I’m out of time right now, but I’d just to mention that adding multiple cores can also save energy, thus increasing your product life time. But that will be another talk. Happy coding!
You can join the conversation or ask questions about Zephyr on the Zephyr Slack channel or Mailing List.