Garbled LCD screens

[printbus]

...Pulling up this link: http://www.reprap.org/wiki/RAMPS_LCD it shows how to build the LCD Panel and it claims it is enabled by taking the comments off of the #define ULTRA_LCD line. But when you look at their directions, they are saying the LCD Panel has 8 data lines and they only hook up 4 of them???? ...

The display modules DO have 8 data lines, but the controller chip supports a data transfer mode that only uses four of them. The modules also have a read/write signal, but common applications don't need to read anything back from the display so they're hardwired for write-only. Using the 4-bit mode saves Arduino pins. (I'll get to i2c savings later)

It would seem they should have some way to reset the panel and get it to a known state??? ...It would seem they should have some 'illegal' combination of RS, R/W and Enable that causes the display chip to reset????

One would think, but no. "Initialization" involves sending a particular sequence of commands to the display module, with specific timing constraints on the transfers. That's all my "fix" is doing - periodically reinitializing the display by going through that command sequence again. There's a bit of delay in doing this, but I don't notice it on my printer. If I understand Marlin right, any printing going on should be handled in interrupts, so the additional time spent reinitializing the display shouldn't affect anything.

Since a lot of the LCD Panels use the same support chip, does this happen equally often with all of them? Or does it mostly happen with specific Arduino boards? Is there some combination that is more prone to the display getting out of sync? Is it at all related to how clean the power is? I know my PrintrBoard had trouble power the Servo for Auto Bed Leveling. Do the LCD Display boards grab a lot of power from the Arduino board?

I think there's too many variables here. I've had static issues on non-printer and non-Arduino designs using the modules, minimized by simply putting the display behind a bezel. They don't all use the same Hitachi HD44780 controller chip. There are clone chips out there. Older boards have discrete chips. Newer boards have the substrate right on the board and coated over. They just all support the same command set as the original HD44780 chips. Then, there's different module circuit board layouts that could lead to differences - maybe trace routing differs, different ground distribution, or maybe some include decoupling capacitors, who knows. Also, maybe some of the Arduino clone boards are better quality than others. Cleanliness of the power supply could make a difference. Wire routing in the printers could make a difference.

The core of the LCD modules I've used only need a couple of milliamps of power. If used, a backlight will draw more, but displays with the typical LED backlighting will still be relatively low. I would assume that those reprap displays with the rotary encoder and SD card still draw minimal power.

---------------

Rather than ramble on here, I'll touch on i2c in another post.

[Roxy]

One would think, but no. "Initialization" involves sending a particular sequence of commands to the display module, with specific timing constraints on the transfers. That's all my "fix" is doing - periodically reinitializing the display by going through that command sequence again. There's a bit of delay in doing this, but I don't notice it on my printer. If I understand Marlin right, any printing going on should be handled in interrupts, so the additional time spent reinitializing the display shouldn't affect anything.

OK... But here is the next question... If you are sending some 'Initialization' sequence, does that involve sending it bytes of data to give it commands? Because if it does and the LCD Panel is out of sync, aren't the 'Initialization Commands' scrambled?

[printbus]

OK... But here is the next question... If you are sending some 'Initialization' sequence, does that involve sending it bytes of data to give it commands? Because if it does and the LCD Panel is out of sync, aren't the 'Initialization Commands' scrambled?

Aw, man. I guess I should have known better than to gloss over details. State of the RS (register select) pin when the E pin is strobed is how the LCD module differentiates commands from data. At the start of the initialization sequence the LCD module doesn't know if the transfers will be 4-bit or 8-bit, but the first commands used only have four valid bits, and the others are don't care. So, the multiple-nibble synchronization problem can't occur on those first commands.

EDIT: I'd summarize the interface these modules have as fairly clunky by today's standards. I don't know how long the interface has been out there - I bought my first module off the surplus market in 2004, so I'm guessing it's been out there 15 years or so.