hzeller / rpi-rgb-led-matrix

Controlling up to three chains of 64x64, 32x32, 16x32 or similar RGB LED displays using Raspberry Pi GPIO
GNU General Public License v2.0
3.67k stars 1.17k forks source link

Use of left GPIO pins #65

Closed samuqu closed 8 years ago

samuqu commented 9 years ago

Hi, I want to show my appreciation for this wonderful piece of code, I've been able to make it work with a custom led panel. However, I've encountered a problem when I wanted to use the leftover pins on the GPIO to input some signals from some infrared sensors, as I want to make an interactive application. I'm very new to C++ so I opted for Python, and used the RPi.GPIO.add_event_detect() to wait for the trigger, however, the signal gets some noise whenever the display is lit. I assumed RGBMatrix was still trying to write to those pins, and I tried uncommenting the #DEFINES+=-DONLY_SINGLE_CHAIN in lib/Makefile and even commenting the pins I'm using in kValidBits in lib/gpio.cc but to no avail, I still get false triggers on my sensors. I hope someone can point me to the right direction Cheers, Samu

hzeller commented 9 years ago

Which GPIOs do you want to use ? Usually, if you don't use all three parallel chains, the ones that are not used by the panels should be free and are untouched by the rgb-led-matrix library (-P1 for instance only uses pins for the first chain). At least, they are not set for writing in the library.

However, I have not explicitly tested myself if the input on other GPIO pins works or is disrupted by other things.

One important thing to make sure is that you dont' stray too much electrical trouble into the inputs. Make sure to have a separate solid ground connection from the ground of the panel to the ground of the RPi so that the load on the panel does not shift levels. A low ESR capacitor at the power input of the panel can help as well getting less noise injected.

Keep signal cables from the Pi to the panel as short as possible to not strain the GPIO output drivers to much; maybe add a HCT245 to separate these (similar to what is done in https://github.com/hzeller/rpi-rgb-led-matrix/tree/master/adapter/active-3 ).

hzeller commented 9 years ago

Did you get this to work ?

samuqu commented 9 years ago

Sorry, I've been busy with other projects, but will come back in the future and test this, as it's a personal project I'm very interested in

On Mon, 19 Oct 2015 at 14:51 Henner Zeller notifications@github.com wrote:

Did you get this to work ?

— Reply to this email directly or view it on GitHub https://github.com/hzeller/rpi-rgb-led-matrix/issues/65#issuecomment-149295996 .

Serzhs commented 1 year ago

@hzeller I am attempting to incorporate a DHT22 sensor alongside my 64x64 LED matrix and operate them simultaneously. However, when both components are active, the DHT22 sensor fails to provide any data. Interestingly, when I omit the initialization function for the LED matrix, the sensor operates as expected.

I have ensured the use of available GPIO pins (otherwise the wiring would be impossible) and selected the "regular-pi1" mapping configuration.

Could you provide insights into the potential reasons for this behavior?

hzeller commented 1 year ago

You find the pins used in hardware-mapping.c.

If you need a particular pin that is in use by your matrix, you can can re-assign pins used by the rpi-rgb-led-matrix library there (don't forget to re-compile and wire up your matrix accordingly); that then frees up that pin for your sensor.

Also, if you have to configure pins, remember that the LED matrix library by default drops the privileges after setting up the GPIO pins. So if you need to set GPIO pin settings afterwards you need to make sure that that privilege dropping does not happen - you can prevent by configuring the drop privileges optinon accordingly. The one-wire protocol of your sensor seems to require that you re-configure the particular GPIO pin from output to input and vice versa at run-time.

Finally: Since the sensor you mention has a one-wire protocol which might be hard to properly have the right timing if the CPU is busy; you mention you use regular-pi1, which is a very old and very slow Raspberry Pi with only one core.