[Interest] [Development] [Proposal] Future QtSerialPort with plugins architecture

[Ch'Gans]

Hi Denis,

Indeed it would be nice to have an extended API for controlling vendor
specific extension in a uniform way.
Switching between RS232/422/485 is a pretty common feature (including
switching b/w full/half duplex, (des)activating termination resistor),
as is controlling a few extra GPIO. These features are not FTDI
specific.
In the past where I made the HW myself, I had the possibility to query
for HW errors too, some TTL/RS level converters offer this feature.
There's as well the possibility to control somehow slew rate
limitation (typ. fast/slow).

Maybe the Serial Port API could be enhanced with "capability" queries
and associated control functions.
Or maybe all of these should be implemented on top of QSP.

Concerning the plugin idea, did you check how QSerialBus is achieving
the discovery and the handling of vendor specifics?

Chris

On 14 February 2016 at 00:24, Denis Shienkov <denis.shienkov at gmail.com> wrote:
> Hi, folks,
>
> I would like to discuss new idea of transition of QtSerialPort to
> an architecture with the plug-ins/backends.
>
> The reason is that we can use different approaches on different
> platforms to enumerating a list of available devices, and to
> implementing a code of I/O engine.
>
> It will simplify a code and its maintenance for developers,
> and also will provide flexibility for users.
>
> = QSerialPortInfo =
>
> For example QSerialPortInfo::availablePorts() can be made with,
> different ways, which I suggest to divide into plug-ins/backends:
>
> * on Windows : [setupapi], wmi, generic
> * on WinCE      : [devmgr]
> * on Linux        : [udev], sysfs, generic
> * on OSX          : [iokit], generic
> * on FreeBSD   : [sysctl], generic
> * on QNX         : [generic?]
> * other Unix    : [generic]
>
> where [...] means that this plugin is preferred/default for this platform.
>
> The user can use/change desired plugin, e.g. via the
> QT_SERIALPORTINFO_PLUGIN environment, or via command line e.g.:
>
> {code}
> set QT_SERIALPORTINFO_PLUGIN=wmi // on windows
> myapp.exe
> {code}
>
> {code}
> export QT_SERIALPORTINFO_PLUGIN=sysfs // on linux
> myapp
> {code}
>
> {code}
> myapp -qspi sysfs // on linux
> {code}
>
> and so on, similar to the Qt's platform backends, like this:
>
> * http://doc.qt.io/qt-5/embedded-linux.html
>
> Currently we have mess-up (mixing-up) multiple approaches in one
> implementation file, via ifdefs and so on, that is looks funny/hard, e.g,:
>
> * on Windows : setupapi + generic
> * on Unix         : udev + sysfs + generic
>
> = QSerialPort =
>
> Here also can be divided to the plugins/backends. E.g. some vendors
> provides own HW chips which is RS232/485/TTL on the physical layer,
> but has own vendor-specific API. An example it is FTDI chip with the
> D2XX API, that is non-standard "serial port" API.
>
> In this case the user can choose desired plugins via other
> QT_SERIALPOR_PLUGIN environment, or via other command line, e.g.:
>
> {code}
> set QT_SERIALPORTINFO_PLUGIN=ftdi
> set QT_SERIALPOR_PLUGIN=ftdi
> myapp.exe
> {code}
>
> {code}
> myapp.exe -qspi ftdi -qsp ftdi
> {code}
>
> Currently, I don't like the current implementation of internal architecture
> of QtSserialPort where the code contains mix from different approaches
> and so on, that is hard and ugly, IMHO.
>
> So, dear community/developers/gurus, what do you think about? :)
>
> BR,
> Denis
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development