Espruino on STM32F4 discovery board

You are reading a single comment by @fanoush and its replies. Click here to read the full conversation.

•

Gordon
Hi - yes, it probably makes sense to pull in the pin negation code. Maybe #ifdef so it's not bloating boards where it isn't used (I should probably have done this on NRF52 too).

I am not sure if this is actually good solution in NRF code

Do you have other suggestions? If there's a better way of doing it I'd be interested.

there was other inverted flag

Yes, that'll help with things like the bootloader/espruino bootup. It's used when declaring stuff like:
```
define LED1_PININDEX 18/* D18 */
define LED1_ONSTATE 1
```
But while it works fine when used from the C code, it doesn't work when accessing pins themselves

•

fanoush in reply to @Gordon
Do you have other suggestions? If there's a better way of doing it I'd be interested.

Few ideas
1. ifdef code and enable only if some pins are really negated in board file - you already mentioned it
2. move this to common code if possible (?) so it is not in each port separately
3. I am actually not sure what it should do and why and on what level this should be, is this mainly just for buttons and leds? So that in javascript code you can treat button/led in normal way - reading,writing, watching change? Will it work if the pull up/down are left alone and instead the negated flag would be visible flag on the Pin object (so you could even toggle it from js yourself on any pin?) because with such flag I'd left figuring out correct pulls on the user code too. So only value would be negated, not pull up/down, that is lot of complicated code. Also if only the BTN1 or LED1 would be negated but the underlying pin D13 not, it could also make the code handling 'normal' pins clear from this if Led and Button would be special object inherited from Pin. Then also the debouncing magic in setWatch in case of buttons would be more clear - watch on Button object would do it, watch on (same) Pin would not. Then maybe port specific code could drop it altogether and Pin and Led with this pin negation feature could be in common code.
So to sum it up I think making negated flag on pins completely invisible/transparent including pull up/down is too heavy and too much magic. Letting user know about it and possibly handle it could be better. An also maybe this should not be feature of the pin at all but something more high level - button, led.

Espruino on STM32F4 discovery board

About

Espruino