{"id":27862,"date":"2020-11-06T22:01:01","date_gmt":"2020-11-06T21:01:01","guid":{"rendered":"https:\/\/pi3g.com\/?p=27862"},"modified":"2020-11-06T22:01:01","modified_gmt":"2020-11-06T21:01:01","slug":"controlling-leds-on-alpine-linux-using-the-command-line","status":"publish","type":"post","link":"https:\/\/pi3g.com\/de\/controlling-leds-on-alpine-linux-using-the-command-line\/","title":{"rendered":"Steuerung von LEDs auf Alpine Linux \u00fcber die Kommandozeile"},"content":{"rendered":"

We have developed an embedded Raspberry Pi Compute Module carrier board for industrial use: the PCCB.<\/p>\n

\"pccb-small\"<\/a><\/p>\n

<\/p>\n

As you can see, there are three (directly) user programmable LEDs on the PCCB: USER \/ INFO \/ ACT.<\/p>\n

These are defined in the device tree. For example, we can define the following in our device tree overlay:<\/p>\n

\n

\/\/LEDs
\nfragment@11 {
   target = <&leds>;
   __overlay__ {
     led_act: ledact {
       label = “myledact”;
       gpios = <&gpio 5 0>;
       linux,default-trigger = “mmc0”;
     };
     led_info: ledinfo {
       label = “myledinfo”;
       gpios = <&gpio 16 0>;
       linux,default-trigger = “cpu”;
     };
     led_user: leduser {
       label = “myleduser”;
       gpios = <&gpio 22 0>;
       linux,default-trigger = “heartbeat”;
     };
   };
\n};\n<\/p>\n

<\/p>\n<\/blockquote>\n

\"image\"<\/a><\/p>\n

The device tree overlay source file (.dts) will need to be compiled, and will yield a .dtbo file.<\/p>\n

\"image\"<\/a><\/p>\n

This file is included as an overlay in the config.txt (in our case it actually is included in a subfile, usercfg.txt which is included from the config.txt)<\/p>\n

\n

# Pi Control Carrier Board Overlay
\ndtoverlay=pi-control-carrier-board<\/p>\n<\/blockquote>\n

This will tell the VideoCore OS which is loaded first to pass on the device tree for the particular Pi model including our overlay to the Linux kernel.<\/p>\n

What is a device tree?<\/h1>\n

ARM devices have become increasingly more customized and diverse as compared to standard x86 devices which had standarized components.<\/p>\n

In order to avoid recompiling the kernel and having to match every single modified hardware, a system of describing the hardware layout to the Linux kernel was devised.<\/p>\n

The device tree.<\/p>\n

It is an OS independent concept, as it is loaded into the OSes Kernel. Any operating system which wishes to, can support it.<\/p>\n

The Linux kernel will receive the device tree, and thus knows which device is present, how it is connected, and how to talk to it (drivers are loaded depending on hints in the device tree, for example).<\/p>\n

As a Raspberry Pi is not static hardware, but it comes in different configurations & can expose different pins, for example, and also have different add-ons (HATs), an additional add-on was required: device tree overlays.<\/p>\n

These files allow to modify the device tree, without having to have an individual new device tree for every possibly combination of hardware you can attach to the Pi \/ configure the Pi to.<\/p>\n

How do I control the LEDs?<\/h1>\n

These LEDs will turn up in the system, in the \/sys\/class\/leds<\/strong> directory:<\/p>\n

\"image\"<\/a><\/p>\n

As you can see, a total of four LEDs is exposed here, three of which (myledact, myledinfo, myleduser) were added by us using the overlay!<\/p>\n

Each of these LEDs is a directory in of itself,<\/p>\n

\"image\"<\/a><\/p>\n

which gives you control over the LED.<\/p>\n

Remember, in Linux everything is a file \/ talking to the kernel is abstracted to doing operations on the filesystem (it\u2019s actually a UNIX paradigm).<\/p>\n

Run<\/p>\n

\n

cat trigger<\/p>\n<\/blockquote>\n

for the LED.<\/p>\n

It will show you a list of which triggers can be set for it:<\/p>\n

none rc-feedback kbd-scrolllock kbd-numlock kbd-capslock kbd-kanalock kbd-shiftlock kbd-altgrlock kbd-ctrllock kbd-altlock kbd-shiftllock kbd-shiftrlock kbd-ctrlllock kbd-ctrlrlock timer oneshot heartbeat backlight gpio cpu cpu0 cpu1 cpu2 cpu3 default-on input panic [mmc0]<\/em><\/p>\n

Note that the last trigger, mmc0 is in square brackets. This is what the LED is currently set to!<\/p>\n

You can try setting it to any of the other triggers by writing this trigger to the LED (if you have sufficient rights \"Smile\"):<\/p>\n

\n

echo \u201ctimer\u201d > trigger<\/p>\n<\/blockquote>\n

Will make the LED blink.<\/p>\n

Note, if you now list the LED control directory again, you\u2019ll see additional entries \u2013 new functionality which is exposed for the timer mode:<\/p>\n

\"image\"<\/a><\/p>\n

delay_off and delay_on<\/p>\n

\n

cat delay_off<\/p>\n<\/blockquote>\n

yields 500. These are 500 milliseconds.<\/p>\n

You can adjust these values to make the LED blink faster, for example:<\/p>\n

\n

echo “150” > delay_off<\/p>\n

echo “150” > delay_on<\/p>\n<\/blockquote>\n

Or slower \u2026<\/p>\n

\n

echo “1500” > delay_on<\/p>\n

echo “1500” > delay_off<\/p>\n<\/blockquote>\n

A couple of noteworthy triggers:<\/p>\n