In 2013, I found myself on a team working to build a flight simulator of the Boeing 787 Dreamliner. To understate, this was an exciting opportunity. The first 787 had only been delivered into service 2 years prior, and the airplane was the buzz of the flight training industry. The avionics of the 787 are part of an evolutionary leap known as Integrated Modular Avionics (IMA), where the software pieces are made portable, hosted on shared hardware resources and networked together throughout the plane. The effort required to build a simulation referencing, and even using parts from, this state-of-the-art, world-class marvel of aviation was tremendous. The project took the full team nearly 2 years to finish. Everyone, and I mean everyone, engineered at a championship level. I spent many of my free hours in study to meet the challenge, and eventually, in June of 2014, I bought myself a BeagleBone Black (aka ‘the Bone’) as a study tool for deploying custom-built Linux kernels. Eventually those studies ended, and I put the Bone in a manila envelope – to the back of the drawer it went! Now, more than 7 years later, I’m ready to play with my Bone again.
The Envelope Contents
The BeagleBone Black (BBB) is a Single Board Computer (SBC), and as such is a very capable device. The device alone looks a bit alien compared to traditional computers, and this isn’t necessarily a bad thing. The Bone is an alien compared to traditional computers! It comes with no case, provides female headers for a variety of electrical connections and has no graphical desktop operating system preinstalled.
A few accessories were required for my study back in 2014, and I saved them in the envelope. After some light testing, however, I discovered that not everything survives 7 years in a drawer. The USB debug cable, for TTL serial communications, failed. I also found only the SD card adapter and not the microSD card itself. Keep this in mind as you review the inventory with me below – I had to purchase some replacements for these parts!
These are my recommended bare-minimum components for starting out with the BBB. Considering the result is a Linux computer the size of an Altoids can, the BOM is quite palatable – coming in under $120 total:
Part | Link | Typical Price |
---|---|---|
BeagleBone Black | Mouser Electronics | $55 |
miniUSB to USB Type A Cable | Amazon | $6 (Usually included) |
+5V DC 2A Power Supply | Amazon | $12 |
TTL Serial to USB Cable | Amazon | $18 |
32GB microSDHC Card | Amazon | $15 |
Plastic Case | Adafruit | $10 |
This kit is essential to study the bootloader, board imaging and deployment, cross compilation, and the runtime operation of the embedded software. These were my original goals, and as usual, the old Bone did not disappoint!
Do note the barrel jack on the power supply should be center positive, and the outer/inner diameters are 5.5mm/2.1mm respectively. Also, take care to use a 3.3V version of a TTL serial cable.
Reference Materials
I originally purchased the BBB as a test target machine for deploying customized Linux images. With online resources readily available for Das U-Boot (the BBB bootloader) and The Yocto Project (the embedded Linux build system), I had everything at-hand to accomplish my task. Now, however, I intend to explore the capabilities of the BBB to interface to external components. For this my learning curve is much steeper, because my professional career to-date has a near-exclusive focus on software.
I researched extensively to identify some materials to guide this journey. My results are as follows:
Make Electronics: Learning Through Discovery by Charles Platt
This text is surprising affordable, coming in less than $20 in paperback. The ordering and cadence of topics is teaching at its best. The book is aimed at the electronics beginner, so pick it up if you are new to circuits. My kids have also enjoyed reviewing some of the breadboards I put together during my studies, and when they are older I believe this text will be getting a fresh read from younger eyes.
While it is possible to gather experimental components for this book a-la-carte, I recommend purchasing a parts kit to speed the process along. This cost adds up — roughly $150 for both kits 1 and 2. However, it’s a nice starting point of a components for future builds of your own. Make sure to buy a kit that matches the edition of the text you are reading!
In addition to the parts, a basic multimeter is required to follow along with this text. I’ve had one for years I use to check batteries and work on the occasional electrical socket (thanks dad), but a digital version with a few more features is an easy and affordable upgrade. See my review of the Extech EX410A Multimeter if you are in the market.
Exploring BeagleBone by Derek Molloy
This book is affectionately known as the “BeagleBone Bible”, and rightly so! Pick it up for less than $30 in paperback. Truthfully I haven’t finished this read yet. I have skimmed ahead, though, and I am really excited about how much this text has to offer. This kind of work is sure to inspire the maker in me, and I anticipate the work to read it will pay dividends towards my efforts to build content on this site!
I had hoped, with the parts kits I have from my read of the Platt book, that I would get through most of the study without needing to buy much else. (I have a wife, and despite her aversion to math, she will eventually start adding up the cost of my new toys.) Unfortunately, the preface BOM omits test equipment that is called for in Chapter 4: Interface Electronics. In this chapter, the author makes a strong case for the Digilent Analog Discovery 2, which packs a whole lab’s worth of tools into a USB form factor. Frankly, I took the recommendation and picked up a kit that includes oscilloscope probes. Check back soon for a review!
The Development Environment

The BBB has a new home on my desk for a reason – I want to learn about circuits and electronics hardware to make cool stuff! The BBB provides ample interfacing for electronics hardware, and it does so on a platform that offers the world of software possibilities that is embedded Linux. With the better part of my career devoted to software architecture, I fully intend to approach this exploration with an efficient development environment.
Essential Computing
I’ll be using the following compute resources to accomplish tasks for projects in this series.
Linux
It is my belief that a desktop or server running Linux as a support machine is a must to develop for embedded Linux. Common Linux distros, like Ubuntu, have easy package managers with rich repositories of open-source software backing them. As a result, setting up critical services for target devices, like TFTP and NFS, is relatively easy. Another straightforward Linux component is the cross-compiler. The BBB uses the AM335x 1GHz ARM® Cortex-A8 processor, so a native compiler from a PC likely won’t produce binaries that run on it. While it certainly is possible to compile source code directly on the BBB, I wouldn’t recommend it beyond the most trivial of applications. A cross-compiler will enable you to build your code on the Linux machine and deploy it to the BBB as a binary. This is the most productive configuration for developing software for the BBB, as you can leverage the more powerful and ample resources of the support machine to work faster.
The easiest way to stand up a Linux box is to use a Virtual Machine (VM). Using a VM is a natural fit for Linux, especially when the workload can be serviced using only a network connection. That said, I happen to have an Ubuntu Linux desktop available, since I needed to Breathe New Life into an Old Mac anyway. If you don’t have spare hardware on-hand, though, most definitely virtualize a Linux instance on your current Windows or Macintosh desktop and carry on!
Windows or macOS
Full disclosure – my Linux box is not my only development host. I find that sometimes I need to use peripherals without Linux drivers. I also use software that isn’t available on the Linux OS. As such, I keep a Windows machine spun up for content and software development, too! The system I’m using at a given moment is simply a choice of the best tool for the task at-hand.
My intention is to use Windows Services for Linux (WSL) to install a cross-compiler to use locally on the Windows machine. This will allow me to work flexibly on either operating system. Look for a future post for the breakdown!
KVM
Using a separate keyboard, mouse and monitor for each platform is frankly not my idea of productivity. Luckily, technology exists to switch the same Keyboard, Video and Mouse (KVM) between multiple computers at the push of a button. I have used multiple KVMs over the course of my career, and my favorite to-date is the StarTech SV431DD2DU3A. I have this little gem consuming DP, HDMI, and DVI from a full set of inputs and outputting to a set of HDMI monitors. The source switching is reliable and the USB hub works hassle-free. If you work with multiple computers (Windows, Macintosh or Linux) increase your context switch efficiency and pick one up for yourself.
The Software Development Cycle
Allow me to step onto my soapbox…

An efficient development environment is one that caters to the development cycle, as pictured above. Each of the three tasks in the cycle must be optimized. Efforts to do so, on any substantial endeavor, will both improve developer engagement and reduce time required to complete the project.
Edit
- Creation of a new working copy must be trivial, consisting of source code either:
- From the latest development
- As-was at a historical reference point, such as a release
- The software editor must:
- Support syntax highlighting for the language displayed
- Suggest autocompletions for variables, functions, etc within the current scope
- Operate quickly
Compile
- Compilation must:
- Be invoked with a single button or script
- Complete within a short period time
- Report results immediately
- Build results must:
- Generate outside of the sources file tree
- Sync or post to the run/debug environment easily or automatically
Debug
- A single button or script must launch the compiled binary
- The command line and arguments must be cached for easy reuse
- The runtime environment should be present or remote-accessible from the development workstation
The Hardware Test Space

I’m just getting started here, so setting up my workspace will be an ongoing adventure. I already have soldering tools, some hookup wire, a few electronics, and a rubber table mat. Oddly enough, the mat was a bit more difficult to sort out. I have previously worked for a company that has manufactured and sold millions of computers, servers and storage devices. During my tenure in that position, I was trained on Electrostatic Discharge (ESD). Static electricity can easily discharge from your person to a sensitive device, like an integrated circuit. A significant portion of failures can be attributed to ESD damage — even when those failures manifest months or years after the event. To remedy, precautions must be taken. The workspace must be grounded, and the worksurface must meet a standard for dissipation of electricity. Buy and use a static control grounding mat from a reputable supplier, like Digi-Key. I settled on the SCS 770074. This mat resists the heat of solder and meets the static dissipation requirements of ANSI/ESD STM4.1-2017.
Wired and Ready to Bone

I have my books downloaded. My BeagleBone Black and a breadboard are wired up to my standing desk — with separate power supplies even. My worksurface is covered with a custom-cut mat and grounded for proper ESD dissipation. My test equipment is ready, and my toolbox is stashed for quick access. It’s time to create!
Thanks for reading, and be sure to subscribe to catch the next project!