Flickering during GUI_MULTIBUF_Begin (?!)

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • Flickering during GUI_MULTIBUF_Begin (?!)

    After including some time critical realtime process to the mcu application which also handles a display flickering occurs.

    The project allready uses double buffering and i found that the flickering occurs when the GUI_MultiBuf_Begin function is called.

    (I set a breakpoint to the function call and when i step over the function the flickering occurs)

    Thinking a bit deeper into it, it seems a legible question wether it's really necessarry for this function to do something which can cause flickering...
    ?(

    I made an experiment where the GUI_MultiBuf_Begin runs through without getting interrupted by the realtime process and the flickering is nearly gone. (But of caurse this will not work as the realtime process needs to be high prio)



    Meanwhile i enabled tripple buffering to give it a try but of course the flickering still occurs, as the flickering is not because of a delayed switch of the buffer (when vsync interrupt occurs) - it seems to have a different cause which lies inside the GUI_MULTIBUF-Begin.


    I also ensured that the flickering can not occur because of emv issues as i disabled all output ports of the realtime process.


    Any ideas?
  • Hi,

    i wanted to let you know what was the solution for this one, if anyone stumples across:

    The problem was that there is no videoram, this means the displaycontroller will frequently request data from the sdram.

    That conflicts with the realtime process accressing the sdram and it also caused some critical jitter in this realtime process.

    The solution was to let the realtime process work with data allocated in the iram and the displaycontroller works with a display buffer allocated in the sdram.

    As i have the iram used for the stack and the sdram used for the heap it was simple: Just allocate the data for the realtime process in the main-method on the stack and give the controller a pointer to this variable (on the stack, in the iram).

    With the data in the iram jitter of the realtime process and also flickering of the display disappeared.
  • RE: Flickering during GUI_MULTIBUF_Begin (?!)

    halstoy wrote:

    After including some time critical realtime process to the mcu application which also handles a display flickering occurs.

    The project allready uses double buffering and i found that the flickering occurs when the GUI_MultiBuf_Begin function is called.

    (I set a breakpoint to the function call and when i step over the function the flickering occurs)

    Thinking a bit deeper into it, it seems a legible question wether it's really necessarry for this function to do something which can cause flickering...
    ?(

    I made an experiment where the GUI_MultiBuf_Begin runs through without getting interrupted by the realtime process and the flickering is nearly gone. (But of caurse this will not work as the realtime process needs to be high prio)



    Meanwhile i enabled tripple buffering to give it a try but of course the flickering still occurs, as the flickering is not because of a delayed switch of the buffer (when vsync interrupt occurs) - it seems to have a different cause which lies inside the GUI_MULTIBUF-Begin.


    I also ensured that the flickering can not occur because of emv issues as i disabled all output ports of the realtime process.


    Any ideas?
    I am using emWin controlled multibuffer. This is done by API WM_MULTIBUF_Enable(TRUE);
    I had the same flickering problem as described by you. After considerable debugging, I found was that emWin's Multibuffer API GUI_MULTIBUF_Begin will switch the buffers even if there is no back buffer available for rendering. This will sometimes result in pending buffer becoming active while you are in middle of rendering on what you think is back buffer, but it is actually already rendered pending buffer. The solution here is to make sure you are not rendering again to already pending buffer. You effective frame rate will drop but you will not see any artifacts/flicker. I am interested to know if this solves your problem aswell.

    C Source Code

    1. if (layer_prop[0].pending_buffer == -1) { GUI_Exec();
    2. }