How to synchronize GUIDRV_FLEXCOLOR writing to SSD1963 with the Tearing Signal of the SSD1963

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

    • How to synchronize GUIDRV_FLEXCOLOR writing to SSD1963 with the Tearing Signal of the SSD1963

      Hello to all,

      I use emwin 6.10 together with a SSD1963 coupled via 16Bit interface.
      I use cached driver:
      GUIDRV_FlexColor_SetFunc(pDevice, &PortAPI, GUIDRV_FLEXCOLOR_F66720, GUIDRV_FLEXCOLOR_M16C1B16);

      The display workes fine as soon as it comes to videos. I tested the demo MOVIE_ShowFeatures.c out of emwin/sample/tutorials.

      The "explosion" scene shows tearing effects.


      I know the GUIDRV_FlexColor does not support multibuffering.


      But I think there must a possibilty to synchronize the output of emwin to the SSD1963 by using its tearing output.


      Is GUIDRV_FlexColor able to use the tearing information in a way?
      If yes, how can we do this?

      Thank you for any help
      Andy

    • Hi,

      The GUI_SetRefreshHook() function is what I wanted to suggest.

      Try something like this:

      C Source Code

      1. static int VSYNC_Signal;
      3. void VSYNC_ISR(void) {
      4. VSYNC_Signal = 1;
      5. }
      7. static void _RefreshHook(void) {
      8. VSYNC_Signal = 0;
      9. while (VSYNC_Signal == 0);
      10. }
      12. void LCD_X_Config(void) {
      13. // ...
      14. GUI_SetRefreshHook(_RefreshHook);
      15. // ...
      16. }
      Display All

      The driver needs to use a cache. When using the Window Manager you have to do nothing else, it will take care of locking/unlocking the cache. If not using the Window Manager you can use LCD_ControlCache(LCD_CC_LOCK) and LCD_ControlCache(LCD_CC_UNLOCK) before and after a drawing operation.

      Do NOT use WM_MULTIBUF_Enable() in your application. This would disable the locking mechanism of the cache.

      Regards,
      Sven
      Please read the forum rules before posting.

      Keep in mind, this is *not* a support forum.
      Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
      Should you be entitled to support you can contact us via our support system: segger.com/ticket/
      Or you can contact us via e-mail.

    • Hello Sven,

      Thank you for your reply indeed, I made some progress especially with LCD_ControlCache(LCD_CC_LOCK). But please let me explain first:

      I did some testing of the GUI_SetRefreshHook() function yesterday already, just to check how often it is called while the picture is drawn.
      However I encountered some strange behaviour...
      I am using the original SEGGER video demo file: MOVIE_ShowFeatures.c out of emwin/sample/tutorials.
      There are four videos, which are shown in this demo:
      1) _acExplosion_200x150
      This video is making the problems.
      In his callback it does:


      case GUI_MOVIE_NOTIFICATION_PREDRAW:
      GUI_MULTIBUF_Begin();
      break;
      case GUI_MOVIE_NOTIFICATION_POSTDRAW:
      GUI_MULTIBUF_End();
      break;

      However in MOVIE_ShowFeatures.c there is no WM_MULTIBUF_Enable() instruction. So maybe these GUI_MULTIBUF_Begin/_End(); are some remainings from another demo program?
      --> But when playing this _acExplosion_200x150 video the GUI_SetRefreshHook() IS NOT TRIGGERED every frame! It is triggered after the whole explosion video is finished... Therefore I cannot use this callback for synchronising the particular frames to the SSD1963.


      2) _acFireworks_160x90
      This video works without problems
      In his callback it is handled using a memory device in order to write the frame number on top of the video.
      When playing this video the GUI_SetRefreshHook() is correctly called every frame, though in detail it is called every second frame only.

      Please tell me, is a memory device to handle each video frame essential to have flickerfree videos with GUIDRV_FlexColor and indirect interface?
      Why is the callback of the video called every second frame only?


      3+4) videos _acTyping_80x45 and _acGeorgiaMountain_80x45
      These videos work fine, but there is no callback function involved, thus no memory device.
      Even though the videos work fine, again the GUI_SetRefreshHook() function is called AFTER the video is finished!
      Maybe the videos work fine, because they are so small?

      I am doing all this experiments because I need to play a video on a 800*480*16bpp screen in the future using the SSD1963.
      I am using the cache driver already GUIDRV_FLEXCOLOR_M16C1B16.
      I modified the callback of video 1) now according to your advice:
      case GUI_MOVIE_NOTIFICATION_PREDRAW:
      LCD_ControlCache(LCD_CC_LOCK);
      break;
      case GUI_MOVIE_NOTIFICATION_POSTDRAW:
      LCD_ControlCache(LCD_CC_UNLOCK);
      break;
      It is working fine now!! But the callback of this video is called every fifth frame only??! I would be happy to understand this...
      (By the way in this configuration GUI_SetRefreshHook() is also called many times during the video now...!)

      As a conclusion I can say:
      When playing a video with GUIDRV_FlexColor and indirect interface a memory assistance of some sort is necessary.
      Either a cache with Lock/Unlock in the callback or handling the frames via memory device (also implemented in the callback of the video)



      Another thing that is curious to me:
      Even though the videos are working fine now, there is still no handling of the tearing signal installed be me, thus no synchronisation emwin/SSD1963 at all.

      (Up to now I tested only how often the GUI_SetRefreshHook() is called, I do nothing in it!)
      My question is: How can there be flickerfree videos with emwin writing to the SSD1963, if emwin has no clue what the SSD1963 is doing currently?
      Is there some cool handling of the incoming data within SSD1963?



      One last thing:
      There is also an animation installed in this demo, showing these words one after the other:

      "emWin", "now", "supports", "!!!Movies!!!"
      This is handled with memory devices.
      However there are huge tearing effects and the GUI_SetRefreshHook() is called after the animation only. (per each word)
      If I would have a solution to handle these anomations smoothly, I would be happy 100%...

      So, this is it, thank you again very much for you help Sven and stay healthy

      Andy

    • Hello Sven,

      I solved my last issue regarding the animation of "emWin", "now", "supports", "!!!Movies!!!" a little.
      There is a memory device that holds the text (hMemText) and another one (hMemWork) which is always the destination for rotation instructions.
      The display works fine, if I always clean the working memory device (hMemWork) before it is repeatedly used in the loops:

      GUI_MEMDEV_Select(hMemWork);
      GUI_Clear();
      GUI_MEMDEV_Select(0);
      Because this demo runs perfect on other hardware with GUI_DRV_LIN and double buffering, I think this clearing of the destination memory device is necessary for
      GUIDRV_FlexColor and indirect interface hardware only.

      But while debugging this I found another issue:
      My driver uses 16bpp and COLOR_CONVERSION GUICC_M565

      However the original SEGGER MOVIE_ShowFeatures.c uses this for the memory device creation:
      hMemText = GUI_MEMDEV_CreateExFixed(xPos, yPos, xSizeDevice, ySizeDevice, GUI_MEMDEV_NOTRANS, GUI_MEMDEV_APILIST_32, GUICC_8888);

      Doing so it works, which is curious, because GUICC_8888 is not my color conversion.


      But if I set it to (which reflects my hardware):
      hMemText = GUI_MEMDEV_CreateExFixed(xPos, yPos, xSizeDevice, ySizeDevice, GUI_MEMDEV_NOTRANS, GUI_MEMDEV_APILIST_16, GUICC_M565);

      A valid handle hMemText is returned (also for hMemWork), but nothing is displayed.

      I also used GUI_MEMDEV_CreateEx() and GUI_MEMDEV_Create() with the same result: nothing is displayed.

      I do not understand why for this GUI_MEMDEV_Rotate(hMemText, hMemWork, 0, 0, 0, Mag) instruction only a memory device created by GUI_MEMDEV_CreateExFixed() works plus the parameters for bpp and colorconversion are obviously wrong and not compatible to my hardware.

      Please apologize for my huge amount of text I wrote to you.
      But I would like to understand this and not just having a workaround.
      In the upcoming years we decided to use emwin for a new project rather than TouchGFX, because emwin is much more flexible and much better documented!
      But as a developer I need a more profound knowledge about this very nice product...

      Best regards to you
      Andy

    • Hi,



      Andy_AN2 wrote:

      1) _acExplosion_200x150
      This video is making the problems.
      In his callback it does:


      case GUI_MOVIE_NOTIFICATION_PREDRAW:
      GUI_MULTIBUF_Begin();
      break;
      case GUI_MOVIE_NOTIFICATION_POSTDRAW:
      GUI_MULTIBUF_End();
      break;
      As you already discovered, simply replace the multibuffering calls by the LCDControlCache() stuff.


      Andy_AN2 wrote:

      However in MOVIE_ShowFeatures.c there is no WM_MULTIBUF_Enable() instruction. So maybe these GUI_MULTIBUF_Begin/_End(); are some remainings from another demo program?
      WM_MULTIBUF_Begin() is for "telling" the Window Manager (WM) that multibuffering should be used. If the application does not make use of the WM you have to take care of switching back and front buffers. This is done by the function GUI_MULTIBUF_Begin/End().

      Andy_AN2 wrote:

      But when playing this _acExplosion_200x150 video the GUI_SetRefreshHook() IS NOT TRIGGERED every frame! It is triggered after the whole explosion video is finished... Therefore I cannot use this callback for synchronising the particular frames to the SSD1963.
      Not sure why the hook function is not being called. Did you already replaced the multibuffering function by the cache functions?

      Andy_AN2 wrote:

      Please tell me, is a memory device to handle each video frame essential to have flickerfree videos with GUIDRV_FlexColor and indirect interface?
      Why is the callback of the video called every second frame only?
      The MOVIE module does not necessarily show every single frame. It tries to keep the movie fluid. On slow systems you would experience something like slide show if the movie module would show every frame. So, instead of showing every frame some are getting skipped to not slow down the movie.

      I guess the desired FPS for the movies in this demo are 25 FPS. So every frame has 40 ms to be displayed. If a single frame takes longer than 40ms it can happen that the next frame will be skipped.

      Andy_AN2 wrote:

      I am doing all this experiments because I need to play a video on a 800*480*16bpp screen in the future using the SSD1963
      800x480... This is pretty huge for video and will be a tough task.

      If you have the video saved as an EMF file, which is in fact nothing else than JPEGs sicked together, this would also include decoding the JPEGs on runtime. It's not only the ~19MB (800x480x2x25) you have to send to the SSD1963 but also the decoding of 25 JPEGs per second (in the best case).

      Which MCU are you using?

      Andy_AN2 wrote:

      But if I set it to (which reflects my hardware):
      hMemText = GUI_MEMDEV_CreateExFixed(xPos, yPos, xSizeDevice, ySizeDevice, GUI_MEMDEV_NOTRANS, GUI_MEMDEV_APILIST_16, GUICC_M565);

      A valid handle hMemText is returned (also for hMemWork), but nothing is displayed.
      This is most likely because the memory devices should be rotated. This works only with 32bpp devices. But instead of GUICC_8888 I would use GUICC_M8888I. Maybe you have an older version of the demo.

      Regards,
      Sven
      Please read the forum rules before posting.

      Keep in mind, this is *not* a support forum.
      Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
      Should you be entitled to support you can contact us via our support system: segger.com/ticket/
      Or you can contact us via e-mail.

    • Hello Sven,

      your comments are of great help thank you.

      Only a few points are left.

      You wrote:
      "Not sure why the hook function is not being called. Did you already replaced the multibuffering function by the cache functions?"

      Yes, at that time I did not replace the multibuffering function by the cache locking functions yet.
      I can see that the hook function works only down to the video frames, if some sort of memory buffering is involved, either multibuffering or cache.
      Is that correct?

      You wrote:
      "Which MCU are you using?"

      I will use the STM32F769 and hopefully the jpg hardware decoder will help.
      In this context I have one question about the cached driver GUIDRV_FLEXCOLOR_M16C1B16: Is this cache, installed by "C1" similar or equal to the DCache described in the manual?
      For my understanding the DCache is only a change detector per pixel with 1bpp, in order to do only necessary writes to the display.
      On the other side if I use a cached driver with "C1" is there a full copy of the framebuffer used as a cache, which resides within emwin (taken from GUI_NUMBYTES)?
      Having this "framebuffer" accessible with a clear memory adress I could imagine to use DMA2D unit in the STM32F769 for copying data to this framebuffer.
      Up to now unfortunately the DMA2D unit in the MCU is useless because I do not use the LTDC unit (which involves GUI_DRV_LIN and nice DMA2D usage)

      Thanks a lot for your reply
      Andy