GTA03 and E-Ink Interface

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:

| btw, the bitbang mechanism used to transfer data to the controller
| doesn't have a maximum period, meaning, data is clocked in using a
| gpio. For example, for the burst write shown previously, I am just
| cycling the WRITE signal on/off to clock the data into the controller.
| Of course, it would be best if I can clock that data in very fast, so
| a gpio that requires more than 50ns to set/clear would still work but
| would make the display appear slower than it really was.

Access to Glamo mapped region is much slower than 50ns.  But, it's 16
bits wide.  If you were able to use all the 16 bit width, you would have
more than enough bandwidth.

Here's an idea, totally abuse the Glamo framebuffer and pixel bus to
store your bitbang sequence as "video".  Then hook up each of your E-ink
bus signals to one bit of pixel data, eg, E-ink nRD <- RED0.

Pixel data generation is synchronous in the Glamo so the edge quality
should be good enough to clock from.  There's a PLL in the Glamo that
can be meddled for Glamo pixel clock: it's 24.5MHz typ IIRC.

Because your bus clock is also derived from pixel data, and your system
is fully synchronous, HSYNC and VSYNC will be invisible so long as you
return your clock to 0 (presumably) before the end of each video line.

There's an auto page flip feature in Glamo that can help you issue this
data just the once, you can keep the other page at all pixels 0x000000,
then it simplifies enabling page flip and watching it do it once, then
disabling page flip.

This should give you highest bandwidth solution possible on GTA02.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkmYrRYACgkQOjLpvpq7dMqa4gCfc5vjanyYIjslaHrr6gHrMV9C
ddEAnjJn2tiEjUm4Pk2qMINNhGmU9zFq
=8znq
-----END PGP SIGNATURE-----