STM32F427 + TFT LCD + STemWIN?

[Berger1]

Hello, I have a few questions about the subject.

Suppose you use a display TFT with a controller any as ILI9341 or ST778 320x240 256k color 8bit interface or SPI. with STM32F427.

The first question concerns how to connect the LCD to the MCU

LCD support Intel 8080 and Motorola 6800 modes 8/16 bit LCD parralel interface and 4 line SPI too. MCU have Flexible memory controller with support LCD paralel interface. 

Which interface to use for LCD to MCU connection? 8bit paraller or SPI? In other words, in terms of display speed or STemWIN, does the 8bit interface bring any advantages over SPI?

MCU include Chrom-ART Accelerator, is this hardware accelerator supported by STemWIN?

Generally, i also have an MDK-ARM that contains emWIN, is there any difference between emWIN from Segger in MDK-ARM and STemWIN? Clearly STemWIN is probably limited to ST products, but besides.

Is there any sample project to connect LCD (with integrated LCD controller) to STM32F4?

[berendi]

The parallel interface might be faster (check the ILI9341 datasheet for actual timings), SPI needs fewer pins, so you might be able to use a smaller package.

EmWin supports any interface that can display pixels, but it has no way to know how did you connect your display hardware, so some driver code must be written or adapted.

I don't think there would be many ready-to-use examples for the STM32F427, because people tend to use STM32F429 instead, which has a dedicated TFT-LCD controller (and 100% identical otherwise). There is an STM32F429 discovery board made by ST, which comes with a few ready-to-use examples. There are a number of sample projects out there for other STM32 MCU families, which could be adapted with various amount of effort.

On the other hand, EmWin is able to draw directly to the MCU or SPI interface, not needing memory for the framebuffer. But without an internal framebuffer, Chrom-ART is not really useful.

There are a dozen ways to do this, the best choice depends on your requirements and priorities. E.g. if the top priority is not having to understand how it works, just drop in a "sample project", use the STM32F429/Discovery as a base. You might be able to leave the external SDRAM out, if the program doesn't need animations or a lot of data storage, as the framebuffer would take up 150 of the 256 kbytes internal RAM.

[waclawek.jan]

While I agree with using the 'F429 DISCO as a starting point....

> But without an internal framebuffer, Chrom-ART is not really useful.

Why not, if the LCD has controller/memory, and is connected through FMC, can't DMA2D (aka ChromART) use it as target?

JW

[berendi]

Yes, thinking about it, DMA2D would still be useful for outputting indexed color or packed pixel formats directly, useful when there is no external framebuffer memory.