This is the chapter web page to support the content in Chapter 9 of the book: Exploring BeagleBone – Tools and Techniques for Building with Embedded Linux. The summary introduction to the chapter is as follows:

In this chapter you can learn how to build on your knowledge of GPIO and bus interfacing. In particular, you can combine hardware and software in order to provide the BBB with the ability to interact with its physical environment in the following three ways: First, by controlling actuators such as motors, the BBB can affect its environment, which is very important for applications such as robotics and home automation. Second, the BBB can gather information about its physical environment by communicating with sensors. Third, by interfacing to display modules, the BBB can present information. This chapter explains how each of these interactions can be performed. Physical interaction hardware and software provides you with the capability to build advanced projects; for example, to build a robotic platform that can sense and interact with its environment. The chapter ends by presenting a framework that enables you to remotely control the BBB using a wired serial connection or a wireless Bluetooth connection to a desktop computer or mobile device.

Learning Outcomes

After completing this chapter, you should be able to:

  • Interface to actuators, such as DC motors, stepper motors, and relays.
  • Protect the BBB ADC from damage using op‐amp clamping.
  • Condition a sensor signal so that it can be interfaced to the BBB ADCs, regardless of the output voltage levels.
  • Interface analog sensors such as distance sensors and accelerometers to the BBB.
  • Interface to low‐cost display modules such as seven‐segment displays and character LCD displays.
  • Use systemd to control services and create custom services that start when the BBB boots.
  • Use the BBB as a serial server, so that it can be remotely controlled.
  • Use Bluetooth to communicate with the BBB and have exposure to the steps involved in desktop application or mobile application control.
  • Build C/C++ code as a dynamic library to be used on the BBB.
Chapter 9 on a Breadboard

Figure 9-A1: Chapter 9 all on one breadboard!

Additional Content

The exploringBB Library

There are several examples in this chapter that leverage the code that is available in Chapter 6 and Chapter 8 of the book. One way that I could have written these examples is to copy the library code into each project directory; however, it would be incredibly difficult to make future corrections and keep the source-code examples up to date. Instead, the code from Chapters 6 and 8 is packaged as a library in the exploringBB/library/ directory.

For an example of how this is utilized, the LCDcharacter example in Chapter 9 consists of a single C++ program, LCDApp.cpp, which begins by including the LCDCharacterDisplay.h header and the exploringBB namespace:

There is no display sub-directory in this project, rather display is a sub-directory of the directory exploringBB/library/. Therefore, to build this code the following compilation instruction is used:

This instruction explicitly includes the shared library and also states that the exploringBB/library/ directory should be added to the include path (using -I), thus bringing the library include directory into the project. The advantages of this approach are:

  • The library code only exists in a single location, and any corrections are therefore applied to all of the examples in the repository — that is a very significant advantage!
  • The library executable code only exists in a single location on the BeagleBone, reducing its storage overhead.
  • The library executable code is compiled code that need not be compiled again. You have access to the text-format header files, but these are not “compiled” into your project. Therefore, compilation times are much faster.

The downside is complexity, but once you have the project structure in place then changes are reasonably straightforward. I would suggest that if you are planning to write a significant amount of code that you use this library directory as a template for your project. To ensure that the process is as seamless as possible, I modified the library in April 2015 to provide support for CMake.

CMake and the exploringBB Library

The make utility and Makefiles provide a build system that can be used to manage the compilation and re-compilation of programs that are written in any programming language. I use Makefiles quite often in my projects to automate the build process; however, there are times when Makefiles become overly complex for the task — particularly when building projects that have multiple sub directories, or projects that are to be deployed to multiple platforms.

The use of Makefiles is described in Chapter 11 (Pg. 439) in order to build Gtk applications. In that context, this discussion is somewhat premature but Chapter 9 is the natural home for this material, so please treat this as a placeholder to which you can revisit after you have completed the later chapters.

The article on my blog site: Introduction to CMake by Example describes how to use CMake in your projects, describing how you can build a simple project, build shared/static libraries, and to use a shared/static library in your application code.

Introduction to CMake by Example

An Introduction to CMake by Example (click to view the article)

The current directory structure of the exploringBB library is visible below:

You can modify the library code to suit your application, for example by adding additional C++ classes. Then, when you are ready you can rebuild the library using the following steps:

This process builds the shared library in the build directory. You can then place it in the parent directory for archival and then install it on your BeagleBone using a call to make install — this essentially places the library in the /usr/lib directory and therefore must be executed with superuser privileges:

If you so wish, you can delete the contents in the build directory after you have built the library.

If you add a new C++ class/file to the project, it is very important that you perform the cmake step again, as the generated Makefiles will not include the new class/file.

Digital Media Resources

Here the digital resources referred to in the chapter web page are provided. There are high-resolution versions of some of the important figures and links to videos, resources and websites that are described in the chapter.
Driving Stepper Motors with the EasyDriver Board

This video examines how we can drive stepper motors using C++ within Embedded Linux using the open source hardware EasyDriver board. The video begins by describing stepper motors and the effects of micro-stepping. It then discusses the EasyDriver Board (V4.4) and all of the available inputs and outputs. The board uses the Allegro A3967 which allows for full, half-, quarter and one eight micro-stepping. The video then explains C++ code that uses the GPIOs on the BeagleBoard to wrap the EasyDriver with a C++ class that is easy to use by creating an object of the class for each stepper motor that is connected.

Source Code

Some High-Resolution Figures from this Chapter

Here are high-resolution images of some of the more complex figures in this chapter, which may help you in wiring the circuits. Please note that you can close this pop-up window by pressing the Escape key.

External Resources

Important Documents

External Web Sites

The AM335x Technical Reference Manual (TRM)

The BeagleBone Black System Reference Manual (SRM)


  • Page 335, typo in figure 9-5 — the PDF input should be PFD input.
  • Page 336, Listing 9-3 refers to StepperMotor.h, not StepperMotor.cpp.
  • Page 346. There is a mistake in the calculation of the cutoff frequency (fc) that is carried forward to Figure 9-15. The equation should be R12C1 = 1/(2π x fc), where R12 = R1||R2 (i.e., R1 in parallel with R2). The top-left of Figure 9-11 should also read: fc = 1/(2π x R12C1). The calculation in Figure 9-15 should therefore read: R12C1 = 1/(2π x fc) = 1/(2π x 52Hz) = 0.00306. Since R12 = R1||R2 = 3080||6920 = 2131 Ω, C1 = 0.00306 / 2131 = 1.44 µF instead of 0.994 µF. Here is an update of Figure 9-15 that includes corrected calculations.
  • Page 353, Figure 9-16 contains an error. The two lines on the right-hand side of the figure have accidentally been reversed. The x-axis output from the ADXL335 should be connected to the 2IN+ input of the MCP6002 and the 2Out/2IN- output from the MCP6002 should be connected to the 3.3KΩ resistor. An updated figure is available in the image carousel above and can be downloaded and printed using this link: Figure 9-16
Click edit button to change this text.