FTDI D2XX impl

[mikepurvis]

Just throwing this out here for consideration— it may be possible to detect when the connected serial device is a USB FTDI, and switch to using its native API:

http://www.ftdichip.com/Support/Documents/ProgramGuides/D2XX_Programmer's_Guide(FT_000071).pdf

The principal gain would be in readline performance, since the FTDI api provides a "block until character" mechanism. Unfortunately, the present design of Serial has readline provided by the main class rather than the impl, so some re-architecting would be necessary to realise this benefit.

Anyhow, feel free to close this if it's completely out-of-scope.

[wjwwood]

I do this exact abstraction but one level higher in my libsegawyrmp library:

https://github.com/segwayrmp/libsegwayrmp/tree/master/include/segwayrmp/impl

The rmp_serial.h implements the rmp interface using my serial library and the rmp_ftd2xx.h header implements it using the ftd2xx library.

I think this would be a neat feature, but it tends to be a compile time decision, making it a runtime decisions might be more complicated. I would be open to having this, but I am wary about adding a dependency (even optional) to the ftdi library.

[mikepurvis]

Ah, very nice.

Certainly runtime would be ideal, as that's the most transparent to the user. Both the devices I use Serial with are deployed by Clearpath on the other end of FTDI cables, but the devices are very much capable of being connected in other ways, so it would be a shame to have to make a compile time decision about that.

You're much better versed than me in these things, but CMake is capable of detecting whether or not libftdi is available, and then optionally building and installing a serial-impl-linux-ftdi.so plugin if it is. Any detection logic would live in the plugin(s), and only be executed if the plugin loaded successfully. The main quirk is that the decision about which plugin to use couldn't be made until the open() call—this would mean that a not-connected Serial instance would have a pimpl==NULL. The other backends could as easily be conditionally compiled (and deployed) as serial-impl-windows.dll and serial-impl-unix.so. Then, of course, you get into needing a cross-platform library loading solution for the main class.

In any case, it's clearly a pretty major shift in architectural approach for the class. There would have to be a pretty clear advantage in doing so.