Rethink interface

[tdicola]

Let's look at remaking the interface to less directly follow the Arduino and Raspberry Pi Python library (which also should probably be updated in the same way and eventually share the same codebase). Using properties to represent touch state might be more in line with python style.

Also consider for the touched function a variation that returns a 12-tuple of bools. This would allow a quick single I2C call lookup of all the touch state and make it easy to parse out results, like:

touched_pins = mpr121.touched_pins()  # Returns 12-tuple of bools
if touched_pins[3]:
    print('Pin 4 touched!')

[tannewt]

@caternuson or @kattni this sounds up your allies.

[caternuson]

The MPR121 has pads labeled with numbers 0 through 11. I'm thinking there should be an individual property for each one with names touch_0 through touch_11.

However, I'm seeing a couple of different syntaxes for touch being used for touch related properties.

CPX:

if cpx.touch_A1:
    print('Touched pad A1')

Crickit:

if crickit.touch_1.value:
    print("Touched Cap Touch Pad 1")

touchio

if touch.value:
    print("Touched!")

What should be done here?

[tannewt]

I like the latter two for this library because then the channel object can be passed around.

cpx is different because its at the highest level of abstraction where you are assumed to be using it directly.

[ladyada]

@tannewt TERRIBLE THOUGHT, maybe intstead of having 12 properties, we could use the array indexing so it returns an introspective class that can return the value:
if mpr121.touch[5].value: do_stuff
or could

touchobject = mpr121.touch[5]
print(touchobject.raw_value)

[tannewt]

@ladyada Good idea! I think @caternuson did something similar for an ADC chip.

[ladyada]

@caternuson would that be ok by you ^? cause then we could maybe get closer to consistancy across all touch devices/interfaces :)

[caternuson]

I'm fine with either and can code up either. I am in favor of consistency though. I think that is critically important given target audience for CP.

Here's the ADC @tannewt mentioned:
https://github.com/adafruit/Adafruit_CircuitPython_ADS1x15
BUT there's a chance I was going to change the way that worked based on the more recent development being done for the MCP3xxxx series ADC by @brentru which took a different approach:
https://github.com/brentru/Adafruit_CircuitPython_MCP3xxx/blob/mcp3008-work/examples/mcp3xxx_simpletest.py#L19
@ladyada I think you and @brentru were working that one out? Another example where I'm fine with either approach, but just want them to be consistent.

Would you change Crikict to match? Otherwise we would be presenting two different looking syntaxes:

crickit.touch_1.value

vs.

mpr121.touch[5].value

A beginner would look at those two and wonder why one has square brackety things and the other has an underline thing.

[ladyada]

yeah we can go back and change crickit. everything is inconsistant right now anways so i dont care if it isnt a 'clean sweep' thru all the captouch libraries :)

[caternuson]

Cool. Than I guess it could just be a question of which syntax is more beginner friendly? I'm a fan of the syntax the array indexing provides.

[ladyada]

i like array indexing myself - there's rarely just one captouch

[caternuson]

OK. I'll go that route then.

@tannewt Any other comments?

[tannewt]

Nope. I agree!

…

On Mon, Sep 17, 2018 at 9:01 AM Carter Nelson ***@***.***> wrote: OK. I'll go that route then. @tannewt <https://github.com/tannewt> Any other comments? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADNqejE48WxZT2bR3Lt_HeTX73DWpUJks5ub8ddgaJpZM4MsgIq> .

[dhalbert]

I suggested indexing before for some of the crickit stuff but was outvoted at the time 😄

[ladyada]

i think some crickit stuff we didnt have space for at the time, but we could try it now that we've optimized some stuff. i was really running out of room :(