GTA03 and E-Ink Interface

[Andy Green]

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

Somebody in the thread at some point said:

|> 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.
|
| I've lost understanding here. I have 22 signals. To talk to the
| display, I need to wiggle 3 control signals, set 16-bits of data,

Glamo only issues 18 bits of pixel data, it's all there is from it.  But
often it's possible to leave one or more of the control signals at a
static level during the transfer.

You can tie the interrupt input to a non pixel-data Glamo GPIO that is
available on the connector also, and poll it.

|> 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.
|
| You lost me here. I have a write signal that is used to clock the data
| in for every 16-bit transfer, perhaps that's what you mean by bus
| clock. For example, a full buffer transfer involves:

Yes exactly.

| set chipselect off     <=== static during txfer
| set data on
| foreach pixel {
| set write off
| set 16-bits framebuffer data
| set write on
| }
| set chipselect on

I didn't see 22 there but 18 mentioned?  This would work without glue
logic like this...

Red0 - Red5      =  data0..5
Green0 - Green5  =  data6..11
Blue0 - Blue3    =  data12..15

Blue4            =  "write"
Blue5            =  spare

LCD_MOSI as GPIO = chipselect

There are two more signals on the connector that can be used as GPIO,
nLDE and LCD_CLK (it's not the pixel clock but an SPI clock).

Is that enough?

BTW there's no possibility of read on the Glamo pixel data bus, just write.

| If we treat write as a clock signal, then the clock must return to

write is just another pixel data bit, it's the "clock" for our bus though.

| idle after exactly the last pixel (of the whole framebuffer) rathar
| than a whole horizontal line. I could use the vsync on the host to
| tell me when to set chipselect on if I treat that as a separate IO.
|
|> 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.
|
| Ok, sounds pretty good although the level of complexity seems high.
| btw, I'd want to tell Glamo to suspend shortly after a transfer since
| it's an E-Ink display since we won't need it to be active until the
| next time we want to draw anything.

Yes we can turn the LCD unit off, but not the whole Glamo if you want
uSD to still work easily.

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

iEYEARECAAYFAkmZA1MACgkQOjLpvpq7dMqlqgCeM5YaAF7T6gcbohwlLvXmjtrR
2koAn0oV3jhqDjmGrBRcTdcL2QzJDRAs
=PHa1
-----END PGP SIGNATURE-----