Progress in UPSide, and a change of plans.

Much has changed in UPSide over the last week. Ground has been broken on the software; one key piece of the control daemon, the policy state machine, now exists.

The big news, though, is that I found Gobot, a Go service library for writing IoT-like stuff and robotics. It’s kind of a hardware abstraction layer that gives you access via Go to things like GPIO pins and two-wire buses without C or assembler glue code. Supports three dozen different platforms, so (it plausibly claims) you get to port your code across them with relatively small changes like the names of the GPIO pins.

This is a big deal. Not having to write and test that glue code will probably cut UPSide’s development time by a good 50%. But even more importantly, it will largely decouple our software from the idiosyncracies of whatever SBC we first develop it on. If it turns out we have to change hardware horses in midstream this greatly reduces the chances of that being a disruptive setback for the software.

Recently I wrote on buying options as a hedge against uncertainty. Using GoBot is a cheap buy that looks like a really effective hedge.

There is only one real drawback. The LIME2 SBC I have is not on their support list. But I had a BeagleBone Black, gifted to me by a hacker at a Penguicon one or two years back, lying around unused. And it has the USB gadget port we need. So I’ve said goodbye to the LIME2 – free to good home – and adopted the BBB.

This has had fast results. This afternoon I got Go+Gobot to blink an LED on the BBB, exercising the GPIO pins. The thread across the chasm – and the whole procedure to set up your BBB and cross-build environment to make that happen is documented.

This is already so much less painful than C/C++ would have been that I feel like grinning like a fool.

There is, however, one purely physical problem with the BB that’s going to be a huge pain in the ass when we fabricate, and may force us to a different SBC in the final design. It’s the placement of the ports. (Good thing “different SBC in the final design” is now thinkable without stark terror, eh?)

The Ethernet, USB gadget port, an power plug are on one short edge of the board. The host port and the micro-DVI are on the opposite edge. Which is OK if you’re just using it in a hobby case – but we’re planning to build it into a larger enclosure, and for that kind of deployment this is crazy. You really want all your external ports on one side where they can be presented through a cutout, the way PC cases do it.

The fact that the power jack points forward is especially irritating. It should have been swapped with the USB host port. (This at least is a mistake the RPi designers didn’t make.) And those LEDs are not important enough to take up scarce edge space – that should be where the micro-DVI comes out.

(The LIME2 had similar though less severe port-placement problems, including the forward-facing power port.)

Oh well. It’s good enough for breadboarding, and if I have to I can imagine a strangely shaped 3D-printed shroud that exposes the Ethernet port while leaving just enough room for a right-angled barrel plug inside it.

Wanted: Linux SBC with one host USB port, one gadget USB port, one Ethernet port, and a mini-DVI all one one edge, with the power jack and SD card slot on a different edge. Grumble…