Go Down

Topic: No problem, just a question (LCD: 4 bit v. 8 bit) (Read 15584 times) previous topic - next topic


More complicated than that. Newer devices tend to be much faster than the Hitachi device. Some can be initialized by the standard HD44780 sequence or their own initialization sequence.

JHD1602 is one such example.


More complicated than that.

I really don't see how a newer device that runs a bit faster but uses the same instruction set makes things more complicated.  If you want your program to work with a wide range of devices, older and slow as well as newer and less slow, you just write to the lowest common denominator.

Some can be initialized by the standard HD44780 sequence or their own initialization sequence.

Be careful about devices that have what looks like their own initialization sequence.  Other than the New Haven Displays (which do not fit in the category of controllers that I am discussing) I tend to think that many of these 'unique' initialization schemes could very well be due to incorrect editing of the Hitachi datasheet that they were copying.

I am pretty sure that you will find that all of the devices that have the same instruction set as the HD44780 can be properly initialized by an program that correctly follows the 'Initialization by Instruction' flowcharts in the Hitachi datasheet.  Your statement does not contradict this - I just want to emphasize it because, unfortunately, I have found very few examples of such programming in my experience.  That would include every version of the LiquidCrystal library that I have seen so far.

JHD1602 is one such example.

I did a quick search for JHD1602 and the ones that I found were distributed primarily by Chinese wholesalers and no two search hits seemed to reference the same device.   I initially thought that this could be be because they are different varieties of essentially the same board just with different displays until I saw that different controllers were specified as well.  I didn't find any datasheets yet or follow up on the various controllers mentioned so I don't know about their recommended initialization sequence.

For reasons that you and I have expressed before there is no practical reason to try to speed up a program, especially one using the Arduino IDE, by tinkering with the LCD timing or by skimping on the initialization sequence which only runs once.



It won't fetch me a beer if I hook up four more wires?

That would have been nice though.


For reasons that you and I have expressed before ...

I don't question that you did but if I did express that view, I must have done it under the influence of Ambien. What I did express, as I recall, is that there are theoretical but practically immaterial speed gain going from 4-bit to 8-bit.

Many of the newer LCDs for example can work with the EN pulse between 100ns - 200ns. And they boot up almost instantaneously (can be initialized in a matter of ms). Code calibrated on those LCDs would not work on a regular HD44780.


I've been using the 4 bit configuration to connect my LCD, and it has performed as expected.

What could I do if I connect it in 8 bit configuration that I can't do now?  What would the other 4 pins get me?

Assuming you are using the shipped LiquidCrystal library,
not much other than 4 less digital pins to use.
Given that the Arduino digitalWrite() routines are so slow and the shipping LiquidCrystal
library has much longer delays in certain places than are necessary, there will only be a very small amount
of gain.
The gain will be mainly due to the library unnecessarily delaying between nibbles that will no longer be done.

Much bigger gains can be achieved by eliminating the unnecessary delays than by going to 8 bit mode
with the existing LiquidCrystal library.
Going to raw port i/o vs using the Arduino core code digitalWrite() functions  can help speed things
up even more. (Raw port i/o is about 75x faster than digitalWrite() )

If you want to play around with an optimized library switch to this LiquidCrystal replacement library:
This library supports multiple interfaces and also supports backlight control)
In 4 bit mode and not using raw port i/o, it is close to 3.5x faster than the Arduino supplied LiquidCrystal library.
Run the included LCDiSpeed sketch to see the speed of the interface.
(It works on the original as well as the replacement library)
You will have to slightly modify the sketch to select your interface (LCDIF_4BIT in your case)
and then fix the 4BIT lcd constructor to match the pins you are using.
It is a great sketch to demonstrate the speed of the interface and very useful for comparing
the speed of different interfaces.
It will display the speed information on the LCD display.

--- bill


Sorry for threadsurrecting, but it seems better than starting a new thread since this one has lots of valuable information, and one of the first places my search brought me.

I'm using an HD4478 compatable 20x4 character display in a project. Curious as to how fast the code was running, I have pin 13 flip between HIGH and LOW every time I run through the loop. With an oscilloscope on that pin, I can see how fast the code runs due to the frequency of the square wave, and I an also see the obvious stall when I call for the LCD to refresh (once a second).

So, in regards to that code stall during the LCD communication, writing to the display with 4 bits takes just over a millisecond. Writing with 8 bits reduced the time to about 670 microseconds.

So, nearly twice as fast to write with 8 bits, but whether or not that's important I guess depends on the application.

Just thought I'd share if someone was interested.


So, nearly twice as fast to write with 8 bits, but whether or not that's important I guess depends on the application.

That is because of a 'feature' of the LiquidCrystal library that Bill mentioned in the previous post.  The LiquidCrystal library includes an unnecessary delay between the transmission of the two nibbles in the 4-bit mode that almost doubles the time it takes to transmit a byte of data to the LCD.  A  library without this 'feature' would give you much closer times for the two modes of operation.



8-bit mode:
put the data in a register
output the data
pulse the enable line
wait until the controller is ready for the next byte of information

4-bit mode:
put the data in a register
output the upper four bits of datadata
pulse the enable line
(IMPORTANT: no delay is needed here)
shift or otherwise manipulate the data
output the data
pulse the enable line
wait until the controller is ready for the next byte of information

Damn it, I should've known... But this wasn't very clear from the datasheet, I assumed that a delay was needed after each 4-bit nibble in 4-bit mode. I've been working on a 2x595 SR 8-bit mode design to get the fastest possible times, and I thought that the gain in performance would be almost two-fold, but apparently it'll only be around 5us. That's not worth the extra trouble I've put into this project. But oh well.

I've just put together a quick test with direct port manipulation and just C, no libraries. I used the busy flag to make sure the LCD has finished processing the previous data\command instead of just adding a delay. On a 12MHz Atmega328 it seems to average at 41.6875us per byte sent using 4 bits and 35.75us per byte using 8-bits.


Aug 29, 2013, 05:44 pm Last Edit: Aug 29, 2013, 05:52 pm by TheCoolest Reason: 1
After some careful examination, the post above is wrong.
Here's the code I wrote (quick and dirty, please don't kill me).
Both interfaces are just as fast, the 8-bit is 0-30us faster per 80 chars.

*Edited* A small change in the code seems to have given the speed advantage back to 8bit mode, but really, they are pretty much identical.

Go Up

Please enter a valid email to subscribe

Confirm your email address

We need to confirm your email address.
To complete the subscription, please click the link in the email we just sent you.

Thank you for subscribing!

via Egeo 16
Torino, 10131