Linux is an Open Source Operating System. Which means the source code of the Linux kernel itself and also of thousands of userspace applications, the so-called Userland, is available for free. Linux is running on most CPU architectures, including x86 and ARM, but also on many other architectures from small CPUs for IoT devices (Internet-of-Things) to large Main Frames and High Performance Computers (HPC). Linux is feature-rich and fully scalable. The number of applications is correspondingly diverse.
● Set-top boxes, media players, DVD/Blu-ray players, TVs
● Network devices, routers
● Storage devices (NAS)
● Home automation
● Industrial and medical applications
The Linux kernel including the device drivers also forms the basis for Android, so in principle all Android devices, i.e. smartphones, tablets, etc., are also Linux devices. In fact most people already use Linux devices, perhaps without knowing it.
All these applications ensure that Linux continues to evolve at a rapid pace. Video and audio codecs are often available for Linux first, also WLAN and Bluetooth drivers. In fact nowadays even Linux itself is the first OS available for most Systems on Chip (SoC), because the SoC manufacturers use Linux to test and verify their hardware. So when the chip is released to the public, there is also immediately a first version of all necessary Linux device drivers available. Linux development is done by the “Community”. On one hand, the Community consists of professional software developers who are employed by companies and earn their money by developing software for Linux. On the other hand, there are many private enthusiasts who contribute code to Linux that they developed in their spare time. In this way, about every nine to ten weeks a new version of the Linux kernel is released. This is the so-called Mainline Kernel.
Despite this variety of people working on the kernel, the quality is at a very high standard. If you want to contribute a change to the kernel, you must first post it to a mailing list. There the code is checked by many people for bugs, shortcomings and even coding style. In most cases there are still complaints and the code has to be revised again. Often several iterations of these revisions have to be performed until the code satisfies the requirements of the kernel maintainers and is then actually integrated into the next kernel release.
One of the biggest advantages of Linux is its diversity. As you can see in Figure 4, there are many distributions with different objectives, many graphical user interfaces, many build systems, many development environments and an overwhelming amount of open source software packages in the Linux ecosystem. So you can choose from a huge amount of libraries, approaches, versions, variants and other options. This flexibility is gigantic.
On the other hand, this is also a problem. Many people miss the red thread that leads them directly to the goal. Especially Linux beginners often find themselves helpless in front of a huge mountain of possibilities and don't know where to start. This problem is very difficult to overcome. It simply needs experience. If you work with Linux, you will definitely have to try a lot, read a lot, research a lot, compare a lot. But since you can almost always find code that you can reuse, this effort is well invested and saves a lot of time in the end. And after a while you will find your individual way through the Linux jungle.
F&S tries to help by providing workshops, documentation and a support forum. Attending these workshops and carefully reading the documentation may save you many hours of own research and unnecessary tries. If there are still unanswered topics, you can ask in our forum. Our software and hardware engineers will answer quickly and competently.
What is Embedded Linux?
An Embedded Linux System basically does not differ from a regular Desktop Linux System. It uses the same source code, it uses the same compilers and software tools and it even uses the same Userland packages. However there are often some constraints that need attendance.
● Embedded Systems usually have less RAM. It is counted in megabytes, not gigabytes. This requires to keep the system small, only start those background services that are really necessary, sometimes software is even optimized for size instead of speed. Also leave out unnecessary parts of software. For example if you know that your application will never need 3D features or web assembly, you can compile a smaller version of the web browser without these elements.
● Embedded Systems usually do not have a hard disc drive, only small flash media. So a full-blown distribution that needs several gigabytes of storage is most probably not appropriate. Even the hundreds of common command line tools take too much space and are often replaced by a compact single tool called Busybox.
● Embedded Systems are often battery-powered. So it is important that all power-saving functions actually work. Sleeping modes like Suspend-to-RAM are essential and fast wake-up features need to be implemented. On the desktop, this is often not a priority topic.
● Embedded Systems are often connected to industrial buses like serial ports, SPI, I²C, CAN and similar, but do not have many PCI lanes, if any at all. So common hardware extensions known from PCs can not be used. On the other hand the SoCs in Embedded devices have lots of built-in periphery, so that additional external hardware is often not necessary at all. This means different device drivers are needed compared to a regular desktop PC.
● Embedded Devices are often headless, i.e. do not have a display. So other means of communicating with the device need to be established. If they have a display, then most probably a touch screen is used, not a mouse. This has to be thought of when designing the GUI. Often no support for high-performance graphics is available, or it is significantly less performant than on a desktop PC. The same is true for multi-media features like video playback.
● Embedded Systems are often not based on x86 CPUs, but on ARM or other SoCs. So we need cross-compilation and different libraries.
● Embedded devices are often used in rough environments, for example outdoors where it can be very cold or hot, or even wet. It is also possible that the power supply is unstable or the power is simply cut off by pulling the plug. This needs very robust filesystems, and also recovery capabilities. Maybe regular filesystems need to be mounted read-only, which is not possible with regular distributions.
An Embedded Linux system is therefore very similar to a regular desktop Linux system, only the weighting of the individual objectives is different.
Buildroot and Yocto
Usually when you are using Linux on a desktop, you are actually working with a specific Linux distribution like Ubuntu, Debian, Suse, Fedora, or similar. There are more than 100 distributions available, most of them with a specific purpose, for example best hardware support, easiest installation, most stable software, and so on. A distribution means that someone has assembled a large collection of software, has subdivided all the software in small packages and makes these packages available as a software repository. You can decide what packages to use and you can download and install additional packages later at any time and you can also uninstall unused packages. The distribution also provides updates, for example to fix security issues or to have newer versions with additional features available.
This results in a very flexible and universal system that is suited for nearly every purpose. However if you want to use an embedded system, you most probably have a specific application in mind. And in such a case a full-blown distribution also has a few disadvantages.
● A distribution is mainly targeted for desktops. This means installation, configuration and usage often implies some kind of display and many components imply that they can show their output on a Graphical User Interface (GUI).
● This also means that all components use a very comprehensive configuration. For example a web browser will support 3D, Web Assembly, multimedia and similar stuff, resulting in a rather large binary. And this binary will pull in a lot of libraries and thus a lot of additional packages. So even if you know that you will never need 3D, you can not uninstall the 3D library package alone because you could not start the browser without this library. The package manager of the distribution will therefore automatically uninstall the browser package, too, if you uninstall the 3D library. This means a distribution can not easily be stripped down to a small system that is specifically targeted for your application. You have to carry a lot of extra ballast around that can also cause additional security issues, even if you never use it.
● Distributions often start a lot of background services that are not required on an embedded system. This slows down the boot process and increases the RAM footprint unnecessarily.
● A generic distribution for ARM often does not support specific hardware features of specific SoC variants. Then you probably can not use hardware accelerated video decoding or similar things.
● Distributions assume that they have lots of RAM and storage memory. To guarantee that a distribution will run on an embedded system, you must also have boards with large amounts of memory, making the devices more expensive.
● Distributions assume swap space. This is usually not available on an embedded system.
● Distributions rely on an initrd, making the boot process unnecessary complex and slowing down the boot process again.
● Distributions are not aware that they are probably running on flash memory based media. So they write to log files arbitrarily often, the /tmp directory is not in a ramdisk, they do not optimize write cycles and they do not care for wear-levelling. This might reduce the lifetime of a flash memory based device considerably.
● Distributions assume that they are shut down in a proper way. If you simply switch such a device off, they will lose data. Shutting down without losing data implies a read-only mounted root filesystem, which is not possible with regular distributions.
● Distributions use the regular set of command line tools. Each tool is rather small, but if you have hundreds of them, this sums up to a considerable amount of memory, also increasing the memory footprint unnecessarily. They do not use Busybox.
From this point of view, a distribution is not the best solution. It is large (a minimal system with graphics is about 1 GB of size), it is slow and it may not support SoC specific hardware acceleration. But there are other build environments that actually do address these issues. Two of them are Buildroot and Yocto and both are available from F&S.
The basic idea of these environments is that you create an own small distribution that just contains those packages that you really need and even these packages are configured in a way that no unnecessary parts are included. This results in very small Linux systems. Our standard image with X11 and a small window manager called matchbox, gstreamer1 for multimedia, ALSA for sound, a set of tools to access CAN, I²C and SPI and a picture viewer, is just about 90 MB in size.
There are releases for Buildroot and Yocto. So you can decide which way to go and which version you want to download.
When you buy a F&S Linux starter kit, it contains the latest buildroot version by default.
A detailed description and links to the Buildroot / Yocto releases can be found under the respective product in the Linux tab.
Mono on F&S boards
Mono is an open source implementation of the .Net framework that is sponsored by Microsoft. It currently supports most .NET libraries up to version 4.7 with the exception of WPF, WWF and with a restricted WCF and ASP.NET asynchronization stack.
Full compatibility information can be found on the Mono project's official website.