We have a USB device controlled by FTDI D2XX drivers. Currently, it is controlled from a Windows machine via the Python interface, and as a fun project I tried to move the control to the Raspberry Pi (about 1/10 of the cost of the PC, not including the cost of the OS).
There were many obstacles to clear, but after a few weeks I finally found the answers to all the questions and earned. Answers were spread over several forums, so thanks to the Stack Overflow community. I thought I was consolidating them.
Firstly, a project is required:
I downloaded the Wheezy distribution and used Win32DiskImager to write to a 4-inch SD card. Raspberry Pi booted without problems. Then I unpacked the D2XX library (libftd2xx.so) and installed it in /usr/local/lib .
PyUSB (1.6) is currently tested only for Windows, but they provide source code. It is quite simple to compile a copy for Raspberry Pi. Basically, change setup.py to reference the libftd2xx.so library (no need to copy it). Also edit d2xx / _d2xx.c to comment on procedures without implementing Linux (currently ftobj_Rescan, ftobj_Reload ftobj_GetComPortNumber). Copy the WinTypes.h and ftd2xx.h files from the FTDI D2XX driver directory (in release) to ftdi-win32 and run python setup.py install , which will compile and install the Python module.
Once all this was done, I wrote a simple Python script to talk to the FTDI chip. Please note that you need to run through sudo.
import d2xx jd = d2xx.open(0) pd = jd.eeRead() print pd
The d2xx module cannot find the libftd2xx.so file. So, I set up setup.py script to reference a static copy of libftd2xx.a library. Voila, I had the first key to the problem: the D2XX library was built using soft-float, and my Wheezy distribution was configured to use floating point registers. That is, gcc on my system generated code that was binary, incompatible with the D2XX libraries and did not allow them to contact.
To fix this, I downloaded the soft-float debian "wheezy" distribution (2012-08-08) and wrote a 4 GB SD card. This time the image will not load. Looking back, I found this useful answer . In short, there is a problem with the boot image for soft-float, so for some Raspberry Pi boards it does not load. The solution is to replace the start.elf file with a soft-float distribution with one that works, for example. copy from Raspbian hard floating image. Fortunately, the SD card has two sections: FAT and ext3 (?). The boot image is located in the FAT section, so it was trivial to pop up the SD card hard drive into the Windows window, copy the start.elf file, pop up on the SD card with a soft float and update its start.elf using the hard-area. After that, Raspberry Pi did not load any problems.
After installing the FTDI D2XX drivers and building the Python d2xx module from PyUSB, I tried the test script again. Again, this did not work. The d2xx module could read the libftd2xx.so library without problems, but for some reason simply could not talk to the device.