App/Operational, but no LED Matrix Ouput

[eximer168]

First of all, thank you for publishing this project.

I get no matrix output on my setup. System details below. I have verified the Henner Zeller-library/demo example produces output.

I have verified pixel data is present within cp-stats-gl in variable 'canvas' up to the line: canvas = matrix->SwapOnVSync(canvas); I can set pixel data to a non-zero value and still no output. I suspect gl is somehow not working, or vsync not occurring.

I have verified the gl versions according to tutorial, linked libraries, and actually run the raspberry pi example program: /opt/vc/src/hello_pi/hello_triangle
Hello_Triangle produced graphics which leads me to believe gl is operable.

Question: Should a window/display appear when running triangle? or cp-stats-gl? Triangle gives me the following status, which I am presuming is 'success' even without a display appearing. Initialized EGL version: 1.4 GL Viewport size: 800x600

Details of system configuration. Brand new Buster v10 (full) Model : Raspberry Pi 3 Model B Rev 1.2

ldd cpu-stats-gl linux-vdso.so.1 (0x7ecdd000) /usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so => /usr/lib/arm-linux-gnueabihf/libarmmem-v7l.so (0x76f22000) libbrcmEGL.so => /opt/vc/lib/libbrcmEGL.so (0x76ed3000) libbrcmGLESv2.so => /opt/vc/lib/libbrcmGLESv2.so (0x76eae000) librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0x76e97000) libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0x76e6d000) libstdc++.so.6 => /lib/arm-linux-gnueabihf/libstdc++.so.6 (0x76d26000) libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0x76ca4000) libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0x76c77000) libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0x76b29000) libbcm_host.so => /opt/vc/lib/libbcm_host.so (0x76b02000) libvchiq_arm.so => /opt/vc/lib/libvchiq_arm.so (0x76aec000) libvcos.so => /opt/vc/lib/libvcos.so (0x76ad3000) libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0x76ac0000) /lib/ld-linux-armhf.so.3 (0x76f37000)

ldd triangle linux-vdso.so.1 (0x7ec77000) /usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so => /usr/lib/arm-linux-gnueabihf/libarmmem-v7l.so (0x76fa9000) libbrcmEGL.so => /opt/vc/lib/libbrcmEGL.so (0x76f5a000) libbrcmGLESv2.so => /opt/vc/lib/libbrcmGLESv2.so (0x76f35000) libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0x76de7000) libbcm_host.so => /opt/vc/lib/libbcm_host.so (0x76dc0000) libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0x76d3e000) libvchiq_arm.so => /opt/vc/lib/libvchiq_arm.so (0x76d28000) libvcos.so => /opt/vc/lib/libvcos.so (0x76d0f000) libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0x76ce5000) libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0x76cd2000) librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0x76cbb000) /lib/ld-linux-armhf.so.3 (0x76fbe000)

[Staacks]

Are your settings in the cpp file correct and do they match your hardware? If there is data on the canvas, it is probably not an OpenGL problem as OpenGL generates the image that is copied to the canvas. Once something is in there, OpenGL is not used anymore. It might be garbage data on the canvas but then it should probably display as garbage and not just "black".

One thing I notice though is that you set your resolution to 800x600 and I somehow doubt that you built a 800x600 cube. This is the resolution of your cube, not your screen. More so, your screen does not come into this at all. The cpp file should run without any x server and it is not supposed to show a window. Since the rPi is built into the cube without an opening for the HDMI port, I am quite sure that no one attaches a screen to the cube. In fact, running a full Raspbian installation might be bad idea as it will spawn several processes that might mess up the timing to control the panel. However, I would expect it to cause additional flickering while it should still display something...

[eximer168]

Solved, in case someone else runs into this: does work on Buster-full

Need to add "--led-gpio-mapping=adafruit-hat" to the command line when launching the executable. (referenced) https://github.com/hzeller/rpi-rgb-led-matrix#cpu-use

closing notes: Thanks for the feedback, the 800x600 was output from the triangle program, the cpu program gives display dimensions 192x64 -- iow. all nominal.

fwiw: other fun add-on applications to make "the matrix" precisely the fun toy GoogleHome ought to have been.

Clock visuals https://www.youtube.com/results?search_query=humans+since+1982 https://www.hackster.io/Mukesh_Sankhla/rgb-hexmatrix-iot-clock-54fc5d

Rendered gif's https://www.element14.com/community/community/halloween/blog/2019/10/31/nes-castlevania-on-an-led-matrix-cube

Blob opera: https://artsandculture.google.com/experiment/blob-opera/AAHWrq360NcGbw

Thanks again!

[Staacks]

Ah, interesting. Did you do the connection to reduce flicker as described here?

The parameter led-gpio-mapping is set in the code as "hardware_mapping": https://github.com/Staacks/there.oughta.be/blob/master/led-cube/led-cube/cpu-stats-gl.cpp#L510

So, you can change this to "adafruit-hat" instead of "adafruit-hat-pwm", so you do not have to set the parameter. However, the difference should be this little hardware modification which is also recommended in Adafruit's documentation.

[eximer168]

The Adafruit library was installed with "convenience mode" (so that there would be HDMI/audio), not "quality" (usb audio only), therefore no soldering jumper between GPIO4 and GPIO18. It's really quite good, though not perfect. -- it does a decent MaxHeadroom suitable glitch with stressed, and can actually be a feature when done right. There are so many things this can be used for! instead of CPU cores, use it as IOT dashboard with tie-ins to IFFTT or Initial State, with Max glitching in to announce an important state change...

https://learn.adafruit.com/adafruit-rgb-matrix-bonnet-for-raspberry-pi/driving-matrices

Address line E for 64x64 is soldered the Adafruit instructions really are great, and the RGB Library even better the fact that it can adapt to such different IO module configurations was really a surprise -- hopefully this will be helpful to someone if other new modules come out. thanks again.