I've done some tidying up of pylibftdi, fixing a few bugs, refactored the pylibftdi package to contain several modules instead of everything dumped in a __init__.py file, and generally made it a bit cleaner. It even has docstrings for most things now, and a test or two!
pylibftdi is a simple interface to libftdi, which in turn allows accessing FTDI's range of USB parallel and serial chips. See here for more details, but very briefly, serial access is provided by a file-like (read/write) interface with a baudrate property, and parallel access is provided by a pair of properties - direction (data direction register) and port (data IO register).
I haven't yet added any more examples, hopefully I'll get round to that in the next week or so. I have been using it as a MIDI interface though, which is fun - I'll get an appropriate example of that out in the next version, together with some diagrams / photos etc.
Thanks for this! I've been using this for a while, and it's certainly nicer than the official libFTDI Python bindings.
ReplyDeleteA note on testing: you'll probably want to use a unit testing framework, like the built-in unittest package. Building test functions directly into your modules could get messy. Unfortunately, complete testing probably requires matching test hardware.
PS: Do you know if it's possible to access the hardware as anyone but root? Adding myself to uucp and tty didn't seem to help.
glad to hear this is working well for you. If you have any comments / feature requests etc don't hesitate to either post them here or put them on the bitbucket page.
ReplyDeletere. testing, I've been lazy I'm afraid - well aware of various test frameworks but haven't got into the habit of regular TDD / mocking etc. I guess the fact that testing would take more code than the package itself has something to do with it...
As far as hardware access is concerned, I have no need for root access on either Mac OS X (10.6) or my EEEPC 701 (Xandros) - I'll try it on my Ubuntu desktop later and see if I can get to the bottom of this - it's the sort of thing which should get into the README. I've not tested it at all under libftdi for Windows and don't plan to (though I might extend it to work with the D2XX DLL with the same API).