Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

KS0108 GLCD Busy & Reads

Status
Not open for further replies.

jpanhalt

Well-Known Member
Most Helpful Member
My adventures with the NHD-12864MZ (KS0108, 64X128) GLCD have progressed to the point that I actually have characters on the screen. These questions are for mostly refinement. If you can point me to any place in an application note or datasheet where they are answered, I will happily do the reading.

Setting CS1/CS2

Many example programs include instructions and/or macros for setting both CS1 and CS2 active or inactive simultaneously. In what circumstances is that useful? For example, if both are active and one reads the busy flag, is a valid result obtained? Is any read simply the result from each controller OR'ed?
Edit: Found answer, you can write but not read simultaneously.

Display Reads

In what circumstances must one do a display read? I realize it advances the Y-axis counter one step, but so would a write, which might be quicker as it does not require any dummy action.

Power Up Delay

After power up or reset, how long do you wait before the first instruction to the display? I have seen delays of a few milliseconds to "at least" 150 milliseconds recommended.

Thanks.
John
 
Last edited:
Hi John,

Some people will set CS1 and CS2 at the same time if they want to do the same thing on both halves of the screen. For example if you want to clear the screen, then you will set both CS pins and clear both halves at the same time. Twice as fast.

It is very unlikely that you must read from the display. It does come in handy though. Lets say you don't have a screen buffer in RAM and you want to scroll the screen across. The only way to do this would be to read the screen and write it back into a different position. In colour screen it's more useful (say) if you want to write something onto the screen transparently. You will read the pixel, modify the colour (for the transparency) and write it back.

For the power up delay, just try it. It depends on a couple of different factors (your particular screen, your power supply) but 100ms should be more than enough. You may get away with 10ms. However it's unlikely you would notice a 100ms delay at the start of your program so there is no disadvantage to having a 100ms delay.

After a reset condition, there is a definite time you will have to wait before you can issue a new command. Just found this in the datasheet:
While RSTB is low, any instruction except status read can be accepted. Reset status appears at DB4. After DB4 is low, any instruction can be accepted.
 
Last edited:
Thanks for the responses.

I was a little surprised by the power-up delay, as I could find nothing on that in the NHD datasheets or ap notes. In fact, the NHD timing diagrams show that signals can begin anywhere from 0 mS to 50 mS after power up. One even goes on to say that signal timing can be ignored as it is handled by the controllers. I have already added a 100 mS delay. It can't hurt. As for delay after reset, that is a little better described, but can also be monitored by status.

I probably won't be doing scrolling, but it is good to know that is one use for doing reads. I was afraid there might be some quirk that would require a byte to be read before re-writing.

As for writing/controlling/reading simultaneously, I had read Pommie's comments about writing simultaneously in his clear screen routine, but wasn't quite sure about the limits for doing such things. This afternoon, I stumbled on a post of his from a couple of years ago about being able to write but not read simultaneously, and it finally dawned on me what he was talking about in his WaitNotbusy routine. Late in the afternoon, I submitted a question to NHD tech service about what one might see on the busy flag when writing simultaneously.

John
 
If you want to do graphics on your Graphic LCD then reading is really useful. To set a single pixel requires a read, modify, write action.

The sequence for setting a single pixel is,
Set address of screen location,
Do Read to move data to GLCD buffer,
Read again to transfer to pic,
OR in the relevant bit,
Set address again,
Write the value back.

Have Fun,

Mike.
 
If you want to do graphics on your Graphic LCD then reading is really useful. To set a single pixel requires a read, modify, write action.

Nice, I didn't even think of what is likely the most common use of reading from the screen. I am used to either a colour screen (one pixel at a time) or having a 1KB buffer for the mono screen.

Do you know how the busy signals work when writing to both halves of the screen at the same time? Perhaps they are ORed together?
 
Thanks for the responses.

I was a little surprised by the power-up delay, as I could find nothing on that in the NHD datasheets or ap notes. In fact, the NHD timing diagrams show that signals can begin anywhere from 0 mS to 50 mS after power up. One even goes on to say that signal timing can be ignored as it is handled by the controllers. I have already added a 100 mS delay. It can't hurt. As for delay after reset, that is a little better described, but can also be monitored by status.

I put in a delay simply to make sure the power supply has stabilised before initialising the screen.
 
Last edited:
Do you know how the busy signals work when writing to both halves of the screen at the same time? Perhaps they are ORed together?

AFAIAA, they cause bus contention if both are enabled when reading. Due to this fact in my WaitNotBusy routine, if both bits are set, I check each individually.

Here is the C version,
Code:
void Wait_Not_Busy(void){
    TRISD=0xff;
    b_GLCD_RS=0;
    b_GLCD_RW=1;
    if (b_GLCD_GCS1==1 && b_GLCD_GCS2==1){
        b_GLCD_GCS1=0;
        while (GLCD_Read()&0x80);
        b_GLCD_GCS1=1;
        b_GLCD_GCS2=0;
        while (GLCD_Read()&0x80);
        b_GLCD_GCS2=1;
    }
    else{
        while (GLCD_Read()&0x80);
    }
    TRISD=0x00;
}

I do it slightly different in the asm version that is floating around.

Mike.
 
@Pommie, #4

So far, I have only done full screen writes with characters in which Y incremented automatically and have not gone for writing to specific pixels. As I understand what you are saying, it is not that one couldn't calculate what is at a specific pixel location when doing graphics, it is just simpler to go to that location and read.

I have not decided yet whether my indicator screen will include graphics or be based entirely on special characters. Right now, my thinking was leaning toward using special characters. It is a slow but evolving process. The Sears inclinometer that started all of this showed the direction of tilt as just one of 3 positions: up, level, down.

Thanks for adding your additional insight.

John
 
Pommie said:
AFAIAA, they cause bus contention if both are enabled when reading. Due to this fact in my WaitNotBusy routine, if both bits are set, I check each individually.

Aren't both controllers on the same clock? Why not check just one and then maybe add a NOP or two just be be sure both are done?

John
 
Aren't both controllers on the same clock? Why not check just one and then maybe add a NOP or two just be be sure both are done?

John

You are probably right, in that if one is finished then the other is too. You could probably write code that will work ok in most situations. However, you can guarantee that your clock will be slightly out of sync with their clock and that is where it all falls down. Your NOP may fix the situation in 9,999,999 in 10,000,000 occurancies but you can't guarantee it. AND, you don't have time to test it 10 million times.

I've always found that doing it right works, taking short cuts comes back to bite real hard. Believe me, after 25 years writing software you learn to never assume, just stick to the data sheet.

Mike.
 
Pommie said:
AND, you don't have time to test it 10 million times.

Given my age and the rate at which I am making progress, I will be lucky to test it once. Maybe it will turn out to be my FYP. ;)

BTW, I agree completely with you about making things as close to 100% reliable as practical. That is the philosophy I tried to live by when I was working. I can tell you about some pretty bad, near disasters that happened with commercial software that IT management refused to thoroughly validate before going live.

Please don't misunderstand my questions, your advice is always appreciated.

John
 
Last edited:
I wasn't being critical, just trying to point out that 20 cycles at 20Mhz is irrelevant and you shouldn't try to save them. I've done the "Save 20 cycles here cause I can" in the past and, not always but now and again, it does bite your arse. I just do things by the book now as those twenty cycles "thrown away" help me sleep comfortably.

Mike.
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top