I was/am reading from the LCDM. (polling the busy flag)
My advice would be don't do that. Apart from the extra complication in code you also need to switch the PIC data pins from outputs to inputs etc, which is another chance of things going bad if your code has issues.
Regarding the transition times for the LCD E pin etc, just driving it from a PIC output should work fine, there's no need for special driving circuitry.
All of the lines on an LCD are normally inputs unless you want to read from the LCD memory.
Mr RB said:Re max speed, I think you may get better speed just writing to the display as you don't need a read operation, and writing chars to the display is very fast. I think it is only the setaddress command than needs a delay? And even that delay can be fine tuned by testing to be "enough" delay without any read overhead.
Mr RB said:I also think using read mode on a 2x20 display to save 40 PIC RAM bytes seems like false economy, but again that's just my opinion and I don't know how much RAM you have or how precious it is.
Anyway I don't use LCD read mode so I'll shut up on the subject. Some people here were in the habit of using read mode on Hitachi text LCDs (was it Pommie?) so they might have some real experience to offer on the matter.
In this thread (see posts #4 and 10) Pommie gives his justification for reads when doing graphics. I am not sure the same reasons would apply equally to a 2X20 character display.
8-bit Initialization:
/**********************************************************/
void command(char i)
{
P1 = i; //put data on output Port
D_I =0; //D/I=LOW : send instruction
R_W =0; //R/W=LOW : Write
E = 1;
Delay(1); //enable pulse width >= 300ns
E = 0; //Clock enable: falling edge
}
/**********************************************************/
void write(char i)
{
P1 = i; //put data on output Port
D_I =1; //D/I=LOW : send data
R_W =0; //R/W=LOW : Write
E = 1;
Delay(1); //enable pulse width >= 300ns
E = 0; //Clock enable: falling edge
}
/**********************************************************/
void init()
{
E = 0;
Delay(100); //Wait >15 msec after power is applied
command(0x30); //command 0x30 = Wake up
Delay(30); //must wait 5ms, busy flag not available
command(0x30); //command 0x30 = Wake up #2
Delay(10); //must wait 160us, busy flag not available
command(0x30); //command 0x30 = Wake up #3
Delay(10); //must wait 160us, busy flag not available
command(0x38); //Function set: 8-bit/2-line
command(0x10); //Set cursor
command(0x0c); //Display ON; Cursor ON
command(0x06); //Entry mode set
}
/**********************************************************/
... see if you can spot the mistake.
...
...
Code:8-bit Initialization:It's insignificant stuff, honestly I'm just being petty. And it's not like I'm perfect with code either, so I probably shouldn't complain. But c-mon, this is supposed to be production grade. ...[/QUOTE] You'll get used to that. After doing this for enough years you soon get used to the idea that you are better than the "professionals" and you will likely be right. ;) One of the older guys here (or on another forum?) worked for NationalSemi and said they used to throw together application circuits for the datasheets almost like it was a joke, to get the boss off their back and finish the datasheets. Then for 30 years people assume that is the "correct" way to use that IC in a circuit. :D
Mr RB said:One of the older guys here (or on another forum?) worked for NationalSemi and said they used to throw together application circuits for the datasheets almost like it was a joke, to get the boss off their back and finish the datasheets. Then for 30 years people assume that is the "correct" way to use that IC in a circuit.
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?