-
Notifications
You must be signed in to change notification settings - Fork 147
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
store configuration response resolution value #105
Comments
👍 |
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. |
That user is me ... the motor driver is a DRV8833 from Adafruit |
I'm using setPin and setPWM directly as a workaround in the meantime |
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 |
+1 |
I will try to find time to add these properties this weekend. |
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 |
We should definitely store all of them. I was just citing those two as an example. |
pin.adcResolution is much simpler to use than pin.resolutions[board.MODES.ANALOG] |
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).
The text was updated successfully, but these errors were encountered: