Showing two MCP23017 expanders soldered onto a PCB

MCP23017 Went Through Shortage Hell, Lost Two Inputs

February 3, 2023 by Arya Voronova 68 Comments

The MCP23017, a 16-bit I2C GPIO expander, has always been a tasty chip. With 16 GPIOs addressable over I2C, proper push/pull outputs, software-enabled pull-ups, eight addresses, maskable interrupts for all pins, and reasonably low price, there’s a reason it’s so popular. No doubt due in part to that popularity, it’s been consistently out of stock during the past year and a half, as those of us unlucky enough to rely on it in our projects will testify.

Now, the chip is back in stock, with 23,000 of them to go around on Mouser alone, but there’s a catch. Apparently, the lengthy out-of-stock period has taken a heavy toll on the IC. Whether it’s the recession or perhaps the gas shortages, the gist is — the MCP23017 now a 14/16-bit expander, with two of the pins (GPA7 and GPB7) losing their input capabilities. The chips look the same, are called the same, and act mostly the same — if you don’t download the latest version of the datasheet (Revision D), you’d never know that there’s been a change. This kind of update is bound to cause a special kind of a debugging evening for a hobbyist, and makes the chip way less suitable for quite a few applications.

It’s baffling to think about such a change happening nearly 20 years after the chip was initially released, and we wonder what could have caused it. This applies to the I2C version specifically — the SPI counterpart, MCP23S17, stays unaffected. Perhaps, using a microcontroller or shift registers for your GPIO expansion isn’t as unattractive of an option after all. Microcontroller GPIO errata are at least expected to happen, and shift registers seem to have stayed the same since the dawn of time.

The reasons for MCP23017 silicon getting cut in such a way, we might never know. At least now, hopefully, this change will be less of a bitter surprise to those of us happy to just see the chip back in stock — and for hackers who have already restocked their MCP23017 hoards, may your shelved boards magically turn out to have a compatible pinout.

Upgrade Board Adds GPIO Pins To Your Replica PDP-11

September 1, 2021 by Tom Nardi 10 Comments

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.

The PCBs for the expander have been released under the two clause BSD license, so you’re free to spin up your own copies however you see fit. But if you’d like to save some time, [Steven] is offering assembled boards on Tindie.

Since [Oscar] first teased it at the 2015 Hackaday Supercon, we’ve been enamored with his fantastic PDP-11 replica. We’re always glad to see when somebody has picked up one of these wonderful kits, and doubly so when they’ve figured out a way to expand it in unexpected ways.

Being An SPI Slave Can Be Trickier Than It Appears

January 8, 2019 by Kerry Scharfglass 10 Comments

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.