We chose Optrex LCD for our prototype, and we were told that ILI9322 is its driver (integrated into the LCD hardware). They didn't provide a manual of APIs to their users.
ILI9322 is a one-chip SoC driver for a-TFT liquid crystal display with resolution of 320RGBx240 dots, which can handle 256 (8-bit) gray scale levels for each color and drive versatile panels with max.
I got the following questions:
Can I assume that the LCD will be supported by any popular embedded RTOS, say QNX? Shall I contact the LCD manufacturer or the RTOS vendor to confirm it?
If it is not supported by the RTOS automatically, how can I know the APIs exposed by the LCD to the programmers?
Where is the place that I can download a driver module for LCDs? Maybe I need to modify the driver to fit with the RTOS.
In this case driver means driving the TFT display, not a software driver.
See above, there's no API in the 9322.
I don't know about RTOS's but I recently wrote my own SPI drivers for the ILI9320. The datasheets on the Ilitek website aren't too bad to follow but they do assume some prior knowledge.
However I think the implementation is somewhat "standard".
I've got it working well with SPI but I am using a high end micro and clocking it at 5Mbps.
If you need any sort of full screen animation then you'll need to use one of the parallel data options which may be conveniently available depending on what other hardware you have, I don't know much about this though sorry.
Single frame is fine with SPI. Video would need RGB parallel.
First of all, you need a micro that can drive upto 8-8-8 (24 bits) RGB or a subset of it. For example, the PIC24F can drive upto 5-6-5 (16 bits), in addition to Hsync & VSync. Furthermore, you need to have enough video buffer on the chip.
Well that depends on your definition of single frame, it does take a noiceable time to write the complete screen and certainly isn't practical even if you only wanted to update every 1s or so.
A basic bitrate of 5Mbps as I'm using suggests that the screen can be written about 4x per second, but not if you want the sysem to do other things as well!
I'd be surprised if there's anything like enough horsepower in the PIC24F to run video, I think you need a dedicated part that reads from memory and blasts it out the video port without any processor intervention.
Again I suppose it depends on how many fps you would need.
Looks like the cart before the horse. Choose lcd and then shoehorn the rest of the design to fit doesn't sound like a good approach. You need to define the problem a lot more before deciding if a serial data interface and available processing power is adequate to meet the required frame update rate. I/o bandwidth requirements are a critical part of any such design.
As for software, you will pay serious $ to get gui / lcd panel support within an rtos from a commercial vendor. You will need some sort of driver and api interface to the application from somewhere. You may find some example driver code from lcd controler companies like epson. Ime, they really are only examples and not good enough for project use, so without lots of $, you will have to write the driver / api yourself.
Example of a similar problem here: An older project used dragonball, which had an integrated lcd controller, with dma / cycle stealing lcd update. Quite good for it's time and easy to program, but has been end of life for years now. All the later micros with integrated lcd controller are over the top and overspecified for the job in terms of package pin count and internal peripherals. I want a low cost, modest pin count micro and the choice so far looks like an stm32f m3 driving an external lcd controller chip via the fsmc external memory interface. This will provide maximum flexibility in terms of display selection and cost, since parallel interface panels are still far more common and cheaper than serial. The panel cost may be the major proportion of the project cost, so you need max flexibility in panel choice. The frame buffer i/o bandwidth will be easier to quantify as well, since the controller memory appears in cpu address space and can be updated at cpu / dma rates...
The PIC24F I am using has 96K internal sram and dedicated graphic controller port running at 96MHz pixel clock. Driving video is not a problem, but getting the video stream is.
I just took a quick look at the chip in question -- it looks like an electrical driver only, with pretty narrow functionality and a need to be fed timing and data just right to produce video. If I'm not mistaken, you have to supply it with sych signals and with pixel data at the time that a pixel is ready to display. This implies that you need to have a controller somewhere on your board to complete the system, which is beyond what you're going to get from lines of code in an RTOS.
How did you think you were going to connect it to your processor?
Ah ok, so you can fiddle about with what you want in the sram which will be quite quick and then you'll get a smooth write the screen without further processor intervention.
With SPI you can see the screen wipe down if I do a complete screen update, it's pretty good with small windowed areas though such that even a small 20px x 20px animation looks good.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.