I2S-parallel example: Drive a 64x32 display

[embedded-creations]

Take a look at the "Hardware" section in the README, and the schematic that's included in that repo. Short answer is the address lines are stored in an external flip flop chip, so some of the RGB lines are used for both RGB data and address data.

[Deouss]

I just received exactly same panel - 64x32 P4 with those crazy connectors.
What code example (esp-idf) should I use to get it working.?
I have two links but not sure if those are latest

https://github.com/ESP32DE/I2S_parallel ... 32_display
https://github.com/pixelmatix/esp32_I2s ... aLedMatrix

[Deouss]

So I am investigating techniques of displaying colors on such 'scan type' panels. I didn't know that panel is only 8-color RGB - however this is case for very easy driving.
This article https://www.sparkfun.com/sparkx/blog/2650 describes some tricky way of dimming led by delay times thus making it possible to map it to duty cycles and led states. You get bit-planes or layers of different color strength that is part of displaying one full frame - from apparently 4 frames needed to create extra bits for RGB. I'm not sure if they mean RGB444 - 12bit color.
This is kind of very crazy way of controlling led pixels. They display and clock out 2 lines at a time of small panel section called 'scan' section. Usually it is 1:16 or 1:8 meaning lines: 1,16 2,17 3,18...(1,8 2,9)etc.
One example uses 8 planes - cool. That would give full RGB888 spectrum. I have to see how it really works)

[ESP_Sprite]

That's actually similar to what my code (as well as the other code that's posted here, which uses a somewhat more advanced scheme) does. Half the fun is in getting on/off led controllers to show as many colors as possible

[Deouss]

Those panels being rgb111 are quite overpriced. Maybe scan sections should be parallely multiplexed for better faster display.
The bitplane technique probably makes the panel flicker more frequent. WS281B panels seem to be much better

[ESP_Sprite]

I don't think there are many panels on the market which aren't RGB111, and the amount of flicker is dependent on how you drive it: seeing as you can drive an individual panel with quite fast dotclocks, the amount of flicker can be similar to the PWM frequency of a WS2811.

[Deouss]

I was trying to find out what performance (fps) was achieved displaying on that panels. Couldn't see what is actually a best technique for non-flicker and full 24bit RGB (or more?) lights.
That fastled library looks very chaotic and seems to be using only RMT for esp - for ATMega all is time-aligned with instruction clock cycles in asm. I am about to dive into how it's done with I2S but there must be some limits prior to muxing speeds on multiple pins.
It is quite a challenge )

[flipflip]

Hello all,

I've taken this example and a few other sources (e.g. SmartMatrix, ESP32-RGB64x32MatrixPanel-I2S-DMA) and tried understanding the code. That was more or less successful I understand some, but not all of it...

Anyway, I've turned it into an ESP-IDF component that can more easily integrate into another project:

https://github.com/phkehl/esp32-leddisplay

It works for me. I have a 64x32 1/16 scan matrix. Perhaps it works for other configurations.

Happy hacking!

Regards,
flipflip

[Deouss]

I wonder if the display process can be done only by CPU. I tried to drive it without I2S and it worked however my panel seems to have very strange behavior. There is something related to OE pin - must be triggered after every row or I am doing something wrong.
They specify OE as active low so it actually should be connected to ground. I am able to lit panel with desired pixels just by shifting or switching 64bits and selecting/increasing row 16 times. All without any clocking in/out.
I guess panels are designed to switch output off for desired time but we can basically write a black color with same result.
Haven't looked at the example code deeper yet because I am trying to connect 3 panels and drive them different way.
If anyone know the working sequence - let me know. I am guessing it should be:

1) OE - HIGH
2) ABCD - set row #
3) LAT - LOW
4) RGB1/2 set 64 bits for top/bottom (clock in/out ?? )
5) LAT - HIGH
6) OE - LOW
7) Repeat ---

What I am doing is simply steps 2 and 4 with delay wait at the end
According to calculations for 256 colors with 60fps we need 1000/60/8 = 2.08 ms to process whole image
I know it all would be possible with parallel REG_WRITE instead of I2S. Maybe some asm
Any suggestions are welcome

[ESP_Sprite]

The OE is meant to turn off the display while you switch rows. If you do not do this, you will have some remaining capacitive effects etc that will cause ghosting of the data of the previous line on the current line.