James,
many thanks for your response on python bindings.
I suspect you may be user #1 of these bindings excluding myself, so you
get to be the alpha tester. Having you respond is great.
I wouldn't call myself a swig expert either but use it pretty regularly to
give me bindings for which no native python things exist.
I agree that the interface exposed is not very pythonic, but it fulfils
the initial basic needs of getting it to work. As with you I'm only using
a small subset of calls. (it does however appear to be very reliable - I
have yet to break it despite best efforts)
I would expect quite a few optimisations to abound, as the bindings are a
basic interface exposure only.
Can you let me know what you had to rearrange to get it to compile...I
originally went the safe way and provided full defines, but to avoid
maintenance the .i file was modified to avoid duplicating all the defines.
Something may have broken.
I hope I didn't cause any makefile dramas. I must admit I don't use the C
automake tools very often.
I tested compile on a recent swig ( I can't check exact version as my
laptops at work) as well as 1.3.31
History of the bindings was I had a matrix orbital display I wanted
working on a embedded machine which could deal with hot plug regardless of
what other devices were plugged in including other serial interfaces. It
started out as a very quick and dirty, but I thought someone would likely
find it useful eventually as the ftdi chipsets appear to work well and are
reasonably common. (plus the fact that the kernel ftdi interface on the
display needs manual kernel module parameters loaded to get it to work)
I used cstring.i for a while intitially but as I always provide my own own
wrapping class when coding, using cstring macros or having a swig derived
class ends up being relatively unimportant to me. That is my wrapping
library hides all the non-pythonic stuff.
Unfortunately releasing this wrapper with the binding increases
maintenance as one has to manage the class in parallel to the library as
things change. I'm not in a position where I can do this for ever and I'm
sure Thomas does not want this task. Maintaining an *.i file that is
mainly an include is much easier.
I've never tried to see if one can provide a proxy class through swig. The
docs appear to hint that this typically relates to C++ coming from
existing classes. The problem I see is that doing this may require
parallel maintenance to the libftdi source itself.
I would think that with a bit of effort creating a userspace pyserial
equivalent for ftdi chipsets should be quite workable and as you indicate
very very handy.
Regards
tarek
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
|
