is probably quite true if you have any hope of doing much with your MCU other than driving this display module. Most LCD displays, including those that I have lying about that are made by SHARP, use a local controller that serializes the data. This display operates very much like a video display and requires periodic refresh to keep the "pixels" active.

What you have, that you don't have with a more-or-less "standard" text LCD module is the limitation as to what you display on the LCD. What has been given up, however, is the character generator that forms the text on the screen.

I think what Stefan means by his title remark, is that, if you have not had extensive experience with microcontrollers and with digital electronics, you may find this particular module too difficult to use.

The portion of the datasheet written in German implies that it uses asynchronous protocol to communicate with the host computer. The remainder of the document makes no mention of the asynchronous serial protocol, how it is implemented, how the data contained in the asynchronous method is interpreted, timed, or anything else related to the asynchronous serial protocol.

The remaining portion of that reference document, which is not a complete datasheet, suggests that you must create a CRT-video-style of interface, in which you'd write data to a refresh memory and, in this case, pixel-by-pixel and send it synchronously to the display as shown in those timing diagrams. I would think that an external memory, a character generator, and a bit of timing logic would serve this purpose better than an '8253.

The writing on your "datasheet" implies that you must drive the pixelated data and a backplane drive (M) to the device at a rate of one pixel every two microseconds. Your MCU can probably manage this, but I seriously doubt that it would have time or the facility to do anything else at all. Your AT89S8253 would then be a dedicated interface circuit for the LCD.

Is that what you want? Much of this task would probably best be handled with a two-ported RAM, an external CPLD to provide the logic, and a character generate (RAM or ROM) to create the pixels in the CPLD. That would then free your MCU to do other useful work.

It remains a mystery just exactly how the "asynchrous serial protocol" comes into play, as was implied by the mention of the "Z80A SIO" and serial port.

RE