The delays are used as a simple way to make sure the pulse widths of the control signals are wide enough to meet the timing spec. There is no simple way, in Windoze, to make microsecond long pulses. It takes a lot of messy code, using the high speed performance counter functions. Otherwise, the timing granularity is only at the millisecond level, which is about a 1000 times longer than the display requires.
Here is some extracted code from the Wintest source file:
Code:
//Reset is an R-C in the hardware.
//R/W is set permanently low in the hardware (write-only)
//These things prety much initialize themselves
//Idle E
CLR_E;
//Talk to the control register.
CLR_RS;
//Talk to both controllers
CLR_CS1;
CLR_CS2;
//Display on
DATA(0x3F);
SET_E;
CLR_E;
Sleep(10);
//Set Start Line 0
DATA(0xC0);
SET_E;
CLR_E;
Sleep(10);
int
row;
for(row=0;row<=7;row++)
{
//Set X address
DATA(0xB8|row);
SET_E;
CLR_E;
Sleep(1);
//Set Y address 0
DATA(0x40);
SET_E;
CLR_E;
Sleep(1);
//Aim at the data register.
SET_RS;
//Talk to controller 1 only
SET_CS1;
int
col;
for(col=0;col<=63;col++)
{
FDATA(cfag12864b[row][col]);
SET_E;
Sleep(1);
CLR_E;
Sleep(1);
}
//Talk to the controller 2
CLR_CS1;
SET_CS2;
for(col=64;col<=127;col++)
{
FDATA(cfag12864b[row][col]);
SET_E;
Sleep(1);
CLR_E;
Sleep(1);
}
Where ever you see the "Sleep(1)" and "Sleep(10)" statements, those are 1 and 10 millisecond delays, which is waaaay longer than necessary. The best way to make things go faster is to test the controller's busy flag, to see when its ready for the next command. But with a PC's parallel port, it is not trivial to change the data bus direction to read the data from the controller. So delays are used. The delays might only need to be 10's of microseconds, but as mentioned above, there is no easy way to do this in Windoze.
