Cheapest/Easiest way to control graphic LCD's. - Page 1
Forum section: electronics / projects

author: Buriedcode
author_rank: Super Contributor
timestamp: December 05, 2016, 01:25:59 am
content: Hi,Some of you may have seen my posts about controlling monochrome (some colour STN too) LCD's using FPGA's, and some SDRAM (bit of a bitch to do, SRAM is so much easier for this). And I'm still having problems getting my cyclone II design to read/write the SDRAM effectively, so rather than get tunnel vision, time for a change of tack. Just to clarify, I'm not talking about the common TFT modules that already have built in controllers, or character LCD's, just 320x240 to 640x480 monochrome displays. I do like the retro look.I know many ARM and non-ARM micro's have built in graphic LCD controllers these days, and there are dedicated IC's for this purpose - SSD1906 for example. I have this device, but its pretty expensive, so it'll get put on a 'test board' with various common LCD pinouts for testing, along with negative voltage generator, LED backlight and CCFL inverter etc...However, if I was to make up a fairly cheap board (because I may end up making 20) what would be the cheapest/easiest path to go? I'm thinking microcontroller as it'll be a single chip board, and could easily be hooked up to flash to store display pages, and there *should* be plenty of libraries about. But the question is which one? I have seen the PIC32 series can have a graphics LCD controller, but I assume several ARM devices have something similar, I just have no experience of them. Whilst its fun to mess about with FPGA's - perhaps even making a very basic controller using a CPLD, it just adds another layer of complexity, board space, and cost, as it'll need a micro anyway to update pages dynamically, and I'll have to add the FPGA with its support circuitry, SRAM, possible level shifting etc..So has anyone used a micro with a graphic LCD controller peripheral? And if so, could you name it. I don't imagine it'll be low pin count, but TQFP64 would be perfect. Also it would be nice if it was supported by emblocks, or mbed or hopefully a 'free' IDE. I can't say I have seen any ST discovery boards with devices that have graphics controllers built in, but perhaps I did not look hard enough. It's a lot to ask but I'm always out of date with whats 'out there', so if there's a $5 micro, or a $20 dev board that'll do the job, its perfect.

author: ebclr
author_rank: Super Contributor
timestamp: December 05, 2016, 01:37:35 am
content: http://www.emcu.it/STM32/STM32-TFT/STM32-TFT.html

author: Buriedcode
author_rank: Super Contributor
timestamp: December 05, 2016, 02:12:44 am
content: Hi,I can't see any references to generating the CP signals (Hsync, Vsync, single pulses) or any devices that have >512k SRAM required for a frame buffer. I had seen discovery boards with TFT's, but I had assumed they were TQFP144 devices, with external memory. With that said, the stm32F10xx series look promising.As monochrome STN is old tech its quite hard to find devices that support it.

author: ebclr
author_rank: Super Contributor
timestamp: December 05, 2016, 03:28:46 am
content: At least readhttp://www.st.com/content/ccc/resource/technical/document/application_note/05/4b/32/22/50/1d/42/02/CD00278141.pdf/files/CD00278141.pdf/jcr:content/translations/en.CD00278141.pdf

author: Buriedcode
author_rank: Super Contributor
timestamp: December 06, 2016, 12:18:29 pm
content: I read that from your first post and whilst it looks like it'll work for TFTs - I'm sure it does - its basically bit banging with the help of DMA and the memory interface module. I had considered bit banging the CP1/CP2/Vsync/Hsync lines then using the DMA to spit out a line, as the micro won't be doing much else this is perfectly doable. But it starts to get tricky for the awkward CSTN's with an 8-bit interface, because it writes two and two thirds of a pixel at a time, so some hardware lookup table would be handy for that, as it would require multiple memory reads and bit shifting for every write (thats every ~0.5us).Also, its a tall order to find a micro with 64k+ SRAM that's relatively 'cheap', so most solutions will require external SRAM. That ups the pin-count and requires some dedicated memory interface run by DMA to fetch/write to it. The largest display I have is only 640x480 monochrome plasma. It can have a framerate of 120Hz allowing for greyscaling. If we say 4bpp then thats 640x480x4 = 1228800 bits, or 150kbytes. As there is only one of these I might just suck it up and make a dedicated board for it rather than a generic 'one size fits all'.I found several app notes from microchip for devices that seem to be somewhat abandoned (not out of production, microchip rarely does that), namely the PIC24FJxxxDA series. 96kByte SRAM and dedicated hardware for driving STN/TFT's, colour look-up tables, and basic rendering functions like lines and boxes. At £6.66 from farnell it isn't particularly cheap, but considering its TQFP64, and I'm familiar with PICs, it sounds pretty damn good as a one chip solution.There has to be some cortex-m3/4 devices with LCD controllers that aren't the 'high end' types.. = expensive, much larger packages, lots of stuff I dont' requires like ethernet and USB OTG etc.. but I'm starting to realize as the displays are old its becoming much more of a niche. Or they are designed specifically for TFT displays with 12/16/18-bit interfaces.That ST app note is food for thought though. I have plenty of PIC24F's with DMA, as well as SAMD21's. Neither has the internal memory for a frame buffer, nor the pincount for an external SRAM interface.. but still handy for developing test pattern generators and getting familiar with using DMA burst transfers for a line.

author: bktemp
author_rank: Super Contributor
timestamp: December 06, 2016, 01:51:35 pm
content: Quote from: Buriedcode on December 06, 2016, 12:18:29 pmYou won't find any modern controller supporting CSTN LCDs.Monochrome LCDs still exist because they are cheap, but colour LCDs have been completely replaced by TFT LCDs.I don't know if it is still available somewhere, but S1D13506 is a nice controller for driving those ancient LCDs. It can do up to 800x600@16bpp using a 1Mx16 EDO DRAM.QuoteThe PIC24FJxxxDA206 series are great little devices. Its display controller and memory can run at up to 96MHz, achieving a throughput of 96Mpixels/s when using the graphics accelerator. Because it can do 1/2/4/8/16bpp, it can drive quite large displays using its internal 96kByte SRAM if you don't need many colours.QuoteSTM32F429/446/469 and STM32F745/769 support SDRAM and TFT LCDs upto 1024x768.The QFP144 package has enough pins for 18bit-TFT + SDRAM + SD card.Depending on your requirements STM32+SDRAM or DA206 are the cheapest and easiest way for driving small to medium sized TFT LCDs (and also monochrome LCDs for DA206).I tried the DMA solution, but external SRAM is rather expensive (compared to SDRAM) and screen updates are annoying because you can only do it during the blanking intervals. This wastes quite a lot of CPU time.

author: Buriedcode
author_rank: Super Contributor
timestamp: December 07, 2016, 10:51:29 pm
content: bktemp,First part of your reply - exactly what I thought. And I'm not complaining, modern TFT's look better, easier to use as they often have built-in controllers that may not have high level functionality, but at least handle refreshing and provide a straight-forward memory array like interface with auto-increment etc..I inquired not for any professional project, but as a hobby one - over the past 10 years I have collected far too many displays and so wanted to just bolt them all to a large board and have them display various things. Mostly so they're doing something useful because I can't make much money from selling STN's (maybe the Planar displays though!) and I don't like things laying about not being useful! This is also the reason for the low cost side. Not nearly as many restrictions as would be for a commercial project (where by I would probably just use an off-the shelf controller, or a small FPGA).Well you've sold me on the PIC24FJxxxDA206. Quite a few 'legacy' boards for driving graphic STN's seem to ahve these on board, which means they must be more than capable. But hearing someone mention them means its not just a marketing thing for microchip. I doubt I would require more than the 96kbyte ram, I don't see the point in giving a CSTN >8-bit resolution (looks crap anyway!), so max memory required would be say 8ppp, for 320x240 CTN, or 2bpp for a mono 640x480 = 75kbyte max.I have ordered a couple of discovery boards (STM32F429 based) as they're so cheap and should get started on ST ARM devices anyway - just needed a reason. Might use those for digital guitar effects...And yes, I too have noticed a bit of an increase in SRAM prices. Farnell still has 4MBit 10ns for £3, where-as the PIC is £6 and would only require a 3.3V-5V converter for the older displays (74HCT541/244/245 will do nicely).As a small side note:whilst developing a CPLD (and then FPGA) LCDcontroller, I had a hard time deciding when one could write to the external memory, opting to add blanking intervals at the end of each line and using a FIFO as a buffer for burst writes. Out of curiosity, if anyone has a verilog/VHDL LCD controller, using external SRAM, I'd be interested to see how others have done it. I was working with an old cyclone II with SDRAM. Might pick up a MACHXO2 board (£20 farnell!) and add SRAM myself, because getting the SDRAM to work was a nightmare.

author: bktemp
author_rank: Super Contributor
timestamp: December 08, 2016, 07:10:09 am
content: Quote from: Buriedcode on December 07, 2016, 10:51:29 pmThere are probably many ways of doing it.I have done a video monitor using a LCD many years ago using an ADC, 128kByte SRAM and a XC95144XL CPLD for driving a 320x240 monochrome LCD. Because CPLDs have no blockram, I clocked everything at 18.432MHz. The ADC was clocked at 18.432MHz/3=6.144MHz giving exactly 320 pixels/line. The ADC data were written directly into SRAM. In the other two clocks data were read from the SRAM and fed into a FRC/dithering block for generating 64 greyscales.Using a SDRAM is a bit more difficult, because you need to do burst reads, otherwise it is really slow.You typically implement a fifo buffer (32-512 bytes) for reading and a similar or maybe smaller one for writing.When the SDRAM controller is idle, it checks if there are data in the write fifo or space for a burst read in the read fifo. When doing a burst read I typically read 16-64 bytes/words. To keep everything simple, the SDRAM is always idle with all banks precharged. Every read/write operation starts with activating a bank followed by the actual read/write burst operation and then precharging the bank again. It may not be the most efficient way, but many SDRAM controllers found in microcontrollers work this way (many of them are really inefficient, because the bursts are rather short, therefore the overhead for activating+precharging the bank is rather high, wasting a lot of memory bandwith). When everything works you can add some more advanced features like checking pending operations if they are in the same row and skip the precharge+activate operations.For writing operations I implemented a fifo holding both data + address for each written value. This enabled random, asynchronous writes from an external microcontroller.If you have everything working upto this point, implementing a display controller is simple.I implemented a freerunning timing controller generating all the sync signals. Because of the fifo at the output of the SDRAM controller it can even run in different clock domain.At the end of each frame, the timing controller generates a reset signal, stopping the SDRAM controller from reading further data and it also flushs any remaining data in the fifo and resets the read address counter. At the last line of the vertical blanking, this reset signal is disabled and the SDRAM controller starts filling the read fifo again.This may not be the best way of doing it, but it worked fine for me.Synchronising the image data and the timing seems to be rather difficult to implement. That's why many display controllers use odd ways of specifying the blanking intervals and sync pulses (By reading the datasheet I couldn't figure out how to set the sync timing correctly for the PIC24FJxxxDA206, I had to look at the microchip graphics library and still don't understand completely how they do it).Because I implemented my own SDRAM controller, it took me a very long time to get it running. It partially worked, but there were many errors in the data. I searched for timing errors, but everything was fine. The problem was timing related, but it wasn't any setup/hold timing related problem, but SDRAMs need a 100us pause after power up. My pause was too short, therefore the SDRAM did not understand the load mode register command and stayed at the default settings. Therefore the CAS latency my controller used was different from the CAS latency the SDRAM used.

author: Buriedcode
author_rank: Super Contributor
timestamp: December 08, 2016, 06:34:31 pm
content: bktemp, thank you again for a detailed reply.So you implemented an SDRAM controller (albeit one specific to the task) from scratch? I was using Quartus' built in SDRAM controller and even when testing with a nois II processor (the FPGA barely had enough room for both) it was rather flakey. I had the LCD controller part (generating sync signals, filling/read FIFO's etc.) part working just fine. I was using a rather old cyclone II board with SDR SDRAM already on the PCB, and that's where I gave up.I will have to knock up a testboard for the PIC24 and use a logic analyser to see what exactly its doing. I suspect it won't do 'dual scan' displays, of which I only have one, but I could fudge that by changing how I write to memory (upper nibbles, upper display, lower nibbles lower).This whole saga was how I got back into programmable logic, which I last studied in university - when the first Spartan was about - and I did make a XC95144XL board with 1Mbit SRAM header board specifically for this task. Chose 55ns SRAM in the hope I could run the CPLD fast enough to allow a write between reads, effectively making it appear transparent to a host controller. Never got used.. its time I put a lid on this, unfinished projects are depressing.

author: bktemp
author_rank: Super Contributor
timestamp: December 08, 2016, 07:45:19 pm
content: Quote from: Buriedcode on December 08, 2016, 06:34:31 pmThe Xilinx memory interface generator for Spartan3 supported only DDR and DDR2 SDRAM, but no SDRAMs, therefore I made my own one.Today it is pretty much obsolete, because all modern FPGAs support DDR3.QuoteIt does not support dual scan displays, but it can be done using the lcd interface set to 8bit data width in the way you described.But then you can't use the GPU for anything useful (except for filling the whole screen). Accessing the upper area of the 96kByte SRAM using the CPU is rather slow, because it can ony be accessed using 32kbyte pages.I found another cheap way of driving those dual scan LCDs using a single chip: All PIC32 have a PMP and DMA (ARM Cortex with DMA and external memory interface can be used).Using DMA you can send the data from SRAM to the parallel master port. It outputs the data and the shift clock pulses for the LCD. A timer + output compare generates the latch pulses. Setting up DMA for the next line and the first line pulse are handled in software.You still need to arrange the nibbles in memory, but the CPU running at >40MHz can do this easily.