I spent a bit of time today getting my various Raspberry Pi boards up to snuff. I worked with one Raspberry Pi 2 Model B V1.1 (in the foreground) and my newer Raspberry Pi 3 Model B V1.2 (background). Both boards are back to using Arch Linux ARM, my comments about going off on a tangent with Raspbian not withstanding. I’m using the RPi 3 as a “build system”, transferring binaries to the RPi 2. Specifically I’m writing code with Google’s Go (golang). The compilation of Go code on the RPi 3 is quite fast. Test Go binaries are secure copied (scp) from the RPi3 to the RPi2 for testing.

I’d written earlier on this blog about trying to use Go on the older Raspberry Pi B+, back when Go was around version 1.4, and back when there were no installable packages for Arch Linux ARM. Because of Go’s lack of full native support on ARM at that time I went off and used node.js and the onoff package to write code in Javascript to manipulate the GPIO pins. That experimentation proved quite successful. But I wanted the same capabilities using Go if at all possible for one very important reason: Go compiles down to a single binary that doesn’t need a special runtime and supporting packages to be installed.

Recently I came across Embd, a Golang-based framework for manipulating all of a Raspberry Pi’s peripherals. It also claims to perform the same way on the Beagle Bone Black, another strong attractor for me as I have a BBB as well. I installed Go V1.6.2 (the latest release) using the standard Arch Linux ARMv7 packages. git was also installed on the RPi3, so I grabbed a copy of embd on Github (go get github.com/kidoman/embd). Once that was accomplished I started to write simple Go applications and tried to see how it operated. And I ran into more than a few problems getting it to work.

An example of a problem I ran into, and my solution to prove that at least a part of embd works, was the sample application fullblinker.go. It’s a test application that’s supposed to toggle the green LED, next to the red power LED, on the corner of the RPi board. As originally delivered it turned the LED on, but it was a solid light, not blinking. After rummaging around a bit in the source, I modified fullblinker to actually blink the LED on the RPI3, then copied it over to the RPI2 and tested it successfully as well. The photo above shows the on state of the LED during the blink test.

// +build ignore// LED blinker, works OOTB on a RPi.package mainimport ("flag""os""os/signal""time""github.com/kidoman/embd"_ "github.com/kidoman/embd/host/rpi")func main() {flag.Parse()if err := embd.InitLED(); err != nil {panic(err)}defer embd.CloseLED()led, err := embd.NewLED(0)if err != nil {panic(err)}defer func() {led.Off()led.Close()}()quit := make(chan os.Signal, 1)signal.Notify(quit, os.Interrupt, os.Kill)defer signal.Stop(quit)var isOff   bool = truefor {select {case <-time.After(250 * time.Millisecond):if isOff {isOff = falseif err := led.On(); err != nil {panic(err)}} else {isOff = trueif err := led.Off(); err != nil {panic(err)}}case <-quit:return}}}

The changes I made to the code are highlighted above. I had to replace the Toggle() function with logic that maintained the LED on or off state, and explicitly call the On() and Off() functions (highlighted lines 43 to 53). Once flashing, this at least validated part of embd. One requirement for running fullblinker is the need to run with sudo (as root), which I’d managed to eliminate with the onoff nodejs GPIO application by using a special group with udev rules. Which appears to cause additional complications with embd, as none of the embd GPIO examples work, failing with a “write /sys/class/gpio/export: device or resource busy” error message. I’ve yet to dig into that problem, but I have several ideas on how to proceed to debug the issue.

embd is a start, along with node.js and onoff. I much prefer how the Javascript application was easy to set up, and I’m mulling over the idea of replicating the Javascript API in spirit to an equivalent GO framework, using what I can pick up from embd.

At this point you’re probably asking why bother? It’s so boring, so mundane. When Google talks about it’s AI TPU, or the net chatters about the rivalry between VR platforms, writing at this low a level on a $35 computer seems like such a waste of time. I can assure you it isn’t. Sooner or later you get back down to this level, and if it doesn’t work at this level then everything further up the stack goes to shit. One major driver to my working on this is my deep appreciation of the Go language, and my desire to use it here. Once I get it working to my satisfaction I’ll have tools that I can build upon, and perhaps something I can share back with the community. I’m just a regular engineer, not a disrupter, and as the Guardian once wrote, it’s the regular people who keep the world afloat.