GTA03 and E-Ink Interface

Jaya Kumar jayakumar.lkml at
Tue Feb 17 11:23:50 CET 2009

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.

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:

On Mon, Feb 16, 2009 at 1:12 AM, Andy Green <andy at> 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.

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


> | 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

19 in the burst write above. framebuffer data is 16 signals.
chipselect, data, write are 3 separate signals.

the following code may help clarify:
(16 data)
+#define DB0_GPIO_PIN	  58
+#define DB15_GPIO_PIN	73

4 output controls
+#define CS_GPIO_PIN	76
+#define DC_GPIO_PIN	48
+#define RD_GPIO_PIN	74
+#define WR_GPIO_PIN	75

1 input control
+#define RDY_GPIO_PIN	32

1 reset
+#define RST_GPIO_PIN	49

22 total.

Let's say we take this sequence alone:
> | 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

and convert it to use the glamo framebuffer-io approach. This means,
we would do:

LCD_MOSI (btw, I'm looking at
Schematics_Freerunner-GTA02_A5-A7cummulative_public_RC0.pdf) and don't
see this signal.
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
fb word 2 = data[0:15][1], write off
fb word 3 = data[0:15][1], write on
fb word 4 = data[0:15][2], write off
fb word 5 = data[0:15][2], write on
fb word 2*w*h = data[0:15][w*h], write on
ask glamo to transfer the framebuffer
set chipselect off

Meaning the framebuffer size is actually 2*w*h. Shouldn't be a
problem, just memory, assuming I can control glamo transfer size. Ok,
so I think burst write looks like it is achievable.

Ok, next item to check. To issue a single command to the display
controller, ie: not a buffer transfer, to do things like a partial
update or a configuration command, the sequence is:

+	par->board->set_ctl(par, BS_CS, 0);
+	par->board->set_ctl(par, BS_DC, 0);
+	par->board->set_ctl(par, BS_WR, 0);
+	par->board->set_hdb(par, command_id);
+	par->board->set_ctl(par, BS_WR, 1);
+	par->board->set_ctl(par, BS_DC, 1);
+	par->board->set_ctl(par, BS_WR, 0);
+	par->board->set_hdb(par, command_arg1);
+	par->board->set_ctl(par, BS_WR, 1);
+	par->board->set_ctl(par, BS_CS, 1);

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. :-)

So yeah, my current feeling is that this seems technically viable,
although quite complex.

btw, Joerg asked:
> For the very slow e-ink display I don't see where concerns about speed of data
> transmission arise from. Anyway with the concept sketched above you just fill

This was during the previous discussion where we were talking about
manually manipulating the IO pins controlled by glamo. I had claimed
up to 50ns of latency is fine. Lets say it takes 250ns to set a gpio
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
(also others in my related videos area) for somewhat interactive
performance on E-Ink demonstration.


More information about the hardware mailing list