Having never used a graphics display (only text so far) is it necessary for the normal day-to-day use of a graphics LCD to be able to read back the data? I know many times on text displays in order to simplify things we just tie the RW pin to ground and only write. If I'm not writing some sort of game with sprites and I'm just using it to draw graphs or or display text and bitmaps do I ever need to read from a graphics display?
Thinking about this in terms of simplifying the wiring.
It is very necessary for the current glcd library.
- BUSY status
- preserving previous pixel data
In order to know when the glcd is ready to process another command or data operation,
the library monitors the BUSY status. The BUSY status is presented
on bit 7 of the data bus. This requires controlling the r/w line and flipping the data bus connections to the AVR around
from write to read.
The library could have blind delays instead of monitoring BUSY like most of the LiquidCrystal type
type libraries, but currently it monitors BUSY to get maximum speed out of the display.
With respect to the actual data,
the difference with a glcd is that things are at a pixel level, but the interface to the graphic ram is at a byte (sometimes 16 bit word) level.
The displays are very dumb. They only have a "write data" command vs a "or data", "xor data", or "set/clear data"
Because of this if you want to modify a single pixel you have to know the contents of the other pixels in the
glcd's memory byte/word "page" because when your write
to the display you are stomping on all the pixels in the page at once.
Now if you are modifying all 8 pixels in the page, then no read is necessary but often that is not the case.
For example, drawing a line of a single pixel width. In this case only a single pixel in the page is being modified.
The same is true if you are rendering a character that is not exactly the same size as the page size in pixels or
not being rendered on a page boundary.
For example, consider a 5x7 font on a ks0108.
The font uses 8 pixels in height (7 of data plus 1 inter character pixel below)
and the page size on a ks0108 is 8 pixels tall.
As long as the character is on a modulo 8 pixel boundary, then all pixels in the glcd page
can be stomped on with the 8 pixel font data.
However, if the character is not being rendered on a 8 pixel boundary say y pixel coordinate 5, then you must read the glcd data
to preserver the pixels above and below the rendered pixels of the character because the rendered
character is spanning two glcd pages.
In the example above 2 pixels of the font would go
in bits 6 & 7 of the upper page at y pixel coordinate 0 and 6 bits would go in bits 0-5 of the lower page at y pixel coordinate 8.
Bits/pixels 0-5 of the upper page and bits/pixels 6 & 7 of the lower page must be preserved.
In order to do that, the data has to be read from somewhere.
It can either be read from a local cache or from the glcd directly.
By default the glcd library reads the data from the glcd to save ram use.