Chapter 12: Prototyping with Breakout Boards

Custom board bring-up is what embedded Linux engineers are called on to do time and time again. A consumer electronics manufacturer wants to build a new device and, more often than not, that device needs to run Linux. The process of assembling the Linux image typically starts before the hardware is ready, and is done using prototypes that are wired together from development and breakout boards. Peripheral I/O pins need to be muxed into device tree bindings for working communications. Only then can the task of coding middleware for an application begin.

Our goal in this chapter is to add a u-blox GPS module to the BeagleBone Black. This requires reading schematics and data sheets so that necessary modifications to the device tree source can be generated using Texas Instruments' SysConfig tool. Next, we will wire up a SparkFun GPS Breakout board to the BeagleBone Black and probe the connected SPI pins with a logic analyzer. Lastly...

Technical requirements

To follow along with the examples in this chapter, make sure you have the following:

• A Linux-based host system
• A Buildroot 2020.02.9 LTS release
• Etcher for Linux
• A microSD card reader and card
• A USB to TTL 3.3V serial cable
• A BeagleBone Black
• A 5V 1A DC power supply
• An Ethernet cable and port for network connectivity
• A SparkFun model GPS-15193 Breakout
• A row (12 or more pins) of straight breakaway headers
• A soldering iron kit
• Six male to female jumper wires
• A U.FL GNSS antenna

You should have already installed the 2020.02.9 release of Buildroot in Chapter 6, Selecting a Build System. If you have not, then refer to the System requirements section of the The Buildroot user manual (https://buildroot.org/downloads/manual/manual.html) before installing Buildroot on your Linux host according to the instructions
from Chapter 6.

A logic analyzer helps with troubleshooting and understanding SPI communications...

Mapping schematics to the device tree's source

Because the BeagleBone Black's Bill Of Materials (BOM), PCB design files, and schematics are all open source, anyone can manufacture a BeagleBone Black as part of their consumer product. Since the BeagleBone Black is intended for development, it contains several components that may not be needed for production, such as an Ethernet cable, a USB port, and a microSD slot. As a dev board, the BeagleBone Black may also be missing one or more peripherals needed for your application such as sensors, an LTE modem, or an OLED display.

The BeagleBone Black is built around Texas Instruments' AM335x, a single core 32-bit ARM Cortex-A8 SoC with dual Programmable Real-Time Units (PRU). There is a more expensive Wireless variant of the BeagleBone Black made by Octavo Systems that swaps out Ethernet with a Wi-Fi and Bluetooth module. The BeagleBone Black Wireless is also open source hardware, but at some point, you may want to design...

Prototyping with breakout boards

Now that we have SPI working on the BeagleBone Black, let's turn our attention back
to the GPS module. Before we can wire up the SparkFun ZOE-M8Q GPS Breakout, we need to do some soldering. Soldering requires desk space, materials, and a considerable time investment.

To perform the soldering for this project, you will need the following items:

• A soldering iron (adjustable temperature) with a conical tip
• Any one of the following: a silicone car dashboard anti-slip mat, a silicone baking mat, or a ceramic tile
• A fine (0.031-inch gauge) electrical rosin core solder
• A soldering iron stand
• A wet sponge
• A wire cutter
• Safety glasses
• A Helping Hands tool, along with a magnifying glass and an LED light
• An X-Acto #2 knife with a #2 blade or #1 knife with a #11 blade

These items are nice to have but not necessary:

• An insulated silicone soldering mat
• solder wick
• A brass sponge
• Sticky tack...

Probing SPI signals with a logic analyzer

Even if you succeeded in receiving NMEA from your GPS module, you should attach a logic analyzer such as the Saleae Logic 8 if you have one. Probing the SPI signals helps us understand how the SPI protocol works and acts as a powerful debugging aid when things go wrong. In this section, we will use a Saleae Logic 8 to sample the SPI signals between the BeagleBone Black and ZOE-M8Q. If something is noticeably off with any of the four SPI signals, then a logic analyzer should make that mistake readily apparent.

The Saleae Logic 8 requires a laptop or desktop computer with a USB 2.0 port. The Saleae Logic 1 software is available for Linux, Mac OS X, and Windows. There is an installdriver.sh script that comes with the Linux version of Logic that grants the software permission to access the device. Find that script in the Logic installation's Drivers directory and run it from the command line so that you do not need to launch Logic with...

Receiving NMEA messages over SPI

NMEA is a data message format supported by most GPS receivers. The ZOE-M8Q outputs NMEA sentences by default. These sentences are ASCII text, starting with the $ character, followed by comma-separated fields. Raw NMEA messages are not always easy to read, so we will use a parser to add helpful annotations to the data fields.

What we want to do is read the stream of NMEA sentences from the ZOE-M8Q out of the /dev/spidev0.0 interface. Since SPI is full-duplex, this also means writing to /dev/spidev0.0, although we can simply write the same 0xFF value over and over again. There is a program called spi-pipe that is designed to do this sort of thing. It is part of the spi-tools package, along with spi-config. Rather than relying on spi-pipe, I chose to modify spidev-test so that it streams the ASCII input from the GPS module to stdout. The source for my spidev-read program can be found in this book's code archive, inside the MELP/Chapter12/spidev...

Summary

In this chapter, we learned how to integrate a peripheral with a popular SoC. To do that, we had to mux pins and modify the device tree source using knowledge gleaned from data sheets and schematics. Without finished hardware in hand, we had to rely on a breakout board and do some soldering so that the part could be wired together with a dev board. Lastly, we learned how to use a logic analyzer to verify and troubleshoot electrical signals. Now that we have working hardware, we can begin to develop our embedded application.

The next two chapters are all about system startup and the different options you have for the init program, from the simple BusyBox init to more complex systems such as System V init, systemd, and BusyBox's runit. Your choice of init program can have a big impact on the user experience of your product, both in terms of boot times and fault tolerance.

Further reading

The following resources provide more information about the topics that were introduced in this chapter:

• Introduction to SPI Interface, by Piyu Dhaker: https://www.analog.com/en/analog-dialogue/articles/introduction-to-spi-interface.html
• Soldering is Easy, by Mitch Altman, Andie Nordgren, and Jeff Keyzer: https://mightyohm.com/blog/2011/04/soldering-is-easy-comic-book
• SparkFun GPS Breakout (ZOE-M8Q and SAM-M8Q) Hookup Guide, by Elias the Sparkiest: https://learn.sparkfun.com/tutorials/sparkfun-gps-breakout-zoe-m8q-and-sam-m8q-hookup-guide