QSerialDevice - Библиотека для работы с COM-портами |
Здравствуйте, гость ( Вход | Регистрация )
QSerialDevice - Библиотека для работы с COM-портами |
Litkevich Yuriy |
10.7.2009, 1:45
Сообщение
#11
|
разработчик РЭА Группа: Сомодератор Сообщений: 9669 Регистрация: 9.1.2008 Из: Тюмень Пользователь №: 64 Спасибо сказали: 807 раз(а) Репутация: 94 |
|
|
|
CrazyDeath |
10.7.2009, 21:42
Сообщение
#12
|
Новичок Группа: Новичок Сообщений: 5 Регистрация: 10.7.2009 Пользователь №: 891 Спасибо сказали: 0 раз(а) Репутация: 0 |
Наверно я делаю, что то не правильно но у меня работает асинхронный режим.
правда библиотека qextserialport из CVS. CVS |
|
|
kuzulis |
13.7.2009, 10:48
Сообщение
#13
|
Активный участник Группа: Участник Сообщений: 393 Регистрация: 29.6.2009 Пользователь №: 862 Спасибо сказали: 36 раз(а) Репутация: 7 |
Цитата увидел сегодня сообщение об альтернативе 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 |
13.7.2009, 21:08
Сообщение
#14
|
Новичок Группа: Новичок Сообщений: 5 Регистрация: 10.7.2009 Пользователь №: 891 Спасибо сказали: 0 раз(а) Репутация: 0 |
Цитата 1. теряет байты при приеме - это раз (у меня по крайней мере) У меня на работе, тестирование QextSerialPort проводилось на довольно разном оборудывании от простых встраиваемых компов до экзотических moxa плат потерь или ошибок выше нормы не наблюдалось(1 -2 байта за 48 часов), хотя скоро буду реализовывать протокол обмена с тактом 5 милисекунд вот тогда все точно станет ясно. Цитата 2. не реализован метод ожидания прихода байтов 3. не полностью реализован в принципе асинхронный режим.. т.к. под асинхронным режимом подразумевается еще , помимо OVERLAPPED, и то, что операция чтения должна возвращатся немедленно! Посмотри на этот костыль для QextSerialPort Qt_comport, там все работает через события. Цитата не полностью используется функционал ядра можно поподробнее, какой именно функционал. |
|
|
kuzulis |
14.7.2009, 7:54
Сообщение
#15
|
Активный участник Группа: Участник Сообщений: 393 Регистрация: 29.6.2009 Пользователь №: 862 Спасибо сказали: 36 раз(а) Репутация: 7 |
Цитата У меня на работе, тестирование QextSerialPort проводилось на довольно разном оборудывании от простых встраиваемых компов до экзотических moxa плат потерь или ошибок выше нормы не наблюдалось(1 -2 байта за 48 часов), хотя скоро буду реализовывать протокол обмена с тактом 5 милисекунд вот тогда все точно станет ясно. А у меня в библиотеке не теряет ничего! Ты в QextSerialPort попробуй прочитай 1000 байт - и увидиш всю прелесть Цитата Посмотри на этот костыль для QextSerialPort Qt_comport, там все работает через события. Я видел уже это... Считаю что реализовано действительно через "костыль":
и сравни, как сделано у меня ! Цитата можно поподробнее, какой именно функционал. имеется ввиду для Win32 использование объектов ядра типа WaitFor и т.п. , а для *.nix select и т.п. .. что более правильно чем использования пококов и т.п. для ожидания прихода байтов и т.п. кроме того у меня сделаны проверни возвращаемых значений всех функций, чтобы можно было легко диагностировать где случился касяк! т.к. я создавал библиотеку для более "продвинутого" использования для разнообразных целей - а не так как авторы QextSerialPort и Qt_comport типа чтобы показать что типа что-то работает и то.. работает ли? ИМХО! |
|
|
CrazyDeath |
15.7.2009, 1:14
Сообщение
#16
|
Новичок Группа: Новичок Сообщений: 5 Регистрация: 10.7.2009 Пользователь №: 891 Спасибо сказали: 0 раз(а) Репутация: 0 |
Цитата попробуй прочитай 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 |
15.7.2009, 7:30
Сообщение
#17
|
Профессионал Группа: Участник Сообщений: 1112 Регистрация: 6.3.2009 Из: Ростов-на-Дону Пользователь №: 591 Спасибо сказали: 264 раз(а) Репутация: 44 |
имеется ввиду для Win32 использование объектов ядра типа WaitFor и т.п. , а для *.nix select и т.п. .. что более правильно чем использования пококов и т.п. для ожидания прихода байтов и т.п. Не знаю как в венде, а под линуксом для это использовал QSocketNotifier. Это встроенный в Qt механизм для select. Посмотри, может под линукс и Mac проще сделать через него. |
|
|
kuzulis |
15.9.2009, 8:52
Сообщение
#18
|
Активный участник Группа: Участник Сообщений: 393 Регистрация: 29.6.2009 Пользователь №: 862 Спасибо сказали: 36 раз(а) Репутация: 7 |
Тихо и незаметно вышла в свет новая версия замечательной кросс платформенной библиотеки для работы с последовательными портами (устройствами) 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 |
1.10.2009, 13:00
Сообщение
#19
|
Новичок Группа: Новичок Сообщений: 1 Регистрация: 30.9.2009 Пользователь №: 1127 Спасибо сказали: 0 раз(а) Репутация: 0 |
Библиотека хорошая,мне подошла лучше,чем qextserial, но хотелось бы ,чтобы автор разобрался с такой багой. Для проверки переделал пример qespta из qetxserial с применением этой либы. В нем экземпляр порта идет как поле обьекта. Так вот создание и инициализация в конструкторе идет- а вот дальше- любое обращение, и вылет. Чего-то в конструкторе AbstractSerial напутано. Если вместо члена класса обьявить порт как глобальную переменную- все окей.
|
|
|
Elfinit |
3.10.2009, 23:29
Сообщение
#20
|
Участник Группа: Участник Сообщений: 127 Регистрация: 17.3.2009 Из: Казань Пользователь №: 619 Спасибо сказали: 7 раз(а) Репутация: 1 |
Что-то не вижу я на главной "Создать материал". Хотел поделиться простой-примитивной тулзой для просмотра exif-метаданных изображения.
|
|
|
Текстовая версия | Сейчас: 11.12.2024, 12:55 |