CrossRoads:
How are graphic LCDs typically used? Write data, couple of status reads, write data, couple of status reads? I could add a couple more gates and keep the read clocks out, that would allow more cycles to get the data.
Here's what I'm thinking of doing and my vision of how it would work.
This web address was hidden your post.
http://www.crossroadsfencing.com/BobuinoRev17/LCD Capture timing.emf
(spaces in file names are not a good thing - as you can see above, it confuses many parsers......)
I can grab the file and download it but I don't know what it is. What kind of file is this?
The interface is always 8 bits as there is no 4 bit mode.
I'm still unclear what you are really trying to do.
I also am still not understanding your terminology for "clocks".
There are no "clocks" in a ks0108 style interface.
The interface can read, write, read status, and write commands.
And E with the control lines synchronizes the operations between
the host and the glcd with it being determined by both edges
of E.
Maybe there is a misunderstanding which way some of the
signals in the ks0108 interface go?
All the control lines including E are inputs to the glcd.
As far as usage goes, it can vary substantially.
It will depend on whether the application has a frame buffer or not
and how smart it is with respect to remembering and keeping
track of where the hardware address registers/counters are.
If there is no frame buffer then there will be an intermixing of reads and writes
as to set a pixel means reading the lcd page to the host, Oring in the pixel, and
writing the page back out.
If the host s/w is not very smart there will be many commands to set row and column
going on in between the reads and writes.
The data/command pattern will also very dramatically depending on what is being done.
Say drawing a line or circle vs drawing a bitmap vs rendering text. They will vary substantially.
In fact even rendering text can vary quite a bit depending on the size of the font and the alignment
of where the font is being rendering on the display.
The glcd v3 library code I've done is very smart, but does not use a frame buffer.
So while it must do reads for the frame buffer data
it will send the absolute minimum read/writes/commands to the glcd to perform the operation.
Depending on the operation, including when rendering text, if the pixels to be rendered on the display
align properly, then no reads will be done and full bytes will be written back to back to back.
All the other libraries I've seen will do many more commands and read/write operations
to get the same thing done.
Some additional details an what you are trying to do would be helpful.
What are you trying to debug?
If you have access to the host, there are much easier ways to track data/command sequencing.
And what you can do will vary depending if you are going to only sniff the glcd pins vs
sit between the host wires and the glcd pins.
--- bill