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 <a...@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. > You can tie the interrupt input to a non pixel-data Glamo GPIO that is > available on the connector also, and poll it. Ok. > > | 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: http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=5354/1 (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 http://www.youtube.com/watch?v=53X_XlqBdfM (also others in my related videos area) for somewhat interactive performance on E-Ink demonstration. Thanks, jaya _______________________________________________ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware