[riot-devel] Re-visiting the LED macros
hauke.petersen at fu-berlin.de
Tue Jul 11 18:04:29 CEST 2017
in #7321  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 ). 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 , but this can be further improved (as
in not taking any ROM if no LEDs are actually used...).
More information about the devel