With his recent blog, Easy LCDs for MCU Designs, Nishant Sood brought back for me memories of the late 1970s when I discovered character-based displays from Hitachi. I still remember the thrill of finding the ICL7660, a switched capacitor negative voltage generator that allowed an easy and cheap way to generate the -5V necessary to adjust the viewing angle of the LCD (all -5V technology was still a dream back then). The module was a harbinger of the direction electronic packaging was going to take much later as it moved to surface mount technology.
I have been working with these character-based LCD displays for over 30 years and I was even motivated to write an article on a systematic way to create hierarchical menus for displays based around a 20 x 4 LCD character module (Hierarchical Menus in Embedded Systems, Circuit Cellar, November 2003). When I read Nishant's blog I thought it was time to drag out my soapbox.
Having observed many failure modes over the years, I have become concerned with designing systems that are robust. I try to design so that there is a reduction in the probability of problems occurring, and where they do occur, that the system can gracefully recover. And yes, I wrote a series of articles on that, too.
The Hitachi HD44780 dot-matrix LCD driver that Nishant mentions is nothing more than a dedicated microcontroller, subject to all the same vagaries of any microcontroller. Power supply surges, long cables, alpha particle radiation, and other "things that go bump in the night" can all scramble its operation. Failure on the display is a much higher profile event than other system failures, though, since the display is the first thing the user sees, even if the rest of the system is operating correctly. Neglecting to design for the possibility the display itself will fail means that you will need to reset the whole system even though all you may need to do is re-initialize the display.
The HD44780 was intended to be interfaced to a microprocessor bus, having been designed at a time when complete microcontrollers were few and far between. It is equipped with an 8-bit bus that could be reconfigured to 4-bit access. It has three control lines: register select (RS) to choose between internal data and control registers, direction select (RW-Read/Write), and enable (E) to enable the data when reading or to strobe the data when writing. (Because it is possible to read back from the module, back in the memory-deficient times of the 1970s I actually used the spare locations of unused digits for variable storage.) This was a typical Motorola interface and needed some glue logic to work with the Intel style of interface.
Because the HD44780 is a slow processor, it takes a fair amount of time to execute an instruction or data store. The device provides a busy flag (BF) that can be read back from the control register, but if the host MCU's software takes the delay into account, it is possible to operate the display without using the BF and therefore have no need for reading back from the module. Using this approach typically means that updating the display will take longer than necessary, since you must allow for the worst case execution time.
But that is not the point of my rant. My point hinges around the fact that our community has a propensity to take the easy way out and treat the display as a Write Only Module, eventually arriving at a simple, low I/O pin count interface using simple logic. Even back in 1978, the HD44780's 450mS access time was considered slow, so there was a move to connect the driver through the MCU's I/O pins rather than the processor bus almost from the start.
As I have mentioned, though, I have seen many occasions where HD44780 has gone "into the weeds" and the display is wrong, or more often, non-responsive, even though the main system is running just fine. If the interface is too simple, your design won't be able to recover from this situation without a full system reboot.
My solution to this error condition is to use an extra host-processor I/O line to control a transistor powering the LCD module. By monitoring the BF and with the use of timeouts, you can detect when the display is non-responsive. However, the HD44780 requires the same control word (for the data width) be written to it three times at start-up before the BF becomes operational. If you cannot read it back, you have no idea if the display is present, let alone operational. Another way to verify that the display is operational is to read back what you have written. This approach is particularly useful when you are writing a built-in self-test (BIST) routine.
When the display becomes non-responsive you can then use the added I/O line to cycle the power to the LCD module and force a reset. Unfortunately, the module does not have a separate reset line. This hardware power control deserves some extra attention, though, because you don't want the outputs that are driving the module to be active whilst the power to the module is turned off. Active lines driving a turned-off module could cause irreversible breakdown of the LCD module inputs.
One last hint: Use another transistor and control pin and you can flash the backlight as a means of attracting operator attention should the display fail unrecoverably.
The simple interface typically used for LCD modules is not, in my opinion, robust. Adding these extra control lines and circuitry will improve the design considerably.
As I return my soapbox to its place behind my desk, let's hear from you. Am I being overly cautious?
Tweet This
