The best display would be one that supported a scroll for a window portion of the display right in the hardware!!

Now with that said, I can point out that some gLCD controllers have a feature wherein the start row and/or column of pixels can be changed simply by writing a new value to an internal register in the controller. The best of these schemes can be used to scroll a display but often they do not work well through the wrap zone where the scroll has to go back to the starting state. Another problem with this scheme is that the whole display is scrolled including any "text" fields that you may have tried to place on the screen in a separate zone from the graphic waveform.

As much as I dislike the T6963C it does have a mode that could be of help to you. If you can stand to use its internal character generator mode with crappy font format you could use that mode to produce your text fields. The T6963C then has a mode where the graphics part of the display can come as a separate display plane in the controller memory. Then using the register that controls the "start of graphics" display area it should be possible to work out a graphics scroll with a static text mode. (But remember that you lose the ability to "have any font anywhere" if you try to use this scheme).

The scanning cursor scheme that I described on the previous page is used in products because it permits the fastest screen update on standard hardware!! If you try to refresh a 240 column display to present a whole width update of the pixels your update rate is strictly limited by how fast you can write the 240 columns of data to the display. On the other hand the scanning cursor method requires that only three columns be written per update. This results in a net increase in speed of 240/3=80 times faster!!

On medical products it is common to use the sweeping cursor because since the display is meant to simulate a strip chart recorder there almost invaribly needs to be a user adjustable chart speed control of say 25 mm/sec, 12.5 mm/sec or 6.25 mm/sec. With the fast update rate allowed via the sweeping cursor method it is possible to use a timer interrupt to trigger the display update speed to simulate the various "chart speeds".

If you elect to implement the sweeping cursor method I would suggest that you find a display controller that has its display memory organized so that the bits in each byte are vertical in line with the same orientation as the cursor bar. This permits display updates simply by writing bytes and no need to read/modify/write in order to merge new data with existing. Unfortunately the crappy T6963C controller typically aligns its bytes horizontally so that it is at right angles to the direction of the sweeping cursor.

Frankly I would only use a display with a T6963C controller in situations where I used the scheme to buffer the whole display content in XRAM and then utilize a burst write mode to output the whole buffer out to the display at once. This offers the fastest display update becasue you can take full advantage of the "auto-increment" of the display memory pointer inside the controller.

With any display controller wherein the screen update requires the new data to be merged into the existing display bytes the auto-increment of the display memory pointer becomes useless. As such you find that you must command the new address for each update byte on top of the fact that the merge requires a read-modify-write operation. This is why that method of update is 5 to 6 times slower than a bulk memory buffer copy to the display.

Another thing to keep in mind is that more and more gLCDs are being made with just the serial mode interface implemented. This is especially true of the COG type displays with flex strip connections. The serial inteface permits a much narrower strip than the parallel interface. These connect and can use the onboard SPI hardware on the microcontroller for fastest shift speeds. On all of the displays that I have used with serial interfaces however the access to the controller is write-only. As such it is essential that you implement the system with an XRAM buffer to hold a whole screen image. Note that the SiLabs C8051F126 parts that I use have on-board XRAM of 8K bytes. This turns out to be an excellent match to buffer small monochrome graphics displays. A 240x128 display for instance requires a 3840 byte buffer.


Michael Karas