LCD Controller Start-up Mode

[jpanhalt]

***************************************************************************************
This new thread is split from:
16X2 Character Display Fills Screen
To facilitate discussion of start-up modes without drifting the original thread.
JimB

***************************************************************************************

"as it is"

Much of this discussion seems based on initialization by instruction; however, the real question is whether the controller comes up in 8-bit mode, which can accept a special 4-bit instruction to change that mode, or whether it comes up in in a pseudo 4-bit mode that ignores the lower bits.
Page 43 of the datasheet shows sending an 8-bit code in whihc both the upper nibble and lower nibble act as control commands:

NB, that is the very first code a user can send. Now, if the user intends to use 4-bit mode, he can at that time, and probably only at that time, send a 4-bit single instruction to achieve 4-bit mode:

The highlighted content makes it clear the device "came up" in 8-bit mode and accepts 8-bit commands. That's how it is.

John

 

[Mike - K8LH]

Thank you, John.

If I understand correctly, MrAl would like proof via experiment that the LCD comes up with a fully functioning 8-bit wide interface after performing its internal power-up reset (while unable or unwilling to back up his claims in the same manner?). Fortunately, I performed one of those 'experiments' awhile back and I actually published it in the form of a demo program in the K8LH 2-Pin 74HC595 LCD "8-bit" Backpack article. That demo program relies on a fully functional 8-bit wide LCD data bus, available after the LCD internal power-up reset, to initialize the LCD. Admittedly, the "initialization by instruction" procedure would have been the preferred method to initialize a display, even when using it in 8-bit interface mode, because it would circumvent problems caused by the microcontroller or host being reset without a corresponding LCD internal power-up reset cycle, but it was expedient for that particular demo.

I found MrAl's response baffling and disturbing. Realism, huh? Gosh, that's deep (lol). I wonder if he's trying to replace Matthew McConaughey in the Lincoln commercials (lol)...

Cheerful regards, Mike

 

[alec_t]

From what I recall, the LCD start-up mode is randomly 4-bit or 8-bit; which is why the codes necessary to establish a definite mode have only 4 bits of significance and are accepted in either mode.

 

[MrAl]

Hi again,

John:
This is what i was hoping to see. So the display comes up in EITHER/OR mode, either 4 bit or 8 bit, depending on how we want to start sending data.

Mike:
Just for your information, i had been using a 1602 LCD display long before anyone ever payed me to use one! (har har har)
I had to mention realism because that is what life is about, not as much about theory and believing what we read is correct all the time without question. Theory and reading is of course a great benefit for learning and prediction, but the down to earth final way of describing things is exactly as they occur, without any added interpretation.
To give an interesting example of this, i once posed the question: What is the largest number?
Think about that for a minute, and you will find that you probably say "infinity", but is that really a number?
A number is something like, 1, 2, 5, 899, 1e23, etc. Infinity is not really a number, it is an idea.
But the real heart of the question is to try to figure out if there is such a thing as the largest number, and by doing that one way we might start as:
Well, 100 is a big number, but if we add another 100 we get 200 and that is even bigger, so 100 cant be it. But then if we add another 100 we get 300 so 200 cant be it. So we think a little more, then maybe say:
Well, if we multiply 300 times 300, we get an even bigger number, which is better than the older 300. But if we multiply that by 90000 we get a bigger number, and then think a little more, then maybe say:
Well, if we take that 90000 and raise it to the power of 90000, we get a really really big number. But if we started with a larger number to begin with, we'd get an even bigger number yet, which is again closer to what we are looking for which is the largest number possible.
Now thinking again, what if we raise that to a power equal to itself, or calculate the factorial of that? We get such a huge number it might not even be possible to write it down on paper.
But all this thinking and calculating takes time, so we have to include the possibility that after we keep thinking and improving the procedure for doing this we might only get up to a certain very large number by the end of our lifetime. Is that the biggest number then?
Well, what if we pass it on to our offspring, so they can continue the process, then they pass it on to their offspring at the end of their lifetime, then after 100 generations, is that the largest number possible?
Well, then what if we wait 100+100 generations, is that the largest possible?
But what if we wait 100*100 generations, is that the largest possible?
But then what if we wait 100^100 generations, is that the largest possible?
Then the future of the human race comes into question: just how long will the human race last in this universe?
When the last man dies calculating the largest number possible, after many many generations, then that must be the largest possible number, at least as the human race is concerned. If there really is alien life, then maybe they can take over.

So that is an illustration of realism. We fantasize about what the largest number can be, but time comes into play and other problems come up when we actually try to calculate it. Even just thinking about it takes time, and we cant even think to the end of that sequence of operations because again time comes into play which means we have a limited time to do this.

Alec:
Did you mean either/or as above or did you mean that we dont know for sure what mode it came up in (random)? I think you meant either/or, where we have the CHOICE which interface to use right from the start after the required delay after power on. If this is not correct, please elaborate.

 

[alec_t]

Alec:
Did you mean either/or as above or did you mean that we dont know for sure what mode it came up in (random)?

I meant random. I'm going by Julyan Ilett's article "How to use intelligent LCDs" in Everyday Practical Electronics, Feb 1997, where he says:
"The data sheets warn that under certain conditions the LCD module may fail to initialise properly when power is first applied. This is particularly likely if the Vdd supply does not rise to its correct operating voltage quickly enough. It is recommended that after power is applied, a command sequence of three bytes of value 0011xxxx ($3x) is sent to the module. The value $30 is probably the most convenient. This will guarantee that the module is in 8-bit mode, and properly initialised. Following this, switching to 4-bit mode (and indeed all other commands) will work reliably."

 

[MrAl]

I meant random. I'm going by Julyan Ilett's article "How to use intelligent LCDs" in Everyday Practical Electronics, Feb 1997, where he says:
"The data sheets warn that under certain conditions the LCD module may fail to initialise properly when power is first applied. This is particularly likely if the Vdd supply does not rise to its correct operating voltage quickly enough. It is recommended that after power is applied, a command sequence of three bytes of value 0011xxxx ($3x) is sent to the module. The value $30 is probably the most convenient. This will guarantee that the module is in 8-bit mode, and properly initialised. Following this, switching to 4-bit mode (and indeed all other commands) will work reliably."

Hi again Alec,

I am happy you posted this as that is quite important to know. So we have been doing it wrong all along.

This also proves that we SHOULD regard it as a realistic 4 bit mode to start with (because we have to send three 4 bit commands to do this).

Very interesting and thanks for posting.

 

[alec_t]

(because we have to send three 4 bit commands to do this).

My understanding is that you send those three 8-bit bytes (even if sent as six 4-bit nibbles). So if the LCD powers up in 8-bit mode it stays in 8-bit mode, whereas if it powers up in 4-bit mode it gets set to 8-bit mode. It can then be changed to 4-bit mode later if desired.

 

[MrAl]

My understanding is that you send those three 8-bit bytes (even if sent as six 4-bit nibbles). So if the LCD powers up in 8-bit mode it stays in 8-bit mode, whereas if it powers up in 4-bit mode it gets set to 8-bit mode. It can then be changed to 4-bit mode later if desired.

Hello again,

It can not be that way because when we ONLY HAVE FOUR WIRES connected between the microcontroller and the LCD display pins we DO NOT HAVE EIGHT BITS to work with, ONLY FOUR. So there is NO WAY we can send an 8 bit command when we PLAN to use it as a 4 bit device.
One ramification of this is that it can not start up in 8 bit mode otherwise we'd never be able to send the right initialization codes when we have only four lines connected to the display.

Also just to note, sending two groups of 4 bits in sequence is NOT the same as sending 8 bits all at once. When we send 4 bits at a time it is always a four bit mode regardless how the receiving device interprets it.

Also note that your original post had mentioned sending the code (binary) 0011xxxx and those x's means that the LCD does not look at those bits, just the first four bits, and that's all we can send anyway with only four lines connected to the LCD (when we plan to use 4 bit mode).

The reason for 4 bit mode is so that we only have to connect 4 data wires to the display. If we had to connect 8 wires just to initialize it we'd be in trouble because we'd have to use 8 data wires for each and every application and never be able to get away with using just four.

From what i understand now, sending those three nibbles is an option, and the other option is to send 5 bits which is considered 8 bits, so that would mean it can accept either 4 or 8 (which is really 5) bits at startup., however, sending 5 (or call it 8) bits means it will think you want to startup in the full 8 bit mode and at that point i think we loose the option to switch to 4.

 

[alec_t]

It can not be that way because when we ONLY HAVE FOUR WIRES connected between the microcontroller and the LCD display pins we DO NOT HAVE EIGHT BITS to work with, ONLY FOUR. So there is NO WAY we can send an 8 bit command when we PLAN to use it as a 4 bit device.

In that case, you'd be sending the four most-significant bits of what would have been an 8-bit command.

Also just to note, sending two groups of 4 bits in sequence is NOT the same as sending 8 bits all at once.

Agreed. My bad.

 

[jpanhalt]

alec_t
It is oft reported that the HD44780 comes up in an unknown state when the power-on reset is not done properly. Unfortunately, those sources simply state that as a fact and none, including Julyan Ilett, give a source for that information. In other words, maybe someone said it, and it just keeps getting repeated. It is hard to find a genuine copy of the HD44780S datasheet that the HD44780U replaced.

I did find a scanned version of the original (LCDII = HD44780S ?) datasheet in which that unknown state is described:

Source: **broken link removed** (March, 1981)

One might well interpret that in the way others have. However, "unclear" may also mean that the engineers at Hitachi hadn't been able to or hadn't tried to determine that state. Regardless of the interpretation of "unclear," a similar statement does not appear in the current datasheet. What might have been true about the HD44780/HD44780S might not apply to the HD44780U. Moreover, the current datasheet does state that the "Interface is 8 bits long" for both initializations by instruction following an improper power-on reset.

That information doesn't really change anything that has been said in this thread, except it does provide a source for the statement that at least some HD44780 versions came up in a state that was "not clear" in 1981.

In any event, we will continue to initialize by instruction as it has been done for the past 35 years.

John

 

[BobW]

Thanks for posting your code. I think I'll probably change my set of 4-bit routines to make use of the busy flag rather than relying on delays. I've never been keen on using delays. Too indefinite.

On the other hand, there's no doubt that the HD44780 is crude by today's standards, and even if we make use of the busy flag, the PIC can end up wasting a lot of time waiting for commands to execute. So, I like the idea of offloading the communications overhead to a backpack chip. And in that regard, Mike's PIC version of the backpack chip would be most efficient, because it could buffer the data from the main processor and deal with the wait loops, while the main processor can just fire off the data and then get on with the rest of its work. I have a little PIC project in the works that is somewhat time critical, and the less time it has to spend dealing with the display, the better.

BTW, I wonder if a moderator should perhaps split off the side discussion about the 'random startup state' issue. I think it's a valid topic on its own, and I have comments to make, but would rather not go off topic here.

 

[jpanhalt]

Hi Bob,

There are a few lines I am sure you caught that I added while trouble shooting: 1) Get rid of the TMR1 stuff; and 2) The temp register is not needed.

I agree, an awful lot of time is spent on printing to that display. I had hoped to get better than 19200 baud, but with those last timings, that seems to be about it. I will also be trying Mike's backpack approach.

EDIT: I think my baud calculation is off by about a factor of 10 using the pulse, rather than character definition. One ascii character every 50 usec or so is fine. Woke up a little slowly.

John

 

[MrAl]

alec_t
It is oft reported that the HD44780 comes up in an unknown state when the power-on reset is not done properly. Unfortunately, those sources simply state that as a fact and none, including Julyan Ilett, give a source for that information. In other words, maybe someone said it, and it just keeps getting repeated. It is hard to find a genuine copy of the HD44780S datasheet that the HD44780U replaced.

I did find a scanned version of the original (LCDII = HD44780S ?) datasheet in which that unknown state is described:

View attachment 95593

Source: **broken link removed** (March, 1981)

One might well interpret that in the way others have. However, "unclear" may also mean that the engineers at Hitachi hadn't been able to or hadn't tried to determine that state. Regardless of the interpretation of "unclear," a similar statement does not appear in the current datasheet. What might have been true about the HD44780/HD44780S might not apply to the HD44780U. Moreover, the current datasheet does state that the "Interface is 8 bits long" for both initializations by instruction following an improper power-on reset.

That information doesn't really change anything that has been said in this thread, except it does provide a source for the statement that at least some HD44780 versions came up in a state that was "not clear" in 1981.

In any event, we will continue to initialize by instruction as it has been done for the past 35 years.

John

Hi John,

That's very interesting, but a very strange set of statements and it's easy to see WHY.
This is because on the one hand, they state that they dont know for sure what mode it comes up in YET they also state that to be SURE we have to first send FOUR BIT commands!

Let me paraphrase...
"We dont know what mode it comes up in for sure, 4 bit or 8 bit, so we better send it three 4 bit commands so we can be sure".
That's almost laughable. If we didnt know, then we would not know if we could send 4 bit commands, but they are telling us to send 4 bit commands so it must be able to respond to 4 bit commands at startup.

With the WinTek display, there is a power on reset pin, that you can toggle with a uC pin if you like, but i have had success always with using a little resistor and capacitor network set up as a power on reset circuit. The power supply would have to come up pretty slow to stop that from resetting the LCD. In all the times i have used it, it never once failed either, probably because power supplies dont come up that slow anymore.
Maybe in the older days they did, but i think most didnt.