16x2 LCD Big Font

[r4z0r7o3]

Hi all,

I'm fairly new to micro's but am having a lot of fun and success (in between measured amounts of letting purple smoke escape free Part of a larger project I'm working on needs a basic screen & simple UI so I got this LCD + Shield kit (which includes this Standard HD44780 LCD board).

The shield and buttons are all working great, and I was so inspired I spent a few days hacking together this 2-line large-character font, and scrolling/positioning functions.

This is working really well (functionally) but I'm not sure if I'm hitting a code-optimization problem or a LCD display limitation. As the block-letters scroll across the screen, there's a redish-blue flash or trail that follows in the opposite direction.

I looks like some kind of "trail" artifact from blanking the pixels, but it's quite possible my code is simply not fast enough. I tried playing with the contrast-pot, and this helps a little bit. However, basically these artifacts severely limit the rate at wich I can scroll characters on the screen. Anything faster than moving one column per 500ms renders the text unreadable.

I managed to catch this artifact with my phone...

Last character on the right is an 'H" rendering with visble redish-blue trail showing. The trail appears to move left-to-right - the direction that I draw characters in.

LCD.jpg (209.75 KiB) Viewed 643 times

[r4z0r7o3]

The redish-blue trail seems to flow in the opposite direction of the characters. It does not appear when my code draws space, or "blank" characters. In other words, it only happens where there was previously an 'on' pixel.

If this is simply a limitation of the display, are there any techniques I could use in my code to limit the effect?

Update: It appears reproducable also when using the standard scrolling HelloWorld example code

[adafruit_support_bill]

LCD displays have notoriously slow response times. What you are seeing is known as "ghosting" and is a property of the display.

[r4z0r7o3]

LCD displays have notoriously slow response times. What you are seeing is known as "ghosting" and is a property of the display.

Darn, so making my code faster will probably make the problem worse then. Out of curiosity, would an OLED or VFD display not exhibit this artefact as much?

[adafruit_support_bill]

OLEDs and VFDs are definitely faster.

A word of caution regarding OLEDs though: The 16x2 OLEDs use a controller that is almost compatible with the common HD44780 LCD controllers. However, the timing and initialization are different and the spec-sheet is largely a work of fiction. Be prepared to do a bit of experimentation when programming it.

[r4z0r7o3]

OLEDs and VFDs are definitely faster.

A word of caution regarding OLEDs though: The 16x2 OLEDs use a controller that is almost compatible with the common HD44780 LCD controllers. However, the timing and initialization are different and the spec-sheet is largely a work of fiction. Be prepared to do a bit of experimentation when programming it.

Thanks. Yes, I did read that, and even looked at the code briefly, seems like it could be hacked to work with the i2c LCD/Button shield (MCP23017) no?. I'll keep those options in mind for next time, since I'm lothe to de-solder header-pins. Thanks again.