5 Things to Understand Before Building a Linux-Based Embedded Device

Your customer asked you to build a Linux-based device. You’re a skilled developer but not experienced with embedded Linux. Here’s a quick overview of the key elements of Linux-based development you’ll need to master in order to successfully move from working prototype to Minimum Viable Product (MVP).

Basics of Developing a Linux-Based Device

Let’s start with the very basics: what is Embedded Linux? With embedded Linux, an embedded system is built with an operating system that uses the Linux kernel. The distribution is smaller and includes fewer features and less processing power than a standard Linux distribution in order to meet the constraints of an embedded device. 

While embedded Linux is built on the same kernel as enterprise Linux systems, it has greater constraints. For instance, devices built with embedded Linux have more intense requirements around security and reliability. And the devices need the ability to communicate with cloud resources (and each other). Plus, embedded Linux-based devices, such as medical devices, typically have a long lifespan – which means they need long-term engineering support (think upwards of 10 years).

Despite these constraints, embedded Linux is a popular choice for embedded development because it provides a modern, cloud-native environment, cross-compilation for supported platforms, broad hardware support and other benefits. 

To prepare yourself to create an embedded Linux-based device, we’ve put together a list of the Top 5 things you’ll need to understand before you begin. 

1. How to Select the Right Toolkit

Using embedded Linux requires you to add packages beyond the original Linux kernel. You’ll choose the specific package based on the type of device you’re planning to build. Regardless of what you choose or what type of device you’re building, you’ll need a basic set of tools.

Start by selecting a source-code versioning system to help you keep track of your source code. There are many options to choose from, from the venerable Subversion (aka SVN) to options like mercurial or  git. Since git was made for the Linux kernel, and Linux is built on top of git, it is a very good choice. In fact, the vast majority of software that conforms to a normal Linux-based operating system uses git to version source code.

But what if you already use a different versioning system? Well, you could elect to use what you have – perhaps erect a bridge between your current system and git. But the reality is that you’ll probably eventually still need git when developing a Linux-based device so you might as well start with it. Using git natively is the best way forward. 

If you’re unfamiliar with git, here’s a great place to begin your educational journey: Scott Chacon’s Pro Git Book, which is available for free as a digital download. Chapters 1 to 5 are must-reads! 

If reading isn’t your thing, we recommend listening to one of his many informative talks, like this introduction to git. If you find it helpful, Chacon has a multitude of other relevant content available on YouTube. 

2. How to Securely Share Code

As I’ve explained, with git you can keep track of the code you’ve created. But to share it, either within your own team or with external developers, you’ll need to choose some collaborative DevOps tools like GitLab, GitHub or bitbucket. Some of these types of tools allow you to have your own on-premises server, while some work strictly as an external resource so you’ll have to decide which option is right for your project.

Beyond providing you with git repositories (you chose to use git, right??) DevOps software packages typically come with helpful tools for user management. And they include automation tools so you can build continuous integration (CI) and continuous delivery (CD) – a best practice for DevOps and agile development – into your software delivery process. 

If you’re not familiar, CI allows for small changes to be continuously merged into the main branch. As for CD, that refers to short development cycles founded on a simple and repeatable deployment process. Even if you don’t think you’ll need to make use of CD it is still best to set up both CI and CD. Doing so will, for example, allow you to add test/coverage to your development process.

When you’re ready to choose a DevOps package for your project, there are some basic questions to answer:

• Do you need a service on-premise or can you do with hiring it externally?
• Do you need to run your own servers for the CI/CD? 
• How many developers will need access? 
• What’s your budget? Some tools are much pricier than others.

3. How to Access External Resources

You’ve made decisions regarding managing and sharing code. Now you need to figure out how to access any external resources you might need. Here’s a primer.

Typically, accessing external https resources (that is, http over an encrypted SSL/TLS channel) is straightforward. This kind of access will help with open source repositories like Debian package repositories or accessing source code for building a Yocto-based distribution. Still, you may run into obstacles. Many companies have strict policies around network access. That means there may be instances when you must ask sysadmins to pretty-please-with-extra-sugar-on-top make an exception that would allow you to gain needed access. Hopefully, they agree. And hopefully, they give you the right kind of access.

Let your sysadmin know that you’re ready to start pushing code to your repository (or fetching it in order to then build it) and need SSH access to do so. This is important. Your sysadmin might view authenticated https access in terms of hardcoded users and passwords. You don’t want to go down that road. So emphasize that you absolutely need SSH access. 

The specific type of SSH connection you need will depend on where you aim to connect to. If your server is on your own network, that might just be internal. But if there’s any chance you might need to work with an external contractor, you’ll need to allow for inbound access. Hired services, on the other hand, are all outbound connections.

4. How to Efficiently Test Your Code

Quality Assurance (QA) is essential to the success of your device. While the intricacies of QA are beyond the scope of this blog, if you’ve read this far you already have the basic toolset you’ll need for QA in the collaborative DevOps tools described previously. They provide you with what you’ll need to test your code – not just from time to time, but from commit to commit.

It is a good practice to have your code tested as much as possible, whether that means unit tests, integration tests or other modalities. Whatever tests you conduct, be sure to create coverage reports so you’ll have metrics around how much of your code is being tested. This is essential since you’re likely to have to satisfy a requirement to reach a certain amount of coverage, and prove that you did so. Even if you don’t face that formal requirement, you should set the requirement yourself and measure accordingly.

If done properly, your CI/CD set-up can serve as your single source of truth. If something does not build there then you’ll know you have a problem. This means the days of “it doesn’t work on my machine” are in the rearview. Instead, your official test results should come from your CI/CD set-up. If you choose, you can even integrate your own custom hardware into the process. For instance, if you set up a proper rig like Balena's AutoKit solution you’ll be able to test your software in the real device. 

5. Where to Find Resources to Close Your Knowledge Gap

By building solid knowledge in the areas we’ve described you’ll have a robust starting point for your first Linux project. If you’d like additional guidance, such as a few hours of consulting time with a Linux pro or even a Linux-experienced developer to add to your project team, ICS can help. Our embedded Linux experts – skilled software engineers who specialize in the Linux operating system version designed for embedded systems – have developed a host of embedded products, from regulated medical devices to sophisticated industrial controls. We’re available to help you create a meaningful customer solution. Get in touch.

And in case you need a reference to remind you of the key elements needed to create a Linux-based embedded device, here’s a handy checklist.

For more on Linux development, read our blog Is Linux OS the Right Platform for Your Medical Device?