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.

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.