Understanding Timing Table

[drkidd22]

I need some help trying to understand the timing table for the SED1330:

Here are the riming characteristics.

 

[crutschow]

And your question is?

 

[drkidd22]

I just basically need help understanding the table, explained.

 

[bychon]

The table IS the answers. Each parameter is being defined by the drawings as time between .8 volt points and 2.2 volt points.

 

[crutschow]

The table and diagram show the timing relationship between the various signals and the Min. or Max. limits on their timing. You must meet those requirements when you interface other circuits to the IC. Violation of any of the timing requirements may cause the circuit or the interface circuits to not operate correctly.

 

[drkidd22]

The table and diagram show the timing relationship between the various signals and the limits on their timing. You must meet those requirements when you interface other circuits to the IC. Violation of any of the timing requirements may cause the circuit or the interface circuits to not operate correctly.

Yes, that is exactly my problem. I think I have some timing issues within my code and that's why I need some help with it. I've never programed this type of LCD and it puzzles me out.

Below is the code I use to write to the controller showing the delay I have in place. But after running for a while the display goes completely blank and have to reset the uC to start over. It all runs in a while loop display two line.

void lcdSendCommand(unsigned  char command )
{
_DATA  = command;
RD = 1;
A0 = 1;
CS = 0;
WR = 0;
Delay1TCY();          //180ns Delay (Nop;)
CS = 1;
WR = 1;
A0 = 0;
}

/*********************************************************/
/* send Data to Controller                               */
/*********************************************************/
void lcdSendData(unsigned char value )
{
_DATA    = value;
    A0 = 0;
    RD = 1;
    CS = 0;
    WR = 0;
Delay1TCY();              //180ns Delay (Nop;)
    CS = 1;
    WR = 1;
}

 

[crutschow]

If it works for awhile and then stops, it would seem more likely you have a software problem rather than a timing problem. Do you have an oscilloscope to observe the timing waveforms?

 

[Mikebits]

Could be marginal timing problems due to software. I think you may be violating the address setup time to read write assertions. You may try asserting address and then assert rd/wr. Just a guess.

 

[BrownOut]

All of the signals you will be generating are MINIMUM times required. You can make sure you have no timing hazzards by slowing the signal generation waaaaaaaayyyy down! There are only two MAXIMUM sigs, and they both relate to signals generated by the device. Put lots of delays in your code and see what happens. Being it's an LCD, there is no reason to push the limits. Keep the timing relationships in mind, however. For example, make sure Address, Write Data and CE are held past WR(BAR) deassertion (rising edge)

PS: in the timing diagram, the signals are are a single line going up and down are single bit signals
The ones that look like two lines crossing are busses or bussed signals.
The ones with a single line that splits into two lines are "tristate" busses.

 

[drkidd22]

Yes I have an oscilloscope and will take a look at the signals with it tomorrow.

The longer the Delay is at the start of the never ending while loop the longer it takes the LCD to get messed up, but I don't want to wait so long since some times lines of text are not displayed complete, so it can take like 2 seconds to see the complete sentence which is not that great I think.

 

[Mikebits]

Well, try to assert signals in order as shown in the timing diagram. From your code it looks as though many signals are all asserted at once, not a code expert so not sure, but take care in ensuring you meet the min timing as described in diagram.

Writes are most important, verify the addr and CS assert low first followed by write strobe going low, data should then be made valid followed by write going high.

 

[BrownOut]

Your 180ns delay isn't near long enough. The minimum puls width for WR is 220ns. Call Delay1 at least four times for each transaction. You also need a delay between WR and CS. Right now, you're toggling both at the same time. Also, if you call the function too quickly, you violate min cycle time. Again, calling Delay1 multiple times each transaction will clear that up.

 

[drkidd22]

Fixed the issue. It turns out that I was sending data to the controller prior to letting the controller know what type of data I was going to send. If it was a command byte or data to be displayed. So I went through the data sheet again and control commands are low byte and data command high byte. Here is how I changed the sequence and it worked out good. Scope signals are also pretty good.

void lcdSendCommand(unsigned  char command )
{

    GLCD_RD = 1;
    GLCD_COMMAND = 1;
    GLCD_CS = 0;
    GLCD_WR = 0;
    GLCD_DATA  = command;
Delay1TCY();
    GLCD_CS = 1;
    GLCD_WR = 1;
    GLCD_COMMAND = 0;
}

/*********************************************************/
/* send Data to Controller                               */
/*********************************************************/

void lcdSendData(unsigned char value )
{ 
    GLCD_RD = 1;
    GLCD_COMMAND = 0;
    GLCD_CS = 0;
    GLCD_WR = 0;
    GLCD_DATA    = value;
Delay1TCY();
    GLCD_CS = 1;
    GLCD_WR = 1;
}

Thanks to all for your help!

 

[drkidd22]

Your 180ns delay isn't near long enough. The minimum puls width for WR is 220ns. Call Delay1 at least four times for each transaction. You also need a delay between WR and CS. Right now, you're toggling both at the same time. Also, if you call the function too quickly, you violate min cycle time. Again, calling Delay1 multiple times each transaction will clear that up.

That's why I don't have WR right after the data sent to the controller. since an instruction cycle is 180ns my WR strobe is more really like 360ns. After you explained to me the table I posted I kinda got a light bulb go on in my brain.

Thanks!