0

I have a Raspberry Pi 3B+, with a keyboard, mouse, and HDMI monitor connected to the Pi. It's being powered by a CanaKit power supply that came with the Pi. I have a string of ws2811 pixels that operate like NeoPixels (non-Adafruit-branded). (I have been driving these pixels with an Arduino for several years.) When I attach the light string as shown by Adafruit (using a 74AHCT125N), everything works just as expected (using GPIO18). (These pixels also works without the tri-state buffer, but I know it's best practice to raise the output from 3.3v to 5v.)

But I have two monitors on my desk, and I wanted the Pi on the other monitor. So, while the Pi was off, I switched the HDMI cable to the other monitor. Now, the light string no longer functions as expected. The lights are glitchy and the colors are not accurate. I thought maybe the GPIO voltage has sagged below the minimum threshold for my first ws2811 chip, but I have the 74AHCT125 there to raise the signal to 5v.

If I switch back to the original monitor, the light string behaves normally once again. With the second monitor, I decided to test GPIO21, which causes the lights behave normally again.

In summary, with the first HDMI monitor, GPIO18 and GPIO21 work fine to drive my pixels. With the second monitor, GPIO18 does not reliably drive the pixels, yet GPIO21 does.

Can anyone explain what relationship the operation of GPIO18 has with what HDMI monitor I'm using? Both monitors are 10-12 years old, max resolution capable is probably 1280x720, both made by Samsung.

user3629081
  • 109
  • 3

2 Answers2

1

Full Disclosure: I have no idea what's causing the issues you're seeing.

You've not given much (useful) detail, but that's understandable.

However, I'll try to offer some resources to help you get started tracking this down for yourself.

First: Have you double-checked your GROUND wiring? Most people are keen on following the supply leads, but tend to forget that current requires a return path to flow. Perhaps connecting/disconnecting your monitor plays a part in this?

Second: Have you used pinout.xyz? It's a useful resource. Most GPIO pins are used for different functions depending on how "things" are configured. For example, if you use pinout.xyz to check out GPIO18, you'll see it has many functions. Do any of these sound familiar? It could be that one of these alternate functions is being triggered by the presence/absence of a monitor?

Third: You should look at what's in your /boot/config.txt file. Have you invoked an overlay that might be using GPIO18? Have you enabled functions or features in raspi-config that might be using one of the "other functions" available on GPIO18?

Finally, simply realizing that GPIO pins have alternative functions (other than just conventional logic I/O) should suggest another obvious course of action: Choose another GPIO pin.

Hope this helps.

Seamus
  • 23,558
  • 5
  • 42
  • 83
0

Using pinout.xyz (thank you to Seamus for your answer), I see that GPIO18 is used for PCM audio. It turns out that my first HDMI monitor has a headphone jack on the back, while the second monitor is actually a VGA/DVI monitor with an HDMI-to-DVI cable.

When using the first monitor, the Pi sends audio through the HDMI cable and GPIO18 is undisturbed. When using my second monitor, the Pi either uses PWM or sends digital audio (not sure which), either of which consumes GPIO18.

Therefore, I disabled audio in config.txt and now GPIO18 works as expected on any monitor.

This helps explain why I was not able to switch monitors without rebooting, since I was unknowingly switching between HDMI and DVI.

user3629081
  • 109
  • 3