Closed nkrackow closed 2 years ago
Hey, @nkrackow thank you for reaching out! I agree from a shallow analysis that the difference is just a little. I think that to address this issue, we cannot support MCP23008 in this repo, but I think we can follow different approaches:
What do you think about it? What approach do you think it's the best? Do you have any other suggestions or thoughts?
Yes I was thinking about the naming too. Starting a new repo for only the MCP23008 would mean potential changes here or there would have to be updated in the other repo. But your code looks to be pretty well tested so maybe that's not gonna be a problem much. But I think it's better if I just make a MCP230XX repo based on yours and once my changes are tested a bit we can think about deprecating this one?
Yeah, I see. So what I propose is this: you can fork mcp23017 repository and proof that with some changes, it would also work with MCP23008. At that point, when you test your implementation, I can mark mcp23017 as obsolete and create a new repository MCP230XX, that supports both devices. Do you agree with this plan?
Sound good! It might actually take a few weeks until I have the hardware I want to use this for. So I'll just come back to you here once I've tested the modifications.
@nkrackow great! Thank you so much!
Hi, just FYI we ended up refactoring almost everything and have mcp230xx now here: https://github.com/quartiq/mcp230xx
Hello :) I am looking into using this driver for the MCP23008 wich, afaict, is exactly the same chip with just one IO bank.
The only thing that would need to change is to be able to use the addressing of
IOCON.BANK=1
aka being able to change this field on the MCP23017 and then using the other addresses. Writing this field on the MCP23008 has no effect.Then you could use the exact same driver with just the first IO bank for the MCP23008.
What do you think of this proposal? Would you accept a PR if I implement these (small) changes?