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 [email protected]
