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 discover
in 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 of0x6014
. 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_VID_LIST
,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 wonderfulitertools.product
). So adding new PIDs in the future is as simple as appending toUSB_PID_LIST
, and a device can be opened with no parameters to theDevice()
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 theDevice()
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 actypes
call), it wouldn’t be interruptible by Ctrl-C.Removed the deprecated use of
Driver()
to be a synonym forDevice()
.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
examples
subpackage is now included in the sdist - sopython -m pylibftdi.examples.led_flash
should 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…
Ben
ReplyDeleteI need to read a UM232H module which is set to the Syncronous 245 communication mode and will be sending data at a rate of about 20 Mb/s. I would like to use Python since the backend of our application iw written in Python.
I believe your driver supports the FT232H chip but I do not fully understand USB and am a bit lost here so I would appreciate any assistance you can offer.
Thanks
John Battle
I've just put the project documentation up on readthedocs - http://pylibftdi.readthedocs.org - I'm planning to regularly update it over the next few days (realistically, weeks...) until it's 'complete'. Hopefully that will eventually answer things!
DeleteUntil then, I've not used my UM232H in sync 245 mode (from what I understand that requires changing the EEPROM settings and I've not done that - I don't have a Windows PC available to use FT_Prog from).
I don't see why it wouldn't work though, it certainly works fine in normal serial (RS232) and async bit-bang modes with high baudrates. I suspected ctypes could be a performance bottleneck at that rate, but it doesn't seem to be (for me, anyway). The underlying baudrate (which I believe is x16 scaled in parallel modes) is accessible through the 'baudrate' property of the device instance - it's worth reading it after writing it, as invalid values won't get applied - the current API doesn't raise an exception, it just leaves the baudrate as it was.
Cheers,
Ben
Hello I have a FTDI based device with a different product ID than 0x6001 and 0x6014.
ReplyDeleteHow can I use the python library and register my device ID?
Do I have access to modify the USB_PID_LIST while using the library without (modifying the library source code).
Thanks in advance.
Loic
Update: I edited the driver.py and reinstalled the library.
ReplyDeleteNow my device is recognized.
Thanks for this very nice library
Regards,
Loic