Recently, we have been evaluating Continuous Integration (CI) systems for a variety of projects (both OSS and customer). There are many OSS options to chose from. Because we already use Docker containers for Yocto/OE builds, Concourse and Drone made the short list. Both communities seem responsive and helpful.
Read More »Drone for Continuous IntegrationAs Embedded Systems become more complex, the complexity of the process to build the software for these systems also increases. As humans, our ability to deal with complexity is limited, so we develop tools and processes to manage the complexity. In the end, these tools and processes are about constraints and patterns. A well-designed tool or process encourages you to do things in a way that is consistent and maintainable, which leads to reliable and predictable results.
Recently I was asked by a developer, who has done windows development for 10 years, how to get started with Embedded Linux. Embedded Linux covers a lot of ground and includes a broad range of components/skills to put together an entire system. Below are a few suggestions.
Read More »Getting started with Embedded Linux
When building a product using Linux, versioning and branching of your software is an important consideration. Everyone’s needs are different depending on the size of the team, culture, and testing requirements, so there is no one size that fits all. However, after working on a number of different projects for a dozen or so different companies, there are several practices that are often used.
Read More »Git, Versioning, and Branching for Embedded Linux Development
As we work with larger and more complex systems (i.e. Linux), more and more of our time is spent on integration and pulling different pieces together. We often need to debug or understand code we did not write — especially in build systems. To work effectively in this scenario you must be able to quickly search through a lot of source code. Therefore, we are always looking for ways to make this more efficient.
Why Docker? When using OE to build software for products, we often run into the scenario where software needs to be built using the same version of OpenEmbedded over the course of several years. Production builds need to be predictable. We’ve also observed that old versions of OE often break as new Linux distros come out. This is just the result of the complexity of building tool chains. Additionally, for predictable builds you really don’t want to be changing the build OS. This requirement automatically rules out Arch Linux, Debian Unstable, Gentoo, etc as production build machines. Additionally, having developers debug OE build issues on varying workstation distributions is frustrating and time consuming.
Recently, I sent a survey to the OpenEmbedded and Yocto mail lists asking a series of questions about how they use OE. 38 people responded. The average number of years using OE is 4.8 years.
I’ve already written about using autotools and qmake in OE. With recent projects, we’re using CMake to build most C/C++ components. Like any good tool, CMake has a learning curve, but it seems to do its job quite well. Below are examples of a CMake build file, and corresponding OE recipe.
Read More »Best practices for using CMake in OpenEmbedded/Yocto
With the BEC OE build template, you can easily set up an opkg feed server that serves up packages from your build directory. This allows… Read More »Setting up an OpenEmbedded Package Feed Server
How does one set an OpenEmbedded/Yocto/Poky/Angstrom build? There are many options. Some include: Angstrom setup scripts Poky Freescale Community BSP OpenEmbedded core standalone (I’m sure… Read More »OpenEmbedded Build Template
