Like many Hackaday readers, [Steven Stallion] has had his eyes on the replica PDP-11 created by [Oscar Vermeulen] for some time now, and this summer he finally got the opportunity to build one himself. But while most owners might be content to just watch the Raspberry Pi based faux-retro computer blink away on a shelf, he wanted to explore putting the machine to more practical use. The end result is the PiDP-11 I/O Expander, an add-on that lets the modern minicomputer interact with the world around it.
Developed after some discussion with [Oscar] himself, the Microchip MCP23016 based expander board fits neatly onto the PiDP-11 PCB, and [Steven] has made sure his installation guide meshes well with the replica’s documentation. The Pi’s I2C bus is actually broken out on the original PCB, so you just need to solder a header on and run some jumpers to where the expander is mounted. You’ll need to pull 5 V as well, and the installation guide has a few tips on convenient connection points.
Each expander board gives you 16 GPIO pins which can be accessed over I2C, including support for interrupts which has been connected to GPIO 19 on the Raspberry Pi. [Steven] notes that you should be able to stack multiples of his expander up should you need even more free pins, though some fiddling with pull-up resistors and I2C addresses will likely be necessary.
Interfacing with the outside world is a fairly common microcontroller task. Outside of certain use cases microcontrollers are arguably primarily useful because of how easily they can interface with other devices. If we just wanted to read and write some data we wouldn’t have gotten that Arduino! But some tasks are more common than others; for instance we’re used to being on the master side of the interface equation, not the slave side. (That’s the job for the TI engineer who designed the temperature sensor, right?) As [Pat] discovered when mocking out a missing SPI GPIO extender, sometimes playing the other role can contain unexpected difficulties.
The simple case for a SPI slave is exactly that: simple. SPI can be wonderful in its apparent simplicity. Unlike I2C there are no weird addressing schemes, read/write bits, stop and start clock conditions. You toggle a clock line and a bit of data comes out, as long as you have the right polarity schemes of course. As a slave device the basic algorithm is of commensurate complexity. Setup an interrupt on the clock pin, wait for your chip select to be asserted, and on each clock edge shift out the next bit of the current word. Check out [Pat]’s eminently readable code to see how simple it can be.
But that last little bit is where the complexity lies. When you’re the master it’s like being the apex predator, the king of the jungle, the head program manager. You dictate the tempo and everyone on the bus dances to the beat of your clock edge. Sure the datasheet for that SRAM says it can’t run faster than 8 MHz but do you really believe it? Not until you try driving that clock a little quicker to see if there’s not a speedier transfer to be had! When you’re the slave you have to have a bit ready every clock edge. Period. Missing even a single bit due to, say, an errant print statement will trash the rest of transaction in ways which are hard to detect and recover from. And your slave code needs to be able to detect those problems in order to reset for the next transaction. Getting stuck waiting to send the 8th bit of a transaction that has ended won’t do.
Check out [Pat]’s very friendly post for a nice refresher on SPI and their discoveries working through the problems of building a SPI slave. There are some helpful tips about how to keep things responsive in a device performing other tasks.