Display Hat Mini - LED logic inverted?

I’m just having a play with the buttons and LED on my display hat mini, and I’ve noticed something weird - under gpiozero the LED logic is inverted?!?!

This is the simple code I’m using to test it:

from gpiozero import LED, Button
from signal import pause

button_a = Button(5)
button_b = Button(6)
button_x = Button(16)
button_y = Button(24)

led_r = LED(17)
led_g = LED(27)
led_b = LED(22)


button_a.when_pressed = led_r.on
button_b.when_released = led_r.off

button_x.when_pressed = led_g.on
button_y.when_released = led_g.off


The three led_x.on() functions turn the LEDs off, and the button presses also work backwards (button A actually turns the red LED segment off, and B turns it on - same for X/Y and the green LED segment).

Can someone who has one of these confirm if this is general, or if I’ve just got a weird HAT?

Note that all the pin assignments etc come from pinout.xyz, as none of the examples in either Python library actually do anything with the LED…

A low / ground turns an led on, keep that in mind.

Which would explain it, just seems rather weird.

But I guess it’s not really designed to play with gpiozero.
Just found some other code on the net with more details in it on how to use the LED and buttons within the displayhatmini module rather than the ST7789 one.

Some of those RGB LEDs are common cathode and some are common anode. That affects how they work. The Pimoroni code takes that into account.
Can led_r.on() be changed to led_r.on(lo) or led_r.on(0)?

Did you see these examples?
pimoroni-pico/micropython/examples/pico_display at main · pimoroni/pimoroni-pico (github.com)

With the Pimoroni uf2 etc you can do stuff like this.

from pimoroni import Button
button_a = Button(7, invert=False)
button_b = Button(8, invert=False)
button_c = Button(9, invert=False)
button_up = Button(22, invert=False)
button_down = Button(6, invert=False)


from pimoroni import RGBLED
led = RGBLED(6, 7, 8)
led.set_rgb(0, 0, 0) 

It’s what I’m doing on Tufty and Display Pack.

No I didn’t. I’d have been a bit wary of them anyway as they’re on Pico rather than Pi, plus I’d not sure there’s suitable stuff in the display hat module to cover that.

This is fundamentally the problem, the documentation for the display hat is surprisingly sparse compared to other boards available like the Unicorn hats.

To save a second post, just to be clear, this is on a Pi (zero in this case) rather than a pico, so there is no uf2 involved. I’ll have a play to see what is actually in the display hat module, but I can’t find much documentation for it anywhere to detail what commands are available.

The issue I think is what you mentioned in the first posts - that they turn on when grounded/low, which is presumably the opposite to what gpiozero is expecting, hence the inversion.

It’s not really a major issue or anything that’s not simple to work around, but it’s just a bit weird.

Ops sorry, confusion on my end, I mixed up what display you were using.
Not sure why I was thinking Pico instead of Pi.
Let me take a minute to rethink things and get back to you with some better info etc.

I’m using RPi.GPIO for button press etc. As an example, my shutdown code is as follows.


import os
import time, datetime

import RPi.GPIO as GPIO

GPIO.setup(5, GPIO.IN, pull_up_down = GPIO.PUD_UP)

def Shutdown(channel):  
    os.system("sudo shutdown now -P")

GPIO.add_event_detect(5, GPIO.FALLING, callback = Shutdown, bouncetime = 2000)

No worries, indeed thanks for the support (as ever).

Looking more deeply into the actual module, in there I’ve found the built-in ones for the buttons and the LED.

There is:

  • set_led(self, r=0, g=0, b=0): with ranges from 0.0-1.0 for each element
  • on_button_pressed(self, callback):
  • read_button(self, pin):
  • set_backlight(self, value):
  • display(self):

That last one I need to look into more, as currently I’m using the ST7789 module for that and the displayhatmini one for the LED and buttons, but I think I can do everything with just the displayhatmini one.

I did some quick testing with the first two (set_led and on_button_press and so far it seems to be working ok.

Just a little disappointing to have to go digging into the code to get the available commands rather than them being documented somewhere. Not up to the usual high standards we’ve come to expect from the team.

1 Like

I’ve had to go that route once or twice myself. Digging into the files for info.
It’s nice when there is a Function Reference. I get the feeling they (Pimoroni) are a bit understaffed?
That being said, I have always got a good support when I did a “contact us” to the support team.
Contact Us for Raspberry Pi Technical Support - Pimoroni

I better own up and say I don’t own one of those displays. I do have several of the Pico based ones on the go though. And many many breakout garden SPI displays I use with Pi’s and Pico. I am in a way partially responsible for the move to Pico Graphics. I got greedy and wanted to run two Display Packs on a Pico. That nudged Phil Howard into doing a redo, that he was already contemplating.

I’ve had mine sat in a drawer for a while, until I found both time and some idea of what to do with it.

Got a spare Pi Zero though recently (amazing what happens when you visit the store in Cambridge!) so brought it into play. Thought I’d have some fun on a project to make a clock/radio controller/news headline/weather display doodah.

Clock is already up and running, and I’ve already got the infrastructure in place for the the radio bit (already do it via Zigbee and MQTT with Home Assistant, so easy to tap into that) and the other bits are OK. Just need to choose suitable APIs and tap into them…

Not really played with Pico, aside from making a clock from one with a unicorn pack to fill a need in my lounge when a digi-box got replaced and we lost a clock display there.

Lots of weather doodahs here, Pi and Pico based. All show real time values from attached sensors. I will be delving into MQTT at some point in the near future.

MQTT is very easy and very powerful. To be honest I’m a little surprised that it’s passed you by so far, given your obvious skills and enthusiasm for these things.

Currently I don’t have local sensors (it’s on the to-do list), so far it’s just playing with cloud services and APIs.

The first thing I do is to have a look at the schematic. That tells you how the wiring is and how the software has to be configured.

In general, I tend to keep away from special (breakout-level) libraries - they often work around specific hardware features (like these described above) and that results in non-portable code. You start using one breakout and then switch to another one with a slightly different setup, and now you start over again. If you stick to basic hardware-level libs (like gpiozero, Rpi.gpio, st7789) all the special setups for a board are transparent in your own code and therefore much easier to port.