Re: [Libnifalcon-devel] v1.0 - What's left to do

[Stephen S. <rad...@gm...>]

On Thu, Nov 13, 2008 at 1:36 AM, Kyle Machulis (qDot)
<ky...@no...> wrote:
> So, there's two major things that I'd at least like to make a decision
> on before moving to the beta (feature freeze, no new major features) of
> 1.0.
>
> First off is, as always, something silly about the communications. As
> I've geeked out about far too much before, we've got 3 solutions we're
> working with now:
>
> libusb-1.0: Works great on linux. Doesn't even have support anywhere else.
> ftd2xx: Comes with novint on windows, works great there. Iffy on linux
> and mac.
> libftdi: Okish on mac, slow on linux.

So neither solution is so great on mac?  In that case I'd go with
libftdi for now, since it's at least open source and maybe works
better.  If you built a Framework bundle to host the library on mac,
you could even statically link it in or distribute it as part of the
Framework without worry about legal issues.

For Linux, I might include instructions on downloading libusb-1.0,
since it's not usually packaged for any distros yet.  Since it's out
there and works way better than libftdi, I might not even bother
explaining.. just tell people to use libusb-1.0.

Generally I think things will be easier if we just choose the best
option on each platform, instead of supported every possibility.
Generating an error if libusb-1.0 is not found would make it really
clear to a user that they should use it, instead of having it find
libftdi and then leave people wondering why it's so slow.


> I may take a crack at using boost threads and seeing if that makes any
> difference whatsoever, but I'm probably not going to spend too much time
> on it. My really simple loop tester says we still manage 1000hz, but I
> know that's not completely true because we get a LOT of malformed
> packets from libftdi at the moment, due to only reading 16 bytes at a
> time and throwing away anything around that.

Hm, I'm not sure if threading is needed, but possibly some kind of
non-blocking call might be useful instead of runIOLoop always making
you wait for data.  Threads might be the only way to do this.  I
usually try to avoid threads, but in this case it might be a good way
to go.


> There's also the solution of going to a platform specific API for the
> comm driver instead of using libusb/libftdi/ftd2xx. I have no issues at
> all with this, I just don't really want to learn Carbon's USB layer, and
> I'd rather not turn what should be a simple communications core into a
> rosetta stone of platform specific API calls if I don't have to. :)

Heh, it'd be better not to re-invent the wheel.  If you do this, you
might end up contributing mac support to libusb though. :)


> The other problem is the FalconDevice class. I haven't done a very good
> job of reflecting the functionality of the other core classes through
> it. You can see this by all of the calls I make to the internal pointer
> classes. I'm not sure what approach to take with this. I could leave the
> very simple glue functions in (i.e. runIOLoop and the behavior creation
> functions, and really, that's about it), or I could try to make it more
> of the PIMPL type approach I was going for at first. Or I could branch
> off and make a policy based class using the trait types as templates. Or
> I could just move all of the glue classes to the examples and let people
> choose what they want (but I really don't like that idea).
>
> So, if anyone has any ideas on this (or wants me to explain this
> further, because I'm kinda just braindumping here), advice would be
> appreciated. :)

I think I follow you, but personally I don't mind the interface you have so-far.
Can you describe better what functionality is not accessible through
FalconDevice?


Steve