cheap LCD (800x480) board

[lpcware]

Content originally posted in LPCWare by jogi.loew on Wed Jun 19 04:13:29 MST 2013

hi there,

i have to start a new project building a lcd+touch board based on the 208qfp version of the lpc185x microcontroller. this is my first LPC based board, so i'd appreciate feedback if i forgot something... my requirements are not too high in terms of graphical capabilities, mostly showing graphics, navigating through menus... nothing fancy (control panel of a machine)...

according to the datasheet the 208qfp part only has a 16bit wide data bus on the emc. according to the bus load calculator it would still only give 45% bus load on SDRAM with 120MHz, 800x480px, 60Hz, 16bit color depth. are there any problems i could run into when adapting the sample codes which use 32bit wide data to my board? do i have to consider anything already beforehand, any pitfalls?

code execution from internal flash plus storage for graphics and everything else that doesn't fit in external QSPI flash connected via SPIFI (QSPI should be the only external flash)

can the touchscreen be connected directly (and used with little programming effort) to the ADC of the microcontroller or do i have to use a touchscreen controller?

i'd like to use the emWin graphics library. would it support the touchscreen when it is connected to the ADC directly?

all in all it should be as basic as possible: LPC1857 208qfn, 16bit wide SDRAM, QSPI flash, LCD connector, touchcontroller yes/no

Any idea anyone if this works?
Thanks in advance,

j

[lpcware]

Content originally posted in LPCWare by wellsk on Fri Jun 28 08:54:00 MST 2013

Sorry, I missed that 60Hz although ti was right there looking at me. With LCDs with fast pixel clocks, the latency for filling the FIFOs when they are getting empty is more important the the bandwidth of the system.

Estimating if an LCD with a fast pixel clock will work in a specific system is a little bit of guesswork. I'd prefer you go with something safer that will work instead of pushing the limits.

Going back and looking at LCD specs, the LCD FIFO is larger than I though (16x64), so that 174nS value is not accurate (by quite a bit!) and the controller will generally request data slower (which is a good thing).

The LCD FIFO needs to buffer enough data to keep the LCD refreshed - smoothly - even when the system is under load. In some cases, system events can occur that cause the LCD FIFO fill to be delayed. For example, the CPU might be doing a burst read from DRAM (memcpy, or maybe a LDM operation with a stack pop), but this may get stalled due to a DRAM refresh cycle. If multiple stalls like this happen, it can cause delays to the LCD refresh cycle and the LCD FIFO will eventually underflow and you'll get a display glitch/tear. The point of the LCD clock rate this tearing starts to happen is systemic - how many devices are trying to use the DRAM, how big is your DRAM bus size, how fast is your DRAM/bus clocks?

>(According to the bandwidth calculator the bus load for my application with the LPC4088 is 54%(@80Mhz,32bit) which is higher than with LPC1788 (45,6%@120Mhz,16bit) which doesn't seem logical, does it?)

The bandwidth calculators are great tools to get an idea of bandwidth used in a system for the LCD controller, but I'm not sure they'll actually tell you if you'll get glitch free operation. DRAM is protocol based and requires setup on muxed address lines prior to bursting the data from the device. The DRAM controller will need to write a row and column address, close or open banks, and occasionally handle DRAM refresh prior to performing the data access. For a 4x32-bit burst read operation, a 32-bit interface would take 4 clock cycles for the data, while a 16-bit interface would require 8 block cycles. - these 4 and 8 clocks don't include the RAS/CAS setup time So if all things are equal (clock rate, CAS/RAS latencies, etc.) and both 16- and 32-bit interfaces did a 4x32-bit transfer of data, the 16-bit transfer wouldn't take twice as long - even though it requires twice the data transfer clocks - because the setup time before the data transfer requires overhead which is the same for both DRAM bus sizes.

...so if I was doing this...I wouldn't go with the 16-bit DRAM bus interface when using the LCD controller at your target pixel clock - especially at 60Hz or 80Hz DRAM clock  speed. IYes - it might work, but you wouldn't really have a lof of bandwidth to work with and you might end up having to lower your LCD clock rate to get a stable image....

Sorry for long delay and the rambling. I hope this helps,

[lpcware]

Content originally posted in LPCWare by jogi.loew on Thu Jun 20 01:24:15 MST 2013

Hi Kevin,

in the starting post i was mentioning 60Hz as refresh rate and 120MHz as SDRAM clock... so 800x480x2B@60Hz... maybe i wrote it a little bit confusingly :)
would you recommend to go down with the refresh rate even more or the use of another part? the only micro i found with 208QFP, 32 bit DRAM width and QSPI would be the LPC4088, but the SDRAM Clock speed is only 80MHz (instead of 120).

(According to the bandwidth calculator the bus load for my application with the LPC4088 is 54%(@80Mhz,32bit) which is higher than with LPC1788 (45,6%@120Mhz,16bit) which doesn't seem logical, does it?)

My application will not have ethernet nor ssd nor usb... any ideas on the touch screen controller?

Which does seem the most viable route to go for you?

Rgds,

j

[lpcware]

Content originally posted in LPCWare by wellsk on Wed Jun 19 14:44:00 MST 2013

Bandwidth is one thing, but LCD FIFO fetch latency is more important in with these system requirements than bandwidth. If the LCD FIFO can't fill fast enough, the LCD controller will starve and you'll get (annoying) flicker. This flicker can get worse when the system goes under load.

At 800x480x2bytes/pixel@120Hz, your looking at LCD pixel clock rate of around 46MHz (or more). Even with the LCD set to refresh at the 8-word trip point, it will only have 174nS to get that data before underflow.

When you factor in other bus masters that can delay LCD FIFO requests - CPU(LDM/STM)/USB(descriptors/buffers)/DMA/SDMMC/Ethernet/etc. plus DRAM refresh cycles - I don't think this is a viable rate to maintain and you'll likely end up going with a lower clock rate (maybe a 60Hz refresh) or less color depth. Even at 32-bits DRAM wdith, I would say this is tough. Going with a 16-bit DRAM width will only make it worse :(