So, I got the Raspberry Pi and I want to do some programming work for it. Why not dive
into kernel development? I still had a nice framebuffer module for intelligent
displays from my SPI-controlled TFT display. I also
had a 2.4" LCD with an ILI9325 controller configurable to do 8-bit transfers. The
8-bit transfer mode was awesome, because it meant I could directly connect it to the
GPIOs of the P1 header of the Raspberry Pi. That made the hardware really simple,
and also much quicker because the data wouldn't have to be serialized first.
As you can see, there's not much to it. Most IO-pins are directly connected. To save some I/O, the /rd-pin is permanently tied to Vcc because it's not necessary to read from the display. There are 4 resistors for the backlight, and that is it. The pin numbers for the LCD seem to differ from datasheet to datasheet, by the way: if the data pin numbers on your LCD go up to DB17, you'll need to connect the GPIO to DB10-17 instead of DB8-15. Notice the touchscreen isn't connected: it wouldn't have much use on a mini arcade case, and would require extra hardware to get working because the RPi doesn't have integrated AD-converters. I later actually removed the touchscreen from the display to get a clearer image.
There's one more hardware thing that needs to happen. The LCD as I bought it has a
16-bit interface, which needs too many pins to connect it directly to the Raspberry Pi.
To make it talk over just 8 of the 16 datalines, you need to move a jumper resistor from
J1 to J2. The jumper resistor is 0402, but a simple wire works too:
The software side was fairly easy: I mostly recycled the framebuffer code from my previous project, exchanging the SPI transfer routines with routines directly writing to the hardware GPIO registers of the Raspberry Pi's main CPU. This unfortunately harms the portability of the code to other processors, but is the quickest way to get things done. I also added a little routine that only updates the pixels that were actually changed: for games where only a part of the display updates, this could give a nice performance gain.
Because of the direct connection to the fairly speedy GPIO of the Raspberry Pi, the display refresh times aren't too bad. I tested it by using mplayer to show a 320x240 variant of the Big Buck Bunny short movie. The video is non-accelerated, by the way: the kernel driver bypasses the Videocore driver that accelerates video in the Raspberry Pi so only software decoding is available.
You may also notice the red board on top of the Ethernet-port: this is a little FT232-board. I use it to get a console without having to have working framebuffer code or having to hook up a HDMI-cable. I also modified it a bit so the Raspberry Pi can power up from this. I kept the board in until the end: getting a console by just plugging in an USB-port can be a huge help.
If you want to replicate this, you can: just get a ILI9325-compatible 320x240 display and connect it in the same way as I did. (Take care: some sellers mistakenly offer displays with Samsung controllers as having an ILI9325-controller. The two aren't compatible.) The software driver is in this patch, apply it to the latest Raspberry Pi kernel sources, enable the ILI9325 framebuffer driver, recompile and you should be good.