1.9k views
in System Integration by
Hi, following are my currently enviroments:

- Embedded Wizard Studio Pro v8.30
- Embedded Wizard Platform Package for RGB565
- Replaced a touchscreen with an LVDS input (MIPI-DSI output is covert into LVDS signals by sn65dsi83 chip)

My situation is the replaced LCD only supports DE-only mode (no VSYNC and HSYNC), So I have to change the BspConfigDisplay() function into DSI video mode.

After the my custom EmWi gui screen show up, I found the framerate is really slow. In 'GraphicsAccelerator' example, the framerate is fixed at 0 fps. I have tried to build a project without EmWi GUI, and the fps is more than 40 when using ST VideoMode_DoubleBuffering example. Therefore, I think the configuration might be something wrong in EmWi display settings. But currently I have no ideas, hope someone can give me a hand !!

In addition, I don't understand why HSYNC, HBP, VBP, VFP, ... all of these are set to 1 in ew_bsp_display?

1 Answer

0 votes
by
 
Best answer

Hello,

after having a short view into the SN65DSI83 data sheet, it seems that it is a video converter that supports the DSI video mode.

The LCD that is mounted on the STM32F469 Discovery of Evalboard can be driven by using the DSI video mode or the DSI command mode

In our Build Environment we are using the the DSI command mode. This is more efficient because it uses graphics memory of the display (GRAM) and only updates are transferred to the display. As a result the memory bandwidth is reduced.

The current implementation of ew_bsp_display.c cannot be used out-of-the-box for the SN65DSI83. If you have a working code for display intialization and refresh you need to integrate that into ew_bsp_display.c.

by

Hello,

In my case, I already have a working code of SN65DSI83 that realized the DSI video mode function. (I have tested with STM32Cube example: VideoMode_DoubleBuffering).

And the LCD we used do not have any GRAM inside, but I don't think it's the reason that cause 'GraphicsAccelerator' example freezed.

Thus I guess I have to do more modifications to ew_bsp_display.c, even I read "Platform Integration: Framebuffer Concepts" I still don't get how EmWi work in the background, for example, I don't know why HSYNC, HBP, VBP, VFP, ... these parameters are all assign to 1. And it is different with settings written in Components/otm8009a/otm8009a.h

/**
  * @brief  OTM8009A_480X800 Timing parameters for Portrait orientation mode
  */
#define  OTM8009A_480X800_HSYNC             ((uint16_t)120)     /* Horizontal synchronization */
#define  OTM8009A_480X800_HBP               ((uint16_t)120)     /* Horizontal back porch      */
#define  OTM8009A_480X800_HFP               ((uint16_t)120)     /* Horizontal front porch     */
#define  OTM8009A_480X800_VSYNC             ((uint16_t)12)      /* Vertical synchronization   */
#define  OTM8009A_480X800_VBP               ((uint16_t)12)      /* Vertical back porch        */
#define  OTM8009A_480X800_VFP               ((uint16_t)12)      /* Vertical front porch       */

 

by
Hello,

the implementation within ew_bsp_display.c is completely based on different ST examples that you will find within the STM32Cube F4 firmware \Projects\STM32469I-Discovery\Examples\LCD_DSI\LCD_DSI_CmdMode_xxx

In case of command mode, the LTDC is not driving the refresh of the display - therefore the timing parameter (HSYNC, HBP, VBP,...) are set to 1 and not to timing values of a display.

The framebuffer concept should be standard double-buffering (EW_USE_DOUBLE_BUFFER=1). But the refresh via DSI video mode has to be integrated into ew_bsp_display.c (and all the command mode code has to be removed).

I hope this helps a little bit - without having the hardware on the table it's difficult to help or to make a bring-up...

Best regards,

Manfred.
by
Hello, Manfred

This is helpful to clarify ew_bsp_display.c is completely implemented based on LCD_DSI_CmdMode_xxx examples.

I have one more question. At what time will EmWi convert RGBA8888 color format into the screen color format, in my case, RGB565? (I know that EmWi use RGBA8888 as internal color format). Is it done in libewgfx-m4-xxx library?

Thanks!
by
Hello,

in case you are using a Graphics Engine library from the folder /PlatformPackage/RGB565 then the color format of the framebuffer is RGB565. In this case all drawing operations are done into the framebuffer by using RGB565. The DMA2D is able to make copy or blend operations with RGBA8888 as source and RGB565 as destination.

Best regards,

Manfred.
by

Hello, Manfred

Thanks for your comment last week. I found the problem was there is no EndOfRefresh interrupt in DSI video mode, everytime EwBspUpdateDisplay function have to wait osSemaphore timeout for 1 sec, this caused framerate delayed.

So I use LTDC LineEventCallback at frame line 0 to instead EndOfRefresh interrupt, and then released semophore in HAL_LTDC_LineEventCallback function. Also I activate LineEvent when EwBspUpdateDisplay is called.

void EwBspUpdateDisplay( void )
{
  /* ensure that LCD update is finished */
  EwBspWaitForDisplayCompletion();

  HAL_LTDC_ProgramLineEvent(&hltdc_handle, 0);

  /* change address within layer configuration structure */
  LayerConfig.FBStartAdress = CurrentFramebufferAddress;

  ...
}
void HAL_LTDC_LineEventCallback(LTDC_HandleTypeDef *hltdc)
{
#if EW_USE_FREE_RTOS == 1   
    osSemaphoreRelease(LcdUpdateSemaphoreId);
#else
    ActiveArea = NO_AREA;
#endif
    
    /* DSI update is done, now let the DMA2D work in parallel with CPU */
    EwBspGraphicsConcurrentOperation( 1 );
}

But the new problem comes from frame update. Refer to image below, the bottom of light blue rectangle is blurred. It happens when rectangles drops down quickly (It won't happen if rectangles move horizontally).

Do you have any ideas what resulting in this problem? Thank you!

by
Just a short question: Are you using double-buffering?
by

Yes, here are my preprocessor defines:

USE_HAL_DRIVER
STM32F469xx
USE_STM32F469I_DISCO
EW_MAX_SURFACE_CACHE_SIZE=0x400000
EW_MAX_GLYPH_SURFACE_WIDTH=256
EW_MAX_GLYPH_SURFACE_HEIGHT=256
EW_USE_DOUBLE_BUFFER=1
EW_USE_FREE_RTOS=1
EW_CPU_LOAD_MEASURING=1
EW_SURFACE_ROTATION=0
EW_FRAME_BUFFER_COLOR_FORMAT=EW_FRAME_BUFFER_COLOR_FORMAT_RGB565

 

by

The settings look fine.

Based on the provided image it is difficult to create some ideas...

Why has the green rectangle a surrounding glow? Or is this a second rectangle?

Can make a simple test that moves a single rectangle just up and down (using a RectEffect)? You can send me a short video sequence.

by

Please see these two videos:

1. https://youtu.be/3h4C1CNBC8w tested on our hardware

2. https://youtu.be/DiunTYj_jYI tested on STM32F469 disco board

And I use timer to move this rectangle every 50ms, not RectEffect.

by

Thanks for providing the video. Can you please make the following two changes and provide another video?

Make a small vertical rectangle (e.g. 50x480 pixel) and move it now horizontally (left to right and back, e.g. within one second) - I want to see if there is some tearing / missing V-sync.

Add a FPS (frames per second) counter.

by
Thanks!

Here's the result: https://youtu.be/mgxDZG3GNj0
by
Are you using still the timer with 50ms? In this case you will get only 20 FPS (1/50 ms).

What is the display size in pixel that you are using? And what is the pixel frequency?

Can you execute the example GraphicsAccelerator -  what is the resulting framerate in case of Rectangle Copy operation?

I'm asking all these questions to figure out if the display refresh is too slow...
by
No. In this video I use a 25ms period timer, and the display size is 800x480. I don't know what pixel frequency exactly means?

If means LCD frequency, it is set to 27MHz. If means DSI channel clock, it is 250 MHz. If means LCD refresh frame rate, it is 60Hz.

The framerate in the case of Rectangle Copy operation is around 22 fps!!
by
Yes, this was the information I wanted to know. So it seems, that for some reasons the update is limited to 20 fps - but the LCD refresh is 60 Hz.

Maybe there is some wrong synchonization or maybe most of the available memory bandwidth is consumed by the DSI update... Difficult to say.

Are you using a Professional Edition of Embedded Wizard? In this case you can send me your display adaptation via email to have a short review.
by
According to your comments, I think the problem might caused by LTDC timing.

After some tries, I have solved the "surrounding glow" problem and the framerate improved to 65fps in the example GraphicsAccelerator. There's still have some problems occured in the Rectangle Blend operation. (the blended rectangle sometimes blinking and make framerate dropdown to 58 fps)

But I think it might be a similar problem, I'll do some more tests. Thanks a lot for your kindly help!

Ask Embedded Wizard

Welcome to the question and answer site for Embedded Wizard users and UI developers.

Ask your question and receive answers from the Embedded Wizard support team or from other members of the community!

Embedded Wizard Website | Privacy Policy | Imprint

...