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

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?

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?

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

One like this. Just a plain old HD44780 type LCD.

http://www.ebay.com/itm/1PCS-IIC-I2C-2004-LCD-module-yellow-Screen-Arduino-/261085900352?_trksid=p5197.m1992&_trkparms=aid%3D111000%26algo%3DREC.CURRENT%26ao%3D1%26asc%3D14%26meid%3D2461681809550052500%26pid%3D100015%26prg%3D1006%26rk%3D1%26sd%3D160872423721%26

If you are referring to a character display, the extra 4 bits won't give you much performance boost. The display starts up in 4-bit mode. It uses 4 wires to communicate. If you let it use 8 wires, it may sound like it will communicate faster, but I've heard experts here say there's no apparent improvement in speed. You can think of the 4 bit as 4 pipes and 8 bit as 8 pipes. You can transfer water with one pipe if you want.

The display starts up in 4-bit mode.

Which display is "The display"?

If you let it use 8 wires, it may sound like it will communicate faster, but I've heard experts here say there's no apparent improvement in speed.

Those "experts" are both right and wrong.

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.

However, transmission time really isn't the bottleneck here. LCD (the display, not the electronics) is slow. As such, it usually like a few ms to update the actual image - much much slower than your data transmission time - you can easily send 16 bytes of data in 1ms in 4-bit mode.

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

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