QSerialDevice - Библиотека для работы с COM-портами Опции

[Litkevich Yuriy]

QextSerialPort вполне спокойно справляется с асинхронным режимом работы.

в версии qextserialport-1.1 асинхрон был написан только для виндовоза, да и тот закоментирован, как сейчас даже не знаю.
А QSerialDevice, так и не попробовал.

[CrazyDeath]

Наверно я делаю, что то не правильно но у меня работает асинхронный режим.
правда библиотека qextserialport из CVS.
CVS

[kuzulis]

увидел сегодня сообщение об альтернативе QextSerialPort
Просмотрев ваши исходники ничего нового, я не увидел, более того
называть вашу библиотеку альтернативой QextSerialPort
не совсем корректно, структура классов и исходников
одинаковая как и у библиотеке QextSerialPort.

Ну дык делал я её в основном брав исходники QextSerialPort . И я сделал максимально аналогичнее
И кстати я в cvs не смотрел, а делал на основе qextserialport-1.1.tar.gz

Намного логичнее было бы оформить ваш труд ввиде
дополнительного класса для QextSerialPort.

Неа, не согласен.

QextSerialPort вполне спокойно справляется с асинхронным режимом работы.

ну если считать, что задействуется структура OVERLAPPED - то можно согласится

Так же я абсолютно не понял преимущества QSerialDevice перед QextSerialPort.

Для QextSerialPort
1. теряет байты при приеме - это раз (у меня по крайней мере)
2. не реализован метод ожидания прихода байтов
3. не полностью реализован в принципе асинхронный режим.. т.к. под асинхронным режимом подразумевается еще , помимо OVERLAPPED, и то, что операция чтения должна возвращатся немедленно!
4. И вообще не полностью используется функционал ядра при работе с последовательным устройством.

И я никого не заставляю использовать QSerialDevice, каждый выбирает сам ! Я просто иногда советую сравнить.

ЗЫ: я могу и еще накопать минусов QextSerialPort По крайней мере для МЕНЯ в моих проектах - QextSerialPort не нужен!

[CrazyDeath]

1. теряет байты при приеме - это раз (у меня по крайней мере)

У меня на работе, тестирование QextSerialPort проводилось на довольно разном оборудывании от простых
встраиваемых компов до экзотических moxa плат
потерь или ошибок выше нормы не наблюдалось(1 -2 байта за 48 часов),
хотя скоро буду реализовывать протокол обмена
с тактом 5 милисекунд вот тогда все точно станет ясно.

2. не реализован метод ожидания прихода байтов
3. не полностью реализован в принципе асинхронный режим.. т.к. под асинхронным режимом подразумевается еще , помимо OVERLAPPED, и то, что операция чтения должна возвращатся немедленно!

Посмотри на этот костыль для QextSerialPort Qt_comport, там все работает через события.

не полностью используется функционал ядра

можно поподробнее, какой именно функционал.

[kuzulis]

У меня на работе, тестирование QextSerialPort проводилось на довольно разном оборудывании от простых
встраиваемых компов до экзотических moxa плат
потерь или ошибок выше нормы не наблюдалось(1 -2 байта за 48 часов),
хотя скоро буду реализовывать протокол обмена
с тактом 5 милисекунд вот тогда все точно станет ясно.

А у меня в библиотеке не теряет ничего!
Ты в QextSerialPort попробуй прочитай 1000 байт - и увидиш всю прелесть

Посмотри на этот костыль для QextSerialPort Qt_comport, там все работает через события.

Я видел уже это... Считаю что реализовано действительно через "костыль":

/*QReceiveThread*/
void ReceiveThread::run()
{
    int count;
    forever 
    {
        msleep(1);
        mutex.lock();
        count = comport->bytesAvailable();
        mutex.unlock();
        if (0 < count)
        {
            emit newDataInPortThread(count);
            QTime timedb;
            qDebug()<<"thread count= "<<count<<"time= "<<"\t"<<timedb.currentTime().second()<<" "<<timedb.currentTime().msec();
        }
    }
}

и сравни, как сделано у меня !

можно поподробнее, какой именно функционал.

имеется ввиду для Win32 использование объектов ядра типа WaitFor и т.п. , а для *.nix select и т.п. .. что более правильно чем использования пококов и т.п. для ожидания прихода байтов и т.п.

кроме того у меня сделаны проверни возвращаемых значений всех функций, чтобы можно было легко диагностировать где случился касяк!
т.к. я создавал библиотеку для более "продвинутого" использования для разнообразных целей - а не так как авторы QextSerialPort и Qt_comport типа чтобы показать что типа что-то работает и то.. работает ли?

ИМХО!

[CrazyDeath]

попробуй прочитай 1000 байт

ты не понял у меня идут потери 1 байт на 4gb,
то есть около 24 часов работы на скоросте 960kb(на moxa плате)
и не повине библиотеки а из-за аппаратуры,
но это норма, всегда есть ошибки.
В usb или tcp/ip на уровне протокола
идет автоматическая коррекция ошибок.
в uart этого нет, по этому люди и удивляются,
а потом реализовывают нормальный протокол обмена.

while (1) {
if (MyDevice->waitForReadyRead(rrto)) {
ba.clear();
ba=MyDevice->read(len);
qDebug() << "Readed is : " << ba.size() << " bytes";
cout << "Rx : ";
printDataToHex(ba);
}
else {
qDebug() << "Timeout read data in time : " << QTime::currentTime();
}

Ну под это, тоже нужно создовать поток.
waitForReadyRead штука конечно хорошая,
но посути делает тоже самое что костыль Qt_comport,
только на уровне ядра системы, что намного лучше,
и теперь возвращаемся с чего начали

Намного логичнее было бы оформить ваш труд ввиде
дополнительного класса для QextSerialPort.

а не так как авторы QextSerialPort и Qt_comport типа чтобы показать что типа что-то работает и то.. работает ли?

Поверь мне на слово, есть очень много проектов которые используют QextSerialPort, и у них все работает.

[BRE]

имеется ввиду для Win32 использование объектов ядра типа WaitFor и т.п. , а для *.nix select и т.п. .. что более правильно чем использования пококов и т.п. для ожидания прихода байтов и т.п.

Не знаю как в венде, а под линуксом для это использовал QSocketNotifier. Это встроенный в Qt механизм для select. Посмотри, может под линукс и Mac проще сделать через него.

[kuzulis]

Тихо и незаметно вышла в свет новая версия замечательной кросс платформенной библиотеки для работы с последовательными портами (устройствами) QSerialDevice v. 0.1.0

В этой версии очень много изменений в отличии от версии 0.0.3, можно сказать, что версия 0.1.0 написана практически с нуля!

Документацию по библиотеке можно найти в самом архиве.

Скачать можно тут:
http://fireforge.net/projects/qserialdevice/
и
http://qt-apps.org/content/show.php?content=112039

[oldcolony]

Библиотека хорошая,мне подошла лучше,чем qextserial, но хотелось бы ,чтобы автор разобрался с такой багой. Для проверки переделал пример qespta из qetxserial с применением этой либы. В нем экземпляр порта идет как поле обьекта. Так вот создание и инициализация в конструкторе идет- а вот дальше- любое обращение, и вылет. Чего-то в конструкторе AbstractSerial напутано. Если вместо члена класса обьявить порт как глобальную переменную- все окей.

[Elfinit]

Что-то не вижу я на главной "Создать материал". Хотел поделиться простой-примитивной тулзой для просмотра exif-метаданных изображения.