[riot-devel] Re-visiting the LED macros

Hauke Petersen hauke.petersen at fu-berlin.de
Tue Jul 11 18:04:29 CEST 2017

Dear community,

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...).


[1] https://github.com/RIOT-OS/RIOT/pull/7321
[2] https://github.com/RIOT-OS/RIOT/pull/7350

More information about the devel mailing list