flicker...

[twinotter]

I'm trying to figure out why I'm getting some flicker. The options in the Common Issues issue don't seem to apply...

Flickering happens somewhat rarely. (Maybe a couple times a second with a frame rate of about 140ish fps.)

I'm double buffering. Drawing to the non-displayed buffer. Then flipping. There is a "fillRect" being used to erase part of the buffer... and is what's leading directly to the flickering. If I remove it, pixels are persistent of course, but the flicker disappears completely. This means the draw buffer, which shouldn't be on display or even in the presently output DMA linked list, is being displayed....

The code is oriented like this:

loop() {

<drawing code> 

    dma_display->showDMABuffer(); // this activates 
    dma_display->flipDMABuffer(); // this flips which buffer you draw to (and waits for a buffer to complete)

}

Originally this had quite a bit of flickering (maybe 3 or 4 times per second with a frame rate of about 70). When I combined them together into a single swap command below there was less flickering and frame rate jumped to 140ish. In ESP32_HUB75_LED_MATRIX_PANEL_DMA_Display.h:

inline void swapDMABuffer() // combined show and flip in order to prevent writing between the show and the flip
    {

        if (!m_cfg.double_buff) return;

        #if SERIAL_DEBUG
                Serial.printf_P(PSTR("Showtime for buffer: %d and the flipping to %d!\n"), back_buffer_id, back_buffer_id^1);
        #endif

        i2s_parallel_flip_to_buffer(I2S_NUM_1, back_buffer_id);
        back_buffer_id ^= 1;

        // Wait before we allow any writing to the buffer. Stop flicker.
        while(!i2s_parallel_is_previous_buffer_free()) { delay(1); }
    }  

This has the advantage of having only a single wait for the previous_buffer_free(). That gives the improved frame rate.

I've got it configured with double buffering. I've tried a number of different configurations

I've found I can eliminate flickering entirely if I run three swap commands in a row, but frame rate drops to about 30fps:

dma_display->swapDMABuffer();
dma_display->swapDMABuffer();
dma_display->swapDMABuffer();

I'm thinking of moving the code that changes the DMA end-of-list pointer and putting it inside the isr... I believe that will likely cause the DMA to output one more complete frame before its switch happens. This is on the theory that the DMA is close to done with a complete frame when the pointer at the end of the linked list changes. thus, perhaps the DMA is moving on to the new buffer before the code gets stopped in the while loop waiting for the dma to finish... this is a stretch both because the timing seems really unlikely and because the isr/main loop are running on the same processor - there is no race condition on that end of things... only potentially between the DMA and the code.

Am I missing something obvious? Has anyone seen this behavior in double buffered setups?

Rudy

[mrcodetastic]

Hi @twinotter,

There have been a couple of discussions about this behaviour over the year(s). I actually made a change to the library similar to you and removed the 'showDmabuffer' call and merged everything into the one flipDMABuffer call, that certainly helped.

My theory is that the DMA calls (this library) and Arduino sketch run independently/asynchronously, and therefore, it could be plausible that the DMA changes to the end of list pointer occur before actual graphics drawing / updates to the DMA buffer haven't finished - only a theory though.

As a hack, I notice that if I put a delay between the end of my graphics logic (i.e. doing updates to the DMA buffer), and then the 'flip', then any flicker largely disappears.

Alternatively, I just create my own in-sketch graphics buffer (i.e. uint16_6 buffer[64][32];), and then iterate through the whole thing and update the DMA buffer (no dma library double buffering required).

[twinotter]

Interesting theory. I think the library, isr, and arduino code are all running on the same core, so there wouldn't be a race condition there.

But the DMA is in some ways like a separate core - with separate timing to the memory bus. My theory (also unsubstantiated) is that the DMA is preloading the next frame pointer from the DMA linked list. Some percentage of the time (based on number of elements in the linked list), it preloads the one that is about to be changed, so has one extra circuit through that buffer before switching. And that's when the flicker changed.

I found adding a 3ms delay right after the flip eliminated my flicker.. without affecting my framerate. (that wait for the end of buffer ISR to trigger is what affects frame rate most) BUT when I added some more debug serial port messaging, more flicker reappeared. So there is more to it than just this.

In short order I'm going to try out using that layer buffer approach - it has the advantage also of being able to read back the true color... and should allow me to go back to single-buffering the DMA... so the memory hit should be somewhat minimal.

But I'm also interested in trying out stopping and restarting the DMA. In this approach, I'd have two DMA buffers that never point to each other (the way page flips are done now). Instead, I'd just reinitialize the DMA with the other DMA buffer's address... hopefully that would clear any pipe-lined DMA memory accesses and eliminate flicker.

It's hard to say which approach is better...

(sorry for my slow response time.)

[mrcodetastic]

In short order I'm going to try out using that layer buffer approach - it has the advantage also of being able to read back the true color... and should allow me to go back to single-buffering the DMA... so the memory hit should be somewhat minimal.

Well.. The memory used for a layer buffer is offset by turning off double-buffering. So the overall memory consumption will be the same.

It's hard to say which approach is better...

Depends on how much you value your time. Not sure it's worth the effort trying to work around Espressif's xtensa SoC hardware quirks at the hardware / dma level.

[twinotter]

True enough. I think the biggest drawback of the Espressif is poor documentation...

[mrcodetastic]

@twinotter - Any chance you could dig up your old flickery sketch you were using, and try it again with the latest version of this library in the git?

I've played around with the flipDMABuffer logic - curious to see if it helped at all.

[tsctrl]

one question regarding this, in theory do i have to change the codes flow on flipping buffer or i can use the same flow for using dma buffer or memory buffer?

i guess, in easy words. whats happen now is double dma is not working as expected per codes completion but the memory buffer guarantee that.

thanks!

[mrcodetastic]

The thing is, the naming of the functions is wrong anyway. There is no 'full' or not full buffer. They're always full and 'free' to be used.

DMA engine is its own beast and looping out output continuously irrespective of whatever the sketch does or any CPU based callbacks do.

Summary: Callbacks don't work, are too slow, and the DMA engine doesn't care and does it's own thing anyway - to pump out data as quickly as possible.

Have you tried the latest git version of the library?

[tsctrl]

will do, i might have some issue with isr and might need to ask you for workaround. will update you once

thanks!

[tsctrl]

hi @mrfaptastic ,

i have integrate the master, removed all delays related to flickering and good news! i didnt see any flickering at all!

some feedback,

1. display are more stable and uniform,
2. no more lustering kind of bright per pixel.
3. more saturated colors.
4. all transition per pixel movement are well lit per movement and no trails.
5. no ISR issue on my end as before.

however:

1. i have to feed 1ms delay on my main loop to feed the wdt but i guess thats a good sign.
2. brightness was reduced from my sight probably 10% less.
3. pixel looks smaller (probably due to less bright)

below just sake for some warning on my end that i fix for notes:
#warning rom/lldesc.h is deprecated, please use esp32/rom/lldesc.h instead
#warning rom/gpio.h is deprecated, please use esp32/rom/gpio.h instead
esp32_i2s_parallel_dma.h:53:9: warning: this statement may fall through [-Wimplicit-fallthrough=] if(port == I2S_NUM_1) {
error: this 'if' clause does not guard... [-Werror=misleading-indentation] if((x_coord) >= lsbBrightness)
note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'if' continue;

the however does not mean is an issue at all and i am keeping the master changes

thank you so much on all the work, and i guess everyone loves you! Merry Christmas!

[mrcodetastic]

That's fantastic to hear! Glad it works now.

Merry Christmas!

[mrcodetastic]

Those compile-time warnings you mentioned should be gone as well now.