GTA03 and E-Ink Interface

[Joerg Reisenweber]

Am Mo  16. Februar 2009 schrieb Jaya Kumar:
> On Mon, Feb 16, 2009 at 8:02 AM, Andy Green <andy at openmoko.com> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > 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.
> 
> Ok, with you so far.
> 
> >
> > 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,
> repeat to  framebuffer size, wiggle some more and then finally wait
> for an interrupt from a 4th control signal to send a command. I think
> there's no input signal on the pixel bus so Glamo won't be able to
> report the interrupt back to me. But I think it would not be a problem
> for me to put that signal on an actual gpio. So that leaves the
> problem of the 3 control signal and 16-bits of data. Is there a way
> for me to store those 19-bits of data in the framebuffer so that glamo
> can push them to the controller. I guess if glamo knows about RGB888
> and can transfer that to the pixel bus, that would work fine since I
> can just store my control sequence + data inside the 24-bits of
> framebuffer data and then get glamo to push that through. That would
> be awesome.
> 
> >
> > 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:
> 
> set chipselect off
> set data on
> foreach pixel {
> set write off
> set 16-bits framebuffer data
> set write on
> }
> set chipselect on
> 
> If we treat write as a clock signal, then the clock must return to
> 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.
> 
> Thanks,
> jaya
> 

if that's a problem getting enough datalines from LCM videodata interface, you 
could use 2 pcs 16bit latch and control their CS and CLK and OE with 2 lines 
while hooking up the rest for latch data input. this way you have full 
control of all 32 (28?) output lines to a time granularity of glamo's 
pixelclock / 2. Of course with gaps during hsync where output won't change.

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 
glamo's videobuffer with the signalpattern for your interleaved 2 x 16 
outputs, enable video output, and your kernel driver is idle during 
glamo "bitbanging" the e-ink interface data via the latches.
I could help better if I had a datasheet of the E-Ink controller interface.

cheers
jOERG
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.openmoko.org/pipermail/hardware/attachments/20090216/b88a00b4/attachment-0001.pgp