I got this screen instead of an SPI one with the intent of expirimenting with more hardware, rather than actually hoping to use the screen in a real project.
It is 16-bit color (5/6/5) and, after you initialize and all that, you basically just set the cursor, then pump colors.
It has a bunch of registers for rotation, address window, etc.
[ol]Direct port of the Adafruit Arduino source. All of the demo functions performed perfectly but it took 3+ seconds to fill the screen, even with black.
I switched to the Domino and used the ParallelPort class. Improved speed, but repumping 0 high and 0 low just to clear the screen seemed stupid.
Adafruit code had shortcut for floodfill whenever high and low words are the same (like black), where you dont rewrite the value, but just toggle the write pin twice for each pixel to fill after the first. I added a buffer IC to allow me to attach the screen’s write pin to the SPI clock for such fills. Improved performance, but only for high==low colors; pathetic otherwise.
Added two registers. When the registers are chip-selected, data comes from the Cerb; while the screen is chip-selected, any previously loaded value scrolls within the registers. Every byte written to the screen effectively swaps the high and low words within the registers. I also added a binary counter to count the clocks and strobe the write pin on every 8th clock. The counter resets asynchronously at that time, as well, preparing for the next byte. There is no useful data sent to the screen via SPI, only clock. The SPI transmission is just an a array of ushorts (0’s).[/ol]
By now, I feel I’ve learned enough to move on; I’m hoping to get the G400 and a new screen soon.
A few little quirks that I’d like to explain/fix but aren’t critical:
[ul]With the hardware in the image and, at low speeds (1KHz so I can see on my crappy DSO Nano), it works worse! The address window register seems to get locked into full height and (the left) half-width of the screen?! At multiple MHz, it doesn’t do that. In previous hardware revisions, it did not do that.
The current hardware revision clears the screen many multiple times per second in any of 165whatever thousand colors. Every… 10th or so(?) clear gets corrupted, throwing in a few lines of a different color amongst whatever it is supposed to be filling with. Sometimes it will continue with the next color. Other times, it will confuse the screen and do something odd. FYI, you select whether you are writing a register or data before the SPI call with an additional control pin.[/ul]
My test application is just a for loop from 0 to ushort.maxvalue with a fillscreen(i) for each.