-
Notifications
You must be signed in to change notification settings - Fork 36
Add SPI (MCP23SXX) devices #41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
@Red-M if you could run pylint locally first, you could follow this guide. and run a |
Thanks, I've run |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Caveat: I don't have the chips to test with.
These look like some great additions to the library. The bank bit in IOCON in mcp23s17.py is my main area of concern as I believe it will break the library if accidentally set (but without hardware I can't verify.)
pre-commit
passes locally and sphinx
builds the docs without issue.
The documentation needs an update but that can be done as a separate PR. If you want, I can do that for you just let me know.
|
||
@io_control.setter | ||
def io_control(self, val): | ||
self._write_u8(_MCP23S17_IOCON, val) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If bit 7 (bank) is set to 1 most of the the _MCP23S17_XXX constants will be wrong including the _MCP23S17_IOCON constant so it can't be unset.
You could either mask out that bit to prevent change and print out a warning or raise an exception. I'm not sure which is the best option.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't have the SPI chips just yet but I can test with real hardware in about a week or so when I get my PCBs in.
If I am understanding this correctly, then the MCP23017 implementation also has this bug.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think if the 2nd bank is disabled, any register values that are changed for the 2nd bank are not applied (but still recorded in the register and basically are not active until the IOCON register has bit 7 changed back to low) if the IOCON register bit 7 is set high because the MCP23017 implementation does the same as the MCP23S17 as far as I know.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The issue is how the additional registers of the 16 pin variants are addressed. There are two options, which the BANK bit of the IOCON registers determines. This library is hard coded with addresses for BANK=0. So someone could break things by sending in a value that results in the BANK bit being set to 1. I'd suggest checking the input value and raising an exception if that will happen.
Thanks for the review, I've made changes based on the feedback, I have a concern regarding the IOCON register value in the I2C implementation then. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hello, sorry I am late to the discussion, I think we discuss over discord over the weekend regarding this.
First Thank you for this: and thanks @lesamouraipourpre for reviewing
Some comments regarding the library, and then a more general kind of approach.
Library
- Functionality: Ideal, the library should continue working as it is, we can add things but people
ideally
should use the library the same way. we do not know how many projects are out there with this, and probably we do not want to break them - For new libraries, you could follow this guide,this provide some tips and tricks on how to create CircuitPython Libraries. There are some additions to it this week so keep updating it.
https://github.com/adafruit/circuitpython/blob/main/docs/design_guide.rst - For new libraries and functionalities it is preferable to include an example showing the new features
Other options and comments.
We could also include this new support in the community bundle, @kattni please advice regarding this
Either way we need to find a way to test, I could have access to S09/S18 not the S17. But I will need to order them. I am willing to test as I think is a fun project. and if @lesamouraipourpre help us out it could be a good addition.
@jposada202020 That is fine but I've not broken any existing code and the original MCP23SXX library owner is wanting to get this in as well per romybompart/Adafruit_CircuitPython_MCP23Sxx#1. These patches only add functionality while retaining the same exact structure to ensure backwards compatibility with zero changes required from any downstream projects. |
@Red-M No problem, thanks for this, just trying to put the general ideal out there what is optimal. I have not gone in deep through the code, lesamouraipourpre did a good job there already. |
Just getting the docs and examples ready to commit as well so the entire thing is all wrapped up in a neat little package. |
Should be another commit coming in soon from my internal version control system. |
Fix docstring for mcp23sxx.
This should be all good to merge now after reviews and CI testing. |
I actually have s17 chips coming soon and boards to use them on, should be here in about a week. |
Let's wait to merge until it's tested on actual hardware. I will make this a draft until then so it's not merged accidentally. |
No worries, will let you know how well the chips work. |
Annoyingly the vendor selling me the SPI variant didn't have their stock listed correctly so its going to be another 3 weeks before I get these chips in. EDIT: Now they've sent them even though its 3 weeks before the backorder date, so the chips should be about a week away. |
I have the chips and they're working perfectly, just missing the polarity inverse. |
Anyone mind reviewing this? |
@caternuson wanna look after you finish the arduino side? |
|
||
@io_control.setter | ||
def io_control(self, val): | ||
self._write_u8(_MCP23S17_IOCON, val) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The issue is how the additional registers of the 16 pin variants are addressed. There are two options, which the BANK bit of the IOCON registers determines. This library is hard coded with addresses for BANK=0. So someone could break things by sending in a value that results in the BANK bit being set to 1. I'd suggest checking the input value and raising an exception if that will happen.
I've used some bitwise operators to just force bit 7 in the io_con register to |
adafruit_mcp230xx/mcp23017.py
Outdated
@@ -259,6 +259,8 @@ def io_control(self): | |||
|
|||
@io_control.setter | |||
def io_control(self, val): | |||
val |= 0b000001 | |||
val ^= 0b000001 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're wanting to force bit 7 to 0 here? How about:
@io_control.setter
def io_control(self, val):
# force BANK bit to 0
val &= ~0x80
self._write_u8(_MCP23017_IOCON, val)
But it may be better to raise an exception since someone may think this gives them full access to the IOCON register, and for some reason they want to use BANK=1 mode (although not sure why that'd ever matter). The exception text could say something like "Only BANK=0 is supported".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if an exception should even be needed, I don't think its a valid usecase since if you don't need the extra pins, just don't use them.
Just also mentioning that this was also in the original code and is technically a bugfix.
I think adding something to the documentation and forcing the BANK
bit is enough.
The CI is failing due to an annoying sphinx quirk. It doesn't like the single backticks in the docstring used for code markup. If I remember right, the fix is to change the single backtick to double backticks on both sides. Or can just remove them. |
OK. Cool. That fixed. OK, let's go with this as is. |
Updating https://github.com/adafruit/Adafruit_CircuitPython_MCP230xx to 2.5.0 from 2.4.6: > Merge pull request adafruit/Adafruit_CircuitPython_MCP230xx#41 from Red-M/master > Moved default branch to main > Moved CI to Python 3.7 Updating https://github.com/adafruit/Adafruit_CircuitPython_SCD4X to 1.1.0 from 1.0.0: > Merge pull request adafruit/Adafruit_CircuitPython_SCD4X#2 from lesamouraipourpre/constants > Merge pull request adafruit/Adafruit_CircuitPython_SCD4X#4 from lesamouraipourpre/docs Updating https://github.com/adafruit/Adafruit_CircuitPython_SGP40 to 1.2.0 from 1.1.0: > Merge pull request adafruit/Adafruit_CircuitPython_SGP40#6 from caternuson/iss5 Updating https://github.com/adafruit/Adafruit_CircuitPython_MacroPad to 1.3.0 from 1.2.0: > Merge pull request adafruit/Adafruit_CircuitPython_MacroPad#15 from kattni/rotation > Merge pull request adafruit/Adafruit_CircuitPython_MacroPad#14 from kattni/display-image-fix Updating https://github.com/adafruit/Adafruit_CircuitPython_Simple_Text_Display to 1.2.0 from 1.1.0: > Merge pull request adafruit/Adafruit_CircuitPython_Simple_Text_Display#6 from terop/fix_doc_typo > Merge pull request adafruit/Adafruit_CircuitPython_Simple_Text_Display#5 from lesamouraipourpre/adaptive-row-height Updating https://github.com/adafruit/Adafruit_CircuitPython_Bundle/circuitpython_library_list.md to NA from NA: > Added the following libraries: Adafruit_CircuitPython_IS31FL3741
No description provided.