GTA03 and E-Ink Interface

Jaya Kumar jayakumar.lkml at gmail.com
Wed Feb 18 10:07:36 CET 2009


On Tue, Feb 17, 2009 at 5:47 AM, Andy Green <andy at openmoko.com> wrote:
> -----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.

Hi Andy,

Hmm, I didn't expect that GTA03 would still require fb-encoded gpio
(for lack of a better term). I had thought that S3C6410 would allow
remapping of VD pins to GPIO. I don't have the actual S3C6410
datasheet, just the S3C6400X that you had linked to in another thread.
That one suggests XvVD[17:0] can be switched into Function 3 (GPIO
mode). Is this assumption invalid for GTA03's 6410?

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

Ok, I understand that to mean that the LCM connector pinout between
GTA02 (CON6001) and GTA03 are similar. So physically not much
difference between interfacing to GTA02 and GTA03. I see that GTA01
has also the same connector, CON6001 and same pinout (I think). I saw
Werner's point that it has host controlled GPIO on the LCM connector
which would make it an attractive option to me as a starting point
since then I can avoid the bringup complexity of fb-encoded gpio.

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

I see what you mean.

Thanks,
jaya



More information about the hardware mailing list