Build Indicators
AKA: Das Blinkenlights
Date: 2017 — now
Status: Steady Green
I sometimes envy those that work in hardware. To be able to build something that one can hold and touch. It's something you really cannot do with software. And yeah, I dabbled a little with Arduino, setting up sketches that would run on prebuilt shields, but I never went beyond the point of building something that, however trivial or crappy, I could call my own.
Except for this one time.
And I admit that this thing is pretty trivial and crappy: little more than some controllable LEDs. But the ultimate irony is that it turned out to be quite useful for a bunch of software projects.Â
The Hardware
I built this Arduino shield a while ago, probably something like
2013. It's really not that complicated: just a bunch of LEDs wired up in
series to a bunch of resistors atop an Arduino prototyping shield. The
LEDs can be divided up into two groups of three, with each group having
a red, amber, and green LED, arrange much like two sets of traffic
lights. I'm using the analogue pins of the Arduino, making it possible
to dim the LEDs (well, "dimmed": the analogue pins are little more than
a square pulse with an adjustable duty cycle).
I can't remember why I built this shield originally: it might had something to do with train signals, or maybe they were intended as indicators right out of the box. But after briefly using them for their original purpose, it sat on my desk for a while before I started using them as indicator lights. Their first use was for some tool that would monitor the download and transcode of videos. This would take between 45–60 minutes, and it was good to be able to start the job, leave the room, and get the current progress without having to wake the screen while I pass by the door. The red LED will slowly pulse while the download was in progress, then the yellow LED will start flashing when transcoding begins. Once everything is done, the green LED will be lit (or the red LED, which will indicate an error). The Arduino sketch had a bunch of predefined patterns, encoded as strings. Each character would indicate an intensity, with "a" being the brightness, and "z" being the dimmest (I believe the space or dot meant "off"). Each LED could be set to a different pattern, which was done via commands sent over the RS-232 connection. I think the code driving this connection was baked into the download-and-transcode tool itself. The Arduino would reset whenever the RS-232 connection is formed, and just letting it do this when the tool started up meant that I didn't need to worry about connection state (it didn't make the code portable though).
Watching Webpack
Eventually this tool fell out of use, and for the long time this board sat in my drawer. Projects came and went, until one came along with a problem that was perfect for this device. I was working on a HTML web-app and I was switching between the code and a web-browser, while Webpack was watching for changes. Because I only had a single screen, the terminal was always out of sight — behind either the code editor or the web-browser — and the version of Webpack I was using would stop watching when it encountered an error (a Go application was serving the files, and Webpack was simply deploying the bundle assets to a public folder, so even though Webpack would stop working, the actual web-server will continue running). Not seeing these errors, I'd fall into the trap into thinking that I was changing things, and getting confused as to why I wasn't seeing them in the browser. I could go for a minute or two like this before I found out that Webpack died because of an earlier error and my changes were not getting deployed at all. So I dug this device out, built a very simple Go CLI tool and daemon that would talk to it, and hacked it into the Webpack config. When a Webpack build started, it would light up the amber LED. If the build was successful, the green LED would light up; if not, the red LED would.
/* * ledstatus - simple led indicators * * SERIAL FORMAT * * Commands take the form: <cmd> <pars>... NL. Any more than * 8 bytes (1 command, 7 parameters) will be ignored. * * Responses from the device will take the form: <status> <par>... NL * */ // Commands #define CMD_NOP 0x0 #define CMD_PING 'p' // a ping, which should simply respond with RES_OK #define CMD_TURN_ON 'o' // 'o' <addr> :: turn on the leds at these addresses #define CMD_TURN_OFF 'f' // 'f' <addr> :: turn off the leds at these addresses // Response #define RES_OK '1' #define PIN_ADDR_G1 (1 << 0) #define PIN_ADDR_Y1 (1 << 1) #define PIN_ADDR_R1 (1 << 2) #define PIN_ADDR_G2 (1 << 3) #define PIN_ADDR_Y2 (1 << 4) #define PIN_ADDR_R2 (1 << 5)
But in a way the simplicity actually helps here. Because it's now a command and daemon, I could use it in anything else where I'd like to show progress without having to see the screen. Just now, for example, I'm working on a Go project that uses Air to rebuild and restart whenever I change a template. The cycle is slightly longer than a simple Webpack run, and I tend to reload the browser window too soon. So waiting for this device to go from amber to green cuts down on these early reloads.
