320x240 LCD UI IC for arduino - Page 1
Forum section: electronics / beginners

author: michaeliv
author_rank: Frequent Contributor
timestamp: February 18, 2016, 11:15:42 pm
content: Hello,Recently I've been working with Arduino and have discovered that it's not possible to drive a high resolution tft ( probably anything over 64x32 ) display at real-time update rate (25fps+, preferably 60fps).So, I was wondering, is there an IC that would sit between the arduino and the LCD display driver (ex ILI9341, etc ..) and translate commands such as "Draw rectangle", "Draw Text", etc ... to draw pixel commands and send them to the display driver ?Does such a IC/category of ICs exist ? I've searched but found nothing.I guess the only way to drive a 320x240 LCD at 60fps would be to use a high-speed ARM chip such as a CORTEX M3 running at ~100Mhz.Does anyone know what do for example cheap Chinese MP3 players use to drive their display. I'm guessing it's an ASIC with everything built in, but I'll ask just in case.What would be the minimum(cheapest) MCU that would be able to drive a 320x240 LCD at 60fps ?Thanks!

author: ade
author_rank: Unknown
timestamp: February 19, 2016, 02:11:22 am
content: 60 fps doing what, exactly? Updating simple 2D images in monochrome is very different than rendering complex objects at 16-bpp even at the same 320x240 resolution.Having said that, Atmel has Cortex and ARM926 based MCUs (such as the SAM9G family) designed to drive larger displays (800x600 and up) which may suit your needs. Most are 200 MHz plus. Prices start around $15 for qty 1.Cheap Chinese MP3 players aren't rendering 60 fps. Maybe not even 20 fps. For that kind of graphics you might get away with something like a PIC24FJ with integrated graphics module. It's good enough to handle uncompressed video at around 20 fps. Prices start around $9 for qty 1.These chips often have integrated LCD drivers so there's some cost savings there.

author: michaeliv
author_rank: Frequent Contributor
timestamp: February 19, 2016, 03:16:16 am
content: Let's say 60fps at 16bpp just filling up the screen with different colors. No extra workload on the CPU.Basically I'm trying to get the idea of what it would take to have a 60fps UI on a decent resolution display.Very interesting about the PIC's, the $6 PIC24FJ128DA106 claims 480x272 @60Hz, 16 bpp and operates at only 32MHz.Anything similar in the STM32 line ?I've tried looking up what cheap Chinese photo frames have in them but apparently they use dedicated chips.As a practical question:Let's say I wanted to draw a different color background + 2 circles + 10 random characters of text at 60fps on this 320x240 ILI9320 LCD :http://www.ebay.com/itm/-/262136737264What would be the simplest / cheapest MCU or IC+slow MCU that would be able to do that ?

author: bktemp
author_rank: Super Contributor
timestamp: February 19, 2016, 06:24:47 am
content: Quote from: michaeliv on February 19, 2016, 03:16:16 amYou need a 2D accelerator, it can copy and fill areas without much CPU load. It may only load the memory bus.QuoteIt runs at 16MHz, but the grpahics accelerator runs at 96MHz, enableling a pixelrate of 96MPixel/s, but only in internal RAM. With external RAM the datarate is much slower.But that does not mean it can render a complex GUI at that datarate. The 60Hz is only the updaterate from memory to screen.Any IL93xx LCD will also have 60Hz refresh rate from memory to screen, the main limitation here is the SPI link from the cpu to the LCD memory.QuoteSTM32F429, STM32F469, STM32F746.They have an externam memory interface + 2D accelerator + LCD controller.But you do not need an LCD conttoller, because the LCD has already integrated a IL93xx. You need a microcontroller with a DMA controller and enough memory to calculate the frame quickly into memory and then transfer it to the LCD using DMA while doing other useful stuff. Most larger STM32 and other 32bit microcontroller should be able to do this.

author: ade
author_rank: Unknown
timestamp: February 19, 2016, 06:35:53 am
content: Assuming a parallel interface @ 60 fps you need to refresh the graphics RAM at 5.7 MHz.The PIC24FJ has hardware acceleration for text and rectangles. Drawing filled circles will be slower unless you have set sizes you can just copy or xor in. But at 32 MHz it might be enough to render the image and transfer it to the LCD, if you're just doing simple fills and text.If you're not tied to the Arduino, also look at the TIVA LaunchPad (80 MHz ARM Cortex M4) and get one of the LCD modules for it. E.g.,:There's a free online course going on right now at EdX to teach you how to program embedded processors with the LaunchPad (including an optional Nokia LCD module). The class already started but there's still plenty of time to join, catch up and finish.https://www.eevblog.com/forum/beginners/free-course-ut-6-03x-embedded-systems-on-edx-starting-now/

author: amyk
author_rank: Super Contributor
timestamp: February 19, 2016, 11:23:18 am
content: It depends what exactly you want to draw on the display. Here's an interesting demo of generating VGA (and audio) from a 20MHz ATmega88:http://www.linusakesson.net/scene/craft/Quote from: michaeliv on February 18, 2016, 11:15:42 pmIf you're referring to the s1mp3s, a 24MHz Z80. They only have 160x128 16bpp at 15FPS though, which comes out to 600KB/s data rate.

author: Skimask
author_rank: Super Contributor
timestamp: February 19, 2016, 01:27:26 pm
content: The problem isn't the LCD, or the circuit. Using the Arduino programming environment as its used by the average person is the issue. Too many layers between your keyboard and the actual hardware. Get rid of a few of those layers by learning how to program the stuff down at the actual haredwaree layer, and you can easily drive, say an 800x480 LCD without a problems ....at high rates too

author: bktemp
author_rank: Super Contributor
timestamp: February 19, 2016, 03:30:55 pm
content: Quote from: Skimask on February 19, 2016, 01:27:26 pmYes, using the arduino environment slows everything down, but 800x480 is painfully slow on an AVR if you want to do something useful, even in assembler.One of the main problems is the connection between the AVR and the display memory. Because most AVRs don't have a memory interface it must be emulated in software. This takes several instructions to set up the memory address (800x480 needs a 20bit address, so at least 3bytes) and transmit a single pixel. Unless you fill the whole screen with a single colour you have a huge overhead, slowing everything down.I don't say it is impossible, but more than 320x240-480x272 is impractical. Using a 16 or even 32bit controllers speeds everything up significantly because it can move all 16bits at once and perform the 32bit address calculations much faster (single cycle instead of 10+ cycles on an AVR).