Writing to a standard 20x2 lcd: How fast can it display ?

[scottc]

Hi guys, I have a general question on the standard 20X2 lcd display
modules that use the Hitachi hd44780 chipset running in 4bit mode.

Currently I can do a complete write to my display in about 1.3ms.
Thats the time the Logic Analyzer displays for putting text etc onto
the actual display, "complete write"

I am wondering if I configure the display for 8bit mode will I gain
anything on the 1.3ms write speed ?

My reason for asking is that I have a rotary encoder routine that updates
a variable that gets displayed on the LCD. If I spin the encoder really
fast, faster than a end user would twist the encoder shaft I drop counts.

The actual encoder routine is not dropping counts. The display just can't
keep up with the changing variable as its changing pretty darn quick.
I tested the encoder routine by writing a H_L sequence out to a pin.
and its not missing counts.

The Processor is a 18f2331 running at 8Mhz, The encoder routine and the
display routine are not using any interrupts.

I am trying to make my routine's a little more robust to give the end user
a better experience with the rotary encoder interface. The road block
is Display.

Any ideas or workarounds most welcome.

Thanks Scott

[andrewg]

8bit mode will be faster, probably around twice as fast. However, it sounds to me like your encoder routine *is* dropping counts. If it wasn't, then when the encoder input slowed down (as it eventually must), your display routine would catch up and display the correct count.

It sounds like your display routine is holding off the encoder routine to the point where the encoder routine is missing signal changes.

You don't say if you check the encoder inputs while updating the display, but that's what I'd recommend first. Check the encoder inputs after every 4-bit transfer. That is, every couple of dozen microseconds. If that doesn't fix the problem, then changing to 8-bit mode won't achieve anything (as you're already checking the encoder inputs as fast as practical).
_________________
Andrew

[scottc]

Andrew, I don't check the encoder per-se but I do, a write to the display
each time the encoder increments or decrements the count variable
"Value".

Here is a sample of the routine to clarify. Can this approach be improved ?

Thanks Scott

[andrewg]

What I'd try is remove Display_Stuff from Rotary_Encoder. If Rotary_Encoder alters value, it should set a flag.

Then, your main line should call Rotary_Encoder, and if the flag is set, clear the flag, save the current value and call Display_Stuff to display the saved value.

Display_Stuff should itself be updated to call Rotary_Encoder more frequently, eg every 4-bit transfer. If the value changes during the display, the flag will be set when it returns to the main loop.

BTW, you don't seem to be using the QEI built into the '2331 to handle the encoder?
_________________
Andrew

[Ttelmah]

There are multiple parts to this:
1) How fast can data be transferred to the normal display memory.
2) How fast can _commands_ execute.
3) How fast can the display update.

Now, the first will be faster using 8bit mode, but not by a lot. The normal figure for the Hitachi controller, is that a single character write takes 46uSec. Even using 4bit mode, the CPU could transfer the data in perhaps 1/4 this time, so the change will not be at all large.
The second is potentially the first 'killer'. If you use something like a 'clear screen' command, this takes typically something between 1.5, and 2mSec to complete. An age. Simple 'goto' commands are reasonable, taking only about the same time as a normal character write.
The last prevents you from updating data on the display, and seeing it, at any great speed. There are two parts to this. The 'response time' of the display, and how fast it is actually scanned. Think of it like the old TV's, where frames were only updated every so often. You can write to the memory at a high speed, but the character shown, won't change till the next scan. Even then the display pixels take time to turn on/off, so if the update was 'every frame', you would probably not be able to read the result...
The response time depends on the LCD technology involved, but is typically quite slow on these text displays (10's of mSec), and the scan rate is typically something around 100KHz per column, giving a complete redraw in perhaps 1mSec, so it is the response time that really matters in this regard. This is usually slow enough, that you won't actually 'see' a character that updates more than perhaps 5 or 6 times/second.

The comments about "don't have LCD routines in the encoder handler", are dead right. You just have not got time to do this.

Ages ago, I did a system that needed rapid display 'reflection' of a fast internal counter, but was doing a lot of work on other things at the same time. The 'solution', was to approach things from the other end. I ran a timer interrupt at a high rate (200Hz), buffered the display data, and in each timer interrupt transferred just one character using 8bit LCD operations, with no waiting at all. The key was that the slowest operation on the LCD involved, still took slightly less time that the interval between interrupts. Hence I never had to check if the LCD was busy, but the interrupt routine, could just output the byte, strobe the LCD, and return immediately. This allowed the main operations to continue without problems, and the display updated as fast as it could.

Best Wishes

[Ken Johnson]

Just a little more . . .

Yes, read the encoder as fast as required (sounds like you are).

But, update the display at a rate that is comfortable to the human observer. That is probably no more than a few times a second - maybe only 1 or 2. If you display different counts at, say, 10 times a second, can you read it?

I usually update a text display no more often than about .8 second intervals.

Good luck,
Ken

[sturnfie]

[scottc]

Thanks for your response guys,

A little history, Although I am using a PIC18F2331 Part I am not using
the dedicated QEI hardware that the chip provides as of yet. I had
a couple of reasons not to use it but in ver 4.110 of compiler there
are no defines for the qei in the 18f2331.h file. I dont have a working
example of using the QEI either so this would be a bit of an up hill
battle at the moment. I bet the qei would work real well but im not there yet

The other reason is I wanted to generate some very generic routines that could be used on pretty much any pic. This way I could use the el-chepo mechanical rotary encoders on any projects that they might be needed on.

The encoder is the 3 pin type with a built in momentry push switch. the
encoder has 20 indents per one complete full turn of the shaft.

I wanted also to keep away from running a hardware ISR for the encoder
pins as this reduces the flexibility of what pins could be used. A timer
based ISR would be ok I guess.

I modified the code to get the call to the display out of the encoder
routine, It appears to work ok. Not sure if this is the best way to implement a changed flag or not.

Here is a snip.

Void Rotary_Encoder(void)
{
Enc_A = (port_c & 0b11000000);

if(Enc_A != Enc_B) {
if (bit_test(Enc_A,7)) {
if (!bit_test(Enc_B,7)) {
changed=true; //added flag
if (bit_test(Enc_A,7) == bit_test(Enc_B,6))
{
value++; //Increment Value
}
else
{
value--; //Decrement Value
}
}
}
}
Enc_B = Enc_A; // save state to complete routine.
Display_Stuff(); // call display function
}

I call this routine from main like this.

void main(void)
{
value=87; //Inital turn on value for display

while (true)
{
rotary_encoder();

if (changed == true) {

display_stuff();

changed=false;
}


}

}
--------------------------------------------------------------------------------
I can spin the shaft on the encoder pretty darn quick and it appears
that the display updates fairly well. If anyone could help clarify the
method on the changed flag I have implemented is ok that would be a big
help

Thanks Scott

[sturnfie]

[scottc]

ah good catch sturnfie, I neglected to update the snip I posted, here is
what was used.

[andrewg]

The DELAY_MS in Rotary_Encoder should not be there! That will be causing the same problems as calling Display_Stuff was in the first place.

Also, Display_Stuff should also be calling Rotary_Encoder as often as possible. In case that updates the changed flag, you should set the changed flag to false before calling Display_Stuff.
_________________
Andrew

[scottc]

Andrew, I posted the wrong snip, I had the delay in there as a test.
I updated the privious post to reflect the change.

I will add the changed flag to the display_stuff routine and also call the encoder routine from there to see how that goes.

Hopefully I can post the correct compiled snip next time

Thanks for the help

Scott

[scottc]

Ok, I made the following changes.

[andrewg]

Try calling Rotary_Encoder from Write_LCD. Really, from whatever your lowest-level LCD function happens to be.

Also, the order of setting changed to false first is important on the chance that the encoder moves while in display_stuff and stops. The display won't update to the correct value until it moves again.
_________________
Andrew

[scottc]

Hummm, interesting ideas Andrew worth a shot IMHO.

You know if I was using the display in 8bit mode I could use the Busy
Flag to call the encoder after each write was complete and the display
was ready. I might for the hell of it see how 8bit mode does with this.
It would be interesting to see.

As a matter of interest, do you think I might pick up any speed if I used
the qei module instead of just using standard pins for the encoder. I am
curious to know if there are any advantages to using the hardware based
qei in the 18f chips.

Thanks Scott