Skip to content

Update to use int1 for tap detection #19

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 3 commits into from
Dec 30, 2017

Conversation

kattni
Copy link
Contributor

@kattni kattni commented Dec 29, 2017

Includes example of creating int1 object in tapped documentation.

# Enable ADCs.
self._write_register_byte(REG_TEMPCFG, 0x80)
# Initialise interrupt pins
self._int1 = int1
self._int2 = int2
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

int2 is passed in but never used. Is it there for future-proofing?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that was the idea. There is an int2 and in the event a board is designed that uses it, we want the driver to work.

# Enable ADCs.
self._write_register_byte(REG_TEMPCFG, 0x80)
# Initialise interrupt pins
self._int1 = int1
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

int1 and int2 are supposed to be DigitalInOut objects that you pass in, but you finish setting up int1's direction and pullup here instead of assuming it's passed in already set up. How about just passing in the pin (e.g. board.D11), not a DigitalInOut? Then the driver can create and manage the DigitalInOut objects itself.

Assuming you do this, change the parameter names to int1_pin and int2_pin.

I'm interested in @tannewt's opinion here too. I do see that in SPIDevice in BusDevice, the chip-select pin is passed in as a DigitalInOut object. So maybe there's a style I'm missing here.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Passing in the DigitalInOut pin means it could be another compatible object instead. The only requirement we pose is that it provides value, direction and pull. So, this could actually be available through a GPIO expander. Taking the board pin restricts our use to directly connected pins.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it. I though you might want to duck-type something.

Copy link
Contributor

@dhalbert dhalbert left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My questions satisfied. Looks good to go!

@kattni
Copy link
Contributor Author

kattni commented Dec 30, 2017

Updated with @ladyada's changes. Both of us have tested successfully with single-tap, double-tap, on breakout board, and in a CPX CircuitPython test-build with the module frozen. This is ready to go!!

@ladyada
Copy link
Member

ladyada commented Dec 30, 2017

i'm into it, shall i merge @tannewt @dhalbert ?

@dhalbert dhalbert merged commit 74afff3 into adafruit:master Dec 30, 2017
tannewt pushed a commit to adafruit/Adafruit_CircuitPython_Bundle that referenced this pull request Dec 30, 2017
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.

4 participants