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 ;)

[soundanalogous]

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

[mdlima]

Hi all. First, thanks for the amazing work on firmata, really incredible how this enable so many other projects.

I've been developing a plant monitoring system and that includes moisture sensors. For those, I really don't want to have them connected to Vcc all the time as the current drawn will increase corrosion (see this Soil Moisture Sensor Hookup Guide).

To cope with this, I need two changes to the way analog readings are done: 1- Separate (much longer in my case) sampling intervals per sensor 2- Linked power source (any digital pin) to be enabled before the reading and disable afterwards

My idea is to implement the individual reporting per pin using the planned EXTENDED_REPORT_ANALOG, passing the period as 2 bytes after the pin number, instead of reportingEnabled (passing 0 would effectively disable reporting).

Do you think this makes sense? Can I go ahead and open the PR?

Do you have any ideas for number 2? Possibly another SYSEX command that links a power ping to an analog pin. This is also good for thermistors, as you usually don't want them burning power and heating up as a consequence of being powered on all the time.

Waiting for your feedback. Cheers.

[soundanalogous]

@mdlima Please file 2 separate issues here. They are not related to this particular thread.

[pgrawehr]

EXTENDED_REPORT_ANALOG will make it to the next protocol release (2.7) and subsequentially to ConfigurableFirmata 3.1. This is required for boards with more than 15 analog channels, or where the numbers are not continuous. E.g. ESP32 has A0, A3..A7, A10, A11, A13..A17.

Note that the value of EXTENDED_REPORT_ANALOG is 0x64, as specified in the feature registry and the code already. EXTENDED_ANALOG is used for reporting the value of analog channels above 15 (same message as with setting PWM outputs).