boards/common/stm32: clean up LED definitions

[maribu]

Contribution description

Let boards only define the port and pin number of each LEDs. The common definitions in stm32_leds.h will provide LED<x>_ON, LED<x>_OFF, LED<x>_TOGGLE, LED<x>_PIN, LED<x>_MASK and LED<x>_PORT.

In addition to code de-duplication, this also makes it easier to use LEDs in GPIO LL, which can be beneficial for super low overhead debugging output - e.g. when a bug is timing sensitive and DEBUG() would spent to much time for stdio to reproduce a bug.

Testing procedure

The LED macros should not change to master. Hence, the (except for debug symbols) the binaries generated should not change compared to master.

One could also test if controlling LEDs still works for all the changed boards...

Issues/PRs references

None

[krzysztof-cabaj]

If I well understand your code You assumed that LED is ON when the port is at HIGH state. I don't know how many boards, but at least old stm32f469i-disco use swap polarity - LOW state ONs the LED - see #18041 for more details.

[maribu]

Thanks for the pointer. I will add support for inverted LEDs to the common header, so that boards with inverted LEDs just have to toss in an #define LED0_IS_INVERTED 1. I will also double check that this doesn't add regressions for other boards where I didn't notice that they have inverted LEDs.

[maribu]

Should be fixed now. If my regex-fu is not too bad, I should also have tracked down all other STM32 boards that were configured to use inverted LEDs, so that this hopefully does not cause regressions.

[maribu]

I successfully tested this on the STM32F103 bluepill via tests/leds. So it does indeed work with STM32F1 and with inverted LEDs.

[krzysztof-cabaj]

I checked your PR with tests/leds on my old STM32F469I-DISCO (boards with inverted LEDs) - I could confirm that everything works fine!

[benpicco]

That's a nice convenience improvement.

[maribu]

I replaced a few thousands of LED[0-9]_FOO and BTN[0-9]_FOO regexes in exclude_patterns with a handful of hand-crafted ones. That should also make sure that future additions of these macros will not be frowned upon from the CI.

[maribu]

Thx :)