Hello Shane,
>I would have expected to see a method to determine supported rates though.
>This would give a list of rates supported by a given port on the system.
>e.g.
>QList<qint32> supportedRates()
It would have been done long ago if it was possible.
But this is impossible, OS's does not provide such interfaces.
If you know the way to do it - then we can discuss it.
>I have seen high speed UART used as a peripheral connection in
embedded systems.
>
>You need to consider how data rates are reported for USB ACM classes
and Bluetooth serial port profile >connections that look like a (RS232)
serial port to the system.
As I repeated the above, it can not be done, at least cross-platform.
On Windows there is a possibility, but not the fact that it is
implemented correctly.
In any case, what's stopping you to do just setRate() and see the result
returned?
>The UART has four control lines: RTS/CTS and DTR/DSR, two inputs and
two outputs.
>
>Your API only represents RTS and DTR, and seems to use them as both
the output - setRts(), and as the input -- rts(), >rtsChanged()
>You have included these signal lines in the API so they can be used
for out of band signalling / GPIO as opposed to >flow control which
would be handled at the device driver level. I think the input signals
and output signals need to >be separated in the API.
Why divide by Input / Output?
So it is clear that you can only control the RTS and DTR, that goes
without saying.
Another thing, that also the OS for these outputs is provides interface
to get their condition,
so, why not use it? :)
>For the rate property, what was the reason not to name it baudRate?
>That's probably a familiar term to people working with serial ports.
Besause baudRate is too long. :)
Best regards,
Denis
23.01.2013 21:22, [email protected] ?????:
QSerialPortInfo API looks mostly good.
I would have expected to see a method to determine supported rates though.
This would give a list of rates supported by a given port on the system.
e.g.
QList<qint32> supportedRates()
I have seen high speed UART used as a peripheral connection in
embedded systems.
You need to consider how data rates are reported for USB ACM classes
and Bluetooth serial port profile connections that look like a (RS232)
serial port to the system.
On QSerialPort I have some small concerns.
The UART has four control lines: RTS/CTS and DTR/DSR, two inputs and
two outputs.
Your API only represents RTS and DTR, and seems to use them as both
the output - setRts(), and as the input -- rts(), rtsChanged()
You have included these signal lines in the API so they can be used
for out of band signalling / GPIO as opposed to flow control which
would be handled at the device driver level. I think the input signals
and output signals need to be separated in the API.
For the rate property, what was the reason not to name it baudRate?
That's probably a familiar term to people working with serial ports.
--
*From:*[email protected]
[mailto:[email protected]]
*On Behalf Of *Laszlo Papp
*Sent:* 10 January 2013 19:47
*To:* Thiago Macieira
*Cc:* [email protected]
*Subject:* Re: [Development] Proposal - QtSerialPort graduation from
the Playground
API headers:
http://qt.gitorious.org/qtplayground/qtserialport/blobs/master/src/serialport/serialport.h
http://qt.gitorious.org/qtplayground/qtserialport/blobs/master/src/serialport/serialportinfo.h
Docs:
http://qt.gitorious.org/qtplayground/qtserialport/blobs/master/src/serialport/serialport.cpp
http://qt.gitorious.org/qtplayground/qtserialport/blobs/master/src/serialport/serialportinfo.cpp
Examples:
http://qt.gitorious.org/qtplayground/qtserialport/trees/master/examples
On Wed, Jan 9, 2013 at 10:37 PM, Thiago Macieira
<[email protected] <mailto:[email protected]>> wrote:
On quarta-feira, 9 de janeiro de 2013 21.18.40 <tel:2013%2021.18.40>,
Laszlo Papp wrote:
> Another try: can we reiterate this question for 5.1?
Can you post the API headers and a link to the docs and examples, so
we can do
an API review?
--
Thiago Macieira - thiago.macieira (AT) intel.com <http://intel.com>
Software Architect - Intel Open Source Technology Center
_______________________________________________
Development mailing list
[email protected] <mailto:[email protected]>
http://lists.qt-project.org/mailman/listinfo/development
------------------------------------------------------------------------
This message is for the designated recipient only and may contain
privileged, proprietary, or otherwise private information. If you have
received it in error, please notify the sender immediately and delete
the original. Any other use of the e-mail by you is prohibited.
Where allowed by local law, electronic communications with Accenture
and its affiliates, including e-mail and instant messaging (including
content), may be scanned by our systems for the purposes of
information security and assessment of internal compliance with
Accenture policy.
______________________________________________________________________________________
www.accenture.com
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development