E-Book, Englisch, 418 Seiten
Simmonds Mastering Embedded Linux Programming
1. Auflage 2024
ISBN: 978-1-78439-902-3
Verlag: De Gruyter
Format: PDF
Kopierschutz: Adobe DRM (»Systemvoraussetzungen)
Harness the power of Linux to create versatile and robust embedded solutions
E-Book, Englisch, 418 Seiten
ISBN: 978-1-78439-902-3
Verlag: De Gruyter
Format: PDF
Kopierschutz: Adobe DRM (»Systemvoraussetzungen)
Mastering Embedded Linux Programming takes you through the product cycle and gives you an in-depth description of the components and options that are available at each stage. You will begin by learning about toolchains, bootloaders, the Linux kernel, and how to configure a root filesystem to create a basic working device. You will then learn how to use the two most commonly used build systems, Buildroot and Yocto, to speed up and simplify the development process. Building on this solid base, the next section considers how to make best use of raw NAND/NOR flash memory and managed flash eMMC chips, including mechanisms for increasing the lifetime of the devices and to perform reliable in-field updates. Next, you need to consider what techniques are best suited to writing applications for your device. We will then see how functions are split between processes and the usage of POSIX threads, which have a big impact on the responsiveness and performance of the final device The closing sections look at the techniques available to developers for profiling and tracing applications and kernel code using perf and ftrace.
Autoren/Hrsg.
Fachgebiete
- Mathematik | Informatik EDV | Informatik Betriebssysteme Linux Betriebssysteme, Open Source Betriebssysteme
- Technische Wissenschaften Elektronik | Nachrichtentechnik Elektronik Mikroprozessoren
- Mathematik | Informatik EDV | Informatik Programmierung | Softwareentwicklung Programmier- und Skriptsprachen
Weitere Infos & Material
Table of Contents - Starting out
- Learning about Toolchain
- Everything about Bootloader
- Porting and Configuring Kernel
- Identifying components of Root file System
- Selecting a Build Framework
- Creating a storage strategy
- Introducing Device drivers
- Starting up: the init program
- Learning Processes and threads
- Managing Memory
- Debugging using GDB
- Profiling and tracing
- Real time programming
The art of cross compiling
Having a working cross toolchain is the starting point of a journey, not the end of it. At some point, you will want to begin cross compiling the various tools, applications, and libraries that you need on your target. Many of them will be open source packages, each of which has its own method of compiling, and each with its own peculiarities. There are some common build systems, including:
- Pure makefiles where the toolchain is controlled by the variable
- The GNU build system known as Autotools
- CMake (https://cmake.org)
I will cover only the first two here since these are the ones needed for even a basic embedded Linux system. For CMake, there are some excellent resources on the CMake website referenced in the preceding point.
Simple makefiles
Some important packages are very simple to cross compile, including the Linux kernel, the U-Boot bootloader, and Busybox. For each of these, you only need to put the toolchain prefix in the variable , for example . Note the trailing dash .
So, to compile Busybox, you would type:
Or, you can set it as a shell variable:
In the case of U-Boot and Linux, you also have to set the variable to one of the machine architectures they support, which I will cover in Chapter 3, and Chapter 4, .
Autotools
The name, Autotools, refers to a group of tools that are used as the build system in many open source projects. The components, together with the appropriate project pages, are:
- GNU Autoconf (http://www.gnu.org/software/autoconf/autoconf.html)
- GNU Automake (http://www.gnu.org/savannah-checkouts/gnu/automake)
- GNU Libtool (http://www.gnu.org/software/libtool/libtool.html)
- Gnulib (https://www.gnu.org/software/gnulib)
The role of Autotools is to smooth over the differences between the many different types of system that the package may be compiled for, accounting for different versions of compilers, different versions of libraries, different locations of header files, and dependencies with other packages. Packages that use Autotools come with a script named that checks dependencies and generates makefiles according to what it finds. The configure script may also give you the opportunity to enable or disable certain features. You can find the options on offer by running .
To configure, build, and install a package for the native operating system, you would typically run these three commands:
Autotools is able to handle cross development as well. You can influence the behavior of the configure script by setting these shell variables:
- : The C compiler command
- : Additional C compiler flags
- : Additional linker flags, for example if you have libraries in a non-standard directory you would add it to the library search path by adding
- : Contains a list of additional libraries to pass to the linker, for instance for the math library
- : Contains C/C++ preprocessor flags, for example you would add to search for headers in a non-standard directory
- : The C preprocessor to use
Sometimes it is sufficient to set only the variable, as follows:
At other times, that will result in an error like this:
The reason for the failure is that often tries to discover the capabilities of the toolchain by compiling snippets of code and running them to see what happens, which cannot work if the program has been cross compiled. Nevertheless, there is a hint in the error message of how to solve the problem. Autotools understands three different types of machine that may be involved when compiling a package:
- Build: This is the computer that is to build the package, which defaults to the current machine.
- Host: This is the computer the program will run on: for a native compile this is left blank and it defaults to be the same computer as build. For a cross compile you set it to be the tuple of your toolchain.
- Target: This is the computer the program will generate code for: you would set this when building a cross compiler, for example.
So, to cross compile, you just need to override host, as follows:
One final thing to note is that the default install directory is . You would usually install it in so that the header files and libraries would be picked up from their default locations. The complete command to configure a typical Autotools package is:
An example: SQLite
The SQLite library implements a simple relational database and is quite popular on embedded devices. You begin by getting a copy of SQLite:
Next, run the configure script:
That seems to work! If it failed, there would be error messages printed to the terminal and recorded in . Note that several makefiles have been created, so now you can build it:
Finally, you install it into the toolchain directory by setting the variable . If you don't, it will try to install it into the host computer's directory which is not what you want.
You may find that final command fails with a file permissions error. A crosstool-NG toolchain will be read-only by default, which is why it is useful to set to when building it. Another common problem is that the toolchain is installed in a system directory such as or in which case you will need root permissions when running the install.
After installing, you should find that various files have been added to your toolchain:
- : sqlite3. This is a command-line interface for SQLite that you can install and run on the target.
- <: libsqlite3.so.0.8.6, libsqlite3.so.0, libsqlite3.so libsqlite3.la libsqlite3.a. These are the shared and static libraries.
- : : This is the package configuration file, as described in the following section.
- : , : These are the header files.
- <: sqlite3.1. This is the manual page.
Now you can compile programs that use sqlite3 by adding at the link stage:
Where, is a hypothetical program that calls SQLite functions. Since sqlite3 has been installed into the sysroot, the compiler will find the header and library files without any problem. If they had been installed elsewhere you would have to add and .
Naturally, there will be...
