HD44780-based Alphanumeric LCDs

LCD modules consisting of a display glass typically in a metal frame attached to a PCB equipped with one or more display driver ICs.

These modules are a common choice for microcontroller projects They are readily available and cheap, however a number of variations exist. 

Note that the control IC used on the module has several software-compatible near-equivalents so even if the module does not have a HD44780 on it is likely to be a compatible equivalent.

Typical display configurations

Modules with only the controller IC

• On its own the HD44780 supports 2 lines of 8 characters
• Alternatively it may be used for one line in a 5x10 character format, however this is unusual. The only display I've seen with characters taller than 8 pixels used an entirely different "graphic" controller
• Sometimes a 16 character display will be implemented as two lines of 8 characters, in order to save the cost of an additional segment driver

Modules with additional segment drivers

• Displays longer than 8 characters require one or more segment driver ICs in addition to the controller to drive the additional columns
• As standard the HD44780 supports up to 2 lines of 40 characters
• An alternative layout often seen gives 4 lines of 20 characters, its effectively the 2*40 configuration, but split so the display goes Line 1 1-20, Line 2 1-20, Line 1 21-40, Line2 21-40

Historically the HD44100R 40 pin driver would support 8 characters, meaning a full size display implemented as per the datasheet would need 5 ICs: the controller and 4 expanders. More recent designs use HD66100F or equivalent 80 pin driver so only 3 ICs are needed.

4 line 40 character modules

• This pattern is typically implemented as two HD44780 controllers and two 2-line displays sharing the same glass
• As the HD44780 lacks a "Chip Enable" pin you should expect to find two "E" pins, one to select each controller
• Typically all other inputs are common to both controllers
• This display pattern may not have a "standard" pin-out (different manufacturers use different pin-outs)
• If you have one of these modules without a datasheet then you'll probably need to "buzz through" with a continuity tester to confirm pin-out

Typical Pinout for a single controller module

A common arrangement is a single row of 14 pins or two rows of 7 pins using the odd-row, even-row pattern

• Pin 1 Ground
• Pin 2 Vcc (5v typically)
• Pin 3 Vo/bias (Ground typically, may need negative supply)
• Pin 4 RS (Register select)
• Pin 5 R/!W (Data direction, sometimes tied to ground)
• Pin 6 E (Enable, idles LOW and data is loaded on falling edge)
• Pin 7 D0 (Optional)
• Pin 8 D1 (Optional)
• Pin 9 D2 (Optional)
• Pin 10 D3 (Optional)
• Pin 11 D4 (Data in)
• Pin 12 D5 (Data in)
• Pin 13 D6 (Data in)
• Pin 14 D7 (Data in)
• Pins 15 and 16 may connect to a backlight if fitted

Timing considerations

Enable has a minimum pulse width of 250ns (e.g. a 2MHz bus clock)

RS and R/W are required to be valid before the rising edge of E

D is only required to be valid in time for falling edge of E, though in microcontroller applications it is normally output earlier.

Supply voltage considerations

If the display has a PCB and metal display bezel it is likely that the display is designed for 5V. It appears as if most Chip-on-board alphanumeric displays are 5V. Chip-on glass type displays tend to be 3.3V.

5v Vcc display operation with a 5V microcontroller

5v operation is the "default" for most modules, and on recent generations of LCD you can expect good contrast if you tie Vo to ground, though a resistor may be needed. 

One useful guideline I've seen is that if the user has the freedom to tilt the display then you may get away with fixed contrast, but if the display is in a fixed location the contrast should be adjustable. 

If you get a very faint display even with Vo grounded you may have a "extended temperature" type, these require a negative Vo. Display application data for an extended temperature type will often include a temperature-compensation circuit to automatically adjust Vo, though fixed voltage operation is also possible. 

5v Vcc display operation with a 3.3V microcontroller

The same contrast considerations apply.

When powered from 5V the inputs of the HD44780U are compatible with 3.3V logic signals. This configuration is well suited to "write-only" applications.

In configurations where it is required to read from the display it is important to note that the data pins may be driven above 3.3V so the microcontroller pins used must tolerate 5V from the display.

3.3v Vcc display operation of a 5v rated display module

If the module is intended for 5v operation then used as-is the 3.3v supply will give insufficient contrast. With Vo grounded the display text may be almost invisible. On the units I've seen if you get the light and angle right it is just about visible. 

The solution is to supply a negative contrast voltage. The key is that the contrast voltage supplied to the LCD is the difference between Vcc and Vo so if Vo is connected to -1.7v then the total contrast supply will be 5v, enough to properly operate the LCD.

Vo is a relatively high impedance input and is well suited to powering from a charge-pump, typically an ICL7660 but due to the low loading a CMOS gate charge pump may be sufficient. It may be possible to program a microcontroller pin to output a square wave which could drive a charge pump.

Example of using a 5V LCD in a 3.3V design using the minimum 4 bit write-only interface.

When using the ICL7660 on strip-board designs it may be worth removing pin 6 to enable the ground to run under the IC unbroken. This makes it easy to install a capacitor between GND and VOUT. 

Control from software

There is a choice of two connection methods, 4-bit or 8-bit, also you have the option of fixed timing or busy-polling. Most library code around tends to support 4-bit fixed timing, and it is often a good choice but not always.

4 bit mode

In 4 bit mode each byte is sent as two half-bytes, high bits first. This cuts down on the number of interface lines required. It is important to maintain synchronisation. On a successful clean power-on-reset the device will be in 8 bit mode, so initially we must send only the top half of the configuration command, then wait for completion. This will switch the display from 8 to 4 bit mode, but will latch garbage in the lower 4 bits.

Once 4 bit mode is achieved then both halves of the command may be sent in order to properly configure it.

I would advise against implementing reading from the display in 4 bit mode. While it is a supported feature my experience has been that the read function frequently  loses synchronisation, meaning the high and low parts get swapped.

8 bit mode

In 8 bit mode all 8 data lines are used. This requires more interface lines but cuts down the number of I/O operations required. This mode might be used if there is already an 8-bit-wide peripheral in a system that can share the data lines. Alternatively if you are using an I/O expander there may be a benefit to using 8 bit mode to halve the number of operations required since a typical SPI/I2C expander implementation may require 32 clocks just to pulse the E line once.

Fixed timing mode

In fixed timing mode the host microcontroller sends a command then waits a set time to allow the display to execute the command. 

Most operations are completed in 40us but the clear and home commands may take 1.6ms (these commands may be recognised as they both have the top six bits clear, so if (command and 0xfc) = 0 then wait), also it may be wise to allow 50us and 2.05ms to allow for slow displays. 

Many libraries implement this, as it is simple and works fine whether the display is connected or not. Unfortunately it can waste a lot of CPU time, particularly if the wait is implemented as a blocking delay.

Timing in more detail

It is necessary to "read between the lines" of the datasheet to properly understand the timing. The command table gives delays for a 270kHz clock frequency, and with that frequency the command delay is 37us, and the long command delay is 1.52ms.

The initialisation sequence uses delays of 4.1ms and 100us. If we assume that the delay is inversely proportional to the clock then it appears that the initialisation sequence assumes a worst case clock of 100kHz. This would seem remarkably low. I wouldn't expect a module clock to be less than 200kHz.

If timing problems are observed then remember that it is not just the short instruction delay that needs scaling up, the long delay needs scaling up too. In my experience it is allowing insufficient time for a "clear" instruction that causes the most problems. In my designs it resulted in a blank display, probably due to a cut-off command being mistaken for display-off.

A simple calculation gives the clock period as 3.7us, implying it takes 10 clock cycles to write one character. The clear delay appears to be 41 times longer, suggesting that a clear operation requires one horizontal "sweep" of the display. As a two line display has 80 characters of memory presumably it is erasing two characters at once.

Busy poll mode

In busy poll mode the driver code reads the display's busy flag to determine if it is ready. This requires more work from the microcontroller, but may be preferable in some round-robin-poll applications where if the display is busy it can be skipped and other tasks executed. 

Polling appears unreliable in 4-bit mode. This may depend on specifics of the circuit in use, but in my experience synchronisation was lost frequently, and this resulted in incorrect BUSY status.

Software initialisation sequence

This is a special way to initialise the display from an unknown state. According to datasheets this is required if the power supply rise time is too long to satisfy the display's internal power on reset. It is also preferable on development boards where the microcontroller is frequently reset without cycling the power as this kind of reset leaves the display out of step. Probably the worst case scenario is that the display is already in 4 bit mode with half a command already latched.

The initialisation sequence consists of sending the 8-bit-mode command repeatedly at set intervals to get the display into 8 bit mode. Then if 4 bit mode is desired then the top half of the 4 bit mode command can be set. The full sequence is:

• Wait 15ms after power-on.
• Send command 0011xxxx as one operation, bottom 4 bits are don't care
• Wait 4.1ms minimum* as this could take a long time: If the display had received half a command beginning "0000" then the previous operation would trigger a "return home" command which is slow.
• Send command 0011xxxx as one operation, bottom 4 bits are don't care
• Wait 100us* minimum
• For 4 bit mode Send command 0010xxxx as one operation** (bottom 4 bits are don't care)

* The datasheet assumes the worst case clock frequency of 100kHz. There isn't much to be gained by speeding up the 4.1ms delay but the 100us delay is actually just your normal write delay.

** this is a common catch, the display is still in 8 bit mode prior to this command so if you mistakenly try to send the full 8 bits as two 4-bit half-writes then the first would be interpreted as a command and the second as half of another command.

After this last operation the busy flag will be valid and the display should return to normal execution times. After this you need to send normal initialisation e.g.

• a complete display mode command
• display on/off
• display clear
• entry mode set.

I would speculate that an improved reset sequence might be possible in which a dummy command 1111 is sent first. Since this can not be transformed into a "home" or "clear" command the extra long wait is not necessary. The following 0011 command should be sent twice but the 4.1ms wait should no longer be needed, avoiding the need for an "initialize display" function to block for over 4 milliseconds.