Pylibftdi library not working (serial mode, UM232H)

Question

First of all I am quite new with both python and Linux. That said I am trying to communicate to an FTDI UM232H chip using the pylibftdi library. I am running my scripts on Linux Ubuntu 12.04. I installed the library that I got here: http://pylibftdi.readthedocs.org/en/latest/ and apparently everything worked fine. I was also able to run some of the examples successfully.

I then tried to write some code to communicate with the device: I wired it in a bus powered configuration (in order to get power from the USB), then I short-circuited TX and RX pins so that what I am sending on TX will be read back on RX. I do not get any error, but I am not able to read back anything on RX. Here is my very simple code:

import pylibftdi as p    
import time

test = p.Driver()
print test.list_devices()
#This is not working
#print test.libftdi_version()

dev1 = p.Device(device_id='FTUBL36A', mode='t')#, chunk_size = 0)

dev1.flush()

dev1.baudrate = 9600
len = dev1.write('Hello World')
time.sleep(1)
res = dev1.read(len)

print 'res: ', res

Also I am not able to get the libftdi_verion information, even though I installed it.

Does anybody have an idea of what I am doing wrong? Has anyone else ever experienced such a problem? Thanks in advance!

Answer 1

I'm afraid I don't have a full answer, but some observations (I would make this more concise and put as a comment, but I don't have sufficient rep).

Disclaimer: I'm the author of pylibftdi

libftdi version / installation

The Ubuntu libftdi package (even latest 13.10) is 0.20. This is particularly confusing / annoying since the Ubuntu package name is 'libftdi1'. Prior to (real) libftdi 1.0, there isn't a ftdi_get_library_version() function, so libftdi_version() won't work with the Ubuntu default package. The next version of pylibftdi recognises this and gives an appropriate response.

To install 1.0, follow the instructions at http://developer.intra2net.com/mailarchive/html/libftdi/2013/msg00014.html (e.g. the following worked for me - note I'd previously had the Ubuntu libftdi1 package installed, and other dependencies may be required):

$ sudo apt-get install cmake libusb-1.0
$ git clone git://developer.intra2net.com/libftdi
$ cd libftdi
$ git checkout tags/v1.0
$ mkdir build; cd build
$ cmake ..
$ make
$ sudo make install
$ sudo ldconfig  # ensure the new library is recognised

Following this, getting the library version should work:

$ python -c 'from pylibftdi import Driver; print Driver().libftdi_version()'
(1, 0, 0, '1.0', 'v1.0')

Data reading errors with UM232H

Note that the latest libftdi (repeat things above but use git checkout master) seems to work slightly better for me, and your program above works perfectly for me with a UM232H (I obviously omitted the device=... parameter, but otherwise left it unchanged). If I replace 'Hello World' with 'Hello World' * 10, writing and reading a longer string, then I get a truncated value returned, typically only 29 bytes. I'm not sure why it's this value; with earlier libftdi versions it seemed to return 17 bytes consistently. Very odd.

With other devices (UB232R, UM232R), this all works perfectly as expected, so in the (admittedly unlikely) event you have a choice of device, you could consider switching... Note the FT232H chip is relatively new and support in libftdi may not be as solid as for the older devices - but equally possible is that I'm incorrectly assuming it should work in a similar way to the older devices in pylibftdi.

Other thoughts

• I've tried blacklisting ftdi_sio (add blacklist ftdi_sio to the end of /etc/modprobe.d/blacklist.conf), which stops the Linux kernel doing who-knows-what with the device on plugging it in (the Rx/Tx LED flashes several times when plugging in without this and the ftdi_sio module is loaded. I'm not sure this is necessary or makes a difference though.

• Note that there's no guarantee that a read() will return anything previously written to the device (assuming an external Tx->Rx loopback), due to internal buffering in the device, and various driver layers (including USB). These are just streams, and framing should be done in the application layer. Having said that, it 'just works' on a UB232R, and even taking this into account seems the UM232H seems to have issues with pylibftdi for serial mode.

• Bitbang mode seems to work fine for UM232H / pylibftdi.

---

I'll continue investigating and update this answer if I find out anything more.