how many memdev drawauto can exec on concurrent?

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

    • how many memdev drawauto can exec on concurrent?

      Hi

      on my project, I create 7 GUI_AUTODEV to draw separate dirty area to speed up screen refresh rate.
      But I always got hardfault_handler exception after free running for a while.
      check the call stack, the last function before HardFault_Handler always is emWin library function, just like _GetPixelIndex().

      I have already alloc 0x400000 bytes size on external SDRAM for GUI library, I think it could not caused by memory not enough.
      I always try to increase stack an heap size to 0x800 and 0x400, but the issue still happen.

      my procedure just like:
      while(1)
      {
      1. update drawing parameters.
      2. call GUI_MEMDEV_DrawAuto for each GUI_AUTODEV
      3. call GUI_Exec()
      }

      The issue happen duration time could soon to happen ( 4 seconds ) or long time to happen (15000 seconds).

      So, I try to decrease the GUI_AUTODEV content numbers down to two memory devices only ( Just update two dirty area), and the problem disappear, free run for 72 hours.

      Is there anything else I miss? thanks a lot.

      Br, Titan.Chen

    • Additional:

      Platoform: stm32F469
      external SDRAM : 8M bytes

      if two GUI_AUTODEV dirty area has cover area, is that possible cause any problem?
      __________________
      | |
      | A |
      | ________ |
      | | | |
      | | B | |
      | |________| |
      |________________|

      Just like above picture, dirty area A cover dirty area B, could I create two GUI_AUTODEV to draw the area in separate?
      why I do it.. because I want to reduce the dirty area in the smallest to speed up.

      Br, Titan.Chen

    • Hello Chen,

      We are not aware of any issues with auto devices. Unfortunately, I do not know how you make use of the devices so it's hard to say what is going wrong here (a simple application which shows how to reproduce the issue is always a good idea).

      In general it shouldn't be necessary to have more than one auto device. The device checks which area is 'dirty' and only this area gets updated. I don't understand why there should be more than one devices.

      Attached is an example for the usage of auto devices.

      You are using a STM32F469, are you also using the internal LCD controller?

      If this is the case it shouldn't be necessary to split the screen in dirty areas becasue only the changed pixel will get updated in the framebuffer.

      If you are using an external LCD controller, e.g. with the GUIDRV_FlexColor driver, you can use a version of the driver with a cache. This cache already manages a dirty rectangle to reduce the workload to a minimum.

      Beside of that you could also use the Window Manager to split the screen into different parts. Set up windows for every part, if one part should be updated only the dedicated window gets redrawn. Like below:

      C Source Code

      1. #include "DIALOG.h"
      3. /*********************************************************************
      4. *
      5. * Externals
      6. *
      7. **********************************************************************
      8. */
      10. /*********************************************************************
      11. *
      12. * Defines
      13. *
      14. **********************************************************************
      15. */
      17. /*********************************************************************
      18. *
      19. * Static data
      20. *
      21. **********************************************************************
      22. */
      23. static GUI_COLOR _aColor[] = { GUI_RED, GUI_GREEN, GUI_BLUE, GUI_YELLOW, GUI_CYAN, GUI_MAGENTA };
      25. /*********************************************************************
      26. *
      27. * Static code
      28. *
      29. **********************************************************************
      30. */
      31. /*********************************************************************
      32. *
      33. * _cbWinA
      34. *
      35. * This callback manages the area of the window A.
      36. *
      37. */
      38. static void _cbWinA(WM_MESSAGE * pMsg) {
      39. static int Index;
      41. switch (pMsg->MsgId) {
      42. case WM_PAINT:
      43. GUI_SetBkColor(_aColor[Index++]);
      44. Index = (Index == GUI_COUNTOF(_aColor)) ? 0 : Index;
      45. GUI_Clear();
      46. break;
      47. default:
      48. WM_DefaultProc(pMsg);
      49. break;
      50. }
      51. }
      53. /*********************************************************************
      54. *
      55. * _cbWinB
      56. *
      57. * This callback manages the area of the window B.
      58. *
      59. */
      60. static void _cbWinB(WM_MESSAGE * pMsg) {
      61. static int Index = GUI_COUNTOF(_aColor) >> 1;
      63. switch (pMsg->MsgId) {
      64. case WM_PAINT:
      65. GUI_SetBkColor(_aColor[Index++]);
      66. Index = (Index == GUI_COUNTOF(_aColor)) ? 0 : Index;
      67. GUI_Clear();
      68. break;
      69. default:
      70. WM_DefaultProc(pMsg);
      71. break;
      72. }
      73. }
      75. /*********************************************************************
      76. *
      77. * _cbBk
      78. *
      79. * This callback manages the complete background, if the other windows
      80. * cover the complete screen this function is not necessary.
      81. */
      82. static void _cbBk(WM_MESSAGE * pMsg) {
      83. switch (pMsg->MsgId) {
      84. case WM_PAINT:
      85. GUI_SetBkColor(GUI_BLACK);
      86. GUI_Clear();
      87. break;
      88. default:
      89. WM_DefaultProc(pMsg);
      90. break;
      91. }
      92. }
      94. /*********************************************************************
      95. *
      96. * Public code
      97. *
      98. **********************************************************************
      99. */
      100. /*********************************************************************
      101. *
      102. * MainTask
      103. */
      104. void MainTask(void) {
      105. WM_HWIN hWinA, hWinB;
      107. GUI_Init();
      108. WM_SetCallback(WM_HBKWIN, _cbBk);
      109. hWinA = WM_CreateWindow(0, 0, 120, 120, WM_CF_SHOW, _cbWinA, 0);
      110. hWinB = WM_CreateWindow(0, 120, 120, 120, WM_CF_SHOW, _cbWinB, 0);
      111. while (1) {
      112. GUI_Delay(500);
      113. WM_InvalidateWindow(hWinA);
      114. GUI_Delay(500);
      115. WM_InvalidateWindow(hWinB);
      116. }
      117. }
      119. /*************************** End of file ****************************/
      Display All
      Regards,
      Sven
      Files
      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.

    • Hi Sven

      thanks for your support. it looks a great ideal using Window Manager to split the screen into different parts.
      You are using a STM32F469, are you also using the internal LCD controller? --> yes, I am using internal LCD controller.

      Is that possible using GUI_MEMDEV_DrawAuto() on window's WM_PAINT event?
      could you please also release a simple code ?

      At first, I used one auto device for whole screen, in my imagination, it will redraw the dirty area at different block only.
      but if the dirty area leave in different discontinues area, just like the picture
      _______________________________
      |
      | ____ _____
      | |A | |B |
      | |__ | |___|
      |
      |______________________________

      it not only redraw the separate block A and B dirty area, it will also redraw the area between A and B.
      The redraw area was increase to speed down the screen refresh ratio.
      that's why I create separate auto device to control the separate area.
      the method was reference GUIDEMO_Automotive.c

      These days I do some experiments to check the hardfault exception.
      I found it I using GUI_DispString on GUI_MEMDEV_DrawAuto's callback funciton, the system easily fall into hardfault_handler even if using on window's WM_PAINT() event function.
      I am using Keil IDE, I check the "Caller Code", the last function before hardfault_handler, it always emWin function.
      I don't have source code to debug, I don't have any ideal what's happen there.
      I can just only do not using some special GUI DRAWING function on special emWin's callback function.
      do you have any suggestion about these issue? or I need to open another thread to discuss?

      Br, Titan.Chen