my third gpio app, now with external program data!

This is my third GPIO application, written in C++ with support from the Boost libraries. My purpose was to strip out the hard-coded LED manipulation pattern so that I could, in effect, “program” how the LEDs would light up, and for how long. I wrote it in comma-separated-value layout, so that it could be edited in either a regular editor or even in a spreadsheet. I’ve done this in the past with other applications because, whether you like it or not, spreadsheets (saved out as CSV) is how an awful lot of people organize information. This is again about approachability, this time with data. Before I present the source, let me present the file we can read now.

# This is an example blink data file
# These are comments that can be added to the 
# data file.
# Values are simple: a hex value with the bit pattern
# to turn on or off an LED (1 = on, 0 = off) followed
# by a delay in milliseconds.
# For example: 0x5,50
# 0x5 has the bit pattern 0101, meaning LED 0 is on,
# LED 1 is off, LED 2 is on, and LED 3 is off
# The wait is 50 milliseconds.

The data are the same hard-coded values that were in the earlier C-based application, including the delay in milliseconds. You can add comments to the data file, as many as you want, anywhere, as long as the comments are on their on line. The comment character, a ‘#’, has to be the first character in the string, although you can have spaces in front of the ‘#’. Blank lines are also considered comments.

Here is the source to the more elaborate blink application.

#include <wiringPi.h>

#include <boost/algorithm/string.hpp>
#include <boost/tokenizer.hpp>

#include <iostream>
#include <fstream>
#include <sstream>

// The data structure and collection into which
// we'll place our LED data and millisecond delays.

struct glyph {
    unsigned int data = 0;  // LED data
    int delay = 0;          // in milliseconds

std::vector<glyph> glyphs;

void loadBlinkData(std::string fileName) {
    std::ifstream inFile;
    std::string inLine;;

    while (std::getline(inFile, inLine)) {

        // Skip comments and empty lines.
        if (not inLine.length() || inLine[0] == '#') {

        // It's not a comment or empty line, so tokenize the lines
        // using the comma that separates the values.
        boost::tokenizer<> tokens(inLine);
        glyph g;
        std::stringstream ss;

        for(auto &&token: tokens) {
            if (token.find("x") != std::string::npos or
                token.find("X") != std::string::npos) {
                ss << std::hex << token;
                ss >>;
            else {
                g.delay = std::stoi(token);



int main () {

    pinMode(0, OUTPUT);
    pinMode(1, OUTPUT);
    pinMode(2, OUTPUT);
    pinMode(3, OUTPUT);


    for (int i = 0; i < 5; ++i) {
        for (auto &&g : glyphs) {
            // Just a series of shifts and ANDs
            // to create the bit necessary to
            // write out to the GPIO pin.
            digitalWrite(0, & 0x1);
            digitalWrite(1, ( >> 1 ) & 0x1 );
            digitalWrite(2, ( >> 2 ) & 0x1 );
            digitalWrite(3, ( >> 3 ) & 0x1 );


    // Turn everything off.
    digitalWrite(0, LOW);
    digitalWrite(1, LOW);
    digitalWrite(2, LOW);
    digitalWrite(3, LOW);

    return 0 ;

The big change is he addition of the loadBlinkData(…) function in place of the hard coded blink data in the prior application. This is where I switched from C to C++ to take advantage of some of C++’s and Boost’s features to both parse the text file as well as store up the parsed results. The main functionality has changed very little.

The datafile name is hard-coded as “blinkdata.csv”. I could have gotten more elaborate and written code to handle command-line input, but I was more interested in writing the parser. Perhaps later.

I am of a very mixed mind about the use of C++. I could have written the parser in a more straight-forward manner with Go’s built-in string package. Instead I had to go rummaging around Boost’s library (and install it) to keep the code down to a readable minimum. The for-each construct was nice to use, allowing me to hide explicit iterator declarations and concentrate on the collection and its individual elements. I also used the C++11 auto keyword and rvalue references (‘&&’), which simplified for-loop coding in significant ways. So C++ has evolved in some very useful ways. But really, the depths I go to to write code on such an itty-bitty machine in C++.

I decided to use C++ because the promise of the Go GPIO frameworks haven’t turned out to work for me. That’s not because of any limitation in the foundational languages. Arch Linux ARM for ARMv7 has native Go v1.6.2 packages, and using yaourt, I installed Rust 1.8 and Cargo. For Python, I have both versions 2.7.11 and 3.5.1. GCC comes out-of-the-box at version 6.1.1, meaning it has full support for C++11. Boost, via pacman, is at version 1.60.0. So I have all the necessary, native, up-to-date language tools that any software folk could want, running natively on my Raspberry Pi 3. When used for other non-trivial applications they seem to work just fine. It’s when I try to mix in libraries and frameworks that I run into issues, except, it would appear, for Wiring Pi’s libraries. And, of course, for node.js and onoff, using Javascript.

I know I wrote earlier about how I’d “permanently” moved to Raspbian. Well, after a bit of a hiatus away from the Raspberry Pi, I decided to go back and give Arch Linux for ARM another whirl. This time I haven’t had any issues, which may be due to my better understanding of how to use Arch, and possibly, just possibly, better quality in the Arch Linux ARM distribution itself. So I’m a happy Arch user again.

And before I forget, here’s the makefile I now use to build this thing. I hate makefiles, which is why I so wanted to use Go’s build or Rust’s cargo system. Anyway…

CC = g++
LDFLAGS = -lwiringPi

TARGET = blinks

all: $(TARGET)

clean: $(TARGET); rm $(TARGET)

$(TARGET): $(TARGET).c; \