Results 11 to 20 of 25
Thread: Garbled LCD screens
Hybrid View
-
08-22-2014, 01:20 PM #1
-
08-22-2014, 03:01 PM #2
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.Last edited by printbus; 08-24-2014 at 03:21 AM.
-
12-14-2014, 07:49 AM #3
Evolution of Marlin took a different approach to the garbled LCD screens that negates the need for the fix proposed here. I don't know when it was changed in Marlin, but the Sept 28 2014 MakerFarm dacb fork now calls the lcd_implementation_init() whenever the printer is displaying the status screen and the LCD panel button is pressed. So, the display recovery occurs as soon as you press the button - you don't have to wait for the display to timeout before the LCD interface is reinitialized like my fix did. The additional delay spent reinitializing the interface before the top menu comes up isn't significant.
So, if you get the garbled LCD display on your printer with a fairly current version of Marlin, you can either just press the knob on the panel or you can insert/eject the SD card.Last edited by printbus; 12-14-2014 at 08:05 AM.
-
08-22-2014, 11:20 AM #4
On to the i2c or i^2c stuff. For the unfamiliar reader, a simple overview first.
The larger Atmel AVR microcontrollers support a serial transfer over what Atmel calls the two-wire interface, or TWI. You can read about TWI in the AVR ATMEGA datasheet of your choosing. This is compatible with the Inter-Integrated Circuit (i2c or i^2c) interface. Read about THAT on wiki or other resource. It's a slick interface that allows support chips to interface with a microcontroller through serial data transfers and device addressing. Communication only requires a couple of pins, and addressing means you share the same signal pins for multiple devices. The Arduino world took this a step farther. The Wire library allows you to perform i2c communication but without committing to having or using the TWI function in the ATMEGA chip, albeit with a substantial amount of software overhead.
Functionally, there's no reason why you couldn't use TWI/i2c for the LCD interface. In fact, there are i2c "LCD backpacks" from sources like Adafruit and Sparkfun that solder directly onto the pins of the LCD module and turn it into an i2c node. The one's I've seen of these still require you to use the LCD in 4-bit mode. Why? The i2c adapters use a shift register chip that decodes the serial data stream into the parallel lines needed to drive the display. This chip can only accept a number of bits at a time. In addition to data lines, the RS signal, E signal, and usually a backlight on/off signal have to be sent. There aren't enough shift register bits to send 8 bits of data, so only 4 get sent. RS and E aren't passed over discrete wires subject to noise and static, so maybe this is still an improvement with regards to the garbled display issue with nibbles getting out of sync. I don't know.
Personally, however, I think it is hard to have an LCD interface that is efficient over i2c, and incredibly so with the Arduino library if it is used. Remember that we need to be setting data lines and toggling RS and E pins to send data and commands to the display. The flexible bit-bang nature of Arduino means everything is being done in software (ie, the ATMEGA TWI hardware isn't used), and there's also i2c overhead involved in setting up each transfer. Send an i2c command to confirm the bus is available. Send i2c commands to address a specific device and set up a data transfer with it. Send four of the display data bits with RS set to the desired level and E not asserted. Resend the same data bits but with E now asserted. Resend the data bits but now toggle E back to inactive. Send the next four data bits with E de-asserted. Send them again with E asserted. Again with E now toggled off. This is coming from dated memory and might not be totally correct, but this should convey a sense of the number of transfers required to send simple messages to the display. BTW, then when done with the transfer, send an i2c command to relinquish the i2c bus. And if I recall my dated research into the Arduino Wire library, acquisition of the i2c bus and addressing a device occurs on every byte or display character sent over the Wire library. Keep in mind that software is dealing with all this one serial bit at a time. Yes, one bit at a time. Very inefficient from a software overhead perspective. I've never used the Wire library, but I've read how this leads to a really slow update for anything but the smallest size display.
FOLLOWUP COMMENT: To be fair, not all of my concerns are with the Arduino Wire library. The software-intensive effort in handling i2c is exasperated by the need to toggle control pins on the LCD display - that's driven by the nature of the LCD modules, not the Wire library. After knocking the dust off more brain cells, I also now remember that the i2c bus acquisition on every character was something done in sample software provided by AdaFruit for their i2c LCD backpack board. The Wire library wouldn't likely require every byte to be handled individually.Last edited by printbus; 08-27-2014 at 01:31 PM.
-
08-22-2014, 04:21 PM #5
- Join Date
- Jun 2014
- Location
- Burnley, UK
- Posts
- 1,662
I think much older than that. Being an old git my mind is unclear but I am sure I remember using a Z80 to talk to them possible as early as 1980.
-
08-22-2014, 05:00 PM #6
Last edited by printbus; 08-24-2014 at 03:21 AM.
-
11-08-2014, 05:08 PM #7
- Join Date
- Nov 2014
- Location
- Kentucky, US
- Posts
- 70
Sorry to bring up an old thread. But I'd like to know how well this fix has worked?I've been fighting this problem for years on other projects.Jim
-
11-08-2014, 05:21 PM #8
I've used the trick maybe twice to recover from a garbled screen since I made the firmware change. Although the screen isn't readable when it occurs, I just hit the button on the smart panel and let Marlin time out and return to the main menu to reinitialize the display interface. I haven't described it in my MakerFarm i3v build thread yet, but I've also added a bezel over the LCD. I learned in other projects a long time ago that having these type of LCDs behind a bezel can do wonders in protecting them from going nuts after inadvertent static discharge.
As I update other projects using the LCDs in 4-bit transfer mode, I'll be looking for ways that I can automatically do the interface reinitialization periodically now that I understand how the data nibbles can get out of sync.
-
05-26-2015, 07:10 PM #9
- Join Date
- May 2015
- Posts
- 3
I don't really think that the screen get garbled due to timings or ESD.
I never supposed that anybody could connect something directly to an MCU pin with a half-meter wire, but they did it... And that single thin GND wire (yep, only one of 20 wires is a GND) only aggravates the situation.
This garbling issue can be fixed by adding a serial resistor to each MCU output connected to the LCD. These resistors should be placed as close as possible to the signal source (i.e. to the MCU in our case case) and by routing a reliable ground wire to the LCD board.
But I'm to lazy to do all these things, so I've just cut the LCD cable (there are two cables - one for LCD and power, and another one for SD card) at the mainboard side and solder 47 Ohm resistors there. This appears to be enough to get rid of LCD screen garbling.
lcd1.jpg
-
05-27-2015, 12:33 PM #10
Interesting. Be sure to report back after a while to confirm whether or not the series termination resistors solved your garbled display problem. I'd try the fix myself, but I've eliminated the nibble transfer display as part of migrating to Smoothieboard on my i3v.
Technically, the bulk of the benefit is likely obtained by adding the termination resistor in the E signal line to the display. IIRC, that is the signal that is pulsed to latch each nibble data transfer into the display module. Ringing on any other pins likely wouldn't matter as long as they're stable when the E pin is pulsed, but there's no reason the termination can't be added in all the data lines. Also note that some of the data lines (encoder, SD reader) on the two cables are driven by the smartpanel and not the ATMEGA2560.
I don't really think that the screen get garbled due to timings or ESD.Last edited by printbus; 05-29-2015 at 11:24 AM.
Ender 3 Neo - Jam Problem
05-08-2024, 03:06 PM in Tips, Tricks and Tech Help