I’ve recently released pylibftdi v0.10. pylibftdi is a ‘minimal Pythonic interface to libftdi’, and is intended to be (possibly?) the easiest way to get up and running for simple use cases of FTDI’s range of USB to serial and parallel interface chips and modules. v0.10 adds a couple of new features and bug fixes.
For a long time I suffered under the misapprehension that version numbers should follow the rules of decimal numbers, and that by all reasonable accounts v1.0 should have followed 0.9, and since I want(ed) 1.0 to be ‘stable’ (I currently classify it as ‘beta’), I’d reached an impasse. I can’t remember the exact moment, but I had a realisation that I didn’t have to approach 1.0 via smaller and smaller increments from 0.9 (as in Zeno’s race), but that I could go from 0.9 to 0.10. Anyway, I still want to do better documentation (and a few other things) before reaching 1.0.
Changes in v0.10:
Running the unit tests is now easier due to some reorganisation - just run
python -m unittest discoverin the top level directory.
Support for the FT232H device - this has a different USB product ID (PID) to the previous devices I’d been testing with and using - mainly FT245BM/RL, FT232R/RL. All those devices have a PID of
0x6001, while the newer FT232H has a PID of
0x6014. I experimented for a while with having (defaulted) extra parameters for specifying the VID and PID of the target device, but this pushed too much complexity up to the user - I really want pylibftdi to be something which can be used with default options and next-to-no set up code for most basic operations. The approach taken is to have two lists (
USB_PID_LIST) and have the device finding code iterate over the cartesian product of these (i.e. a nested loop, but implemented through the wonderful
itertools.product). So adding new PIDs in the future is as simple as appending to
USB_PID_LIST, and a device can be opened with no parameters to the
Device()constructor if it’s the only FTDI device on the USB bus.
Resetting the device to serial mode on open. There’s been discussion about implementing this logic in the library on the libftdi mailing list, but doing it in pylibftdi as well doesn’t hurt. This fixes the unexpected condition that if a previous application had used a device in BitBang mode, reopening it just using
Device()would leave it in BitBang mode, rather than the expected serial mode (for devices which have support both).
Added a ‘
buffer_size’ parameter to the
Device()constructor (defaulted to zero, which retains previous behaviour) which chunks reads and writes into accesses of that length at most. This avoids the issue that a call of (for example)
dev.write(‘hello’ * 100000)over a 9600 serial link would take an incredibly long time, and since it is all running in the library context (via a
ctypescall), it wouldn’t be interruptible by Ctrl-C.
Removed the deprecated use of
Driver()to be a synonym for
Update: I've already done two maintenance releases in the hours since originally writing this - v0.10.2 is now current. One of the major changes is that the
examplessubpackage is now included in the sdist - so
python -m pylibftdi.examples.led_flashshould work if you have an LED attached to D0 on your device.
The plan for the next release is just more tidy-ups, examples and more documentation, but I might squeeze a few other things in there…