Status LEDs to GPIO header

[DarkElvenAngel]

Hello everyone,

I'm working on a project for a headless setup and I want status LEDs lots of them!

I'm hoping someone knows if I can get the Ethernet status LEDs and wi-fi ACT.

I'm looking for the pi models with built in wifi and ethernet.

[DarkElvenAngel]

A long time ago I came across a project to turn the LEDs of the Ethernet ports off or you could change them I don't know if any of the code could be used to get information from the Ethernet chip however newer Pi's use different Ethernet chips. https://github.com/dumpsite/lan951x-led-ctl

As for WiFi I was hoping to find some way to get activity status from it maybe there is a different way to do this?

The Board is going into a box and none of the on-board LEDS will be visible. The Indicators don't have to be accurate just show if something is happening.

[cleverca22]

https://github.com/raspberrypi/linux/bl ... tsi#L9-L17

Code: Select all

leds {
  compatible = "gpio-leds";
  act {
    label = "ACT";
    default-state = "keep";
    linux,default-trigger = "heartbeat";
    gpios = <&gpio 42 GPIO_ACTIVE_HIGH>;
  };
};

this part of the device-tree code sets up gpio 42 as an led called "ACT" and sets the default trigger

on my rpi4, i can enable the green LED via:

Code: Select all

root@raspberrypi:/sys/class/leds/led0# echo 1 > brightness

but since i didnt change the trigger, it turns itself off after a short period

Code: Select all

root@raspberrypi:/sys/class/leds/led0# cat trigger 
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 mmc1 [mmc0] rfkill-any rfkill-none rfkill0 rfkill1 
root@raspberrypi:/sys/class/leds/led0# echo cpu > trigger 

but you can also just change the trigger to almost anything, and it will begin blinking away according to the new rules

and once you find a trigger you want, you should be able to encode that into the dts file to make it a default

Code: Select all

root@raspberrypi:/sys/class/leds/led0# modprobe ledtrig-netdev
root@raspberrypi:/sys/class/leds/led0# echo netdev > trigger 
root@raspberrypi:/sys/class/leds/led0# echo eth0 > device_name 
root@raspberrypi:/sys/class/leds/led0# echo 1 > link

and now the green led is showing the link status for eth0

Code: Select all

root@raspberrypi:/sys/class/leds/led0# echo 0 > link
root@raspberrypi:/sys/class/leds/led0# echo 1 > rx
root@raspberrypi:/sys/class/leds/led0# echo 1 > tx

or just basic tx/tx activity instead

[DarkElvenAngel]

https://github.com/raspberrypi/linux/bl ... tsi#L9-L17

Code: Select all

leds {
  compatible = "gpio-leds";
  act {
    label = "ACT";
    default-state = "keep";
    linux,default-trigger = "heartbeat";
    gpios = <&gpio 42 GPIO_ACTIVE_HIGH>;
  };
};

this part of the device-tree code sets up gpio 42 as an led called "ACT" and sets the default trigger

on my rpi4, i can enable the green LED via:

Code: Select all

root@raspberrypi:/sys/class/leds/led0# echo 1 > brightness

but since i didnt change the trigger, it turns itself off after a short period

Code: Select all

root@raspberrypi:/sys/class/leds/led0# cat trigger 
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 mmc1 [mmc0] rfkill-any rfkill-none rfkill0 rfkill1 
root@raspberrypi:/sys/class/leds/led0# echo cpu > trigger 

but you can also just change the trigger to almost anything, and it will begin blinking away according to the new rules

and once you find a trigger you want, you should be able to encode that into the dts file to make it a default

Code: Select all

root@raspberrypi:/sys/class/leds/led0# modprobe ledtrig-netdev
root@raspberrypi:/sys/class/leds/led0# echo netdev > trigger 
root@raspberrypi:/sys/class/leds/led0# echo eth0 > device_name 
root@raspberrypi:/sys/class/leds/led0# echo 1 > link

and now the green led is showing the link status for eth0

Code: Select all

root@raspberrypi:/sys/class/leds/led0# echo 0 > link
root@raspberrypi:/sys/class/leds/led0# echo 1 > rx
root@raspberrypi:/sys/class/leds/led0# echo 1 > tx

or just basic tx/tx activity instead

This is amazing, how would I add more led# to the /sys/class/leds and point them to a GPIO??

[DarkElvenAngel]

Okay I think I understand this a little better now??

I need to write a device tree overlay that will add the LEDs I want and I can set the default triggers. What I don't understand is how to write the overlay

I looked at the simplest Pi the 0 and found this entry

Code: Select all

&leds {
	act_led: act {
		label = "led0";
		linux,default-trigger = "mmc0";
		gpios = <&gpio 47 0>;
	};
};

I'm just spinning in my head but could I do

Code: Select all

&leds {
	act_led: act {
		label = "led0";
		linux,default-trigger = "mmc0";
		gpios = <&gpio 47 0>;
	};
	pwr_led: pwr {
		label = "led1"
		linux,default-trigger = "default-on";
		gpios = <&gpio 16 0>;
};

If so how can I make it portable? I think this might require a new thread in the overlays or move this to overlays?

[cleverca22]

viewtopic.php?f=107&t=222428&p=1641425

i think you would create an overlay with a target-path `/leds` and then you can insert more things into that section

Code: Select all

root@raspberrypi:~# ls -l /proc/device-tree/leds/
total 0
drwxr-xr-x 2 root root  0 May 11 01:16 act
-r--r--r-- 1 root root 10 May 11 19:41 compatible
-r--r--r-- 1 root root  5 May 11 19:41 name
-r--r--r-- 1 root root  4 May 11 19:41 phandle
drwxr-xr-x 2 root root  0 May 11 01:16 pwr

this lets you view the final device-tree, after all overlays have been applied, so you can debug what the overlay actually did to things

note that a lot of the entries in that area will be raw binary, so you may want to use `hexdump -C`` when reading then:

Code: Select all

root@raspberrypi:~# hexdump -C /proc/device-tree/leds/act/gpios
00000000  00 00 00 0f 00 00 00 2a  00 00 00 00              |.......*....|
0000000c

the `0xf` is the `phandle` of the gpio node
and the 0x2a is just 42 in hex

[DarkElvenAngel]

Progress,

I can now put my network act, tx, tx out to the gpio header, I also have power and mmc out on the gpio.

Problems I still have I need to load the ledtrig-netdev and setup manually I don't understand how to do this with my overlay. As I understand it the overlay does't load the modules.

Thanks goes to cleverca22 for pointing me in the right direction and for helping with the overlay. Thank you very much.

[6by9]

To load additional modules at boot time, add them to the file /etc/modules (one per line).

Most drivers loaded via device tree will load the modules automagically, but I'm guessing that is an additional part of the led triggers that is optional.

[cleverca22]

Code: Select all

root@raspberrypi:~# modinfo snd_bcm2835
filename:       /lib/modules/4.19.97-v7l+/kernel/drivers/staging/vc04_services/bcm2835-audio/snd-bcm2835.ko
license:        GPL
description:    Alsa driver for BCM2835 chip
author:         Dom Cobley
srcversion:     7AA1377144CA37D54C9971C
alias:          of:N*T*Cbrcm,bcm2835-audioC*
alias:          of:N*T*Cbrcm,bcm2835-audio

the of: part of the alias, is for matching against a compatible= from DT

Code: Select all

root@raspberrypi:~# cat /proc/device-tree/soc/audio/compatible;echo
brcm,bcm2835-audio

i think the kernel or udev will just blindly try to modprobe every compatible it can see, and let the aliases find the targets

but an led trigger isnt a compatible=, id say this is maybe a bug/design-flaw in the led subsystem

[DarkElvenAngel]

Code: Select all

root@raspberrypi:~# modinfo snd_bcm2835
filename:       /lib/modules/4.19.97-v7l+/kernel/drivers/staging/vc04_services/bcm2835-audio/snd-bcm2835.ko
license:        GPL
description:    Alsa driver for BCM2835 chip
author:         Dom Cobley
srcversion:     7AA1377144CA37D54C9971C
alias:          of:N*T*Cbrcm,bcm2835-audioC*
alias:          of:N*T*Cbrcm,bcm2835-audio

the of: part of the alias, is for matching against a compatible= from DT

Code: Select all

root@raspberrypi:~# cat /proc/device-tree/soc/audio/compatible;echo
brcm,bcm2835-audio

i think the kernel or udev will just blindly try to modprobe every compatible it can see, and let the aliases find the targets

but an led trigger isnt a compatible=, id say this is maybe a bug/design-flaw in the led subsystem

Maybe a rule in udev is the answer, the question is can we catch the definition of the /proc/device-tree/LEDs/xxxx if that can be done then writing a rule to load the module and setup the device and functions.

It's worth a look

[DarkElvenAngel]

Maybe a rule in udev is the answer, the question is can we catch the definition of the /proc/device-tree/leds/xxxx if that can be done then writing a rule to load the module and setup the device and functions.

It's worth a look

This seems to be a dead end I've looked and looked but udev doesn't seem to do anything with the ledtrig-netdev or the /proc/device-tree path.

I'm going to look into maybe a service that can handle this, My focus is on Buildroot for this one as that's my target but I'm sure systemd would have something to take care of this.

I'm thinking a simple sh script to work through this raw data

Code: Select all

$  ls /proc/device-tree/leds/
act  compatible  nact  name  nlink  phandle  pwr
$  ls /proc/device-tree/leds/nact/
gpios  linux,default-device_name  linux,default-trigger  name
label  linux,default-rx           linux,default-tx

Code: Select all

#!/bin/sh
if [[ -d /proc/device-tree/nact ]]; then
	cat /proc/device-tree/nact/linux,default-device_name > /sys/class/leds/led2/device_name
	cat /proc/device-tree/nact/linux,default-tx > /sys/class/leds/led2/tx
	cat /proc/device-tree/nact/linux,default-rx > /sys/class/leds/led2/rx
fi
if [[ -d /proc/device-tree/nlink ]]; then
	cat /proc/device-tree/nact/linux,default-device_name > /sys/class/leds/led3/device_name
	cat /proc/device-tree/nact/linux,default-link > /sys/class/leds/led2/link
fi

[alanbork]

https://github.com/raspberrypi/linux/bl ... tsi#L9-L17

Code: Select all

leds {
  compatible = "gpio-leds";
  act {
    label = "ACT";
    default-state = "keep";
    linux,default-trigger = "heartbeat";
    gpios = <&gpio 42 GPIO_ACTIVE_HIGH>;
  };
};

this part of the device-tree code sets up gpio 42 as an led called "ACT" and sets the default trigger

Is this correct for the PI4? I tried toggling BCM pin 42 and it doesn't cause the LED0 to change. on my Pi zero I could do this by

"gpio -g blink 47", so on my Pi4 I tried "gpio -g blink 42", but no joy.

I think the pin number is right: https://raw.githubusercontent.com/raspb ... pi-4-b.dts

[DarkElvenAngel]

https://github.com/raspberrypi/linux/bl ... tsi#L9-L17

Code: Select all

leds {
  compatible = "gpio-leds";
  act {
    label = "ACT";
    default-state = "keep";
    linux,default-trigger = "heartbeat";
    gpios = <&gpio 42 GPIO_ACTIVE_HIGH>;
  };
};

this part of the device-tree code sets up gpio 42 as an led called "ACT" and sets the default trigger

Is this correct for the PI4? I tried toggling BCM pin 42 and it doesn't cause the LED0 to change. on my Pi zero I could do this by

"gpio -g blink 47", so on my Pi4 I tried "gpio -g blink 42", but no joy.

I think the pin number is right: https://raw.githubusercontent.com/raspb ... pi-4-b.dts

The LEDs on a Pi 4 are on a GPIO expander. You can't just flip the led like in the zero unfortunately.

[alanbork]

Is this correct for the PI4? I tried toggling BCM pin 42 and it doesn't cause the LED0 to change. on my Pi zero I could do this by

"gpio -g blink 47", so on my Pi4 I tried "gpio -g blink 42", but no joy.

I think the pin number is right: https://raw.githubusercontent.com/raspb ... pi-4-b.dts

The LEDs on a Pi 4 are on a GPIO expander. You can't just flip the led like in the zero unfortunately.

Bummer! Man, this pi4... Makes me wish for my Pi Zero again. But, moving on.. So is there a faster (lower latency) method to twiddle the LEDs than via filesystem writes to led0/led1? I'm looking for sub-millisecond here.

I notice that one of the "trigger" options for the led0/1 is "gpio". Does that provide some other access point?

[DarkElvenAngel]

Is this correct for the PI4? I tried toggling BCM pin 42 and it doesn't cause the LED0 to change. on my Pi zero I could do this by

"gpio -g blink 47", so on my Pi4 I tried "gpio -g blink 42", but no joy.

I think the pin number is right: https://raw.githubusercontent.com/raspb ... pi-4-b.dts

The LEDs on a Pi 4 are on a GPIO expander. You can't just flip the led like in the zero unfortunately.

Bummer! Man, this pi4... Makes me wish for my Pi Zero again. But, moving on.. So is there a faster (lower latency) method to twiddle the LEDs than via filesystem writes to led0/led1? I'm looking for sub-millisecond here.

I notice that one of the "trigger" options for the led0/1 is "gpio". Does that provide some other access point?

If you set the trigger to gpio this will create a new entry gpio. You then set that to the gpio you want to follow. By that I mean it will basically copy the state hight or low of the selected gpio. I don't know how accurate that is though or how fast I don't have a way to measure that.

[alanbork]

Bummer! Man, this pi4... Makes me wish for my Pi Zero again. But, moving on.. So is there a faster (lower latency) method to twiddle the LEDs than via filesystem writes to led0/led1? I'm looking for sub-millisecond here.

I notice that one of the "trigger" options for the led0/1 is "gpio". Does that provide some other access point?

If you set the trigger to gpio this will create a new entry gpio. You then set that to the gpio you want to follow. By that I mean it will basically copy the state hight or low of the selected gpio. I don't know how accurate that is though or how fast I don't have a way to measure that.

Hmm - worth trying. What's the syntax for that? Just for laughs I tried

echo gpio 16 > /sys/class/leds/led0/trigger

but no humor was experienced.

FYI I have timed using fputc to control the LED and that is quite a bit delayed and inconsistent in timing relative to wiring pi on the zero where I can touch the GPIO directly.

Code: Select all

pin = fopen("/sys/class/leds/led0/brightness", "w");
fputc('0', pin); // turn off led
fflush(pin);

[DarkElvenAngel]

Hmm - worth trying. What's the syntax for that? Just for laughs I tried

echo gpio 16 > /sys/class/leds/led0/trigger

but no humor was experienced.

The syntax for your example would be

Code: Select all

echo gpio | sudo tee /sys/class/leds/led0/trigger
echo 16 | sudo tee /sys/class/leds/led0/gpio

Hope it helps

[alanbork]

The syntax for your example would be

Code: Select all

echo gpio | sudo tee /sys/class/leds/led0/trigger
echo 13 | sudo tee /sys/class/leds/led0/gpio

Hope it helps

thank you! I can confirm that this works with raspi-gpio (raspi-gpio set 13 dh ). The wiringPi library doesn't work with this in my c code, however, nor does it work at the command line: gpio -g blink 13 does nothing. I suppose gpio/wiringpi is just really not the way to do any thing pi4

PS for anybody that cares: I timed lighting the LED using the file system: it typically takes about 1.5-3ms and sometimes 4ms from fputc to led response (and another 4ms to reach full brightness). due to adc noise it's hard to measure exactly but there's definitely some variability on the pi's timing. I can tolerate it for now, and go low level later.

[nogardvfx]

Hi, I was wondering if you might be able to provide a step by step tutorial on what you did to get the TX and RX to output to an LED? I have tried multiple solutions using non-GPIO methods and have had no luck to get anything working.

Cheers!

[DarkElvenAngel]

Hi, I was wondering if you might be able to provide a step by step tutorial on what you did to get the TX and RX to output to an LED? I have tried multiple solutions using non-GPIO methods and have had no luck to get anything working
Cheers!

Well it's been awhile since I did all this but I'll tell you how I managed it. I'm assuming you want the Network TX and RX to light LEDs connected to the GPIO header?

Firstly to make your life super easy you need to make a device tree overlay and have it load when you next boot. Call it netled.dts

Code: Select all

// Enable extra leds in the /sys/class/leds
/dts-v1/;
/plugin/;

/ {
	compatible = "brcm,bcm2708";

	fragment@0 {
		target = <&leds>;
		__overlay__ {
			nlink {
				label = "led2";
				linux,default-trigger = "netdev";
				linux,default-device_name = "eth0";
				linux,default-link = "1";
				gpios = <&gpio 19 0>;
			};
			nact {
				label = "led3";
				linux,default-trigger = "netdev";
				linux,default-device_name = "eth0";
				linux,default-tx = "1";
				linux,default-rx = "1";
				gpios = <&gpio 13 0>;
			};
		};
	};
};

Now you have to compile this so that the pi can read it at boot time.

Code: Select all

dtc -@ -I dts -O dtb -o netled.dts netled.dtbo

This was for my configuration you might want something different I'm using GPIO 13 and 19.

Now you must copy the netled.otbo to /boot/overlays

Code: Select all

sudo cp netled.dtbo /boot/overlay

Now you have to tell your pi to load it so edit the config.txt and add this line

Code: Select all

dtoverlay=netled

Now add this line to the /etc/modules

Code: Select all

ledtrig-netdev

Let's check everything is working reboot your pi and then run this command

Code: Select all

ls /sys/class/leds

you should see led0 led1 led2 led3 and maybe some others entries too. The important ones are led2 and led3 this tells us the overlay loaded and is working. If you have LEDs connected to GPIO 13 and 19 then you can make sure they work with this command

Code: Select all

echo default-on | sudo tee /sys/class/led{2,3}/trigger 

Now if the LEDs are on, this is the last bit

Edit /etc/rc.local
Add this code

Code: Select all

if [[ -d /proc/device-tree/nact ]]; then
	cat /proc/device-tree/nact/linux,default-device_name > /sys/class/leds/led2/device_name
	cat /proc/device-tree/nact/linux,default-tx > /sys/class/leds/led2/tx
	cat /proc/device-tree/nact/linux,default-rx > /sys/class/leds/led2/rx
fi
if [[ -d /proc/device-tree/nlink ]]; then
	cat /proc/device-tree/nact/linux,default-device_name > /sys/class/leds/led3/device_name
	cat /proc/device-tree/nact/linux,default-link > /sys/class/leds/led2/link
fi

put this before the exit 0

Then reboot on more time. Now you should see that if you're ethernet cable is plugged in you'll have one LED on and the other will blink with any network traffic.

Hope this helps you. Post back your results if it works, you need more help, or want to change something.

Good luck,

[nogardvfx]

Sorry, I should have been specific. I have a serial interface (RS232) connected to the TX and RX pins on the Pi. Wanted to get those connected up to LEDs.

[DarkElvenAngel]

Sorry, I should have been specific. I have a serial interface (RS232) connected to the TX and RX pins on the Pi. Wanted to get those connected up to LEDs.

I had a sense that was what you were after. So are you using the serial on the GPIO header or a USB to Serial? And where are you hoping to get the LEDs connected?

What your after isn't as complex as the network status LEDs as far as software goes but it will all be hardware.

Since you have been trying other methods and it didn't work an idea of what those are would be helpful. Also attaching a picture or you setup could help. RS232 signals aren't compatible with the 3v3 GPIO header a proper RS232 will be 12v and -12v. I can tell you what you need but I need to see what you serial device your using and does the communication work now?

[nogardvfx]

Wow awesome. Thank you so much. I seem to be going around and around on this and it is all new territory for me. I will be upfront and say I do not know a ton when it come to electronics. More of the user side of things. But I can solder and with a bit of help I can figure things out.

Here is what I am using on the hardware side of things:

https://www.mikroe.com/max232-board with a raspberry pi zero.
more images of the board and the bottom:
https://www.soselectronic.com/products/ ... 2-1-156633


Yes I am using the GPIO pins. I am running the 5V on the pi (pin 2) to the 5v on the max232. Running neg (pin 6) to the neg on the 232. TX on the Pi (pin 8) to the RX on the 232. And finally, RX (pin 10) to TX on the 232. I have also hooked up CTS and RTS and they work. Actually, everything is working great. Just want those LEDs for TX and RX.

What I have tried is using this post:
https://electronics.stackexchange.com/q ... ics-rx-pin
(the last post)
What I tried was splitting off the TX off the PI running one wire to the RX on the 232 and another to a BS170 Mosfet (Pin 2 Gate). I ran a 5v from the Pi to a 1000 ohm resister, then to the LED, and then to the source pin (3). Then from pin1 I ran a wire to a negative pin on the Pi. I also tried reversing the Source and Drain connections, but it made no difference. The LED stayed on no matter what. Even after shutting down the Pi. I would have to physically pull the power to shut it off. I was using pin 4 for the power.

I just need this all dumbed down as to what to by and how to hook it up. More of a visual kind of guy to be honest.


I am amazed your so helpful. Thank you again!

[nogardvfx]

I also wanted to add that I found this page:

https://electronics.stackexchange.com/q ... ics-rx-pin

And I used the info from the last post. Maybe I just hook this all up incorrectly.

What I did was split the TX signal running one wire to the rs232 and the other to the BS170's Gate pin. I ran a 5v from the pi to the 1000ohm resistor , then to the LED, and then to the source. Then the Drain to the ground on the Pi. I also tried reversing the Source and Drain lines. The LED just stays lit all the time.

I was thinking that maybe I need to run this directly off the RS232 board, but I really do not know where to "plug" it in.

[rpdom]

The MAX323 chip will put 5V on the Pi's GPIOs which will damage the Pi. You should use a MAX3232 instead which will work at the correct 3.3V levels.