Using STM32L micros for RGB LCD, it is possible?

[vaualbus]

I have to design a board to adapt to a LCD display that is feed via RGB interface. Initial I was the happiest man because I thought that display had already a controller in it and can be command via SPI. (In fact I had arleady a board designed and I was very very happy about the result, just waste one night I guess  )
Luckily I understand that it is not the case when I read the controller datasheet.
 The display I want to use is the following: NHD-3.5-320240MB-ASXV-CTP that use the NV3035C controller.
Now i want to be able to use the STM32L496 micro with an external SRAM. Now that micro does not provide and interface to RGB data (it miss the LTDC module that I used and is present in higher end F7 micros).
No my question is, it is feasible to generate RGB timing using a micros or is better to use like a simple CPLD/FPGA in which I implement an RGB controller?
I will use the LCD using the 8bit "serial" mode because I don't wan tto full the micros pins (I need other things attached to it).
I know that it exist already some controller like the SSD1963 but that is only available in chine and I have to use parts from main suppliers like mouser/farnell.
It is possible to emulate using timers the proper timings?
Best regards,
Alberto.

 

[Silenos]

I have once considered some STM32L4 for paralel LCD: tldr: I strongly disadvise. Save ton of time and hardware money, get mcu with ltdc and enough ram onboard and enjoy the life.

Precisely, I used FMC, no external memory. Targeted in magnificent, unbuffered 8-bit color space. Thing turned out to have to have risky, close to margin timings, depending on internal bus clock and internal FMC write fifo and timings trims. Required external gates, timers for sync pulses and wasn't sure if lcd would approve of not ideally synchronised pulses. Plus a lot of soft to control, DMA's 16bit item counter wasn't enough, bla bla. Generally I dropped it, too many nasty contraints and potential, fatal pitfalls.

[SiliconWizard]

You could consider the L4+ series instead, with similar power draw, but TFT interface and more RAM (can also be clocked higher), such as the STM32L4R7.

[vaualbus]

I know but I have have a lot of 496 chip in house that I bought last year for another problem I wanted to optimize cost. But if I have no way around I will but them. Just want to figured out if it is possible at all or I'm running against a wall

[Silenos]

Put two or three of those L4 instead some cpld and memories?

[vaualbus]

I'm serious it seem that for 3.5 inch display almost none use MCU interface but 24bit RGB interface. I guess is because of timing? Like I fund some chinese display with MCu but of course they are not on main reseller sites 

[vaualbus]

By the way it seem that you can't use LDTC and SRAM toghether, because there overlapping pins. At least I can't configure both of them in STMCube.
So yeah the display is too bif for internal RAM and I'm again against a wall 

[jhpadjustable]

Epson Electronics Americas offers many external LCD controllers with internal RAM that might serve your needs, for example S1D13781F00A100, but they might cost more than a micro with native TFT support.

[vaualbus]

Epson Electronics Americas offers many external LCD controllers with internal RAM that might serve your needs, for example S1D13781F00A100, but they might cost more than a micro with native TFT support.

Yeah they have a lot of functions that I really don't need so I guess the idea of an FPGA can be considered. I have arleady some IP that drive VGA for another project so I guess I should look at do a custom implementation to basicly acess to the SRAM and send it to the display as RGB. Still I will take a look at what you said. Thanks 

[thm_w]

That display is $56, touch too..

Ruideng managed to have a good update rate from a STM32F103, which is going to be a bit slower. Not sure of the exact display resolution though. Its also all text based, not much graphical.
I think the key, if you go cheap, is to get a display with either readable memory or a tearing output, and sync the writes to happen under one frame time. I assumed they all had internal RAM?
eg ST7789. Maybe I'm misinterpreting the statement.

[vaualbus]

Yeah I know that the display is expensive but it is great because it have mounting holes for the display and the board d that will solve a lot of "pain" 😅

As far as I can see almost nine 3.5 inch display have "easy" interface I guess I will loo at 2.8 inch as it seem all have MCU interface.

[uer166]

The internal routing of LTDC seems to be completely brain-dead, all 4 corners have approx. same number of pins in the bus 

Doable, but I wish they somehow consolidated the bus on one or 2 sides, not completely scattered around..

[mino-fm]

If you are happy using 64 colours you can use FSMC and DMA of STM32, which will need 6 x datalines (D0-D5), 1 x CLK (/WR), 1 x HSYNC (A16) and 1 x VSYNC (A17). Internal RAM of F469 is sufficient and fast to be used as framebuffer.

Added picture shows use of STM32F7xx, but F4xx acts similar.
Code can be found here: https://www.mikrocontroller.net/topic/470988#5777870

[ehughes]

For those RGB displays,  just get an MCU with the proper interface.    It will make your life 100% easier.

I am currently do an eval of that same family from NewHaven.   This display:

https://www.buydisplay.com/3-5-inch-tft-lcd-color-module-in-320x240-touch-screen-lq035nc111

has the same pinout,  visually looks the same, etc for a 1/3 the price.   We had them side by side they looked the same.     The controller just needs some adjustment for the horizontal and vertical back porch timings. (I am driving from an NXP LPC4357)

Also, if you really want to use the the controller without the LCD interface,  there are chips (SSD1963)  that have a large SRAM for a frame buffer and have the proper interface to the display.   For the price though, you might as well just get an MCU with the LCD controller.