0

I am using Pi Zero W with latest Raspberry Pi OS.

I have a backlight of an LCD that I am trying to control via PWM.

If I use RPi.GPIO I get flicker at anything other that 100% (or 0%) duty cycle. As I understand, this is probably due to the timing of the software PWM being affected by other processes.

If I use pigpio, I get good dimming but as soon as I turn the backlight off and back on, it breaks the dimming and I only get full-on or off. Only a reboot fixes this.

The backlight goes off even if I set the DC to 1 (/255) not only to zero , which is also strange and in either case, as mentioned, it breaks the dimming until reboot.

The backlight also automatically comes on as I have it in an overlay for the screen, here is the extract from the dts file. If I comment out that fragment, then I get no dimming at all, just on/off from the start. Also, default-off doesn't change anything.

    fragment@5 {
        target-path = "/";
        __overlay__ {
            rpi_backlight: rpi_backlight {
                compatible = "gpio-backlight";
                gpios = <&gpio 18 0>;
                default-on;
            };
        };
    };

Ideally, I would remove that fragment and only control the backlight from Python and ideally without a daemon consuming resources.

  1. How can I fix pigpio so that I can turn the backlight off and then get it dimming again (ideally without DTS fragment above or with it defaulting to off)?

  2. pigpio daemon is going to continually use resources just for a backlight, is there a fix for RPi.GPIO so that I can use the hardware PWM (since I am using GPIO 18 which has that capability, as I understand) - also ideally without fragment@5

Edit: This is the python script that dims the backlight up and down.

$ sudo pigpiod
$ python3
import pigpio
import time
gpio = pigpio.pi()
gpio.set_mode(18, pigpio.OUTPUT)
#gpio.set_mode(18, pigpio.ALT5) - behaves the same

def dim_up():
    for x in range(2,200):
        gpio.set_PWM_dutycycle(18, x)
        print('level =', x)
        time.sleep(0.01)

def dim_down():
    for x in range(200,1,-1):
        gpio.set_PWM_dutycycle(18, x)
        print('level =', x)
        time.sleep(0.01)

def cycle_dim():
    while True:
        dim_up()
        dim_down()

cycle_dim()

This works fine and dims up and down smoothly until you change either range to include 1 or 0 in the range. Then, the first time before it hits those numbers, it works fine, then after those numbers it is either full on or full off, no range in between.

2 Answers 2

0

The dtb fragment is irrelevant to pigpio. It makes no use of the fragment.

With pigpio you can use any expansion header GPIO to generate flicker free PWM suitable for LEDs. You can easily check by using the pigs utility from the command line.

e.g. for GPIO 18 use e.g. pigs p 18 x, for GPIO 5 use pigs p 5 x etc. Where x is 0 for off, 255 for fully on, and intermediate values for settings between off and fully on.

RPi.GPIO currently has no support for hardware PWM.

If you have a problem with pigpio and Python a listing showing the problem will be useful.

15
  • Thanks Joan. The problem with pigpio is as I have stated in my question: as soon as the DC is set to either 1 or 0, any value I send >1 results in fully on Commented Jul 8, 2020 at 10:31
  • I would need to see the code you are using as what you describe is not what happens, so either the code is wrong or your wiring is wrong or the backlight does not work as you think.
    – joan
    Commented Jul 8, 2020 at 10:36
  • I don't think either the code or the wiring is wrong but I have updated my question to include the code. It seems to me to be a pigpio bug or some lower level problem Commented Jul 8, 2020 at 10:43
  • I have run that code and it works fine. I have also tried range(0,200) and range(200,0,-1) and they work fine as well. The PWM continues to cycle correctly as can be seen using piscope.
    – joan
    Commented Jul 8, 2020 at 10:53
  • Yes, I agree, it should work but it doesn't so don't know where to dig deeper to find the issue. It must be a driver issue somewhere... Commented Jul 8, 2020 at 11:12
0

This turned out to be an issue with the way PWM was interfacing with the Texas Instruments TPS61165 LED driver which made it switch control modes to EasyScale. As Joan kindly pointed out, increasing the PWM frequency to 1m stopped this from happening and provided reliable dimming.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.