Skip to content

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

Merged
merged 18 commits into from
Jul 29, 2021
Merged

Add SPI (MCP23SXX) devices #41

merged 18 commits into from
Jul 29, 2021

Conversation

Red-M
Copy link
Contributor

@Red-M Red-M commented Apr 26, 2021

No description provided.

@ladyada ladyada requested a review from a team April 26, 2021 13:51
@jposada202020
Copy link
Contributor

@Red-M if you could run pylint locally first, you could follow this guide. and run a
https://learn.adafruit.com/improve-your-code-with-pylint
If you are cloning this and creating a virtual env, you could run pre-comit run -all-files, the repository is already configured for that and make life easier :)

@Red-M
Copy link
Contributor Author

Red-M commented Apr 26, 2021

Thanks, I've run pre-commit and fixed all the issues there.

Copy link

@lesamouraipourpre lesamouraipourpre left a 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)

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

@Red-M Red-M Apr 28, 2021

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.

Copy link
Contributor

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.

@Red-M
Copy link
Contributor Author

Red-M commented Apr 28, 2021

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.

Copy link
Contributor

@jposada202020 jposada202020 left a 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

  1. 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
  2. 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
  3. 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 jposada202020 requested a review from kattni April 28, 2021 09:17
@Red-M
Copy link
Contributor Author

Red-M commented Apr 28, 2021

@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.

@jposada202020
Copy link
Contributor

@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.

@Red-M
Copy link
Contributor Author

Red-M commented Apr 28, 2021

Just getting the docs and examples ready to commit as well so the entire thing is all wrapped up in a neat little package.

@Red-M Red-M requested a review from jposada202020 April 28, 2021 09:56
@Red-M
Copy link
Contributor Author

Red-M commented Apr 28, 2021

Should be another commit coming in soon from my internal version control system.

@Red-M
Copy link
Contributor Author

Red-M commented Apr 28, 2021

This should be all good to merge now after reviews and CI testing.

@Red-M
Copy link
Contributor Author

Red-M commented Apr 28, 2021

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.

I actually have s17 chips coming soon and boards to use them on, should be here in about a week.

@dhalbert
Copy link
Contributor

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.

@dhalbert dhalbert marked this pull request as draft April 28, 2021 12:12
@Red-M
Copy link
Contributor Author

Red-M commented Apr 28, 2021

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.

@Red-M
Copy link
Contributor Author

Red-M commented May 5, 2021

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.

@Red-M
Copy link
Contributor Author

Red-M commented May 10, 2021

I have the chips and they're working perfectly, just missing the polarity inverse.

@Red-M Red-M marked this pull request as ready for review May 10, 2021 13:11
@evaherrada evaherrada changed the base branch from master to main June 7, 2021 19:00
@Red-M
Copy link
Contributor Author

Red-M commented Jun 13, 2021

Anyone mind reviewing this?

@ladyada
Copy link
Member

ladyada commented Jun 13, 2021

@caternuson wanna look after you finish the arduino side?


@io_control.setter
def io_control(self, val):
self._write_u8(_MCP23S17_IOCON, val)
Copy link
Contributor

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.

@caternuson
Copy link
Contributor

I'm working on a similar refactor for Arduino. So currently have a setup of each of I2C/SPI and 17/08 = 4 total variants. Tested this library with each for basic output (LED) and input (button). All work fine. Made a few suggestions in code review.

mcp_test

@Red-M
Copy link
Contributor Author

Red-M commented Jul 27, 2021

I've used some bitwise operators to just force bit 7 in the io_con register to 0 at all times regardless of user input.

@@ -259,6 +259,8 @@ def io_control(self):

@io_control.setter
def io_control(self, val):
val |= 0b000001
val ^= 0b000001
Copy link
Contributor

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".

Copy link
Contributor Author

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.

@caternuson
Copy link
Contributor

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.

@caternuson
Copy link
Contributor

OK. Cool. That fixed. OK, let's go with this as is.

@caternuson caternuson merged commit 63c459d into adafruit:main Jul 29, 2021
adafruit-adabot added a commit to adafruit/Adafruit_CircuitPython_Bundle that referenced this pull request Aug 4, 2021
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants