I’ve been hunting lately for code examples for manipulating the peripherals on the Raspberry Pi, all three versions. Up to this point I’ve been able to work with the peripherals, especially the GPIO pins, using node.js and onoff. But I was looking for something that was more self contained, with the idea I could build it into a stand-alone executable for deployment. I’ve been investigating many projects such as Gobot and embd. Unfortunately, after going to a lot of trouble, such as installing Go 1.6.2 (the current release) and git, and doing pulls for both from Github, and building simple applications using both frameworks, nothing worked for me.

So I went off looking for any C/C++ frameworks and examples, and came across Wiring Pi. From there I downloaded and installed their C framework, and modified one of the C examples, to replicate the Cylon LED cycle I first wrote in Javascript using node.js and onoff. Here’s the sample C code.

#include <wiringPi.h>int main () {wiringPiSetup();// These pins correspond to GPIO 17, 18, 27 and 22.//pinMode(0, OUTPUT);pinMode(1, OUTPUT);pinMode(2, OUTPUT);pinMode(3, OUTPUT);for (int i = 0; i < 20; ++i) {// We'll scale up...//digitalWrite(0, HIGH); delay(50); digitalWrite(0, LOW);digitalWrite(1, HIGH); delay(50); digitalWrite(1, LOW);digitalWrite(2, HIGH); delay(50); digitalWrite(2, LOW);digitalWrite(3, HIGH); delay(50); digitalWrite(3, LOW);// ... then appear to scale back down with the middle two// LEDs. LED 0 will then turn on at the top of the loop// completing the illusion.//digitalWrite(2, HIGH); delay(50); digitalWrite(2, LOW);digitalWrite(1, HIGH); delay(50); digitalWrite(1, LOW);}// Make sure to turn everything off.//digitalWrite(0, LOW);digitalWrite(1, LOW);digitalWrite(2, LOW);digitalWrite(3, LOW);return 0;}

It compiles and works as long as I run it with sudo. So right now, by relaxing some of my requirements (implemented in Go, stand-alone binary, must not use sudo) I have something other than Javascript that works. I’ll investigate further to see if I can create a parallel implementation in Go, or possibly even Rust. I prefer Go over Rust because there’s an Arch Linux ARM package for ARMv7 and later that’s up to date. Tooling under Arch on ARM is excellent, and I’d rather use as much pre-existing languages if possible.

Again it’s late and I’m tired and tomorrow is another workday. The three-day Memorial weekend is coming up; hopefully I can be a bit more verbose about these subjects.