Thanks for this great tool. The new interrupt code for reading input was applying the inverted config property twice—once via sysFS as active_low, and once again in getOn. Since activeLow was being set on if not inverted, this meant the input would only behave like an inverted contact (inverted off: do set active_low, don't alter the wpi.digitalRead value; inverted on: don't set active_low, do alter the wpi.digitalRead value). So far just leaving active_low as is (0) works for either inverted state.
I left it there, but gpiopin.active_low = ((gpiopins[i].pull === "down") * 1); doesn't seem to do anything either. Also, mixing pull-down state and inverting logic is confusing. I think of pull-up/down as "what to do if the wire gets cut". I.e. no information, but we want to tie it to a definite state.
Thanks for the fix. Agreed on the mixing active_low and PUD resistor settings - not sure why I mixed those together! Will merge your current fix and apply to the branch I'm (slowly) working on as well.
Thanks for this great tool. The new interrupt code for reading input was applying the
inverted
config property twice—once via sysFS asactive_low
, and once again ingetOn
. SinceactiveLow
was being set on if not inverted, this meant the input would only behave like an inverted contact (inverted off: do set active_low, don't alter thewpi.digitalRead
value; inverted on: don't set active_low, do alter thewpi.digitalRead
value). So far just leavingactive_low
as is (0) works for eitherinverted
state.I left it there, but
gpiopin.active_low = ((gpiopins[i].pull === "down") * 1);
doesn't seem to do anything either. Also, mixing pull-down state and inverting logic is confusing. I think of pull-up/down as "what to do if the wire gets cut". I.e. no information, but we want to tie it to a definite state.