-
This was added because beginners complained a lot about 'why does the LED go off when I do LED.set()' and so on... and you're the first person to complain the other way so far...
No, not complaining about this. This I would keep, but only this - inverting value. Not pull up/down. If you know what pin.setMode("input_pullup") means you can manage inverted flag and set it as pulldown yourself. beginners won't touch this, they will have their leds,buttons,motors already working. BTW are you inverting PWM duty cycle too?
It was quite a surprise to me that in board file I must set pull the other way than it is for real, e.g. here https://github.com/espruino/Espruino/blob/master/boards/NRF52832DK.py#L70 it is in fact set as pullup! here I would really expect to set it like it really is.
It's not that easy if we want to allow people do use digitalPulse/analogWrite/etc on a LED or screen backlight - which are all pretty common things to want to do.
Well , I don't know how hard it is to implement it. As for behavior - when using BTN1, LED1 object it should do the magic (with everything that makes sense for that type of object - digitalPulse/analogWrite), when using underlying pin directly it should not do this. That would be least surprising to me. E.g. I have one board (E104-BT5032A-TB) where buttons and leds are enabled by jumpers and are inverted, if I disable the jumper and use the pin on the header directly as is and refer it by pin number, I would expect the pin to be not inverted.
However we could negate anyway, and it makes sense to expose the fact the pin is negated via pin.getInfo
yes
You are reading a single comment by @fanoush and its replies.
Click here to read the full conversation.
fanoush
I'll all for ifdefing the code and maybe making it common...
And vibration, heart rate/etc on watches. I'd also considered making some boards with motor drivers and it might get used there if the drivers were inverting.
Yes - but also in Espruino's firmware as well.
This was added because beginners complained a lot about 'why does the LED go off when I do LED.set()' and so on... and you're the first person to complain the other way so far...
I think a very high percentage of beginners wouldn't want their first command -
LED.set()to not work.However we could negate anyway, and it makes sense to expose the fact the pin is negated via
pin.getInfoIt's not that easy if we want to allow people do use
digitalPulse/analogWrite/etc on a LED or screen backlight - which are all pretty common things to want to do.While with 'virtual pins' we could handle it a little (at least for 'soft' PWM) that still requires a check inside
jshPinSetValue- and is arguably a lot less efficient.