alanbork
Posts: 26
Joined: Thu Apr 23, 2020 11:18 pm

PI4: Controlling LED0 via broadcom pins/wiringpi

Thu Jun 25, 2020 7:37 pm

I'm building a tool for measuring input lag on displays (how long a LCD/etc takes to respond to changes in the HDMI signal, https://alantechreview.blogspot.com/202 ... berry.html). It sends a frame of video to the monitor using openGL and simultaneously lites LED0, and then you measure the delta between LED0 lighting up and the display changing. This works great on the Pi0 (https://alantechreview.blogspot.com/202 ... lt-in.html). I use wiringpi, instead of the file system to minimize any latency and variability.

Now I want to do the same on the Pi4. Unsurprisingly, the BCM pin for the LED has changed, but I can't find any documentation of what it is. Is there an official list anywhere? on the zero it's 47. On a model before the pi4 it's 16. But on the Pi4 it's neither.

Side note: is wiringPi still the best way to do this? It seems that the author has stopped supporting it.

alanbork
Posts: 26
Joined: Thu Apr 23, 2020 11:18 pm

Re: PI4: Controlling LED0 via broadcom pins/wiringpi

Thu Jun 25, 2020 8:41 pm

I found some source code that suggests that it's pin 42: https://raw.githubusercontent.com/raspb ... pi-4-b.dts

but trying to blink 42 via wiringpi does nothing

Code: Select all

 gpio -g blink 42
trying to use the file-system GPIO method just to check that the wiringpi library isn't the cause:

Code: Select all

# echo none > /sys/class/leds/led0/trigger
# echo 42 >  /sys/class/gpio/export
-bash: echo: write error: Device or resource busy
any ideas?

cleverca22
Posts: 490
Joined: Sat Aug 18, 2012 2:33 pm

Re: PI4: Controlling LED0 via broadcom pins/wiringpi

Sun Jun 28, 2020 11:37 pm

that pin is used by the LED subsystem in linux by default, you can find it under `/sys/class/leds` i believe
if you change the trigger to `none`, then you can use the brightness file to turn it on/off
and i think if you change the trigger to `gpio`, you can then treat it as a normal gpio?

alanbork
Posts: 26
Joined: Thu Apr 23, 2020 11:18 pm

Re: PI4: Controlling LED0 via broadcom pins/wiringpi

Mon Jun 29, 2020 5:32 am

And once it's in GPIO mode, which pin is it? I've tried 42 with no luck.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 8678
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: PI4: Controlling LED0 via broadcom pins/wiringpi

Mon Jun 29, 2020 7:58 am

Believe DT as that is what Linux is using, but you don't need to worry about it.

As cleverca22 says, write "none" to /sys/class/leds/led0/trigger, and then you can control the brightness by writing to /sys/class/leds/led0/brightness.

(WiringPi is deprecated, and may well not be allowing you to write to bank1 GPIOs as they are used for internal purposes (eg SD card). You can use "raspi-gpio set 42 dh" and "raspi-gpio set 42 dl" (drive high and drive low) if you really need to go low level)
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

alanbork
Posts: 26
Joined: Thu Apr 23, 2020 11:18 pm

Re: PI4: Controlling LED0 via broadcom pins/wiringpi

Tue Jun 30, 2020 11:33 pm

6by9 wrote: Believe DT as that is what Linux is using, but you don't need to worry about it.

As cleverca22 says, write "none" to /sys/class/leds/led0/trigger, and then you can control the brightness by writing to /sys/class/leds/led0/brightness.
I already eliminated that as an option - the file system is slow and inconsistent in it's delay factor, at least if I do it this way:
pin = fopen("/sys/class/leds/led0/brightness", "w");
fputc('0', pin); // turn off led
fflush(pin);
maybe there's an unbuffered IO I could use instead.
6by9 wrote: (WiringPi is deprecated, and may well not be allowing you to write to bank1 GPIOs as they are used for internal purposes (eg SD card). You can use "raspi-gpio set 42 dh" and "raspi-gpio set 42 dl" (drive high and drive low) if you really need to go low level)
Awesome! It works, too, confirming that 42 is indeed the proper GPIO. Source code at https://github.com/RPi-Distro/raspi-gpi ... spi-gpio.c is begging to be turned into a proper library, although it seems hard to believe it hasn't been done already.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 8678
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: PI4: Controlling LED0 via broadcom pins/wiringpi

Wed Jul 01, 2020 7:16 am

alanbork wrote:
Tue Jun 30, 2020 11:33 pm
6by9 wrote: (WiringPi is deprecated, and may well not be allowing you to write to bank1 GPIOs as they are used for internal purposes (eg SD card). You can use "raspi-gpio set 42 dh" and "raspi-gpio set 42 dl" (drive high and drive low) if you really need to go low level)
Awesome! It works, too, confirming that 42 is indeed the proper GPIO. Source code at https://github.com/RPi-Distro/raspi-gpi ... spi-gpio.c is begging to be turned into a proper library, although it seems hard to believe it hasn't been done already.
NO!!!
Twiddling hardware registers from userspace is totally the wrong way to go as there is no arbitration between clients, and you can totally mess things up.
libgpiod is the correct thing to use. It replaced /sys/class/gpio as the correct route for userspace to access GPIOs via the kernel.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

alanbork
Posts: 26
Joined: Thu Apr 23, 2020 11:18 pm

Re: PI4: Controlling LED0 via broadcom pins/wiringpi

Wed Jul 01, 2020 3:48 pm

6by9 wrote:
alanbork wrote:
Tue Jun 30, 2020 11:33 pm

Awesome! It works, too, confirming that 42 is indeed the proper GPIO. Source code at https://github.com/RPi-Distro/raspi-gpi ... spi-gpio.c is begging to be turned into a proper library, although it seems hard to believe it hasn't been done already.
NO!!!
Twiddling hardware registers from userspace is totally the wrong way to go as there is no arbitration between clients, and you can totally mess things up.
libgpiod is the correct thing to use. It replaced /sys/class/gpio as the correct route for userspace to access GPIOs via the kernel.
You may be right from an implementation perspective, but I have to say that library is ugly from an interface perspective, and with only C++/python bindings it's not very usable. In any case I won't rock the boat; if I do make a library based on raspi-gpio I'll keep it to myself.

thanks for all your help.

Return to “Interfacing (DSI, CSI, I2C, etc.)”