pylibftdi 0.6 has been out the door and onto PyPI for the last few days, but I'm only just getting round to blogging about it. It's basically some minor work for Python 3 compatibility - the same code now works on both Python 2 (2.6/2.7) and Python 3. This means support for Python 2.5 has been dropped (due to use of bytearray
/bytes
types). I can always add it back in if people shout.
Other than trivially fixing a print statement to be a function call, the main change required was the expected bytes/string issue. The driver also gains a couple of parameters; mode = 't'
('t':text, 'b':binary) and encoding = 'latin1'
.
In binary mode (the default - so no user code changes are required for this release), read() and write() take and return instances of type bytes
. For text mode, write()
will take either bytes
/bytearray
, or a string which it will encode with the given driver encoding, and read()
will return a string. I've set the default to be latin1
rather than using utf-8
as it is an equivalence mapping over the first 256 code points.
Coming soon...
I've started work on 0.7 - the main feature of which is support for multiple devices. I had a few problems getting the right ctypes incantations to follow the linked-list which ftdi_usb_find_all sets, but that's sorted now. The bigger issue is that it really needs a split between driver and device, which could cause the API to change. I'm thinking of various ways to keep existing code working, and will probably go for something like:
- 0.7 - set pylibftdi.SUPPORT_MULTIPLE to True to use new API / support multiple devices
- 0.8 - set pylibftdi.SUPPORT_MULTIPLE to False to use old API / only support a single device / get a deprecation warning
- 0.9 - SUPPORT_MULTIPLE no longer used; old API disappears.
So 0.7 is all about multiple device support, 0.8 will probably be support for Windows (supporting D2XX, for example), and 0.9 (or maybe just 1.0) will be a tidy-up / bug-fix / improve docs release. In parallel with all of this I'm writing some test code which will gradually bring this side of things up-to-standard. I'm not allowing myself to do a 1.0 release without decent testing & docs. All that will probably take a two months; I only get a couple of hours a week looking at this. But it could be sooner - or later.
pylibftdi 0.7 should be out in within a week or so, and I'll elaborate more then, hence the lack of any examples here. I'm on the case!
No comments:
Post a Comment