On May 5, 2009, at 5:59 AM, tarek@xxxxxxxxxxxxxxx wrote:
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 think the change I had to make was moving the %include "ftdi.h" down
to the bottom after the main block of definitions. I think the issue
I ended up encountering was that the %apply macros weren't working for
me.
I hope I didn't cause any makefile dramas. I must admit I don't use
the C
automake tools very often.
Nope. I'm not very familiar with autotools either, so I'm planning
not to touch anything outside of the .i file if I can.
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)
Fair enough. It does look like they're usable as-is, and having a
working version of something is preferrable to no Python bindings. I
was thinking a month or so ago about doing something like this myself.
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.
Ah, well, this was something I was debating. I don't care much if the
direct bindings are pythonic or not, but it would be nice to wrap
them. It seems like with a medium amount of work one can make SWIG
provide some nice class-based interfaces to libftdi, but I'm not sure
whether it would be more productive to just leave them as simple as
possible and wrap a class around things, or to bother with the nicer
interface.
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.
Right. I wouldn't commit to this on a long-term basis either :-) I
see the advantage of letting SWIG do some heavy lifting to create
bindings from the header file, while at the same time it should pretty
much work even if libftdi changes a bunch of things.
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.
Yeah. It doesn't have to be based on C++ classes, you can treat
structs as classes (which I think C++ does, kindof, when you compile C
as C++). The maintenance is the tough part.
One thought I've just had in the past couple days though is that there
is now a C++ interface for ftdi. I wonder if basing the SWIG bindings
on these might do some of this task more automatically? I haven't
tried it yet, but I may just see what it spits out. This defers some
of the maintenance responsibility, and might cover a fair amount of
the work that would be necessary in SWIG .i syntax to make classes work.
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.
That's my aim :-) I'll be happy to provide sources for that if I get
it working. I'll take a look at what happens with bindings based on
ftdipp. If that fails, I'll see how complicated it might be to work
with the bare SWIG bindings to make something usable. Having looked
at pyserial, I don't think it will actually be too hard to make a
class that mimics its behavior well enough.
Best.
-jsnyder
--
James Snyder
Biomedical Engineering
Northwestern University
jbsnyder@xxxxxxxxxxxxxx
http://fanplastic.org/key.txt
ph: (847) 448-0386
PGP.sig
Description: This is a digitally signed message part
|
