crossplatform.ru

Здравствуйте, гость ( Вход | Регистрация )

44 страниц V  < 1 2 3 4 > »   
Ответить в данную темуНачать новую тему
> QSerialDevice - Библиотека для работы с COM-портами
Litkevich Yuriy
  опции профиля:
сообщение 10.7.2009, 1:45
Сообщение #11


разработчик РЭА
*******

Группа: Сомодератор
Сообщений: 9634
Регистрация: 9.1.2008
Из: Тюмень
Пользователь №: 64

Спасибо сказали: 769 раз(а)




Репутация:   94  


Цитата(CrazyDeath @ 10.7.2009, 5:37) *
QextSerialPort вполне спокойно справляется с асинхронным режимом работы.
в версии qextserialport-1.1 асинхрон был написан только для виндовоза, да и тот закоментирован, как сейчас даже не знаю.
А QSerialDevice, так и не попробовал.
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
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, там все работает через события.

Я видел уже это... Считаю что реализовано действительно через "костыль":
/*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
  опции профиля:
сообщение 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  


Цитата(kuzulis @ 14.7.2009, 8:54) *
имеется ввиду для 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-метаданных изображения.
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение

44 страниц V  < 1 2 3 4 > » 
Быстрый ответОтветить в данную темуНачать новую тему
Теги
Нет тегов для показа


1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0




RSS Текстовая версия Сейчас: 17.1.2018, 4:24