[Development] [Proposal] Future QtSerialPort with plugins architecture

Denis Shienkov denis.shienkov at gmail.com
Sun Feb 14 12:42:46 CET 2016


Chris,

 > 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.

At the moment, the QSerialPort provides the handle() method for these 
purposes.
Where the user can do a specific ioctl's on a device handle. I think, it 
is enough.

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

Yes, of course, I have looked how it is doing in QtSerialBus. But, there 
is used a few others ideas...
Besides there still is no any QxxInfo classes to take it as template for 
QSerialPortInfo...
A near template - it is something like QCameraInfo implementation of 
QtMultimedia, IMHO.

BR,
Denis

14.02.2016 2:33, 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




More information about the Development mailing list