Chapter 8. Advanced Software Topics

So far, all of our programming has been done using high-level languages, such as shell script or Node.js. In this chapter, we will look at other BeagleBone software development methods along with other pieces of software on the BeagleBone that are necessary to support additional hardware. The BeagleBone is a full Linux system like Linux on a desktop or laptop and most desktop development techniques will be applicable. In this chapter, we will cover the following topics:

• BeagleBone programming with the C and Linux APIs

• User space / kernel space

• Kernel driver on the BeagleBone

• Device tree on the BeagleBone

• Pinmuxing

• Real-time behavior on Linux

The BeagleBone programming with the C and Linux APIs

Almost all Linux programs written in C for a desktop or laptop can be made to work on the BeagleBone if it uses only the Linux API. While this is a qualified statement, many programs will fall into this category. The gating factor is the presence of hardware. For example, a program that requires a keyboard will not work unless a keyboard is installed.

Tip

This section is applicable to other programming languages such as C++.

The things that are likely to break when moving from the desktop to the BeagleBone are as follows:

• Software that accesses hardware using the low-level APIs rather than the higher-level abstractions layers; for example, an older desktop system may offer a parallel port that some applications will try to use as GPIOs. While the parallel port access is a standard Linux API, there is no equivalent parallel port on the BeagleBone.

  Note

  Most software written to use the parallel port in this fashion can often be rewritten to use...

User space versus kernel space on the BeagleBone

On Linux, software is divided into two realms. The first realm, kernel space, is a privileged space that has visibility of the entire system. On some systems, this is also known as the supervisor mode. The other realm, user space, is an unprivileged space backed by hardware. It has a limited visibility of the entire system. All hardware access is done through the Linux API. Attempts to increase visibility beyond what the Linux API allows will result in a fault or at least an error. All the exercises up to this point have been exclusively in the user space. One important detail to note is that the system software or distributions include both kernel and user space components. Kernel space is exclusively in the Linux kernel and everything else is user space.

The distinction between user space and kernel on the BeagleBone is very important. The kernel is aware of the differences in hardware. A few things that the kernel is aware of are as follows...

Kernel drivers on the BeagleBone

The proper means to support hardware on the BeagleBone is with a Linux kernel driver. This includes both stock hardware on the BeagleBone and any new added hardware. Using a kernel driver avoids the preceding drawbacks and allows maximum performance benefits. The resources on the SoC can be used with minimal difficulty. Access to things such as DMA and interrupts are very difficult in user space but are relatively straightforward in the kernel.

Writing a device driver is beyond the scope of this introductory book. However, advanced beginners should be aware of how to build the kernel. The Linux kernel is well written and cross compilation is easily done. Building the kernel can be done in a series of steps. You will need a cross compiler. The sample command lines assume the cross compiler prefix is arm-none-eabi-. If you have a different compiler setup, replace that prefix with yours. All the following commands will have ARCH=arm to tell the kernel build system...

Device trees on the BeagleBone

One feature that was introduced in the Linux kernel is the concept of a device tree. The goal of the device tree is to allow one kernel binary to support different hardware by changing the device tree. A device tree is a data structure used by the kernel to describe the underlying hardware.

The device tree data informs the kernel about the following:

• Physical address of the hardware blocks, for example, the I2C block on the BeagleBone is supported by the same driver as the one on the original Beagle boards. However, they differ by the address.

• Any hardware revision differences.

• Name of the driver the hardware uses. This is often specified as a compatible attribute.

• Hardware resources such as interrupts and DMA resources used.

• Register settings specific to the hardware.

The device tree information depends on the driver using it. There can be other attributes such as GPIOs to enable functions.

Like building a kernel, the device tree is an advanced topic. We will go through...

Pinmuxing on the BeagleBone

Pinmuxing is a combined software and hardware concept that embedded users, such as the BeagleBone users, must be very aware of if they are using anything other than the basic functions of the BeagleBone. Any interfacing using the expansion connector P8 and P9 is likely to involve the pinmux unless the hardware being interfaced matches the default settings. Some of the off-the-shelf expansion boards come with configuration settings to automate this process. Regardless of whether it is automated, it is a good idea to at least confirm the pinmux settings. As described in Chapter 7, Interfacing with the BeagleBone, pinmux is used to select one of the eight functions on each signal from the SoC. It is the last part of the SoC before a signal leaves and the first part before a signal enters the SoC.

From a software standpoint, it is possible for the kernel driver to be configured perfectly and yet any external connected hardware to the SoC would not work. The pinmux...

Figuring out the pinmux on the BeagleBone

The process of figuring out the pinmux can be very confusing for a new user. What is described here is an attempt to identify the information from different sources and connect them to determine a pinmux setting. There are four documents that contain relevant information. They are as follows:

• BeagleBone SRM: This describes the signals from the SoC that are exposed on the expansion connectors, P8 and P9. Most users will start here to identify the pins they are using.

• BeagleBone schematics: While not strictly needed, the schematics can help clarify some signals. Some signals on the BeagleBone are connected together for backward compatibility with older revisions of the board. The schematic along with the SRM will help you identify them.

• AM335x datasheet: This is the documentation labeled as the datasheet on the Texas Instruments website. It is a much smaller PDF document than the TRM. Most of the information here is hardware-specific but we need it...

The BeagleBone and real-time performance

New users that are not from Linux-based embedded backgrounds often have an expectation of real-time performance. Linux is not a real-time operating system (RTOS). It is beyond the scope of this book to fully address this point but some clarification of potential confusion is needed.

Real-time performance means repeatable and predictable timing behavior. It does not mean higher performance as the name would suggest. Real-time performance is often needed in embedded devices so they can respond to external events in a timely manner. For example, maintaining a consistent motor speed from a BeagleBone requires the BeagleBone to respond to the motor speed measurements in a consistent manner.

On the BeagleBone systems running Linux, real-time behavior can be addressed in the following ways for noncritical systems:

• Compared to many smaller embedded systems, the BeagleBone is considerably faster. This may be enough to approximate the real time for most of the...

Summary

In this chapter, we looked at several advanced software topics. We began by looking at programming the BeagleBone like a desktop system using the C and Linux APIs. You learned that the BeagleBone shares many things with a desktop Linux system and can reuse most libraries and software developed on the desktop. However, leveraging desktop-developed software may have some potential issues on the BeagleBone. Despite the potential issues, a desktop can prototype applications with a few caveats.

We then looked at software compilation for the BeagleBone. Next, we looked at the native compilation on the BeagleBone, which works just like a desktop. However, this process can be slower compared to a desktop. We also looked at the concept of cross compiling where we compiled software for the BeagleBone on the desktop. Cross compiling is faster but there can be complications.

As an example of building software, we built a C version of Hello, World for the BeagleBone in two ways. First, we natively...