Garbled LCD screens

[printbus]

Oh, what the heck. I have a firmware change uploaded to test. I'll post details after I run this a while to make sure there are no ramifications of the change and after I witness the display recovering from "garbled mode".

The fix is oriented around LCD interfaces that leverage the 4-bit or nibble mode to send data to the displays. As best I can interpret the possibly dated code base from MakerFarm that I'm working with, this will be the case for those with a configuration.h file that has #define statements for ULTIPANEL, REPRAP_DISCOUNT_SMART_CONTROLLER, G3D_PANEL, or ULTIMAKERCONTROLLER. These in turn will invoke the ULTRA_LCD stuff that is important here.

In the 4-bit data mode, two transfers to the LCD display are required for most commands and data characters. The problem is that if we miss a transfer or double-clock one due to static, noise, firmware timing, or whatever, the data being sent to the display gets out of sync. For display characters, data gets displayed that is say the last four bits in one character and the four bits from the next character. This out-of-sync error will remain until the Arduino board is restarted or reset.

There's an easy way to prove this theory for those running the printer from a host like Repetier that allows you to send G-code commands in real time. If you see the display garbled, send this to the printer without the quotes: "M117 ccccccccc" (be sure it is lower case). When things are working properly, this should cause the string of c's to be written to the status line at the bottom of the screen. In garbled mode, a string of 6's will be printed somewhere instead. Why 6's? The character address code for "c" is binary 01100011, and is sent to the display in two transfers consisting of 0110 and 0011. When things get out of sync the LCD will read these repetitive transfers in as 0011 and 0110 instead, or 00110110 combined. That's the character address code for the number 6. The location of the 6's may be somewhere other than the bottom row; it's likely that command messages can get messed up just like the character address messages.

The display modules support 8-bits of character codes. The predefined character sets in the display modules supplement the normal 7-bit ASCII alpha-numeric character set with 128 Greek and other symbols. Once the character data transfers get messed up, it doesn't take much for characters to be selected from the extra symbols. If you have a font table for one of the Hitachi-based LCD modules and the display is garbled, you can use the M117 command to play around with how different "intentional" characters get misinterpreted as stuff in the extended character set, etc. You could even use the font table to reverse things and decode what a garbled display is trying to tell you.

What I've uploaded to test is a one-line code change that reinitializes the LCD interface whenever the display will revert back to the main status screen. When the garbled display occurs, simply letting the display timeout should restore things. If the main display itself is what's garbled, pressing the panel knob and then waiting for the timeout that returns to the main status display should restore things.