In this case, the viper in question is an old industrial control computer, based on an Intel PXA255 processor, in PC104 form factor, running a minimal linux. It was originally manufactured by Arcom Ltd, who have in the intervening years been taken over by Eurotech S.p.A. and comes with a nice complement of default communications options.
Mine is a standard “full-fat” Viper board, with no additional expansion cards, but mounted in an industrial enclosure with an integral UPS battery-backup. Sadly it’s been lying around gathering dust in my study for about the last 5 years, and as part of a recent attempt to tidy up some of my clutter I decided I either needed to make use of it, or get rid of it.
A little searching unearthed the power supply, and then, according to the little red LED on the back panel, we had life.
The first problem was how to talk to it. This is a true industrial device – no screen or keyboard. The options are either to telnet or ssh in over the network connection, or use an ASCII terminal over a serial connection. And therein lay the first problem; it didn’t connect to my network as I was expecting, leaving only the serial option open to me. But as I’m almost exclusively laptop-based these days, finding a machine with a serial port, and then a serial cable to link it to the Viper, took quite some effort.
But having done so, and set up minicom with the correct serial port parameters (helpfully documented in the Viper manuals) I was able to login to the Viper, at which point a little debugging of the network stack revealed the issue – at some point I’d defined the Viper with a static IP address, on a different subnet to my current home network.
A few quick edits to return it to DHCP operation, and a little configuration work on my home servers dnsmasq configuration returned the Viper to my home network, at a readily accessible IP address, allowing me to ssh in again.
At this point, having proved that the system is working again, I now need to decide what to do with it; and in this case, I’m going to use it as part of my plan to implement a set of DIY ambient orbs, as I mentioned back in this post. The Viper happens to consume only 9w while network connected, and has a built-in I2C interface, which can connect to BlinkM LED’s which I can mount in my B&Q Cubo housings. This will allow me to control the colour of the orbs from a program running on the Viper.
Better than that though, I can then install an MQTT client on the Viper, allowing my Viper program to subscribe to a topic on my home servers MQTT micro-broker. This will allow me to have the Viper change the colours of the orbs in response to messages published to the broker on my home server. At that point I can trivially integrate any sort of external input to the orbs just by administering my home server, & without needing to make further updates to the Viper.
So all I need to do now is to get the AEL development kit (cross-compiler etc) set up so I can write some code for the Viper, and then buy some BlinkM LEDs. Which sounds simple, but unfortunately the AEL development kit hasn’t been updated for some 4 years now, and isn’t keen on installing on my latest and greatest Ubuntu 10.10 development machine. I’ve put some calls out to colleagues who have also had experience with these Arcom Vipers, but so far no joy. Next step will be to see if Eurotech can provide a little help – after all, I suspect the original Arcom engineers will mostly still be working there. I guess the worst case will be to set up a *really* old Linux system in a virtual machine, and install the AEL development kit on that instead.