Enable reporting of individual pins

[soundanalogous]

In order to support a change from defaulting all pins to OUTPUT on startup, to defaulting to INPUT, we will need the ability to enable individual digital pins rather than entire digital ports.

0  START_SYSEX            (0xF0)
1  REPORT_DIGITAL_PIN     (0x63)
2  pinNumber              (0 - 127)
3  reportingEnabled       (0 | 1)
4  END_SYSEX              (0xF7)

Once this is in place, digital port reporting (0xD0) should be deprecated. The reason is that when the pin mode is set to INPUT (electrically much safer and should also fix issues users have with relays) rather than OUTPUT by default, non grounded pins (or pins without pull-ups enabled) will report stray voltages and DIGITAL_MESSAGE would report these as pin changes. When REPORT_DIGITAL_PIN is added, Firmata should not report a pin value for any pin that is not enabled (much like how analog pin reporting currently works). This will prevent reporting stray voltages as input pin state changes.

[soundanalogous]

It may be useful to make this message work for both analog and digital pins since the current report analog pin message (0xC0) is limited to 16 pins, while some boards have more than 16 analog pins. A version that works for both analog and digital could look like this:

0  START_SYSEX            (0xF0)
1  REPORT_PIN             (0x63)
2  pinType                (0: digital | 1: analog)
3  pinNumber              (0 - 127)
4  reportingEnabled       (0 | 1)
5  END_SYSEX              (0xF7)

or

0  START_SYSEX            (0xF0)
1  REPORT_PIN             (0x63)
2  pinNumber              (0 - 127)
3  reportingEnabled       (bit 0: enabled 0 | 1, bit 4: type 0 = digital | 1 = analog)
4  END_SYSEX              (0xF7)

[gkzsolt]

Can't we infer the pin type from the pin number? (I don't remember exactly if an analog pin can be used as digital, and how relevant this would be.)

[gkzsolt]

Do you receive any email notifications from the comments? I always have to check the page.

[soundanalogous]

Can't we infer the pin type from the pin number? (I don't remember exactly if an analog pin can be used as digital, and how relevant this would be.)

Generally, but not always. There are some boards (such as some of the Teensy boards) that have a few analog only pins. The analog to digital pin mapping is not always straight forward either (if you look at Leonardo for example) so having a way to specify analog vs digital is useful in reducing chance of user (or even library author) error.

Do you receive any email notifications from the comments? I always have to check the page.

Make sure you set the status at the top of the page to "Watching" (next to where you can Star and Fork) and then I think you should get emails whenever a new comment is posted.

[soundanalogous]

There is also a Notifications button on bottom of the right hand column of this page so that may be another way to ensure you are notified of updates to a thread.

[soundanalogous]

I guess the pinType could be inferred from the pinMode since the user should set the pinMode before they enable a pin (these two steps could be combined in a client library). The only risk there is enforcing the order, but I guess we could assume Digital if no pinMode is specified for a pin when the ENABLE_PIN message is received.

[gkzsolt]

I solved the notification issue, thanks (the "Watching" status is useful, curiously the Notifications at the bottom of the page was set, but with no effect. I set also some options in my GitHub profile.)

[soundanalogous]

My latest thoughts on this are that we should use my initial proposal:

0  START_SYSEX            (0xF0)
1  REPORT_DIGITAL_PIN     (0x63)
2  pinNumber              (0 - 127)
3  reportingEnabled       (0 | 1)
4  END_SYSEX              (0xF7)

Then add a separate EXTENDED_REPORT_ANALOG message, since the existing REPORT_ANALOG is sufficient for the majority of compatible boards (up to 16 analog pins). This would also be more inline with how the ANALOG_MESSAGE command was extended via EXTENDED_ANALOG as defined here.

[gkzsolt]

Makes sense, since there is already a REPORT_ANALOG with one data byte for the pin. It may seem a bit inconsequent to have REPORT_ANALOG for a pin, REPORT_DIGITAL for a port and REPORT_DIGITAL_PIN for a pin, though.

[soundanalogous]

I'll rename REPORT_DIGITAL to REPORT_DIGITAL_PORT when these changes are made in order to make that distinction clear.

[gkzsolt]

Thanks ;)