634 PIC18F8720 Hyperterminal


New member
We are working on hooking up a 634 LCD up to our PIC18F8720. We have the Pic sending 'PIC18F872' to the LCD just testing it out. Usually the 8F87 comes out ok but the rest is all jarbled. My friend was messing with the LCD in Hyperterminal last night and it was doing the same thing, until he turned Flow Control to Xon/Xoff and then everything works fine. Our pic is on a devboard and has a RS232 controller on it so that is what we are using right now. It also runs at 19200. Doesn't anybody know what to do?

Thanks Mike
Looking for additional LCD resources? Check out our LCD blog for the latest developments in LCD technology.


New member
Here's what we're seeing:

My program writes "Eric" to the uart then stops... I'm resetting the PIC manually to write each "Eric" so that I'm sure I'm not overflowing the lcd buffer. As you can see, the "i" is sometimes interpretted as an "o" or an "m", which I noticed all have the same first 4 bits, so maybe that's a clue.

I think this might be a protocol mismatch of some sort since it seems to be getting an extra bit here and there but it still is mostly correct. I'm resusing some uart code that came with this devboard, which works fine in Hyperterminal running at 19,200 and 8n1 format with hardware flow control. Like mphollo says, when I tried to control the display itself through hyperterminal I had to switch flow control to Xon/Xoff, but I really don't know what that means as far as how the lcd is handling data.

If I hook the devboard to my PC and open Hyperterminal with 19,200/8n1 and hardware flow control, it reads "Eric" every time. It also reads anything else I code in there perfectly. The LCD works fine with WinTest, so at least we know the module is not goofy.

Any tips or simple uart code that works with a CF display would be greatly appreciated :cool:
USB LCD Displays - Graphic and Character LCDs with a Keypad

CF Tech

It pretty much cannot be protocol.

No handshaking is need ed on the LCD, it can stay ahead of the 19,200 baud data stream.

Turning on software (Xon/Xoff) handshaking could actually cause some trouble, since the LCD would try to display the Xon and Xoff characters.

My guess would be a level issue, or a grounding issue.If you connect the LCD to the PC and use HyperTerminal or WinTest, does the module work OK?

My guess would be an issue with levels or grounding.

What is between the PIC's port pins and the LCD's connector? Is there a RS-232 level converter?

What are the votages of the high and low states of the Rx line at the DB-9 of the LCD?


New member
The 634 does work fine with WinTest but I just tried again and I can't get it to work with Hyperterminal.

The devboard we're using has a maxim MAX232 for line level conversion. I don't have access to a scope at the moment but the datasheet says its transmitter typically has a +/- 8V swing with a guaranteed minimum of +/- 5V swing. Are these too low for the 634 to interpret?


New member
I would agree with CF. Sounds like a grounding issue.

No - + 5v should be fine. This is all that is outputted on a laptop serial port. Ground is used for reference, it is either -5v(from ground) or +5v(from ground) when communications occur.

Do you have any thing in between or tied to the TX pin usart on the pic? Or does it go straight to the MAX232 chip input?



New member
According to the schematic, TXD is tied directly to the 232 and nothing else. I don't have a common power ground between the 634 and the PIC board, only the signal ground in the serial cable... is that sufficient?


New member

I added a tiny delay to the uart function so that each character is delayed by a few ms and it works fine now! I don't really understand why this works since I thought the 19.2 data rate insured that everything would be ok but I guess I don't fully understand how this serial comm is working. Oh well, it works :D