Hi,
I am building a big 320x256 panel, which I want to be split horizontally, so I can I arrange it as a 640x128 panel alternatively. For keeping the cabling simple and short I thought of using four chaines of five 64x64 panels, but the Raspi currently can only drive three row because of GPIO limits.
Now I thought of creating an alternative addon-board using registers (74HCT574) instead of bus drivers and a fast inverter to invert the clock line. You then only need four sets of RGB lines instead of eight. You have to write one register pair at the rising edge of clock and the other set on falling edge. So you can use for rows with only half the pin count. If you add a register chip you can even use six rows this way.
Since for most panels we have to reduce the clock speed on Raspi 3 or above, it seems the Raspi has some ressources left, so that it maybe possible without performance degration.
But therefore you have to alter the software. I tried to understand it, but that is kind of over the head for me. I even do not find the piece of code were the data is written to the GPIOs. Is anyone interrested in this, who may help or even point me the right source file where the data transfer is done, Mr. Zeller perhaps.
Or what else could be used? I tried first to control a Colorligth receiver board, but I get no stable pictures, much flickering and occasional hangups.
Or maybe a Raspi compute module, but that has no LAN.
Or whatelse?
I tried with an STM32 board. It works, but it has too less memory and also no LAN.
WARNING: very long answer.
Thank you for your answer. I already read your blog, this impressive builds really creates the wish to build one myself. But my problem is, I have two use cases:
An aprox. 4:3 display with 320 pixel width for video games, like this:
An widescreen info display with about 640 pixel width like this:
I am using 64x64 3mm panels with 32 multitplex. To fit both usecases I split the panel like in the first picture, so I can arrange it to both usecases with little efford. With the shown cabling I have a maxumum of 320 LED (5 modules) per row and only two cables from one panel to the other.
In your project you have kind of zigzag cabling of four 128x64 modules (or 8 64x64) which gave you 520 LEDs per row. The more LEDs per row the higher the pixel clock or the lower the screen refresh rate. Since the modules stop working above 20MHz pixel clock, I think I will not get reasonable refresh rates like that. Plus I have to connect three cables between the two panels. And I have a not connected “last” column of modules per panel, which is unused bandwidth.
Therefore I choosed the above cabling approach. But this has also unsolved issues:
obviously I need four chains and Raspi can support only three in the current hardware version
cables are too long. If I do the cabling as variant 1 leaving the uppermost module row unconnected, I get random pixel on the 2nd row from above. I think the cable from Raspi to that row is too long. That will become catastrophic if I switch to variant 2. I will try using terminating resistors thes days.
That Beaglebone board looks interesting, but without software I think I cannot get it working. I can easily program a mikrocontroller in C. But if a complicated OS or chipset is involved, or more than a bit C++ I get problems. So porting hzellers library to some other hardware is too complicated for me.
CM4 would be a nice possibilty, but I need ethernet. And all the carrier boards I found with Ethernet have the limited number of GPIOs like the original Raspi. Maybe I could design my own carrier board, but creating a 4-port board for raspi using that “DDR” approach mentioned in my original post would be much easier and cheaper. In the meantime I have a bit better understanding of the library. Maybe I can alter it.
But the cable length problems are also there. Maybe it would be better to use two raspis, one for the upper and one for the lower panel.
A little progress: I added 180 ohm resistor arrays to +5V on the panel side of the cables. Now the noisy pixels are gone. But another quality issue remains. There is a unregular flickering sometimes. I have no idea if this is caused by some software or configuration issue or another hardware bug.
I use DietPi on a Raspberry 3b. In top one core (number 3) is under 83% load, two cores are nearly 0% and one core is on 53%.
Ddi you use my Vmapper:Z code to use the shortest cables possible between panels in you stack them? (if they are side by side, never mind, that’s already the shortest path possible)
From your command line, increasing -led-slowdown-gpio by one, may help with noise, but will also slow down your refresh rate
The reality is the resolution you want, indeed nicely matches 4 chains, and we don’t currently have that.
I personally never looked at whether you can get 4 chains out of regular Pi by playing some tricks. For instance, can the 6 color channels be connected to multiple panels at the same time and feed colors to panel 1 vs panel2 based on which one you can sending clock signals to? Of course it will slow things down, but a Pi4 is faster than all panels I have, and needs to be slowed down, so maybe each Pi4 channel can actually feed 2 channels by alternating a clock/OE between panel 1 and panel 2, giving you up to 6 channels if there are enough GPIO pins left, or at least more than 3 channels.
Either way, this would be for you to develop depending on how badly you need/want this
