GTA03 and E-Ink Interface

[Andy Green]

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

Somebody in the thread at some point said:
| Hi Andy, Joerg, friends,
|
| A quick question before investing further effort along the glamo path
| of inquiry. I assume GTA03 changes this significantly since there is
| no glamo. So shouldn't I instead design for GTA03 instead of this
| approach? I imagine that by the time I build an interface board for
| GTA02-E-Ink and debug and resolve all these issues with manipulating
| glamo, GTA03 will probably be here already.

GTA03 will give you pretty similar situation, you'd still be writing
coded bitbang into a memory-mapped framebuffer.  But you should have a
proper VSYNC interrupt.

It's the same LCM connector signals right now.  So there is not too much
hit doing it on GTA02 + Glamo vs GTA03.

| By the way, I meant to ask, if there are any other people interested
| in interfacing GTAs with E-Ink displays, it would be good to let me
| know. Ok, now, returning to the glamo approach:

I think it would be a pretty awesome capability to be able to consider
to swap out the LCM for E-ink display.  Obviously it has major impact on
power, especially and you can suspend and leave the display up with zero
power.

| On Mon, Feb 16, 2009 at 1:12 AM, Andy Green <andy at openmoko.com> wrote:
|> 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.
|
| Ok, I see now. I see signals LCD[0:23] RGB888 on Glamo but to LCM
| CON6001, it is twiddled to RGB666 and hence only 18-bits. That's
| normal. Does it have any implications on the format I will need to use
| to store data in the framebuffer? Presumably, I just setup fb as
| RGB666 and store as RGB664 and have 2-bits left to store control. Ok.

Yes that's the point exactly.

| LCD_MOSI (btw, I'm looking at
| Schematics_Freerunner-GTA02_A5-A7cummulative_public_RC0.pdf) and don't
| see this signal.

It's p11 on the LCM connector, marked "DIN" on that connector.

| set LCD_MOSI (chipselect) off
| set another gpio (data control, DC) on
| fill the framebuffer with:
| fb word 0 = data[0:15][0], write off
| fb word 1 = data[0:15][0], write on

There's a race there, you may need to sequence one change at a time for
reliable operation depending on the hold time requirement of your device
~ --->

~ fb word 0 = data[0:15][0], write off
~ fb word 1 = data[0:15][0], write on
~ fb word 2 = data[0:15][0], write off

| DC, CS, WR needs to be wiggled in sequence with the framebuffer
| content whereas we only have space to store 2 of those. But CS is only
| at start and end so okay, just put DC and WR into framebuffer. Now, I
| guess we don't need to fill the entire framebuffer, just the top n
| words and then at the end of the glamo transfer, we finally wiggle CS
| manually with a gpio. A bit ugly, but by now, we're comfortable with
| ugliness. :-)

It's the Glamo we talk about :-)

| pin, and one has to 800*600*3 gpio sets, then that's 800*600*3(at
| least 3 gpio sets (wr, data, wr) for each pixel)*250ns = 360ms for a
| framebuffer transfer, which means we are talking about ~2Hz as the
| best case display update rate. E-Ink displays are capable of better
| performance than that. See http://www.youtube.com/watch?v=53X_XlqBdfM
| (also others in my related videos area) for somewhat interactive
| performance on E-Ink demonstration.

I worked on E-ink design with Metronome chipset before, I have a good
idea about latencies for changing the cells, I understand the broadsheet
is considerably more advanced.

We can spew the data at very fast bandwidth to the controller chip, but
I think it'd be most limited by preparing the bitbang sequence in Glamo
memory.  Still it'll be pretty fast and workable since we are not having
to directly deliver shaking pulses and so on directly as video bitbang,
just higher level data and the smarter controller with take care of
timing and other detail.

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

iEYEARECAAYFAkmalcMACgkQOjLpvpq7dMqYIQCfZqjgcqpCAHAyFMGcCVeaJY8P
6bYAn0cAeo60xWRNzbWgf+iWBUQKVc8b
=Lrtw
-----END PGP SIGNATURE-----