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);
      10. //
      11. // Display driver configuration
      12. //
      13. LCD_SetSizeEx (0, XSIZE_PHYS , YSIZE_PHYS);
      14. LCD_SetVSizeEx(0, VXSIZE_PHYS, VYSIZE_PHYS);
      15. //
      16. // Configuration
      17. //
      18. /* Orientation possible values
      19. GUI_MIRROR_X: Mirroring X-axis
      20. GUI_MIRROR_Y: Mirroring Y-axis
      21. GUI_SWAP_XY: Swapping X and Y axis
      22. */
      23. #if DISPLAY_CONFIG_PORTRAIT
      24. Config.Orientation = GUI_MIRROR_X;
      25. #elif DISPLAY_CONFIG_LANDSCAPE
      26. Config.Orientation = GUI_MIRROR_X|GUI_MIRROR_Y|GUI_SWAP_XY;
      27. #endif
      28. #if (NUM_BUFFERS > 1)
      29. GUI_MULTIBUF_ConfigEx(0, NUM_BUFFERS);
      30. #endif
      31. GUIDRV_FlexColor_Config(pDevice, &Config);
      32. //
      33. // Set controller and operation mode
      34. //
      35. PortAPI.pfWrite8_A0 = LcdWriteReg;
      36. PortAPI.pfWrite8_A1 = LcdWriteData;
      37. PortAPI.pfWriteM8_A1 = LcdWriteDataMultiple;
      38. PortAPI.pfReadM8_A1 = LcdReadDataMultiple;
      39. GUIDRV_FlexColor_SetFunc(pDevice, &PortAPI, GUIDRV_FLEXCOLOR_F66709, GUIDRV_FLEXCOLOR_M16C0B8);
      40. }
      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. }
      12. void LCD_IO_ReadMultipleData8(uint8_t Cmd, uint8_t *pData, uint32_t Size, uint32_t DummySize)
      13. {
      14. uint8_t *dummy_data;
      15. // CS LOW
      16. CS_GPIO_Port->BSRR = (uint32_t)CS_Pin << 16U;
      17. // DCX HI
      18. DCX_GPIO_Port->BSRR = (uint32_t)DCX_Pin;
      19. // Write HI
      20. WRX_GPIO_Port->BSRR = (uint32_t)WRX_Pin;
      21. // Read LOW
      22. RDX_GPIO_Port->BSRR = (uint32_t)RDX_Pin << 16U;
      23. GPIO_InitTypeDef GPIO_InitStruct = {0};
      24. __HAL_RCC_GPIOA_CLK_ENABLE();
      25. //Set port as input
      26. /*Configure GPIO pin Output Level */
      27. HAL_GPIO_WritePin(GPIOA, DB0_Pin|DB1_Pin|DB2_Pin|DB3_Pin
      28. |DB4_Pin|DB5_Pin|DB6_Pin|DB7_Pin, GPIO_PIN_RESET);
      29. GPIO_InitStruct.Pin = DB0_Pin|DB1_Pin|DB2_Pin|DB3_Pin
      30. |DB4_Pin|DB5_Pin|DB6_Pin|DB7_Pin;
      31. GPIO_InitStruct.Mode = GPIO_MODE_INPUT;
      32. GPIO_InitStruct.Pull = GPIO_PULLUP;
      33. GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_VERY_HIGH;
      34. HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);
      35. //Dummy read
      36. LCD_IO_InData8(dummy_data);
      37. // Read LOW
      38. RDX_GPIO_Port->BSRR = (uint32_t)RDX_Pin << 16U;
      39. for(; Size; Size--){
      40. // Read LOW
      41. RDX_GPIO_Port->BSRR = (uint32_t)RDX_Pin << 16U;
      42. // IN Data
      43. LCD_IO_InData8(pData);
      44. pData++;
      45. }
      46. // Read HI
      47. RDX_GPIO_Port->BSRR = (uint32_t)RDX_Pin;
      48. // CS HI
      49. CS_GPIO_Port->BSRR = CS_Pin;
      50. __HAL_RCC_GPIOA_CLK_ENABLE();
      51. //Set port as output
      52. /*Configure GPIO pin Output Level */
      53. HAL_GPIO_WritePin(GPIOA, DB0_Pin|DB1_Pin|DB2_Pin|DB3_Pin
      54. |DB4_Pin|DB5_Pin|DB6_Pin|DB7_Pin, GPIO_PIN_RESET);
      55. GPIO_InitStruct.Pin = DB0_Pin|DB1_Pin|DB2_Pin|DB3_Pin
      56. |DB4_Pin|DB5_Pin|DB6_Pin|DB7_Pin;
      57. GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP;
      58. GPIO_InitStruct.Pull = GPIO_NOPULL;
      59. GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_VERY_HIGH;
      60. HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);
      61. }
      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
      4. /*********************************************************************
      5. *
      6. * Static data
      7. *
      8. **********************************************************************
      9. */
      10. /* 32 bit aligned memory area */
      11. 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