Python driver problem


New member
Lastnight I downloaded the Python driver and some Linux specific software for my CF635 display. It all worked fine lastnight. Today I changed out the LCD because the old one would lock up. Now I'm getting an error from Python when I start up the test script.

[starlon@localhost cf]$ python 
Traceback (most recent call last):
  File "", line 51, in <module>
    if not hello.Connect('/dev/ttyUSB0'): print "Failed to connect!"
  File "/home/starlon/Download/cf/", line 80, in Connect
    if (self.Ping("Test") != "Test"): 
  File "/home/starlon/Download/cf/", line 174, in Ping
    return self.SendCommand(0,msg)
  File "/home/starlon/Download/cf/", line 262, in SendCommand
    cmdResponse = ord( # Read the command response
TypeError: ord() expected a character, but string of length 0 found
For some reason isn't receiving anything. I tested with the other Linux software and the display is working properly. It has something to do with this Python implementation not being able to read a character from the tty.

Like I said, the only thing that I've done is install a new LCD module, and I've tested it in both Windows and Linux and it's working fine, except for this Python implementation. And it was working fine before that. Any ideas?

Here's part of SendCommand(), up to the error point.

    def SendCommand ( self, command, data ):
        """GetCRC (buffer) - Finds the CRC checksum buffer. SRC: CrystalFontz"""
        if self.ser == None: return "Error: Not connected!" # Check for a connection
        output = '%c%c%s' % (chr(command), chr(len(data)), data ) # Parse the command
        CRCValue = self.getCRC(output) # Get the CRC Value
        output = "%s%c%c" % (output, chr(CRCValue & 0xFF), chr((CRCValue>>8)&0xFF) ) # Add the CRC value
        self.ser.flushOutput() # Flush the output
        self.ser.flushInput()  # Flush the input
        self.ser.write(output)   # Send the command
        cmdResponse = ord( # Read the command response
Looking for additional LCD resources? Check out our LCD blog for the latest developments in LCD technology.


New member
I tried this python implementation in Windows and I got the same error. I'm going to contact the author about it. It's just weird that it would work before changing the module. That's why I posted here before contacting the author. I didn't check jumpers on the new module. I'm wondering if I was supposed to prepare it. It seems to be working everywhere else though.


New member
Ok, turning RTS/CTS flow control off fixed the problem. I'm curious why that was on? Is it usually needed? It's strange that it worked on the older LCD version but not on this one. The one I have now is CFA635:h1.0,v1.4. Something's different or it's configured differently. I'm still learning about the LCD so this stuff's new to me.

Code:, Line 77:
        -self.ser = serial.Serial(com,baud,rtscts=1, timeout = timeout) # Connect
        +self.ser = serial.Serial(com,baud, timeout = timeout) # Connect

CF Tech

This is a USB CFA-635, right? If do the serial port is "virtual" and there are no physical RTS/CTS lines.

There was a change in the USB chip from a "B" version to an "R" version (the B is a QFP, the R is an TSSOP). The back photo here shows the older "B" version:

The newer "R" version has different circuitry over by the USB connector.

This information might explain why there is a difference (different USB chip version on the module causing different behavior in the driver for some reason), but since that change is in the hardware, the fix would have to be in software, as you discovered.


New member
This one's a CFA635:h1.0,v1.4. I specifically waited for and received one with one of the newer usb modules. At any rate I'm not having any issues without the flow control. Would that effect key polling?