I’m not really a C kind of person. And so when I finished building my PiDP kit, I immediately started thinking, ‘Wouldn’t it be nice to use all these switches and lights from Python?’
Because Python really is my kind of language. You can be properly expressive in it. And there’s not all that nasty business with make files.
Fortunately, the RPi.GPIO library makes dealing with the Raspberry Pi’s GPIO pins a doddle. I’ve used it a lot with other projects. But first, a little reverse engineering was called for.
The creator of the PiDP, Oscar Vermeulen, is very modest about his coding skills. But when I started delving into his C source code, which is designed to run alongside SIMH, I was impressed. And for ‘impressed’, read ‘baffled’. Not that the code is impenetrable – it’s actually very well commented. It’s just that my ageing brain doesn’t parse C very well, and C isn’t what you’d call a self-documenting language.
Fortunately, Oscar has also published some technical notes on his site along with a handy schematic that helped me work out which LEDs and switches are operated by which pins. After about a day’s worth of hacking and cursing (my usual coding style), I had a Python 3 class that would selectively turn on lights, read switches … and crash.
And when I say crash, I mean unplug-the-bastard-and-swear-and-plug-back-in kind of crash. It was ugly. The program wouldn’t run for more than five minutes, often less.
The problem, I decided eventually, is that the matrix of rows and columns needed to drive 89 LEDs and 26 switches with the Raspberry Pi’s modest armoury of GPIO pins means the constant switching of pins between output and input, sometimes with the inputs needing use of the internal pull-up resistors. Somehow the system was tripping over itself. I re-read Oscar’s code and took out some of the bits of mine that I thought were clever.
For example, there are eight ‘rows’ of lights and three ‘rows’ of switches — at least from the point of view of the circuitry. Each row is controlled by a row pin. When setting the LEDs, I would try to set only the pin for the row currently being changed. And I did the same for the ‘column’ pins. But I noticed that Oscar would reset all the row or column pins before setting them again.
I did something similar and tried running the program again. After five hours without a crash I was ready to declare problem solved. If you want to review the results, they’re on Github.