Qudor-Engineer / DMD32

A library for driving the Freetronics 512 pixel dot matrix LED display "DMD", a 32 x 16 layout using ESP32.
GNU General Public License v3.0
29 stars 19 forks source link

Not working with multiple displays #16

Closed MiyukiDark closed 1 year ago

MiyukiDark commented 1 year ago

It behaves strangely dmd_demo works with 1x2 and 2x1 configuration but no higher, it just have black screen dmd_latin_chars works on 3x3 but not on 3x4 but at least show some pixels compiled against esp32 1.0.5 and running on ESP32-WROM-32UE Any similar problem recorded ?

daveharnett commented 1 year ago

I'm working on a project with DISPLAYS_ACROSS 5 and DISPLAYS_DOWN 3 right now with good results. I had to reduce the frequency of the triggerScan timer/callback to prevent timeout crashes.

platform = espressif32@3.5.0 board = esp32doit-devkit-v1

Looking at the modules from the front, they are connected in a Z arrangement (with the esp32 connected to the bottom right module).

At some stage when moving from 1 panel to 2x2, I started running into some general unpredictability that was ultimately solved by adding level shifters to bump the signal from 3.3 to 5v.

From reading issues on other projects using these panels, it seems like the most common problem is inadequite power. At the experimental stage, i'd allow for 2A per panel to be confident it's not an issue.

MiyukiDark commented 1 year ago

Thanks, it was a timing issue, scan cycles were too close together so they overlap. Do you also have a problem with compiling against newer IDF/Arduino libs? I needed to comment following lines in DMD32.cpp to have anything at the output. And according to the ESP documentation, the SPI lines shall be left managed by SPI itself.

` DMD::DMD(byte panelsWide, byte panelsHigh) {

uint16_t ui;
DisplaysWide=panelsWide;
DisplaysHigh=panelsHigh;
DisplaysTotal=DisplaysWide*DisplaysHigh;
row1 = DisplaysTotal<<4;
row2 = DisplaysTotal<<5;
row3 = ((DisplaysTotal<<2)*3)<<2;
bDMDScreenRAM = (byte *) malloc(DisplaysTotal*DMD_RAM_SIZE_BYTES);

//initialise instance of the SPIClass attached to vspi
vspi = new SPIClass(VSPI);

// initialize the SPI port
vspi->begin();      // initiate VSPI with the default pinsinitiat VSPI with the defualt pins

digitalWrite(PIN_DMD_A, LOW);   // 
digitalWrite(PIN_DMD_B, LOW);   // 
//digitalWrite(PIN_DMD_CLK, LOW);   //  commented out, managed by SPI
digitalWrite(PIN_DMD_SCLK, LOW);    // 
//digitalWrite(PIN_DMD_R_DATA, HIGH);   //  commented out, managed by SPI
digitalWrite(PIN_DMD_nOE, LOW); //

pinMode(PIN_DMD_A, OUTPUT); //
pinMode(PIN_DMD_B, OUTPUT); //
//pinMode(PIN_DMD_CLK, OUTPUT); // commented out, managed by SPI
pinMode(PIN_DMD_SCLK, OUTPUT);  //
//pinMode(PIN_DMD_R_DATA, OUTPUT);  // commented out, managed by SPI
pinMode(PIN_DMD_nOE, OUTPUT);   //

clearScreen(true);

// init the scan line/ram pointer to the required start point
bDMDByte = 0;

}`

daveharnett commented 1 year ago

Yes, I had some compatibility problems with the latest arduino libs, though I think it might have stemmed from some other dependancy in my project (WiFiManager AFAIR).

Interesting re: commenting out the pin control stuff. I haven't bumped into this issue (at least not yet). Makes sense that the spi library would handle those pins internally.

MiyukiDark commented 1 year ago

I also do some tweaks in scanDisplayBySPI to make it about 2.5 times faster. So now can push it to way more display modules without reducing the refresh rate or needing for increasing the SPI clock. I have it in my fork

daveharnett commented 9 months ago

Looking at the panels from the back, start at the bottom left, and daisy-chain right, then up. Each row starts at the left:

20230223_095423