Is there support for frame buffer line padding?

Question

Hi there,

I'm using the STM32F7xxx device with Embedded Wizard 8.3, and our underlying frame data is confgured as RGB565

The STMicro AppNote AN4861 for LTDC specifies that the line data size must be a multiple of 64 bytes, to allow the LTDC peripheral to execute burst reads. If it is not, then LTDC underrun errors arise.

Example: One of our displays has width 720px, which is 720*2 bytes = 1440 bytes. Which is not a multiple of 64 bytes, and LTDC underrun errors arise.

Another of our displays has width  800px, which is 1600 bytes. This is a multiple of 64 bytes, and everything is fine.

In order to rectify this, we chose the option to add dummy bytes at the end of each line. The LTDC width remains set at 720 bytes, and we specify the pitch at 736 px. As long as each line has 32 bytes (16 px) of dummy data at the end of it, we see that everything is perfect.

The big question is. Does the Embedded Wizard app support the ability to stuff padding bytes at the end of each line of the frame buffer?

* If yes, super, can you please tell me how?

* If no, we will have to change our Embedded Wizard application screen width from 720 -> 736, and apply offsets for all of our controls, and also offset touch information too, which will be very complicated.

Kind Regards,

Rob Shand

Answer 1

Hi Rob,

of course, this is supported - with current versions. You can keep the ScreenSize in your GUI application as it corresponds to the physical size of the display and just increase the framebuffer width so that it fits into a multiple of 64 byte.

For example (taken from ewconfig.h for STM32F769-Discovery):

#define EW_DISPLAY_WIDTH                800
#define EW_DISPLAY_HEIGHT               480

/* make sure each line of the framebuffer is a multiple of 64 bytes */
#if ( EW_FRAME_BUFFER_COLOR_FORMAT == EW_FRAME_BUFFER_COLOR_FORMAT_RGB888 )
  #define EW_FRAME_BUFFER_WIDTH         832
#else
  #define EW_FRAME_BUFFER_WIDTH         800
#endif

#define EW_FRAME_BUFFER_HEIGHT          480
 

However, I'm not sure if this is already supported for version 8.3 - which is more than 6 years old.

Best regards,

Manfred.

Comments

Hi Manfred, thanks for the response!

I have checked, and unfortunately, 8.3 does not support this feature.

Tell me, for the latest version.of EW, do those defines take effect. I found that for 8.3, the comment says that to change defines, it needs a recompile of the library, and a professional license is required. Is that correct? Could I trouble you to remind me quickly what licensing optinons there are again?

Kind Regards,

Rob

---

Hi Rob,

only for some flags it is necessary to have the source code in order to rebuild everything. It depends on the flags and it is mentioned in the comment or in the online help.

For version 8.3 you can try to adapt the file ewextgfx.c - I assume there is a check that ensures that display width corresponds to framebuffer width.

You can try to remove that and verify if it works. However, I'm not sure if the stride is handled correctly. In the latest versions it is handled correctly and the check was adapted.

Best regards,

Manfred.

---

Hi Manfred, Thanks again for your (as always) prompt reply :-)

Thanks for your feedback on the flags, and for your suggestion. I removed the condition in STM32InitViewport, ensured that the EwScreenSize was (720,1280), and the frame size was (726, 1280) (fed into EwInitViewport), and the output remains the same.

So the stride is not factored in, which is probably why the condition existed, but I appreciate your suggestion to give it a shot :-)

For other users who might read this question, I did come right though. I made the screen size of the Embedded Wizard project (736x1280), and moved the entire application down by 16 pixels. Fortunately everything in our application is dynamically calculated, so it was quite easy to do

Kind regards,

Rob