Which MCU for graphics LCD display?

[Nogginboink]

I'm planning a project that will use a graphic LCD display; something like a touchscreen remote control would be a good mental model. I haven't spec'd out the resolution I'll need or other factors, but I'm realizing that I don't know what I don't know, and therefore choosing an LCD and a microcontroller for this project is challenging.

How would y'all go about choosing these parts? I'm leaning toward the STM32F429 series with the built-in LCD display driver, because, well, it's got a built-in LCD display driver and I've worked with STM32 in the past, and well, I don't know what I don't know.

Other than driving a graphics LCD panel, I'll need to support a USB mouse or joystick, but USB ports are becoming pretty ubiquitous these days, so I think that requirement would be less of a driver of chip selection.

How would you go choosing an LCD panel/microcontroller combination? How important/useful is the LCD controller that's embedded in the STM32F4? Would it be just as easy/easier to get an LCD panel with a built in controller? Is there likely to be a cost difference? What do I need to know that I don't?

(Yes, I realize my question is rather overbroad; I'm curious to get some generalized answers from the community.)

[nctnico]

I'd start with the really hard part: what kind of graphics speed do you need and what kind of GUI? Better look for which graphics/GUI library is available and go from there.

[ovnr]

It Depends^TM. Some general notes:

Does your LCD display have a built-in driver (with memory) or not? If "not", you sorta need a micro with a built-in controller. Possible without, but a massive pain in the arse.

If the display actually has a driver in it, the next question becomes: What are you doing with it? Do you write some text and graphics to it once in a blue moon - think standard GUI - or are you doing more involved things with animation and such? Former case: Normal micro is fine. Latter case: A built-in controller makes things less painful.

[mperativ]

The PIC32MX DA series is a great alternative.  Versions of this controller include 32MB of DDR on the die, as well as basic graphics acceleration and support for layers and alpha blending.  Capacitive touch is also supported via the CTMU and Microchip's mTouch libraries (which I've never used).  However, check the errata since it is relatively new silicon with some notable issues in the past...

[ggchab]

As a hobbyist, I am currently playing with a 480x320 ili9488 compatible LCD display (a very cheap model for Arduino) and a dsPIC33EV to build the user interface of a power supply.
This is the first time I use something more powerful than a PIC18F and a graphic display. Despite this, after some research, I found it very easy to drive I am really impressed by the combination of the display and the PIC.
The LCD is not very fast but well enough for a simple user interface.

[Rerouter]

Ok to simplify it, your microcontroller choice will be heavily influenced by :

- needing a USBOTG interface, preferably with a free stack that can handle hubs.
- Having a DMA that can shove out data to your display at the rate you wish, e.g. a 320x480 display with a 16 bit interface, well you can treat most screens with controllers like a memory, so you hook it on to the external 16 bit memory bus, and can then complete 95% of the interfacing with a DMA,

Ok so this leaves the rest of the sub requirements, selecting what images to load as a background, and for buttons, you would point the DMA at the start location, load the number of bytes for the horizontal width, then when you get the flag for transfer compete, load the next line, rendering down with almost no processing input on your part,

Now the harder part, you have a mouse, so you want a cursor, there are a few ways to approach it, but it will generally require either:

a full frame buffer that you modify, then render the cursor after it,
or a change buffer where you keep track of where the cursor occludes, then once you move to the next spot re-render that space, record the next occlusion space, then render the cursor.

one costs you far more processing time, and there are other ways to approch it,

I'm far more used to 4-10 button interfaces with an encoder for high distance granular settings, in this case I defined render areas, and then cut my UI's into image chunks, so I only had to DMA render in chunks to say show a button, and for text, i had the processor assemble it in chunks using array rotation, essentially i stored the fonts in 16 bit ints, vertical strips 16 pixels high, and X many wide depending on the font size, just being a mask, so I could assemble words just by dragging in say the first strip, AND it so it was just 1 bit, and if it was a 1, send out the 2 bytes from the text colour property. going down the array of the text until the end, then doubling the mask to the next bit and walking down the strips again, rotating vertical strips in to horizontal colours as the LCD expected.

In that case, that was me chasing as much speed as I could with foreground tasks, while still wanting some font sizes and things like italicization and bolding, leaving only a few letters needing special rules like VA where there gap is actually 0, because they get squished together.

[ogden]

How would y'all go about choosing these parts? I'm leaning toward the STM32F429 series with the built-in LCD display driver, because, well, it's got a built-in LCD display driver and I've worked with STM32 in the past, and well, I don't know what I don't know.

I would lean towards chip series which possibly is up-to the task and what's most important - I am familiar with. Stm32 is preferable in your case. Only question left - which exactly part to pick.  STM32F429 is good for the job for even 640x480 display. You really shall calculate early - how much bitmap and font static memory your application can take. Fonts & bitmaps can take lot of precious flash memory space, icons too.

[asmi]

If you only need display for the GUI (with perhaps touchscreen) and don't plan to do any fancy graphics, I'd look at FT8xx family of ICs from FTDI, which are essentially display co-processors. They talk via SPI, so you can connect them to pretty much any MCU out there, and they provide interrupts for handling touch input.

[technix]

For your intention I feel like you might want to use some kind of operating system. Maybe a Raspberry Pi will work for your purpose?

If your true intention is a remote controller with touchscreen, it may be better to build a small headless dongle (that is, no display at all) and build the UI as an app on a computer or a smartphone? The simplest of this kind of controller is based on a ESP8266 module, providing a Wi-Fi to IR bridge. You can also use Bluetooth Smart, USB or headphone jack as the communication channel. That might be a lot cheaper and packs a better user experience as the dongle can be tucked away at somewhere hidden from plain sight, and the user does not need to manage yet another extra remote control.

Or if you are developing the controlled appliance too, you can just skip the IR remote control entirely and embed some kind of wireless connectivity directly in, and build a smartphone app that goes along with it.

Most smartphone have built-in QR code scanner app. You just need to print the QR code to the link downloading the app onto the product manual and the packaging, the user will pick up on that, scan the code and get the remote control app.