Category: Arch Linux

a tale told by an idiot

whbeebe

I have been wrestling recently with a series of self-imposed requirements that sprang from two personal needs; the first being the development of “sane” native tools and libraries for manipulating Raspberry Pi 3 built-in peripherals (GPIO being at the top of my list), and the second being a way to find a common language and framework that would work across multiple operating systems, those operating systems being Arch Linux ARM, Mac OS X, and Windows 10. And a web framework would be really nice to have because I’m really getting tired of having to use ssh all the time.

So I did a bit of research and decided to focus on Python, specifically version 3.5 and later. That version of Python is available across all those platforms, and appears to work equally well across them. That means that trivial and not-so-trivial Python applications that aren’t platform specific work equally well across all three. That means I can do a good deal of work on either my Samsung running Windows 10 or my MBP, which includes debugging. I would then transfer the code over to the RPi3 and do final integration there.

The problem I ran into was the choice of a Python web framework. For reasons I won’t go into here I decided to install and learn how to use Django. I’ve successfully followed the getting started tutorials on both the MBP and the Samsung. On the MBP I’ve used Homebrew  to install a number of up-to-date software tools, specifically Python 3.5, while on Windows I downloaded and installed Python 3.5 from the Python site. The only comments I have to make about installing Python on Windows 10 are these:

  • Install Python at the root of the C: drive (i.e. C:\Python3.5, for example). This makes the path to Python a lot shorter than where the default is, somewhere in your private user area.
  • Assuming you installed Python in C:\Python3.5 (for example) you should also add the Python Scripts folder to the path, i.e. C:\Python3.5\Scripts. This will put pip and django-admin in the path and make the instructions for using both the same as under Linux and Mac OS X. I don’t know why the tutorial instructions didn’t point this out.

As I said, running the Django utilities works just fine on Mac OS X and Windows 10. Getting Django installed on Arch Linux ARM doesn’t work, either as a pacman package or via pip. There is no package for ARM Arch, and even though the pip install seems to work, trying to create a default site with django-admin on Arch ARM fails, with django-admin complaining there is no django.core. This makes the second major framework failure I’ve run into under Arch ARM, the first being the failure of Express under Node.js. The Express failure was particularly annoying, as it worked about a year ago when I was investigating Express and Node.js on the Raspberry Pi 2. If anything, these failures have proven that the Raspberry Pi 3, at least under Arch Linux ARM, is not the full first-class client that regular installations are.

I suppose I could be a hero (to someone) if I could find and fix the problems I’ve run into on the Raspberry Pi 3, but I don’t feel particularly heroic. I’e gone down multiple paths now with trying to build a full stack of software with a web front end on the RPi 3, and it’s not gone well. One reason for doing the same types of activities on a “regular” computer is to see if the tutorials are repeatable, and they are. It’s trying to move over to the RPi 3 with Arch Linux where it breaks down.

Perhaps it’s time to realize that if I want a better development experience that I need to spend more money and buy a more commercial system than the Raspberry.

As for where the title came from, here it is:

Life’s but a walking shadow, a poor player
That struts and frets his hour upon the stage
And then is heard no more: it is a tale
Told by an idiot, full of sound and fury,
Signifying nothing.
Macbeth, Act 5, Scene 5

The quote about life could just as easily apply to software development.

gpio app evolves, and i come to accept coding in c++11

whbeebe

I am easily seduced by the new. I read about how wonderful something is, and I fall like a sack of potatoes for the sales pitch. In this case I fell for both Go’s and Rust’s sales pitch, without completely thinking things through, like how I would transition complex software already written in one language (C++) into equivalents in either Go or Rust. I also too easily bought into the “better, faster, safer” code argument for both Go and Rust.

I’ve had some time to try out both languages and various Raspberry Pi device frameworks, some of them written in Go, another written in Javascript, and at least one written in C/C++. It turns out that the C/C++ framework, WiringPi, is the most complete, and the one that works best for me. The Javascript framework is a very close second. In spite of some intense personal research into Go and Rust, I’m still a better C++ programmer (or at least, I understand it best) than I am in either Go or Rust. All of this combines to lead me one inevitable decision: write my code in C++ with what works best right now. And if I want “better, faster, safer” software then (re-) learn best C++ coding practices and use them diligently. And not just C++ specific best practices, but good old fashioned common sense best software engineering practices. If there’s one thing I’ve learned over time, it’s that no language will save you from a poor design: above all, KISS.

With that in mind, here’s the latest GPIO manipulation application source.

#include <wiringPi.h>#include <boost/algorithm/string.hpp>#include <boost/tokenizer.hpp>#include <iostream>#include <fstream>#include <sstream>struct glyph {unsigned int GPIOpindata = 0;int delayInMillis = 0;};std::vector<glyph> glyphs;bool loadBlinkData(std::string const fileName) {std::ifstream inFile(fileName);glyphs.clear();if (not inFile.is_open()) {std::cout << "Could not open " << fileName << std::endl;return false;}std::cout << "Using " << fileName << std::endl;std::string inLine;while (std::getline(inFile, inLine)) {boost::trim(inLine);if (not inLine.length() or inLine[0] == '#') {continue;}boost::tokenizer<> tokens(inLine);glyph g;for(auto &&token: tokens) {if (token.find("x") != std::string::npos or token.find("X") != std::string::npos) {g.GPIOpindata = std::stoul(token, nullptr, 16);}else {g.delayInMillis = std::stoi(token);}}glyphs.push_back(g);}inFile.close();return true;}std::string defaultDataFile("blinkdata.csv");int main (int argc, char *argv[]) {// Check to see if we passed another file on the command line.// If so, use it instead of the default.//if (argc > 1) {defaultDataFile = argv[1];}// Look to see if we can open and parse the file.// If not, stop.//if (not loadBlinkData(defaultDataFile)) {return 1;}// The input file was opened and parsed.// Now go to work.//wiringPiSetup();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 // write out to the GPIO pin. // digitalWrite(0, g.GPIOpindata & 0x1);digitalWrite(1, (g.GPIOpindata >> 1 ) & 0x1 );digitalWrite(2, (g.GPIOpindata >> 2 ) & 0x1 );digitalWrite(3, (g.GPIOpindata >> 3 ) & 0x1 );delay(g.delayInMillis);}}// Turn everything off.//digitalWrite(0, LOW);digitalWrite(1, LOW);digitalWrite(2, LOW);digitalWrite(3, LOW);return 0;}

Little improvements abound in this re-write.

  • Idiomatic C++11 is used as much as possible to avoid older C++ hacks (see the use of std::stoul at line 41 to convert the hex data string, for example) and cleaner reading code (see the for loops at lines 38 and 83, for example).
  • I use the One True Brace Style (1TBS) throughout, which frankly is just a variation of K&R brace style (the opening brace is on the same line as code). 1TBS helps these tired old eyes read code more easily. It also helps to minimize errors like Apple’s SSL/TLS “goto fail” bug.
  • More descriptive variable names are used throughout, and variables are declared close to where they’re first needed. Scope actually means something.
  • Rudimentary error checking now takes place, with quick exits that minimize resource usage on various failures. For example, the input data file is checked to see if it can be opened and parsed before any I/O devices are initialized.
  • I performed a static code check with cppcheck to make sure I haven’t missed anything like improperly uninitialized variables.
  • The code is compiled with ‘-Wall’ to get all warnings, and all warnings are treated as errors; they’re corrected.
  • Write the namespace (std:: and boost::) in front of elements explicitly, rather than use the lazy way of declaring a namespace globally with “using namespace namespace” at the top of source. I know exactly what comes  from where, which is quite useful when I revisit code six months after writing it.

It’s barely 100 lines long, but it’s an opportunity to get back into good C++ coding habits and to stay there than go off with a new, and unknown-to-me language.