Porting MZXT06A to Arduino

After having tested the MZXT06A LCD with my Raspberry Pi, I was wondering how much performance I would get out of a Arduino, knowing the processing power is much much smaller on a Arduino Uno or Mini Pro.

First thing  I did was figuring out how to connect the LCD-Board on the Arduino.
Turns out the Raspberry Pi driver is actually only using the MOSI/CLK signals and it is using the MISO/CE and GPIO25 as standard GPIO to interface the LCD-board.

A word about the MZXT06A. It is actually interfaced using a Altera EPM3213 PLD-chip. It's kind of weird because the LCD-controller has 18-bit RGB connectivity, but also 16-bit RGB over SPI. So what the EPLD does, is providing a true 18bit RGB interface over SPI.
The Altera  chip needs 3V power, but it's interface pins are 5V tolerant. This explains why a lot of people are capable of interfacing with 5V-Arduino boards. If you use a 3V Arduino, all will be fine.

I use the Arduino Mini Pro, running at 3.3V and 8 Mhz.

I connected the Display as follows :

- Arduino MOSI (11) : to pin 6 (LCD-SCI)
- Arduino CLK (13): to pin 7 (LCD-SCL)

- Arduino D2 (2) : to pin 5 (LCD-CS)
- Arduino D5 (5) : to pin 4 (LCD-RS)
- Arduino D9 (9) : to pin 3 (LCD-RST)

VCC,LED need 3V
GND goes to GND

Once connected, the display backlight should light up.

I have ported portions of the MZXT06A source-code to Arduino as a proof of concept.
I am now able to fill rectangles, draw circles and draw dots.
I havent figured out what goes wrong with the display_char function. I have put the font-data in PROGMEM because of the lack of dataspace on my Arduino, but no luck. It draws something, but it looks like random data (within the 8x16 characterspace).
Update: found the mistake with display_char. If one stores data in PROGMEM, one has to retrieve this data using a special function "pgm_read_byte_near" referencing the data using a pointer.


Performance is pretty good, considering the 8Mhz MEGA328P.
The display draws approx. 90mA of current and it fills a full frame at 1fps writing 1 byte at the time.
I'm sure this can be optimized.
Update: only way to speed up is to use a higher clock-rate. Currently the interface runs at half the processor speed and it's not the SPI-speed, but rather the CPU which is the bottleneck. Will try later on the Arduino Uno. Should run much faster.

If you need the code for your Arduino, just let me know.