One of the biggest advantages of OS-based development on platforms such as embedded Linux is that it's so similar to a regular desktop Linux installation. Especially when running an OS such as a Debian-based Linux distribution (Armbian, Raspbian, and others) on SoCs, we have practically the same tools available, with the entire package manager, compiler collections, and libraries available with a few keystrokes.

This is, however, also its biggest pitfall.

We can write code, copy it over to the SBC, compile it there, run the test, and make changes to the code before repeating the process. Or, we can even write the code on the SBC itself, essentially using it as our sole development platform.

The main reasons why we should never do this are as follows:

• A modern PC is much faster.
• Testing on real hardware should never be done until the final stages of development.
• Automated integration testing is made much harder.

Here, the first point seems fairly obvious. What takes a single or dual-core ARM SoC a good minute to compile will quickly go from start of compilation to linking the objects in ten seconds or less with a relatively modern multi-core, multithreaded processor at 3+ GHz, and a toolchain that supports multi-core compilation.

This means that, instead of waiting half a minute or longer before we can run a new test or start a debugging session, we can do so almost instantly.

The next two points are related. While it may seem advantageous to test on the real hardware, it comes with its own complications. One thing is that this hardware relies on a number of external factors to work properly, including its power supply, any wiring between power sources, peripherals, and signal interfaces. Things such as electromagnetic interference may also cause issues, in terms of signal degradation, as well as interrupts being triggered due to electromagnetic coupling.

All of these potential hardware-related issues show that such tests aren't nearly as deterministic as we would wish them to be. The potential result of this is that project development takes much longer than planned, with debugging being complicated due to conflicting and non-deterministic test results.

Another effect of a focus on developing on and for real hardware is that it makes automated testing much harder. The reason for this is that we cannot use any generic build cluster and, for example, Linux VM-based testing environment, as is common with mainstream Continuous Integration (CI) services.

Instead of this, we would have to somehow integrate something such as an SBC into the CI system, having it either cross-compile and copy the binary to the SBC for running the test, or compile it on the SBC itself, which gets us back to the first point.

In the next few sections, we'll look at a of approaches to make embedded Linux-based development as painless as possible, starting with cross-compilation.