I have seen this thread https://community.st.com/s/question/0D53W000007XLbHSAW/why-does-animating-an-l8-image-take-significantly-longer-than-a-standard-image which states that RGB565_L8 transformation is completely handled on the cpu without dma2d assistance , indeed the reference manual of my mcu states that dma2d only handler RGB888_L8. So I was wondering which of the following solutions is better for my case :
I am currently using 4.16.1 and I would like a catch up to know if there is an official solution/patch to the problem above. As people mentioned it should have been up on 4.15.*
Furthermore just to be sure I would like some insight for the usefulness of each feature on my usecase. I have an stm32h743vit custom board, an external flash of 16Mb with quad spi and an spi screen 320*240 rgb565 . As expected I would like to add as many images as I can to the flash and I would like to do most of the computations on the chrom-Art dma2d instead of the cpu (the second part is more important).
The question is quite simple.
- Should I use L8_RGB565 when possible for minimum flash consumption or it will unavoidably clutter my cpu?
- If choice one is inapplicable should I use L8_RGB888 instead and expect chrome-art to assist my cpu better even though it will have to modify the images to RGB565 after the conversion from L8 to non L8 ?I am aware that L8_RGB565 and L8_RGB888 have insignificant data size differences.
- If choice two is inapplicable should I use normal rgb565?
I should be able to answer this question alone but my current input is a bit contradicting as the reference manual of stm32h7 at page 721 https://www.st.com/resource/en/reference_manual/dm00314099-stm32h742-stm32h743-753-and-stm32h750-value-line-advanced-arm-based-32-bit-mcus-stmicroelectronics.pdf states that chrom-art can use only l8_rgb888 (so choice number two) but the thread I point you at on the first link suggests that for an stm32h7 not to use l8 at all or use the cpu with l8_rgb565
