in #7321 [1] an old friend of discussion popped up again: should we get rid of the special handling for on-board LEDs and move over to use the `periph/gpio` driver for controlling them? This could be done in a global module (as for example proposed in #7350 [2]). The benefit would be less redundant code and a simplified board configuration.
To recap the original motivation for the 'direct-control-LED-macros': the idea was to make the LED pins controllable with the least possible overhead (-> 1 instruction on most platforms), so they can be used for debugging and profiling without adding any/much overhead themselves.
Now as I see it, the situation today is the following: on most platforms, we have some sort of pretty nice debugging possibilities (e.g. gdb) so we don't really need the LEDs for debugging anymore? Or has anyone using the LED macros for time-critical debugging lately?
For the purpose of profiling using GPIO pins, I think it makes more sense to think about something like a CPU specific `pin_debug` header for a small number (say 2?) pins that can be directly (say without overhead) controlled. The actual pins used should still be configured by the board, but we can put default pins in place and we don't need all this redundant pin wobble clutter in a board's configuration.
So the main question here is: is anyone o.k. with refactoring the LED code or their opinions against proceeding with this? As said, one proposed solution is in #7350 [2], but this can be further improved (as in not taking any ROM if no LEDs are actually used...).
For the purpose of profiling using GPIO pins, I think it makes more sense to
think about something like a CPU specific `pin_debug` header for a small
number (say 2?) pins that can be directly (say without overhead) controlled.
The actual pins used should still be configured by the board, but we can put
default pins in place and we don't need all this redundant pin wobble
clutter in a board's configuration.
I don't fully get this point. How would this header differ from the current
LED control?
Besides, I would still vote for keeping the LED macros, because they are so
simple that you can always rely on them - even in case you have fucked
something completely up. Splitting them into a different header and maybe even
make them optional, however, is fine with me.
For the purpose of profiling using GPIO pins, I think it makes more sense to
think about something like a CPU specific `pin_debug` header for a small
number (say 2?) pins that can be directly (say without overhead) controlled.
The actual pins used should still be configured by the board, but we can put
default pins in place and we don't need all this redundant pin wobble
clutter in a board's configuration.
I don't fully get this point. How would this header differ from the current
LED control?
Besides, I would still vote for keeping the LED macros, because they are so
simple that you can always rely on them
But they are problematic in some contexts:
- currently, they increase power consumption even if not used (LED pins are always initialized, independent of their use)
- some boards have pin usage clashes (e.g. LED pin also used for SPI/UART/I2C etc)
So making the LEDs optional in some way is IMHO needed in any case...
- even in case you have fucked
something completely up. Splitting them into a different header and maybe even
make them optional, however, is fine with me.
Actually, I think this is pretty much what we did with #7350 and #7352.