No problem, just a question (LCD: 4 bit v. 8 bit)

So any speed gain going from 8-bit to 4-bit makes no practical gain for human eyes.

Makes sense... but why would virtually all display manufacturers waste so much effort to implement something that has so little payoff?

Makes sense... but why would virtually all display manufacturers waste so much effort to implement something that has so little payoff?

Because it was designed several decades ago when devices such as this were attached directly to the data bus of a microprocessor. The 4-bit mode was required since early microprocessors, such as the 4004 had only a 4-bit data bus. The 8-bit mode was available since the latest (at that time) microprocessors, such as the 8008, had an 8-bit data bus.

Don

why would virtually all display manufacturers waste so much effort to implement something that has so little payoff?

For HD44780-like displays, it was due to compatibility with the original HD44780. I think they offered 4-bit back then was for wiring simplicity / reduce pin count.

Newer graphics LCDs have a diverse set of transmission arrangement, from serial to 14/16/18/24/32 bit parallel modes.

14/16/18/24/32 bit parallel modes.

The issue there is fresh rates when large amount of data, pixel + color, needs to be transmitted quickly.

Now to address some of the previous answers.

What would the other 4 pins get me?

To give a meaningful answer, it is most likely necessary to know what specific LCD you are using.

Most of the time I would agree with you, but not in this case. Since he is talking about "(LCD: 4 bit v. 8 bit)" he obviously is referring to the character mode LCDs driven by an HD44780 compatible controller. He verified this when he responded in reply #2. The answer is the same for all of them.

The display starts up in 4-bit mode. It uses 4 wires to communicate.

No and yes. The device actually starts up in 8-bit mode. Since it may actually be hooked up in a 4-bit system the first few instructions in the initialization sequence, the ones that are used to switch it out of the 8-bit mode if that is necessary, only require the use the of the upper four bits - the lower four bits are ignored even if they are hooked up.

You do cut down the transmission time considerably in 8-bit mode: rather than presenting your data once in 8 bits, you now have to represent your data twice in 4 bits. That does speed up the time.

That is true, but it may not help things in the long run. Lets do the math:

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

The instructions used to perform the tasks of manipulating the data and pulsing the enable line each take some small multiple of 62.5nS. The time it takes to do these instructions in either mode is much less than the time that you have to wait until the LCD controller is ready for the next byte of data.

So, if you are simply sending a string of characters to the LCD it really doesn't matter which mode you use. There are at least two ways you can speed things up: (1) by testing the busy flag to avoid having to wait the full 40 uS and (2) by doing something else while waiting for the 40 uS to elapse or for the busy flag to expire.

If you use either of these methods it may be possible to make the 8-bit interface perform better than the 4-bit interface, but don't forget to make sure not to get it too fast since you cannot pulse the enable bit more often than every 500nS.

Don

Generally agreed with your assessment.

pulsing the enable line each take some small multiple of 67.5nS.

Not sure where that number comes from. But if you just eyeball the datasheet, you need a minimum of 540ns to transmit one data (4-bit or 8-bit), plus 1 flag checking (that time depends on the particular data / commands).

So to transmit a byte in 4-bit, you need 1us + flag check, and in 8-bit 0.5us + flag checking.

Either way, that difference isn't vital as the bottleneck is somewhere else.

dhenry:

pulsing the enable line each take some small multiple of 67.5nS.

Not sure where that number comes from.

If you divide one by sixteen million,

floresta:

The display starts up in 4-bit mode. It uses 4 wires to communicate.

No and yes. The device actually starts up in 8-bit mode. Since it may actually be hooked up in a 4-bit system the first few instructions in the initialization sequence, the ones that are used to switch it out of the 8-bit mode if that is necessary, only require the use the of the upper four bits - the lower four bits are ignored even if they are hooked up.

Thanks for pointing that out. I did read the spec sheet a while back and that was in it.

So, the short answer to the question is, "Double the bandwidth, with a theoretical and highly arguable increase in actual speed performance."?

No extra character sets? No 8-bit-only commands? etc?
It won't fetch me a beer if I hook up four more wires?

That pretty well wraps it up.

Virtually all of the other manufacturers over the years have duplicated not only the operation of the HD44780 but also the data sheet, right down to the same unique version of the English language, and the same errors and omissions. I guess that at least some of these are licensed copies but I would guess that some of the later versions are pure counterfeits as well.

To my knowledge only New Haven Displays has made any additions to the instruction set while keeping the basic device largely, but not totally, compatible with the HD44780.

Don

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.

Don

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.

ChuckJaxFL:
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:
https://bitbucket.org/fmalpartida/new-liquidcrystal/overview
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.

Don

floresta:
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.

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.