store configuration response resolution value

[soundanalogous]

It appears that the only the pin modes are recorded from the configuration query response. The resolution value should also be stored because it contains info such as the resolution of the analog input and output pins (PWM and also soon to be added DAC) as well as pin mapping for Serial pins (which pins correspond to which UART) and I2C mapping (SDA pin vs SCL pin).

[rwaldron]

👍

[dtex]

Just a note to say that we have a real user with a problem that could be solved by this. The user is running a Feather Huzzah (10-bit PWM) and is trying to drive a motor (via an h-bridge). J5 sends 255 because it doesn't know the pin capability of the Huzzah.

[ghtomcat]

That user is me ... the motor driver is a DRV8833 from Adafruit

[ghtomcat]

I'm using setPin and setPWM directly as a workaround in the meantime

[soundanalogous]

StandardFirmata already reports a 10-bit resolution for the ESP8266 boards so this simply needs to be defined in firmata.js. There are different resolutions for any give pin depending on which mode it's in. The pin object in firmata.js could use a pwmResolution property and an adcResolution property and then those would be set when the capability query returns.

[rwaldron]

The pin object in firmata.js could use a pwmResolution property and an adcResolution property and then those would be set when the capability query returns.

+1

[soundanalogous]

I will try to find time to add these properties this weekend.

[monteslu]

Any reason we wouldn't want to keep all the resolutions in a map per mode as opposed to just the 2 properties? Doesn't matter for digital IO, but we still have SERVO, STEPPER, and SERIAL.

Might be just a corner case for me with remote-io, but kinda feels like we should just keep all the resolution data since we're marshaling it with CAPABILITY_RESPONSE anyway.

Maybe something instead of pin.adcResolution we do pin.resolutions[board.MODES.ANALOG]

[soundanalogous]

We should definitely store all of them. I was just citing those two as an example.

[soundanalogous]

pin.adcResolution is much simpler to use than pin.resolutions[board.MODES.ANALOG]