• We recently switched our forum platform. If you experience any issues please email support@crystalfontz.com

PIC 16f877A to CFA 635 (Serial Communication Baud 19200 Problem)


New member
Description: I am trying to use a PIC 16F877A Microcontroller to write text lines to my CFA 635 serially. I am using the CCS PCWH compiler for the PIC and have tried several configuration. The problem is not in my programming, it is the communication link between my PIC serial and the LCD. Here is the work I have done.
//Setup Information
//CFA 635
//RS232 for communications
//Baud @19200
//PIC 16F877A
//Compiler CCS PCWH
//Crystal 20MHz

//:DScenerio 1 - using
I communicate VIA RS232 Com1 of the Pc through this software no problems everything works great. I changed my setting to use the baud 19200 and ran the packet debugger to store settings as default in EEPROM. Now my baud is set.
//:DScenerio 2 - PIC to Windows
//Terminal VIA RS232 COM1 19200
I have programed my pic to perform the correct operations described in the data sheet. Program works beautifully. Auto sets up the string format and calcs the CRC, and sends packet correctly. I verified with the packet debugger. An example is the following string. I type "Hello there" the following hex code from PIC to terminal is "1f 0d 00 00 48 65 6c 6c 6f 20 74 68 65 72 65 43 c1" thats
TYPE = 0x1f (31)
Length = oxod (13) 2loc 11text
Loc = 0x00 0x00
data is just hex text
CRC = 0x43 0xc1

Another example string from my PIC is the following.

I want to send
LINE 0:"Hello there"
LINE 1:"This is your"
LINE 2:"computer speaking"
LINE 3:"to you VIA PIC16f877"

LINE 0:"1F 0D 00 00 48 65 6C 6C 6F 20 74 68 65 72 65 43 C1"
LINE 1:"1F 0E 00 01 54 68 69 73 20 69 73 20 79 6F 75 72 9C 92"
LINE 2:"1F 13 00 02 63 6F 6D 70 75 74 65 72 20 73 70 65 61 6B 69 6E 67 8F DE"
LINE 3"1F 16 00 03 74 6F 20 79 6F 75 20 56 49 41 20 50 49 43 31 36 66 38 37 37 98 43"

Appears to be working perfectly, using the "C" bit shift implementation.

//:(Scenerio 3 - Trying to send directly
//from PIC to LCD
Since all data streams are correct, I should be able to connect PIC->RS232 Line converter->Line Converter on LCD-->LCD SCREEN.

with this setup I have tried both strait through and Null modem connection (EG switching RX TX). using your cables. I spoke with you guys on the phone, and tried removing line converters on both sides and doing TTL level communication rx tx and tx rx. LCD still doesn't repond!
I though maybee I wasn't streaming the packets smothly so I used a basic RS232 program and manually send the packets so there was no delay. Still no luck.

I can plug the LCD into the PC and it works fine with your cable, what is wrong? Are there more connection than TX RX +5 GND? Is their RS232 Handshaking eg CLS DTS?

ONE thing, i can parallel the connection to the PC and LCD, so i can see on my terminal what is writing and should be sent to LCD. My TTL level cabling is using your header1 "H1" pins F4P to PIC TX, F4T to PIC RX, +5 to +5, GND to GND. When I Let pin F4p go to TX my console stopps responding like its hanging my data? maybee wrong line or shorting levels? Please Help, and sorry this post is so long. Thanks for any advice you can give.

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

CF Tech

The CFA-635 is insensitive to the spacing of the bytes that make a packet. They can be closely packed or spaced out.

The CFA-635 only cares about Rx & Tx.

The first thing I would want to do here is grab a scope and look at the waveforms. Is there any way for you to gain access to a scope?

CF Tech

These show "logic level" signals (0v to 5v), so I assume you are connecting them directly into F4P and F4T on the LCD?

It is hard to tell accurately from the shots, but it looks like the byte times are about right for 19200 baud. (One byte is 10 bits (start, 8 data, stop) and takes 10/19200 = 521uS.)

Try this:

1: Connect the LCD to the PC to where you can use 635_WinTest to talk to the LCD.

2: Connect one oscilloscope channel to F4T (that is the LCD's Rx, PC's Tx--trigger on this channel) and one channel to F4P (that is the LCD's Tx, PC's Rx). Best might be to tack some fine (wire wrap) wire to the appropriate two legs of the white connector, then clip the oscilloscope to these.

3) Use 635_WinTest to send a short packet (ping with 0 data is good). Set up the oscilloscope to where you can see the packet come in from the PC on the one channel, and get echoed back by the CFA-635 on the other channel.

4) Record that oscilloscope image (photo or print or whatever). This is what the module needs to see in order to work.

5) Connect your board, leave the oscilloscope connected to F4T and F4P.

6) Run your program (make it send the same packet as you used in 635_WinTest) and look at the oscilloscope traces. Same? Different?


New member
OK, so I was finally able to get some good traces. On some of the pictures I have merged two traces together for one to get a better realization as to how the traces flow together (My scope was rather difficult to get traces!). I have three main sources of traces.

One from the Packet Debugger to LCD. This one workes fine and writes decimal code 31, data length, pos, "Mike", crc...

Next is from the PC WinTest program to the LCD and works fine. What is interesting is there are many repititious bits at the end of this send. You can see them in the images. Although it still sends correctly I dont know what these bits are.

The last is from my PIC to the LCD. I note some minor changes. First of all there are no repititious bits. Second, the timing seems slightly off, where my PIC packets are just slightly over one division, and the Comps slightly under. Third there are 5 extra bits coming from WinTest. Now my hex code coming from the PIC to the PC clearly reads the correct hex code that the Packet Debugger sends. What do you think is going on?

The following is a link to the pictures, you may post them in this post if you would like.



New member
Progress Made

Finally I have figured out the problem, and a full resolve is underway. Firstly the reason I would see repeating bits is because the CF WinTest program pads every unwritten bit with a space. In the case of writing "Mike" it actually sends "Mike ". Additionally I used the following setup for analysis.

Wintest PC to LCD & Terminal. LCD & Terminal Paralled so you can see both command action on the LCD and the corresponding hex bits on another PC. You would assume that what you see on the Terminal produced from your wintest sofware is what you need to reproduce to speak with an LCD.

Using this setup I found that the previous string as noted in previous posts, was in fact flawed. The only issue was the CRC check is "bit-wise inverted" as stated in your datasheet. The only problem is using your packet debugger in WinTest Version 1, your CRC is NOT bitwise inverted, which is how I arranged my string. Since I was matching the data coming from your packet debugger I assumed it was correct. This in fact was mostlikely the issue, and with the CRC bitwise inverted, everything works with the LCD perfectly.

Thank-you for your help I am just happy to have this problem resolved. Again I want to let you know that it is nice CrystalFontz supports you when problems arise. I do appreciate it.

USB LCD Displays - Graphic and Character LCDs with a Keypad

CF Tech

I am glad that you got it sorted out. Sorry I did not reply for a few days, I was out of the office.