🛠 LED et bouton USER : triggers kernel et gpio-keys

Objectives

Get familiar with BeaglePlay I/O without writing a driver: control the five gpio-leds LEDs defined in the device tree via the /sys/class/leds interface, change their triggers (heartbeat, cpu, mmc, gpio), and read the USER button declared as gpio-keys on GPIO line GPIO0_18, using evtest.

Hardware

• A BeaglePlay board (recent Debian image)
• No external components: LEDs and button are onboard
• SSH or serial access

Complete code

# Lister les LED déclarées par le device tree
ls /sys/class/leds/

# Voir les triggers disponibles puis activer heartbeat
cat /sys/class/leds/green:heartbeat/trigger
echo heartbeat | sudo tee /sys/class/leds/green:heartbeat/trigger

# Pilotage manuel
echo none | sudo tee /sys/class/leds/green:heartbeat/trigger
echo 1 | sudo tee /sys/class/leds/green:heartbeat/brightness
echo 200 | sudo tee /sys/class/leds/green:heartbeat/delay_on

# Bouton USER (gpio-keys, GPIO0_18) : écouter les événements
sudo evtest        # choisir l'entrée gpio-keys, appuyer : BTN_0 down/up

Expected verification

ls /sys/class/leds/ displays the LEDs from the device tree; after echo heartbeat, the LED blinks at the kernel's rate. sudo evtest lists an entry named after the button; pressing it prints EV_KEY / BTN_0 / value 1 followed by value 0. If you write gpio to the trigger file, the LED only responds to brightness.

Common errors

• Looking for a /sys/class/gpio/gpio... file: with gpio-keys and gpio-leds, the lines are claimed by the kernel, and gpioget/gpioset return EBUSY.
• Using the wrong LED name: the exact labels are provided by ls /sys/class/leds, not by the schematic.
• Writing to brightness without setting trigger to none: the trigger constantly overwrites the value.
• Connecting an external button to GPIO0_18 expecting raw input: you must remove the gpio-keys node from the DTBO, otherwise the line remains occupied.
• Forgetting sudo with evtest: without permissions on /dev/input, the tool lists no entries.