SparkFun Forums 

Where electronics enthusiasts find answers.

Have questions about a SparkFun product or board? This is the place to be.
By ferrick
OK, gang, here's whats up: I have over the past year or so been playing around with a couple of SerLCD modules (+ 2x16 displays). After a couple of speedbumps, most notably that only HSEROUT seems to work with a 16F628, I was at the point of having it all happy and nice.

Note that I said "was". Right at the moment things are screwy, and to tell you the truth I've tried swapping/changing so many parts of the puzzle over the last few days I'm not completely sure where I am!

How about this for a specific: has anybody seen behavior where a module comes up OK (the splash screen shows), then the display stays blank until you bring a finger near the wire leading to RX, at which point semi-random characters appear? Yeah, there is a 7805 with a decoupling cap behind everything. Yeah, IC-Prog works fine otherwise via a PG2 programmer.

What other LCD show-stoppers have people found, preferably with solutions attached?!


User avatar
By sparky
Hi Patrick,

Happens all the time with the SerLCD modules under test. The RX pin is floating no? You touch it with your finger, a pen, a random piece of wire, and the on-board UART will actively interpret the spike/change in voltage as the start bit. What follows is a non-sensible stream of bits. Hence, you get the jibberish character displayed on the screen.

It sounds like there is more to your problem...

By ferrick
OK, here's some more LCD info: I have RX on the SerLCD connected to pin RB2 (TX) on a 16F628, the hardware USART. So it's not floating, or shouldn't be. I have tried other micros, and what's really weird is that I get slightly different results with different chips. Sometimes i get the random, finger-induced-spike garbage, sometimes i get ALMOST the same characters as I sent (via HSEROUT) mixed with some garbage. Sometimes cursor-positioning control characters work, sometimes not.

I'm beginning to suspect the SerLCD itself, but I have no reason to think that anything should be wrong with it. (The first SerLCD that I accidentally connected 12V to, now that's a different story! That one I killed in a momentary lapse of concentration...!) And I also don't think that I've managed to mess up the TX ports of a half-dozen microcontrollers either.

I'm going to order a third module and keep my fingers crossed. Is there some failure mode of the modules (or of a '628s USART) that I am missing here? Are they especially subject to static damage?

User avatar
By sparky
Lol - I fixed your topic typo.

As for the SerLCD - I'd be more than willing to take a look at it for you. Please email at spark @ and we'll arrange a return.

By kadet
I am using the Hitatchi 44780 connected to a 16F877A via parallel 4 bit set up. I am using a simple program to make Hello World appear on the LCD. When I power up I get the Hello on the first line and World on the second line, just like I'm supposed to, but since the program is a loop, when it continues Hello and world start loosing letters like hello would be hllo, or substituting characters like world would be wvrld, etc..., about once every 10 times through Hello World appears like it should. My crystal is properly defined in the program as 20 mhz. The only mod to the LCD was removal of the back pack so it would go parallel instead of serial. I was getting the same prob when I was experimenting with it in serial mode, prior to removing the back pack. Could this be a prob with the length of my wires going from the dev board to the lcd? The length is about 4 inches. Could it be a bad LCD module. Any suggestions as to why the lcd is getting so confused?
By Vraz
Does your software actually ready the BUSY flag on the 44780 to determine when it is ready for the next command or does it use static timing? Your reference to "crystal is defined in the program as 20 mhz" implies the latter. I have never had good luck driving LCDs with static timing and have run into data loss and issues like you describe unless I use very conservative timing. Even then its a pain since different commands take different amounts of time. On the other hand, I have found the busy flag to be completely reliable though it does require one additional output pin.

Assuming you are using software with static timing and you have it defined as 20 mhz, you could try changing the 20 to 50 (assuming the 20 is only used to calculate LCD timings). By increasing to 50, it will cause the software to increase the delay when communicating with the LCD. If the problems are reduced/eliminated, then that will confirm the issue is timing related.
By kadet
Thanks! I will give it a try, and let you know the results.