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.shien...@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@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
