Nowadays, it’s all the rage.
What could Embedded Linux bring to your product? When is it a good choice and when should you choose something else?
Embedded Linux, RTOS, bare metal: I’m a bit lost, what are the differences?
Let’s start with bare metal, the approach closest to hardware.
Bare metal, put simply, means writing code that runs without an operating system, thus making the most of the underlying hardware resources. It’s ideal for low-end microcontrollers. However, scalability can be a problem. When adding features like a rich user interface (UI) or connectivity, you will probably need to move to the next step up.
A Real-Time Operating System, (RTOS for short), provides more facilities to the developer, such as multitasking and software timers, which enables responsive systems. An RTOS can run on constrained systems and its footprint is of the order of 10kB ROM/512B RAM. They will typically run on ARM Cortex-M microcontrollers. Debugging is significantly harder when compared to bare metal. Some of the challenges include handling concurrent access to resources and inter-task communication.
And Embedded Linux? When moving into the realm of microprocessors (like Cortex-A based microprocessors, such as the ones found in smartphones), you will need to use a proper operating system, such as Embedded Linux. With these platforms, the boilerplate code required just to initialise the device becomes very complex. A Board Support Package (BSP) is often used for portability, meaning you won’t have to change your application code if you later decide to move to different hardware. Linux distributions are available in all flavours (more on that later), but memory requirements are typically several orders of magnitude higher compared to an RTOS.
So, when would you typically use Embedded Linux versus an RTOS or just go bare metal? Here are a few scenarios to help you choose what’s best for your project.
I want to demo a prototype with a UI to a panel of potential customers or investors
Using Embedded Linux allows you to create a Proof of Concept much quicker than using a more basic platform. Using a framework like Qt (Bluefruit has experience with this), you can create a UI in a few days. With the UI in place, you can do some user research and gather data on how they will interact with your product. Changes are relatively easy to make. This allows you to get quick feedback, and greatly speeds up your time-to-market.
I want an audio-based UI for my system
Within the rich open source ecosystem, you will find a number of voice assistants ready to use. It’s easy to feel overwhelmed with the range of options available (see “Where do I start? There’s too much choice!” section for more on this), so one of the biggest challenges is to find the solution most suited to the problem you’re trying to solve.
I want a highly connected, feature-rich device
Cloud connectivity, touch screen interface, embedded web server—these are situations where you would choose Embedded Linux. The rich ecosystem allows you to build a complete system much quicker than you would be able to if you were going bare metal. If you’re looking at using strong encryption, streaming audio or video, you’d probably want to use one of the open source libraries that run on Linux as well.
I want to drive a brushless DC motor
You do not want to use Embedded Linux for that—that would be excessive. However, if you need a user interface to control your motor, you could go for a dual processor solution, such as the STM32MP series, with an ARM Cortex-M MCU doing the calculation intensive, real-time motor control, and an ARM Cortex-A running Embedded Linux for the user interface.
I want a scalable application
With hundreds of computer-on-modules capable of running Embedded Linux, it’s very easy to port your software from one platform to the other, with very little coupling to the underlying hardware.
What about Windows IoT?
Formerly known as Windows Embedded, it is the other common option for feature-rich embedded products. Due to its closed nature, porting to an unsupported platform is typically more difficult. For example, there are restrictions on which versions can run on ARM architectures. Licensing, pricing, and long-term support also must be considered carefully. Security update availability is generally slower compared to Linux based applications.
I’m worried about cost
Bringing up a prototype can be very quick with Embedded Linux. Though reaching a commercial stage can be somewhat more challenging. The fact that it is open source doesn’t mean that it’s free as in “free beer”, and you must think carefully about licensing options (see below).
Embedded Linux is significantly heavier than an RTOS and requires a beefier processor. If you need to save a few £££, you should consider going for a smaller device and running an RTOS, or even just bare metal. Keep in mind, this must be balanced against development cost, as it’s likely to be higher for an RTOS to achieve the same feature set.
(Having a roadmap for your products will help you make the right choice here.)
For technology companies, recruiting can also be an issue. It is much easier to recruit Embedded Linux engineers than it is to find experienced bare metal ones.
I’m worried about power
It depends: how complex is your product? Once you start looking at products with a very high level of complexity, using an operating system becomes important to simplify the development space, but requires more powerful hardware. You can put the device into a lower power mode during down-time, which for complex systems an operating system like Embedded Linux can make much simpler. But if your device needs to be extremely low power, those big components are probably too much so you’ll want a bare metal application designed from start to finish with power in mind.
I’m worried about licensing
And you should be! It’s a complicated world. GNU/Linux (its proper name) is open source software, but there are a variety of licences, ranging from permissive ones such as MIT to much more restrictive ones like GPL v3.
Linking to GPL licensed libraries in your software adulterates the code base, meaning you must release all its source code. This is often an aspect that holds back organisations from using open source software.
But before you write this option off, there are a number of vendors that offer two licensing options: a (free) open source licence, or a (paid for) commercial licence which offers better protection for your Intellectual Property (IP), doesn’t force you to release your source code and comes with technical support.
Licensing is a very complex area, but this is something we can advise on and certainly put you in touch with trusted partners as needed.
I need to build a prototype
Building a protype using a Raspberry Pi running Raspbian is an option here. Raspbian is at its core an Embedded Linux operating system and for what it is, offers a lot of prototyping opportunities in product development before moving onto dedicated hardware.
In the past year, we’ve successfully used Raspberry Pi boards and Raspbian as part of prototyping work for a client. The combination helps to uncover full system requirements when it’s time to move onto the next stage of development.
(We’ve also been using several Raspberry Pi devices for prototyping an AI led audio classification project.)
I want auditable code
Open source means the code can be inspected for vulnerabilities and hidden backdoors. Popular open source software also benefits from great community support. It should however be noted that open source doesn’t mean habitable. Some parts of the Linux kernel are notoriously hard to make sense of.
Where do I start? There’s too much choice!
There are numerous “flavours” of Embedded Linux distributions available. But one strength of the open source movement is the number of solutions out there, meaning there are probably several existing software libraries to address every issue you’re trying to solve. But the importance of curating shouldn’t be understated.
Some of the criteria to consider are the maturity of the project, associated community support, licensing options, and obviously the quality of the source code.
We’d recommend creating your own distribution using a tool such as Yocto (we have teams with experience using it). The learning curve can seem steep, but it’s well worth the effort, as it allows you to only include the packages you really need, thereby reducing the footprint of your application, the maintenance burden and the attack surface for cybersecurity threats.
The biggest pitfall of Embedded Linux? Security
Security is the big one. Not a day goes by without a new IoT security breach making the headlines. Embedded Linux is powerful, but with great power comes great responsibility.
Configure, configure, configure
Configuration is key, and you will want to think carefully about which services and features you really need, and which ones you don’t. Anything you do not need must be disabled to avoid providing a backdoor to attackers.
There is no “security by obscurity”
The ubiquity of Embedded Linux makes it a preferred target for attackers. In contrast, niche Real-Time Operating Systems are much less vulnerable because their attack surface is much smaller. The more you rely on common, widely available software like Embedded Linux, the more often you’ll have to update your system as you outrace hackers who may be looking into your software in particular.
Still, it’s not such a simple dichotomy as it seems because “security by obscurity” is also quite risky. There are big advantages to using mature security libraries compared to rolling out your own/using some obscure one—or not doing it at all because it’s HARD.
Finally, you also need to think about firmware updates and fixing security holes once your device is out in the field. Which channel will you use? Over-the-air upgrades are notoriously vulnerable, but any interface can potentially be used by a determined hacker. Be clear on which features you actually need, to avoid creating a maintenance headache for yourself in the future.
Any system has potential flaws
Despite all this, product teams shouldn’t shy away from Embedded Linux. Any embedded system, whether it’s running on bare metal, RTOS or Embedded Linux will have flaws, including security ones.
Embedded Linux can be a powerful choice for an embedded system
We hope from reading this post, you can see that Embedded Linux has a lot to offer embedded systems. Teams just need to consider carefully whether it’s the right choice for their product.
Why is psychological safety critical to managing software risk?
Are you wondering what it really takes to prevent hazards and harms from embedded devices and systems? The tool many organisations are missing from their software development and product teams’ toolboxes:
You can download your copy of Why is psychological safety critical to managing software risk today. It doesn’t matter if you’re new to the concept or need a refresher; in our new ebook, you’ll learn about:
- What is psychological safety?
- The four stages vital to building psychological safety within teams.
- How psychological safety diminishes project risk.
- Project management practices that work well in organisations with psychological safety.
- How two businesses squandered psychological safety and paid the price for it.
Embedded software development insights
Quality software for embedded systems
Do you need embedded software engineers and testers to help with your latest Embedded Linux project? Bluefruit Software has over 20 years of experience providing high-quality software development, testing and consulting to clients in a range of sectors including medtech, industrial, aerospace and scientific.
Did you know that we have a monthly newsletter?
If you’d like insights into software development, Lean-Agile practices, advances in technology and more to your inbox once a month—sign up today!Find out more