Large Flickering on Double Buffer about esp32-hub75-matrixpanel-i2s-dma HOT 35 CLOSED

Great!

@Lukaswnd - you win a prize.

Managed to solve the problem that I wasn't smart enough to fix.

from esp32-hub75-matrixpanel-i2s-dma.

Do you have 3d printer so i can send you the files or do you want me to send some to you (im from Poland)? Please mind that different density and size of the panels have different distances between screws and it depends also how you chain them. Please let me know the details and the distances of your threaded inserts that you would need. I also can create "pill shaped" screw holes so you will be able to fit it as you want.

Wow that's amazing. I don't have a 3D printer, but I can probably find somebody local (in the UK) if you have a 3d model that's of use?

I have a bunch of P3 panels that I use to regression test this library with. 46mm and 22mm seem to be the important lengths.

@mrfaptastic I tried the newest version of the library. It is working in all orientations now :) It is nice that now you can even rotate the display by changing CHAIN_TOP_LEFT_DOWN to CHAIN_BOTTOM_RIGHT_UP because they are somehow interchangable :) It works with long and short cable configuration so all configurations possible. I find it very stable with double buffer finally working as expected.

Meanwhile, thank you very much again and i am attaching the joints files that i have prepared for your 46x22 spaces.
46x22fix.zip

from esp32-hub75-matrixpanel-i2s-dma.

the reason i am updating library is due to panic issue in the library v2.0.6 as below:

======================== THREADS INFO =========================
  Id   Target Id          Frame
* 1    process 1073472652 0x40081a55 in panic_abort (details=0x3ffb0d5a \"abort() was called at PC 0x4013a918 on core 0\") at esp_system/panic.c:402
  2    process 1073483172 0x400d907a in flipDMABuffer (this=0x3ffc70e8) at esp32_led_matrix_dma.h:540
  3    process 1073478008 0x40194da0 in ?? () at ../components/app/src/app.cpp:77
  4    process 1073483532 0x401d3eae in trc_calc_duration () at freertos_tasks_c_additions.h:50
  5    process 1073507628 0x4012fdb6 in i2c_master_read (cmd_handle=0x3ffc6ac8, data=0x3ffc3334 <error: Cannot access memory at address 0x3ffc3334>, data_len=1, ack=I2C_MASTER_LAST_NACK) at driver/i2c.c:1238

the old mechanism to clear DMA buffer in v2.0.6 library version is having shared flag to check if the buffer was cleared. but the approach to do a while loop in the flip buffer to wait for the buffer to clear before returning true was causing system panic.

code that cause panic in v2.0.6:
while(i2s_parallel_is_previous_buffer_free() == false) { }

from snippet below:

// Double buffering flipping
// Flip to a buffer: 0 for bufa, 1 for bufb
// dmadesc_a and dmadesc_b point to the same memory if double buffering isn't enabled.
void i2s_parallel_flip_to_buffer(i2s_port_t port, int buffer_id) {

    if (i2s_state == NULL) {
      return; // :-()
    }

    lldesc_t *active_dma_chain;
    if (buffer_id == 0) {
        active_dma_chain=(lldesc_t*)&i2s_state->dmadesc_a[0];
    } else {
        active_dma_chain=(lldesc_t*)&i2s_state->dmadesc_b[0];
    }

    // setup linked list to refresh from new buffer (continuously) when the end of the current list has been reached
    i2s_state->dmadesc_a[i2s_state->desccount_a-1].qe.stqe_next = active_dma_chain;
    i2s_state->dmadesc_b[i2s_state->desccount_b-1].qe.stqe_next = active_dma_chain;

    // we're still shifting out the buffer, so it shouldn't be written to yet.
    //previousBufferFree = false;
	i2s_parallel_set_previous_buffer_not_free();
}

bool i2s_parallel_is_previous_buffer_free() {
    return previousBufferFree;
}

inline void IRAM_ATTR flipDMABuffer() 
{         
  if ( !m_cfg.double_buff) return;
    
    #if SERIAL_DEBUG     
            Serial.printf_P(PSTR("Set back buffer to: %d\n"), back_buffer_id);
    #endif      

    i2s_parallel_set_previous_buffer_not_free();       
    // Wait before we allow any writing to the buffer. Stop flicker.
    while(i2s_parallel_is_previous_buffer_free() == false) { }       
    
    i2s_parallel_flip_to_buffer(ESP32_I2S_DEVICE, back_buffer_id);        
    // Flip to other buffer as the backbuffer. 
    // i.e. Graphic changes happen to this buffer, but aren't displayed until flipDMABuffer() is called again.
    back_buffer_id ^= 1;        
    
    i2s_parallel_set_previous_buffer_not_free();       
    // Wait before we allow any writing to the buffer. Stop flicker.
    while(i2s_parallel_is_previous_buffer_free() == false) { }          

}

i was looking for the updated library where i could try the new approach on how the display was cleared. but looking the approach was to simply paint screen to black was causing the screen to be flickering

inline void clearScreen() { updateMatrixDMABuffer(0,0,0); };
this should be address properly @mrfaptastic, like the approach known before to use the showDMABuffer() and to have a method exposed by the library if ( !display->backbuffready() ) return; that can be use by user to properly timed the buffer clearing.

from esp32-hub75-matrixpanel-i2s-dma.

The old flickering issue strikes again. There is never going to be a clean solution for this, as the DMA hardware is completely asynchronous to the Arduino sketch and at no stage are the timings guaranteed.... but this doesn't mean I am going to give up trying to find a solution!

I have pushed a few changes to the repository. Not sure if they fix the flickering, but it shouldn't cause a memory read fatal error.

from esp32-hub75-matrixpanel-i2s-dma.

As for me, I also do face the flicker.

Mind to put at the end of setup() dma_display->flipBuffer()?

from esp32-hub75-matrixpanel-i2s-dma.

hi @mrfaptastic ,

the display still have flickering but lesser than before. (before can say around 3 flicker a sec) now is 1 every 10 sec.
but the display become very slow. it reduces the speed by half.

from esp32-hub75-matrixpanel-i2s-dma.

To confirm, with:

• 2.0.6 you didn't get flicker, but you got a panic?

I have made a change to 2.0.6 (2.0.7 legacy branch) which I think will fix for the panic condition you were having. Try going back to the 'old' version to see if it solves for your issue.

from esp32-hub75-matrixpanel-i2s-dma.

ya, panic issue is solved. i just add yield there. wondering if i can update to 3.0.5 to have s3 capability. and yes 2.0.6 has no flickering only panic. flicker is 3.0.5 which i tested with result above

from esp32-hub75-matrixpanel-i2s-dma.

from my observation, the flicker was due to high speed flip buffer. and look like the black timings are more longer than the suppose to be the proper pixel lit.

means the display was displaying black without the pixel draw to be ready in place. more prominent with drawrgb bitmap function.

from esp32-hub75-matrixpanel-i2s-dma.

I can confirm that doublebuffer works noticeably worse in 3.0.5

from esp32-hub75-matrixpanel-i2s-dma.

I'm going to work on a whole new way of doing this secondary buffer thing.

This "flipping the DMA chain pointer" approach doesn't work because the DMA hardware does it's own thing and the software that runs on the CPU will never be able to synchronise perfectly.

from esp32-hub75-matrixpanel-i2s-dma.

from esp32-hub75-matrixpanel-i2s-dma.

What hardware? A standard ESP32?

from esp32-hub75-matrixpanel-i2s-dma.

from esp32-hub75-matrixpanel-i2s-dma.

Try the latest git master. @Lukaswnd made a commit to fix things.

from esp32-hub75-matrixpanel-i2s-dma.

I can confirm that usage of doublebuffer is acting properly now. Everything is working for me as exprected, the buffer is not skipped :) Also no flickering for me.

from esp32-hub75-matrixpanel-i2s-dma.

May i ask You @mrfaptastic about orientation of the display? I am using six 64x64 panels (SM5166PF, SM16208, they are working on FM6124 setting tho) connected as serpentine where second row is turned upside down like in readme. I attach pictures:

As you can see in this orientation everything is working fine. The ribbon which is connecting rows together is very long and connectors are far apart from each other. The only other way is to connect them like so with short cable:

but then the display will look like so (sorry im to lazy to reconnect them again and again)

There is my question. Can i somehow change the placement of xy origin or switch rows with one another? Or do you have any idea how can i connect it using short cable and be able to correctly display it?

BTW the chips(Shall i stay on FM6124 while its working?):

from esp32-hub75-matrixpanel-i2s-dma.

Are you using the virtualmatrix wrapper class? Per the documentation: https://github.com/mrfaptastic/ESP32-HUB75-MatrixPanel-DMA/tree/master/examples/ChainedPanels

You should never need to use a long cable like that. The virtual matrix class should solve for the rotation of that 'row' of panels.

#define SERPENT true
#define TOPDOWN false

from esp32-hub75-matrixpanel-i2s-dma.

Ok, so basically what it seems like is the 'bottom up' serpentine chaining is broken.

Can you please run the basic ChainedPanels example (with the test pattern) based on the bottom-up chaining you want with the short cable, and send me a photo? I need to understand the exact panel rotation and then look at the code.

from esp32-hub75-matrixpanel-i2s-dma.

Yes i will try and send you the results

from esp32-hub75-matrixpanel-i2s-dma.

@mrfaptastic

Long cable setup:

Short cable setup (code is the same) :

As you can see, lines do not match

from esp32-hub75-matrixpanel-i2s-dma.

I take it for the long cable (top down chain) photo it's the following:

#define SERPENT true
#define TOPDOWN true

and shot cable photo

#define SERPENT true
#define TOPDOWN false

?

Can you run the short cable (bottom up chain) example with the 'top down' config... I know it will produce a mess but will help visually:

#define SERPENT true
#define TOPDOWN true

from esp32-hub75-matrixpanel-i2s-dma.

Every example i showed you was serpent true topdown false. With long cable the output is ok. Now i will show you short cable with true true:

from esp32-hub75-matrixpanel-i2s-dma.

Connection, pinology, esp placement do not change when i rearrange those displays so i think it is still serpent true topdown false with long and short cable. So no fix in the software will get me to the right result. The construction of the displays cause that the connectors are far apart from each other.. I am glad that double buffer works now. Thank you for everything.

from esp32-hub75-matrixpanel-i2s-dma.

No No. This can be fixed in software easily. I will need to find some old panels to test this.

from esp32-hub75-matrixpanel-i2s-dma.

from esp32-hub75-matrixpanel-i2s-dma.

You're right. I need to have top down from left, top down from right, bottom up from left, bottom up from right.

Never thought the starting left/right location of the ESP32 device would matter... But there you go.

Just to confirm, in the last photo with the short cable the esp is behind the panel on the bottom right ?

from esp32-hub75-matrixpanel-i2s-dma.

@mrfaptastic
Yeah that is what i think that we need to specify if the esp is closer to the middle or closer to the edge :D.
BOTTOM:

Im flipping to the led side like this:

So it becomes:
SERPENTINE TRUE TOPDOWN FALSE:

SERPENTINE TRUE TOPDOWN TRUE:

from esp32-hub75-matrixpanel-i2s-dma.

@primus192 - I ended up going down a rabbits hole and re-engineering the VirtualMatrixPanel class.

It will now support this chaining using the CHAIN_TOP_LEFT_DOWN chain type.

Refer to the updated 'ChainedPanels' example and documentation. These changes break backward compatability. If you have issues, please raise a new issue specific to this issue. Thanks.

from esp32-hub75-matrixpanel-i2s-dma.

from esp32-hub75-matrixpanel-i2s-dma.

Thank you. Please let me know if it works as well.

from esp32-hub75-matrixpanel-i2s-dma.

Also, where do you get those plastic clips to connect the panels together? Have you custom made those with a 3d printer? Can I buy some off you?

from esp32-hub75-matrixpanel-i2s-dma.

Also, where do you get those plastic clips to connect the panels together? Have you custom made those with a 3d printer? Can I buy some off you?

Yes, the joints are designed and 3d printed .

I currently have three of them for 64x64 p3 panels like so:

Joint for middle fixing four 64x64 panels:

Joint for fixing edges of columns:

Joint for fixing edges of rows:

Do you have 3d printer so i can send you the files or do you want me to send some to you (im from Poland)? Please mind that different density and size of the panels have different distances between screws and it depends also how you chain them. Please let me know the details and the distances of your threaded inserts that you would need. I also can create "pill shaped" screw holes so you will be able to fit it as you want.

from esp32-hub75-matrixpanel-i2s-dma.

Do you have 3d printer so i can send you the files or do you want me to send some to you (im from Poland)? Please mind that different density and size of the panels have different distances between screws and it depends also how you chain them. Please let me know the details and the distances of your threaded inserts that you would need. I also can create "pill shaped" screw holes so you will be able to fit it as you want.

Wow that's amazing. I don't have a 3D printer, but I can probably find somebody local (in the UK) if you have a 3d model that's of use?

I have a bunch of P3 panels that I use to regression test this library with. 46mm and 22mm seem to be the important lengths.

from esp32-hub75-matrixpanel-i2s-dma.

@mrfaptastic ,

on my end i still could see a blink once every 1-2 sec, did not have issue on gif and jpg rendering. however the changes are workable and less than before, probably i need to retest by removing delay at some other place and try again, but i doubt it will fix this issue.

from esp32-hub75-matrixpanel-i2s-dma.