Some people have reported an undocumented bug that can potentially corrupt the I2C bus. It occurs if an MCP230XX input pin state changes during I2C readout. This should be very rare. For more information, see this forum post and this knowledge base article.
In short, if I make a pin state change during I2C readout, it causes corruption in I2C bus.
My questions are,
Is there a workaround for this bug in software manner which does not limit a user's usage?
Is there better alternative of MCP23008 which supports I2C and interrupt? I know there's SPI variant MCP23S08 but I am looking for I2C first.
FYI, I am considering use MCP23008 for my DIY keyboard to expand I/O pins. Since a user could press or release each key literally anytime, even though the library page says the bug case is very rare, I don't think it is not so rare when using the chip for a keyboard, especially for instance during playing game such as MMORPGs which requires many skill rotations or... you know, rhythm games.
Where did the block quote come from? One of the links leads to a missing page page, the other gets quickly into weeds I think you are far away from.
Keyboard scanning activity (or anything with a human in the loop) makes relatively little tax on that part, which is used in circumstances where changes are significantly more frequent.
So why haven't we heard about this problem? Seems like it would have caused enough ppl enough hassle to make the news. My suspicion is that it is only a problem in some certain circumstances, which circumstances will not obtain in the simple use you intend.
Have you experienced the problem you are worried about? I applaud your foresight, it is best to avoid potential problems (and spending money), but you may be worryinfg without good cause.
There are certainly other port expanders. Also you could easily switch to SPI for the communication method. At the higher level, no one would need to know, or care.
Nope. Well, the condition seems consistent from the first link. I have to limit pin state change somehow during reading I2C, otherwise, this bug will be triggered. This is not about how fast a human can react in my case because I will use it for keyboard. Single MCP23008 provides multiple 8 GPIO pins so up to 8 key switches will be connected to a single chip and pressing multiple key in very close timing is not uncommon case.
Well, there's a way a use mentioned to recover from corruption but I am not sure I can use this.
Other one mentioned to enforce pin change exclusively which is not an option for my usecase.
THX, FYI you can undelete a deleted reply, at least for some time.
I'll read more when I get to the beach. I think the Umbrella Academy will take interest in this also.
Just now I have to reiterate my surprise that this is not a fatal flaw that would keep anyone from using the I2C version of the chip.
You could switch to the SPI part, which so far as I know just works, and have no I2C problem of any kind.
I've had good luck forever with I2C which luck ironically seems to have run out with my current exploitation of it… I'm getting bad behaviour I don't yet even understand, let alone know how to compensate for.