Antialiasing functions (AA) not working

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

    • Antialiasing functions (AA) not working

      Hello,

      I've setup a project with the following hardware/software:
      - STM32F401xE (84MHz clock, 96KB SRAM - no internal buffer)
      - 3.5" Display with ILI9488 controller, 8 bit I8080
      - I've assigned 32KB of SRAM memory to the emWin library (STemWin GUI_VERSION 54401)

      LCD_X_Config :

      Source Code

      1. void LCD_X_Config(void)
      2. {
      3. GUI_DEVICE * pDevice;
      4. CONFIG_FLEXCOLOR Config = {0};
      5. GUI_PORT_API PortAPI = {0};
      6. //
      7. // Set display driver and color conversion
      8. //
      9. pDevice = GUI_DEVICE_CreateAndLink(GUIDRV_FLEXCOLOR, GUICC_565, 0, 0);
      11. //
      12. // Display driver configuration
      13. //
      14. LCD_SetSizeEx (0, XSIZE_PHYS , YSIZE_PHYS);
      15. LCD_SetVSizeEx(0, VXSIZE_PHYS, VYSIZE_PHYS);
      16. //
      17. // Configuration
      18. //
      19. /* Orientation possible values
      20. GUI_MIRROR_X: Mirroring X-axis
      21. GUI_MIRROR_Y: Mirroring Y-axis
      22. GUI_SWAP_XY: Swapping X and Y axis
      23. */
      24. #if DISPLAY_CONFIG_PORTRAIT
      25. Config.Orientation = GUI_MIRROR_X;
      26. #elif DISPLAY_CONFIG_LANDSCAPE
      27. Config.Orientation = GUI_MIRROR_X|GUI_MIRROR_Y|GUI_SWAP_XY;
      28. #endif
      29. #if (NUM_BUFFERS > 1)
      30. GUI_MULTIBUF_ConfigEx(0, NUM_BUFFERS);
      31. #endif
      32. GUIDRV_FlexColor_Config(pDevice, &Config);
      34. //
      35. // Set controller and operation mode
      36. //
      37. PortAPI.pfWrite8_A0 = LcdWriteReg;
      38. PortAPI.pfWrite8_A1 = LcdWriteData;
      39. PortAPI.pfWriteM8_A1 = LcdWriteDataMultiple;
      40. PortAPI.pfReadM8_A1 = LcdReadDataMultiple;
      41. GUIDRV_FlexColor_SetFunc(pDevice, &PortAPI, GUIDRV_FLEXCOLOR_F66709, GUIDRV_FLEXCOLOR_M16C0B8);
      42. }
      Display All

      I've made a test with the GUI_AA_DrawArc function and it is only working when I set GUI_AA_SetFactor(1).

      If I set a number higher than 1 on GUI_AA_SetFactor() the program will execute the ReadM8_A1 function and will get stuck on a HardFault after its execution.
      Same happens to GUI_AA_DrawPolygon.

      Is it something related to the display controller reading back function or is it a RAM issue?
      According to the documentation the pfReadM8_A1 is a pointer to a function which reads multiple bytes from the controller with C/D line high.
      From my understanding it has to be the function related to a generically read on the controller after the command (when C/D line is low).

      This is the implementation:

      Source Code

      1. /********************************************************************
      2. *
      3. * LcdReadDataMultiple
      4. *
      5. * Function description:
      6. * Reads multiple values from a display register.
      7. */
      8. static void LcdReadDataMultiple(U8 * pData, int NumItems)
      9. {
      10. LCD_IO_ReadMultipleData8(0, pData, NumItems, 0);
      11. }
      13. void LCD_IO_ReadMultipleData8(uint8_t Cmd, uint8_t *pData, uint32_t Size, uint32_t DummySize)
      14. {
      15. uint8_t *dummy_data;
      16. // CS LOW
      17. CS_GPIO_Port->BSRR = (uint32_t)CS_Pin << 16U;
      18. // DCX HI
      19. DCX_GPIO_Port->BSRR = (uint32_t)DCX_Pin;
      20. // Write HI
      21. WRX_GPIO_Port->BSRR = (uint32_t)WRX_Pin;
      22. // Read LOW
      23. RDX_GPIO_Port->BSRR = (uint32_t)RDX_Pin << 16U;
      25. GPIO_InitTypeDef GPIO_InitStruct = {0};
      26. __HAL_RCC_GPIOA_CLK_ENABLE();
      27. //Set port as input
      28. /*Configure GPIO pin Output Level */
      29. HAL_GPIO_WritePin(GPIOA, DB0_Pin|DB1_Pin|DB2_Pin|DB3_Pin
      30. |DB4_Pin|DB5_Pin|DB6_Pin|DB7_Pin, GPIO_PIN_RESET);
      31. GPIO_InitStruct.Pin = DB0_Pin|DB1_Pin|DB2_Pin|DB3_Pin
      32. |DB4_Pin|DB5_Pin|DB6_Pin|DB7_Pin;
      33. GPIO_InitStruct.Mode = GPIO_MODE_INPUT;
      34. GPIO_InitStruct.Pull = GPIO_PULLUP;
      35. GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_VERY_HIGH;
      36. HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);
      38. //Dummy read
      39. LCD_IO_InData8(dummy_data);
      40. // Read LOW
      41. RDX_GPIO_Port->BSRR = (uint32_t)RDX_Pin << 16U;
      43. for(; Size; Size--){
      44. // Read LOW
      45. RDX_GPIO_Port->BSRR = (uint32_t)RDX_Pin << 16U;
      46. // IN Data
      47. LCD_IO_InData8(pData);
      48. pData++;
      49. }
      50. // Read HI
      51. RDX_GPIO_Port->BSRR = (uint32_t)RDX_Pin;
      52. // CS HI
      53. CS_GPIO_Port->BSRR = CS_Pin;
      55. __HAL_RCC_GPIOA_CLK_ENABLE();
      56. //Set port as output
      57. /*Configure GPIO pin Output Level */
      58. HAL_GPIO_WritePin(GPIOA, DB0_Pin|DB1_Pin|DB2_Pin|DB3_Pin
      59. |DB4_Pin|DB5_Pin|DB6_Pin|DB7_Pin, GPIO_PIN_RESET);
      60. GPIO_InitStruct.Pin = DB0_Pin|DB1_Pin|DB2_Pin|DB3_Pin
      61. |DB4_Pin|DB5_Pin|DB6_Pin|DB7_Pin;
      62. GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP;
      63. GPIO_InitStruct.Pull = GPIO_NOPULL;
      64. GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_VERY_HIGH;
      65. HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);
      66. }
      Display All

      No problems with other drawing functions such as GUI_DrawArc, GUI_DrawPolygon, etc with no Antialiasing (it doesn't seem to need to read back pixels from the controller).

      Any hints on which could cause this behavior and how to solve it?

      Thanks a lot!

      Mark

    • Hi,

      When drawing AA shapes emWin needs to read the background to mix it with the semi transparent foreground pixels of the AA shapes.

      Mark_C wrote:

      If I set a number higher than 1 on GUI_AA_SetFactor() the program will execute the ReadM8_A1 function and will get stuck on a HardFault after its execution.
      Same happens to GUI_AA_DrawPolygon.
      So, it crashes when the programm returns from LcdReadDataMultiple() and is within emWin code again?

      Or does it crash while within one of the read functions?

      Mark_C wrote:

      Is it something related to the display controller reading back function or is it a RAM issue?
      According to the documentation the pfReadM8_A1 is a pointer to a function which reads multiple bytes from the controller with C/D line high.
      From my understanding it has to be the function related to a generically read on the controller after the command (when C/D line is low).
      The function set to pfReadM8_A1() is used to read data. As far as I know it can be different depending on the controller. We had already controller which expect the C/D line low to read data and others which expected the C/D line high to read data. But, I wouldn't expect a crash, just some strange "pixel data" being read.

      Unfortunately, it is hard to say why the crash happens.

      If you have enough RAM available you could also try to use a cached version of the driver. When using a cache it is not required to set a reading routine. You could use a cache just for testing. If it doesn't crash I suppose there is something wrong with the reading routine (maybe writing too often pData).

      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.

    • SEGGER - Schoenen wrote:



      The function set to pfReadM8_A1() is used to read data. As far as I know it can be different depending on the controller. We had already controller which expect the C/D line low to read data and others which expected the C/D line high to read data. But, I wouldn't expect a crash, just some strange "pixel data" being read.
      Hello Sven, thank you for your answer.

      It crashed in the data reading function, the function pointed by pfReadM8_A1 has apparently to be the complete reading function (not only the part of the message with C/D line low).
      I set up the complete reading function and now also the AA functions are working properly.

      SEGGER - Schoenen wrote:

      If you have enough RAM available you could also try to use a cached version of the driver. When using a cache it is not required to set a reading routine. You could use a cache just for testing. If it doesn't crash I suppose there is something wrong with the reading routine (maybe writing too often pData)
      Unfortunately I have very little internal SRAM (96K) and no external memory, not enough for a frame.

      One more question:
      regarding the memory assigned to the libraries I've setup the GUIConf.c file as the following (32K in the internal SRAM):


      Source Code

      1. // Define the available number of bytes available for the GUI
      2. //
      3. #define GUI_NUMBYTES (1024) * 32 // x KByte
      5. /*********************************************************************
      6. *
      7. * Static data
      8. *
      9. **********************************************************************
      10. */
      12. /* 32 bit aligned memory area */
      13. static U32 extMem[GUI_NUMBYTES / 4] __attribute__((at(0x20001000)));
      Display All
      Is it OK like this or is it necessary to make some other setting?

      Thank you!

      Regards,
      Mark

    • Hi,


      Mark_C wrote:

      Is it OK like this or is it necessary to make some other setting?
      This is the only location where you need to configure the memory used by emWin. Any emWin operation which needs a piece of memory uses this memory block.

      The only exception is the GUIDRV_Lin driver. Its framebuffer needs to be allocated by the user.

      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.

    • SEGGER - Schoenen wrote:

      Hi,


      Mark_C wrote:

      Is it OK like this or is it necessary to make some other setting?
      This is the only location where you need to configure the memory used by emWin. Any emWin operation which needs a piece of memory uses this memory block.
      The only exception is the GUIDRV_Lin driver. Its framebuffer needs to be allocated by the user.

      Regards,
      Sven
      Thank you very much for your answer and support, Sven!
      Best regards,
      Mark