GLCD Instruction Timing

I am just beginning to use a GLCD, a New Haven Display NHD-12864MZ. The display uses a KS0108 chip set. My MCU is a 16F1519, and language is MPASM.

I have relied heavily on code from others to initialize the display and display characters. The most common code examples monitor the "busy" status, but one example simply ignores the matter and runs the MCU at 4 MHz. The latter example (**broken link removed** ) uses two NOP's between setting E and clearing it, but no busy check. I have been able to reproduce its results. It will display characters at 4 MHz, but not at 8 MHz.

Source: pdf page 52; thesis page 38:
However, in this thesis, the LCD controller is interfaced with the PIC via the I/O ports and also PIC is configured to operate at lower frequency (4MHz). As a result, the LCD status check is not required.

Click to expand...

In contrast, bigdogguru states here: https://www.edaboard.com/threads/239623/

Also you are using a set 10ms delay for all commands in both the LCD_ini() and LCD_data() routines, this maybe too short a delay for the initialization commands and longer than needed for the operational commands. In most LCDs the monitoring of the Busy Flag is the preferred method rather than a fixed delay when issuing operational commands.

Click to expand...

Checking the Busy Flag makes sense, if the busy time is variable and is longer than a few MCU clock cycles. What I find quite confusing is the absence of a clear description of how long in microseconds the busy flag takes to clear between operational commands and between display data writes, if different. Some authors suggest the range for operational commands is in milliseconds, but the above dissertation clearly shows it must be shorter than that.

The datasheets from Samsung and NHD show a timing diagram in which the busy flag is high for between 1 and 3 display clock cycles. That clock cycle frequency appears to be about 1 MHz, based on the clock for the enable bit that is shown. If that is the case, then the approach used in the above reference dissertation makes sense. However, far more examples can be found in which the busy time is references as "mS" and the context is such that I assume the meaning is "millisecond," not microsecond.

How are those two descriptions of the busy flag timing reconciled?

A second and related question regards reading the display before writing to it. Under what conditions must one read the display data bus/ram (not control data) for a location before writing to it? My question is not about the dummy read to set the data latches, but rather why read, if you are going to write by moving an entire byte?

Obviously, I am very new at this and apologize beforehand for such novice questions.

John

Have a look on this Tutorial

https://sites.google.com/site/coolembeddedlaboratory/home/pic18f4550/tutorial-list/graphical-lcd

jpanhalt said:

How are those two descriptions of the busy flag timing reconciled?

A second and related question regards reading the display before writing to it. Under what conditions must one read the display data bus/ram (not control data) for a location before writing to it? My question is not about the dummy read to set the data latches, but rather why read, if you are going to write by moving an entire byte?

Obviously, I am very new at this and apologize beforehand for such novice questions.

John

Click to expand...

Hi,

As you have found out, there are not many examples of glcd code in assembler.

Its a few years since I did any code for them, so am a little rusty in answering your questions precisely.

Re the busy flag, which is output on DB7, have not seen much code using this feature, think basically the glcd controller is fast enough to handle what any micro running at 4 or 8 mhz can throw at it - however not 100% sure on that point.

The Dummy Read is needed to load the Data Register / Latch prior to reading the data.
In first access, data in display data RAM is latched into output
register. In second access, MPU can read data which is latched. That is, to read the data in display data RAM, it
needs dummy read. But status read is not needed dummy read.
Think the reason you would read the data is to identify when a certain location contains certain data.
example - if the glcd data register has been written to by a subroutine, it may be easier for the main loop to check for specific data less frequently than trying to check every time the subroutine outputted its data.

Have attached 2 set of files that may contain some useful info.


Also have my own Assembler code for the 18F chips and the much newer EADOG 128x64 glcd if interested.

@wp100

Yesterday was a chores day for me, so I didn't get back to this GLCD project until this morning. Thank you for your comments.

Re: Busy flag

What I have found in assembly examples is that some programmers do ignore it and just rely on a slower processor speed or NOP's. I gave a link to an example of that approach in my original post. Others do monitor it for better reliability and flexibility in choosing processor speeds. I am inclined toward doing the latter, if things are not slowed down too much.

Here is an example of the latter. Unfortunately, the poster doesn't give his code or the MCU clock frequency, but if one calculates out for 1024 bytes, that is only 5.4 µS per byte, so his checking routine must be pretty efficient:

**broken link removed**

Poster= CF Tech (Administrator, 2006)
These displays are not particularly slow. In the AVR code I wrote (fairly optimized, and it checks the busy flag), it takes less than 5.5mS to update the entire display's memory from the corresponding image in the AVR's memory.

Click to expand...

Re: Data reads

That perspective helpful. I think using a read as simpler way to find out what is at a specific position, without going through the original calculation and table look-up for that byte, will find application in my project.

Regards, John