Digital IO instances need a `mode` property

[dtex]

In the event that a peripheral library provides higher-level functionality that augments a digital pin and that library accepts a digital IO instance in its constructor (as opposed to an io configuration object), it must be able to know the mode. A pullup resistor will invert the values used to detect if a circuit is open or closed.

I think we need a read-only mode property to handle this.

This is similar to the resolution property on analog where we need to know the resolution in order to evaluate the input.

[fivdi]

A pullup resistor will invert the values used to detect if a circuit is open or closed.

I'm not sure I understand here. I think the main goal of an internal pullup resistor is to ensure that an input pin reads as 1 when it would otherwise be floating.

[dtex]

Sorry, I opened the issue while working on too much and was conflating two different things... maybe three.

Nevermind

[dtex]

My initial concern might be valid. I'll test tonight.

[phoddie]

@dtex - I've been quietly following this thread because I'm not sure I understand it yet.

I recently implemented a Button class that follows the Peripheral Class Pattern and handles inverting the sense of the input. It accepts a invert property on the options object to control the behavior instead of looking at the input mode. I'm not ready to take position on which is better or more correct, but I thought the example might be useful to this discussion.

Note: the API of Button follows the Peripheral Class Pattern but the implementation uses Moddable SDK APIs, not the IO Class Pattern API.

[dtex]

It sounds like you understand my issue. The invert property is a perfectly fine solution but it bugs me a little

It seems less than ideal that a user would need to pass mode: inputPullUp and invert: true to the Button constructor. Since the button constructor instantiates the IO on behalf of the user it can invert based on the mode (it already knows it needs to invert the values).

To complicate things a bit more, you might have a button that is normally closed and only open when pressed . invert might need to be reserved for that since your active state is "pressed".

The only difference with my original issue is that I was thinking of a Button class that accepts an existing instance of IO. Here too we could require that the user pass invert: true to the Button constructor, but if the Button constructor could just check the mode of the IO we could save the user from some mental gymnastics (pullup resistor + normally closed switch + invert = 🤯 ).

Like many things I bring up, this might be higher-level stuff that libraries can worry about. This scenario does not match the peripheral class pattern.

[phoddie]

@dtex - I wasn't comfortable assuming that every time pull-up is selected that invert is appropriate. I also think there are cases where pull-up is not selected (external pull-up, for example) where invert still needs to be set.

But, I agree that most developers shouldn't need to tangle with that. Since the physical details depend on the board, the software details should go in the host. Here's one host that uses the Button, a NodeMCU ESP8266 board:

To use the built-in button on the board, a developer doesn't need to write the pin, mode, or invert properties.

new Host.Button.Default({
   onReadable() {
     // do whatever
   }
})