QSerialDevice - Библиотека для работы с COM-портами Опции Подписка на тему Сообщить другу Версия для печати Скачать тему Подписка на этот форум Режимы отображения Переключить на: Древовидный Стандартный Переключить на: Линейный

[kuzulis]

Доброго времени суток!

Я создал библиотеку для работы с последовательными портами, которая является альтернативой QextSerialPort и хочу выложить её на этот ресурс..
На главной странице этого сайта написано, что если я хочу чем-то поделиться - то я должен в соответствующем разделе форума об этом заявить.. так вот вопрос: ЧТО это за раздел? И как мне это сделать?

[Litkevich Yuriy]

Сайт:
В боковой панели сайта (http://www.crossplatform.ru/) выбери "Создать материал" -> "Исходники", заполни необходимые.
Если не видишь пункта создать материал, то залогинься на сайте.

Форум:
Административный -> Crossplatform.ru - все о нем -> Обсуждение исходников с сайта

[ViGOur]

На сайте не нужно логинится, достаточно быть залогиненым на форуме и после этого зайти на сайт.

[kuzulis]

Всем спасибо! Отправил запрос.. ждемс

[Litkevich Yuriy]

Отправил запрос..

какой запрос?

[kuzulis]

ну типа с описанием либы , и там сказали что ответ ждать нужно 72 часа

ой! я ошибся.. я на fireforge.net отправил ...

ЗЫ: заработался совсем

[kuzulis]

Всё, теперь и на crossplatform.ru я послал запрос

[Litkevich Yuriy]

послал запрос

у нас нет ни каких запросов, просто пишешь и всё.

См. ещё моё сообщение №2, создай в указаном подфоруме тему. А на сайте сделай ссылку ( в поле "Обсудить на форуме:") на тему в форуме.
Тогда будешь иметь возможность обратной связи с пользователями.

(Посмотри как делает IMPOMEZIA, для своейго чата IMPOMEZIA Simple Chat)


П.С. Новости на сайте ты аж 2 сделал

[ViGOur]

kuzulis, добавил ссылки скачать и обсудить на форуме...

[CrazyDeath]

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

QSerialDevice - реализует:
- асинхронный режим работы с последовательным портом

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

[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-метаданных изображения.

[ViGOur]

Я пока отключил общую авторизацию сайта и форума, ибо глючит она.
Немного подождете и я перенесу все на новую версию сайта и все будет ок.

[rcdimon]

Наблюдаются проблемы при работе с виртуальными COM портами. Что очень плохо для отладки, ведь это часто с компа, где COM портов нет. Я например работаю на ноутбуке. Я создал виртуальный нуль модемный кабель, на одной стороне у меня висит гипертерминал, на другой подключается моя программа. Обмен данными по нуль-модемному кабелю контролируется еще одной софтиной. И это очень удобно для отладки. К сожалению Ваша библиотека не может открыть такой порт, хотя обычный WinAPI работает с ним без проблем, проверено. В чем может быть дело? Может надо просто какие настройки исправить или пару строчек кода? :-) Было бы замечательно

[rcdimon]

Установил другую программу для создания виртуальных COM портов и все заработало ) Извиняюсь за беспокойство )

[kuzulis]

Доброго времени.

Скажите, а что нужно сделать, чтобы обновить информацию о библиотеке QSerialDevice ? т.к. скоро выйдет новая версия и я хочу, чтобы тут (в исходниках или новостях) это выло видно!

[ViGOur]

1. Заходишь в тему: QSerialDevice и так как ты автор, то редактируешь ее.
2. Добавляешь на форум описание...

[kuzulis]

Итак, анонсирую релиз: QSerialDevice v 0.2.0

Изменений много, писать нет смысла, поэтому предоставляю краткую вырезку аннотации:

QSerialDevice - это кросс-платформенная библиотека для работы с последовательными устройствами, которая использует фрэймворк Qt4 (см. http://qt.nokia.com/).

Требования:

OC : Win2K/WinXP/WinVista/Win7 или любой дистрибутив GNU/Linux
Qt4 : >= 4.5.0
Процессор : любой (который поддерживается Qt4)
Компилятор : любой (который поддерживается Qt4)

Заметки:

В силу того, что Я (автор) не имею возможности протестировать библиотеку на всех возможных операционных системах, всех компиляторах, процессорах и т.п. - то возможно что библиотека в некоторых случаях не будет работать .
Библиотека тестировалась только на:
OC : Windows XP Pro Sp3 (win32) и GNU ArchLinux x86_64
Qt4 : от 4.5.3 до 4.6.2
Процессор : AMD Athlon 4400+ 64x2 Socket AM2
Компилятор : gcc, MinGw
Теоретически (с небольшими исправлениями исходного кода) можно добиться того, чтобы библиотека работала и на других платформах.

Библиотека QSerialDevice содержит следующие классы:

• AbstractSerial
• SerialDeviceWatcher
• SerialDeviceInfo

AbstractSerial

Класс AbstractSerial - предоставляет самодостаточный набор методов и свойств для легкой и простой работы с последовательными устройствами (последовательными портами) вашего PC (или другого устройства).
Класс поддерживает следующие возможности:

• устанавливать скорость обмена данными
• устанавливать количество бит данных
• устанавливать количество стоп-бит
• устанавливать режимы контроля четности
• устанавливать режимы контроля потока
• устанавливать таймаут ожидания символа
• записывать данные в последовательное устройство
• читать данные из последовательного устройства
• управлять такими линиями порта как: DTR, RTS
• читать состояния таких линий порта как: CTS, DSR, DCD, RI, RTS, DTR, ST, SR
• автоматически получать нотификацию при:
  
  • приеме хотя бы одного байта (символа) в входной буфер
  • записи последнего байта в выходной буфер
  • изменении состояния последовательного устройства (при ошибках и т.п.)
• получать текущее значение количества байт в приемном буфере
• устанавливать таймаут ожидания прихода хотя бы одного байта (символа) в входной буфер

(более подробно см. описание AbstractSerial и исходный код)

SerialDeviceWatcher

Класс SerialDeviceWatcher - является вспомогательным классом для мониторинга последовательных устройств.
Класс предоставляет следующие возможности:

• получать список имен всех последовательных устройств, которые имеются в системе
• автоматически получать нотификацию при добавлении/удалении какого либо последовательного устройства

(более подробно см. описание SerialDeviceWatcher и исходный код)

SerialDeviceInfo

Класс SerialDeviceInfo - также является вспомогательным классом для получения информации о последовательном устройстве.
Класс предоставляет следующие возможности:

• получать "дружественное" имя интересующего нас последовательного устройства
• получать "описание" интересующего нас последовательного устройства
• получать VID и PID интересующего нас последовательного устройства (experimental)
• проверять интересующее нас последовательное устройство на существование
• проверять интересующее нас последовательное устройство на занятость (блокировку)
• и т.д.

(более подробно см. описание SerialDeviceInfo и исходный код)

Скачать релиз можно с домашней страницы проекта: http://fireforge.net/frs/?group_id=199
Скачать последние срезы SVN: http://fireforge.net/snapshots.php?group_id=199

Сообщение отредактировал kuzulis - 3.3.2010, 19:51

[mezmay]

попробовал...

Сначала написал прогу по получению данных c GPSприемника по COM порту на QextSerialPort, упрощенный фрагмент:
// QextSerialPort
QextSerialPort *port = new QextSerialPort("COM1");
port->setBaudRate(BAUD4800);
port->setFlowControl(FLOW_OFF);
port->setDataBits(DATA_8);
port->setStopBits(STOP_1);
port->setParity(PAR_NONE);
if(port->open(QIODevice::ReadOnly))
QByteArray ba = port->read(100);

получает данные правильно, но иногда очень сильно тормозит на чтении

потом на QSerialDevice, вроде все тоже самое:
// QSerialDevice
AbstractSerial *port = new AbstractSerial();
port->setDeviceName("COM1");
port->setBaudRate(AbstractSerial::BaudRate4800);
port->setFlowControl(AbstractSerial::FlowControlOff);
port->setDataBits(AbstractSerial::DataBits8);
port->setStopBits(AbstractSerial::StopBits1);
port->setParity(AbstractSerial::ParityNone);
if(port->open(QIODevice::ReadOnly | QIODevice::Unbuffered))
QByteArray ba = port->read(100);

- получает некорректные данные... почему? Даже если QIODevice::Unbuffered убрать

Причина редактирования: Убрал гигантскую цитату

[Litkevich Yuriy]

mezmay, не было ни какой нужды цитировать целое сообщение.
См. справку: Справка по кнопкам и тэгам форума

[kuzulis]

mezmay,

Задание:
прочитать внимательнее документацию QSerialDevice и посмотреть внимательнее примеры QSerialDevice и найти отличия c тем что у вас и с тем что там

[Гость_dekar_*]

Хм. тут проблемка выползла. Он как-то не особо охотно разблокирует порты при ->close();

Linux: NativeSerialEnginePrivate::nativeOpen(QIODevice::OpenMode mode)
-> function: lockDevice(lockFileName) returned: false. Error!

Linux: NativeSerialEnginePrivate::nativeClose()
-> fd == -1. Error!

После чего, конечно же, повторно не открывает, но и не работает. Руками убираю lock-файл. Есть мысль, где копать?

[kuzulis]

Берите последний срез SVN, там эта проблема вроде решена... Да и поотключал я в этом срезе вывод отладки, чтоб не мозолил глаза. Проверьте.

[Гость_Гость_*]

Берите последний срез SVN, там эта проблема вроде решена... Да и поотключал я в этом срезе вывод отладки, чтоб не мозолил глаза. Проверьте.

Увы. SVN просто не собирается.

Раскрывающийся текст

/usr/lib64/qt/bin/moc -DQT_NO_DEBUG -DQT_CORE_LIB -DQT_SHARED -I/usr/lib64/qt/mkspecs/linux-g++-64 -I. -I/usr/lib64/qt/include/QtCore -I/usr/lib64/qt/include -Iqserialdevice -Iqserialdeviceinfo -Iqserialdevicewatcher -Ibuild/lib/qintegratedserialdevice/moc qserialdevice/abstractserial.h -o build/lib/qintegratedserialdevice/moc/moc_abstractserial.cpp
g++ -c -m64 -pipe -O2 -fPIC -Wall -W -D_REENTRANT -DQT_NO_DEBUG -DQT_CORE_LIB -DQT_SHARED -I/usr/lib64/qt/mkspecs/linux-g++-64 -I. -I/usr/lib64/qt/include/QtCore -I/usr/lib64/qt/include -Iqserialdevice -Iqserialdeviceinfo -Iqserialdevicewatcher -Ibuild/lib/qintegratedserialdevice/moc -o build/lib/qintegratedserialdevice/obj/moc_abstractserial.o build/lib/qintegratedserialdevice/moc/moc_abstractserial.cpp
build/lib/qintegratedserialdevice/moc/moc_abstractserial.cpp:12:2: error: #error "The header file 'abstractserial.h' doesn't include <QObject>."
In file included from build/lib/qintegratedserialdevice/moc/moc_abstractserial.cpp:10:
build/lib/qintegratedserialdevice/moc/../../../../qserialdevice/abstractserial.h:43: error: expected class-name before '{' token
build/lib/qintegratedserialdevice/moc/../../../../qserialdevice/abstractserial.h:44: error: 'Q_OBJECT' does not name a type
In file included from build/lib/qintegratedserialdevice/moc/moc_abstractserial.cpp:10:
build/lib/qintegratedserialdevice/moc/../../../../qserialdevice/abstractserial.h:220: error: expected ')' before '*' token
build/lib/qintegratedserialdevice/moc/../../../../qserialdevice/abstractserial.h:307: error: 'd_func' is not a type
build/lib/qintegratedserialdevice/moc/../../../../qserialdevice/abstractserial.h:307: error: ISO C++ forbids declaration of 'Q_PRIVATE_SLOT' with no type
build/lib/qintegratedserialdevice/moc/../../../../qserialdevice/abstractserial.h:309: error: expected ';' before 'void'
build/lib/qintegratedserialdevice/moc/moc_abstractserial.cpp:49: error: 'QMetaObject' does not name a type
build/lib/qintegratedserialdevice/moc/moc_abstractserial.cpp:54: error: expected initializer before '*' token
build/lib/qintegratedserialdevice/moc/moc_abstractserial.cpp:59: error: no 'void* AbstractSerial::qt_metacast(const char*)' member function declared in class 'AbstractSerial'
build/lib/qintegratedserialdevice/moc/moc_abstractserial.cpp:67: error: 'int AbstractSerial::qt_metacall' is not a static member of 'class AbstractSerial'
build/lib/qintegratedserialdevice/moc/moc_abstractserial.cpp:67: error: 'QMetaObject' has not been declared
build/lib/qintegratedserialdevice/moc/moc_abstractserial.cpp:67: error: expected primary-expression before 'int'
build/lib/qintegratedserialdevice/moc/moc_abstractserial.cpp:67: error: expected primary-expression before 'void'
build/lib/qintegratedserialdevice/moc/moc_abstractserial.cpp:67: error: initializer expression list treated as compound expression
build/lib/qintegratedserialdevice/moc/moc_abstractserial.cpp:68: error: expected ',' or ';' before '{' token
make: *** [build/lib/qintegratedserialdevice/obj/moc_abstractserial.o] Error 1

[kuzulis]

Увы. SVN просто не собирается.

Упс... Вы плавы.

1. Скачайте тут: http://fireforge.net/scm/viewvc.php/trunk/...ce&view=log

файл abstractserial.h ревизии 98!!!
(Он отличается только от этого же файла (ревизии 99) тем, что почему-то в более новом файле (ревизия 99) "слетела" кодировка с UTF-8 на ANSII! QtCreator меня замучал - он виноват )

2. Замените в вашем снапшоте abstractserial.h 99 ревизии на abstractserial.h 98 ревизии +
в файле abstractserial.h 98 ревизии добавьте:

...
#include <QtCore/QObject>
...

Сообщение отредактировал kuzulis - 5.4.2010, 8:15

[Гость_dekar_*]

Ура. SVN я собрал. Првада, проблема всё равнон не решилась.

Закрываю порт. Все дебаги включил.

Status: "Closed::Device is successfully closed. OK!" QDateTime("Mon Apr 5 06:07:58 2010")

Думаю - руль!

Открываю опять:

AbstractSerial::setDeviceName(const QString &deviceName)
-> forbidden to set the name for the open device. Warning!
Status: "Device is already open. Error!" QDateTime("Mon Apr 5 06:08:04 2010")
ERROR: Serial device "/dev/ttyUSB0" can not be opened!

[kuzulis]

Лана, вечером доковыряю

[kuzulis]

Вроде исправил.. Пробуйте!

[Гость_dekar_*]

Теперь мне надо до работы доползти :)
А это будет не раньше четверга. Качать SVN?

[kuzulis]

Качать SVN?

Да.

[Гость_dekar_*]

Увы. Опять тот же симптом.

[Гость_Гость_*]

Нет, огромное спасибо! Всё заработало отлично. Забыл просто проект пересобрать.

[dekar]

Решил всё-таки зарегистрироваться.

Итак
1) serialdeviceinfo.h обёрнут в #ifndef SERIALDEVICEWATCHER_H, что сильно мешает в одном проекте использовать оба класса.
2) Проблемы с lock-файлами остались. Просто теперь класс кладёт на них, что не совсем есть гут.
3) В качестве фичи - советую объединить watcher и info в один класс. Плохо себе представляю watcher без info для использования.f

И ещё тут придумал фичу -
QByteArray readTimeout (int length, int msec)
читает length байт с порта, и их возвращает. Также возвращает те байты, которые успела прочитать за время msec. Удобно для опроса всех портов на предмет наличия определённого ответа.

[Litkevich Yuriy]

QByteArray readTimeout (int length, int msec)
читает length байт с порта, и их возвращает. Также возвращает те байты, которые успела прочитать за время msec. Удобно для опроса всех портов на предмет наличия определённого ответа.

название функции совершенно не ассоциируется с описанием.
Если откинуть аргументы и оставить только имя, то эта функция всего лишь читает величину таймаута, но почему-то возвращает её в неуклюжем виде.
Надо имя пересмотреть

[kuzulis]

1) serialdeviceinfo.h обёрнут в #ifndef SERIALDEVICEWATCHER_H, что сильно мешает в одном проекте использовать оба класса.

исправил

2) Проблемы с lock-файлами остались. Просто теперь класс кладёт на них, что не совсем есть гут.

изменил

3) В качестве фичи - советую объединить watcher и info в один класс. Плохо себе представляю watcher без info для использования.f

нет.. не объединю...

И ещё тут придумал фичу -
QByteArray readTimeout (int length, int msec)
читает length байт с порта, и их возвращает. Также возвращает те байты, которые успела прочитать за время msec. Удобно для опроса всех портов на предмет наличия определённого ответа.

пока не вижу в этом сакрального смысла

[dekar]

Вот и новая проблема. Не знаю, насколько она решаема, но...
Дело в том, что watcher не перехватывает события отключения порта, когда он... открыт. И я понимаю почему, он и из системы не пропадает. Собственно вопрос: можно ли с этим чего-либо сделать. И есть ли такая же проблема в венде?

[Litkevich Yuriy]

не перехватывает события отключения порта

хорошо, если он в системе не пропадает, то как ты определяешь, что он отключен?

[dekar]

хорошо, если он в системе не пропадает, то как ты определяешь, что он отключен?

А очень просто. Надо перехватывать все события udev'а, а не только те, что связаны с rs232 портами. И смотреть, являлось ли отключённое устройство портом.

А может быть есть информация о том, есть ли такая же проблема в венде?

[Litkevich Yuriy]

я использую QxtSerialPort в виндовозе, для отлова отключения преобразователя USB-RS232 при открытом порте всегда проверяю кол-во принятых байт. Драйвер FTDI'ного преобразователя всегда отрицательное значение возвращает.

[dekar]

хм. Удачно. Только проблемка - у меня не FTDI, а програмный UART на меге 8.
usb 2-1: Product: USB-232
usb 2-1: Manufacturer: www.recursion.jp
Буду глядеть, что там с кол-вом принятых байт.

[Litkevich Yuriy]

ну а на ПК у тебя стандартный (аппаратный) COM-порт?

[dekar]

ну а на ПК у тебя стандартный (аппаратный) COM-порт?

Нет, конечно. Мегу подцепил к УСБ, а она уже, в частности, как УСБ -> UART ведёт себя. Очень не хотел делать устройство, которому нужны были дрова. Вот и прикидывается девайс "шнурком"

[kuzulis]

А очень просто. Надо перехватывать все события udev'а, а не только те, что связаны с rs232 портами. И смотреть, являлось ли отключённое устройство портом.

Да так там и работает. Ловятся любые события от UDEV а потом просто смотрим что изменилось в директории /dev, и если там пропало у-во которое является tty* - то мы сообщаем об этом. Значит при выдергивании порта когда он открыт события не приходят от UDEV. Нужно проверить как нибудь попозже.

я использую QxtSerialPort в виндовозе, для отлова отключения преобразователя USB-RS232 при открытом порте всегда проверяю кол-во принятых байт. Драйвер FTDI'ного преобразователя всегда отрицательное значение возвращает.

Так это не означает, что конвертер отключен. Это означает что произошла какая то ошибка ввода - вывода ИМХО.

---
Резюмирую: чтобы реализовать полностью такую фичу как "отлов втыкания/выдергивания" конвертеров в любых состояниях (открыт или закрыт или что-то там еще) необходимо найти те механизмы в ОС которые позволяли бы обнаружить втыкание/извлечение конвертера.

Вот к примеру, если конвертер (порт) закрыт, то его "втыкание/извлечение" в принципе легко отслеживается. Но, если он открыт и в этот момент его мы "выдернули" - то это проблема ОС ! Если в ней еще сохраняется состояние того что порт присутствует - то виноват "индус" который писал ОС!

Если вы найдете механизм, который четко и однозначно определял наличие порта в системе - то я это реализую. Присылайте патчи.. Я только ЗА всеми руками!

[Litkevich Yuriy]

Так это не означает, что конвертер отключен.

само собой. Просто FTDI'ный драйвер гарантирует такое поведение при отключении устр-ва при открытом порте.

Справедливо для виндовоза:
Проблема большинства имитаторов COM-порта: при открытом порте вытаскиваем USB-устройство, далее если мы не закрываем порт и снова вставляем USB-устройство. То - приплыли. Больше мы этим портом воспользоватся не сможем, пока не проделаем следующую процедуру:
1) опять выдёргиваем USB-устройство
2) в диспетчере устройств делаем обновить, соответствующий COM-порт должен исчезнуть из списка
3) Вставляем USB-устройство вновь, оно должно определиться и снова должен появится COM-порт.

Тот трюк который проделываю я:
Если приняли отрицательное кол-во байт, порт сразу закрываю. Т.к. вставка USB-устройства при закрытом порте не приводит к выше описанному криминалу.

Но, если он открыт и в этот момент его мы "выдернули" - то это проблема ОС ! Если в ней еще сохраняется состояние того что порт присутствует - то виноват "индус" который писал ОС!

индус прав. Открытый порт не может исчезнуть вдруг. Т.к. этот ресурс занят программой.

программа не может ни с того ни с сего лишиться ресурса. Представь себе ситуацию:

// ты создал переменную - тоже ресурс
int myvar = 10;
...
// далее ты хочешь воспользоваться ею
int var2 = myvar;
// но вот не задача, ресурс myvar исчез

[dekar]

Да так там и работает. Ловятся любые события от UDEV а потом просто смотрим что изменилось в директории /dev, и если там пропало у-во которое является tty* - то мы сообщаем об этом. Значит при выдергивании порта когда он открыт события не приходят от UDEV. Нужно проверить как нибудь попозже.

---
Резюмирую: чтобы реализовать полностью такую фичу как "отлов втыкания/выдергивания" конвертеров в любых состояниях (открыт или закрыт или что-то там еще) необходимо найти те механизмы в ОС которые позволяли бы обнаружить втыкание/извлечение конвертера.

Вот к примеру, если конвертер (порт) закрыт, то его "втыкание/извлечение" в принципе легко отслеживается. Но, если он открыт и в этот момент его мы "выдернули" - то это проблема ОС ! Если в ней еще сохраняется состояние того что порт присутствует - то виноват "индус" который писал ОС!

Если вы найдете механизм, который четко и однозначно определял наличие порта в системе - то я это реализую. Присылайте патчи.. Я только ЗА всеми руками!

Мы подключаем устройство.

Вот события удева:

CODE

KERNEL[1273928448.612580] add /devices/pci0000:00/0000:00:1d.0/usb2/2-1 (usb)
KERNEL[1273928448.615458] add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0 (usb)
KERNEL[1273928448.622468] add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0/tty/ttyACM0 (tty)
KERNEL[1273928448.622593] add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.1 (usb)
KERNEL[1273928448.622606] add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/usb_device/usbdev2.112 (usb_device)
UDEV [1273928448.626864] add /devices/pci0000:00/0000:00:1d.0/usb2/2-1 (usb)
UDEV [1273928448.627187] add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0 (usb)
UDEV [1273928448.628576] add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.1 (usb)
UDEV [1273928448.640491] add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0/tty/ttyACM0 (tty)
UDEV [1273928448.644527] add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/usb_device/usbdev2.112 (usb_device)

Мы видим, что подключено устройство, связанное с tty

Теперь мы порт открываем, после чего вытаскиваем устройство. Результат:

CODE

KERNEL[1273928469.995045] remove /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0 (usb)
KERNEL[1273928469.995079] remove /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.1 (usb)
KERNEL[1273928469.996906] remove /devices/pci0000:00/0000:00:1d.0/usb2/2-1/usb_device/usbdev2.112 (usb_device)
UDEV [1273928469.996923] remove /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0 (usb)
KERNEL[1273928469.996937] remove /devices/pci0000:00/0000:00:1d.0/usb2/2-1 (usb)
UDEV [1273928469.998121] remove /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.1 (usb)
UDEV [1273928469.999564] remove /devices/pci0000:00/0000:00:1d.0/usb2/2-1/usb_device/usbdev2.112 (usb_device)
UDEV [1273928469.999826] remove /devices/pci0000:00/0000:00:1d.0/usb2/2-1 (usb)

Видно, что ttyACM0 не изчез. Но, если бы мы на прошлой итерации запомнили ещё и /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0/, то тогда мы бы могли сейчас подать сигнал о том, что вынули именно ttyACM0.

Если устройство было подключено до старта watcher'а, то тогда его путь в ядре можно было бы отловить в самом начале, делая табличку интересующих нас устройств, т.е. tty* (да, знаю устройств много. Но, ИМХО, это полезая фича.

[Litkevich Yuriy]

Но, ИМХО, это полезая фича

безусловно.

dekar, решение действительно хорошее, может kuzulis, возьмёт его на заметку.

П.С. по поводу оформления сообщений прочитай тему: Справка по кнопкам и тэгам форума

[dekar]

А ты можешь пока проверить, есть ли сигнал от изчезновения уже открытого порта в венде? На той версии, что уже есть. Ибо у меня пока нет возможности что-то под оной собрать.

И, если не сложно, краткое описание того, как вообще в венде собирать что-то. Там gcc вообще есть? make? Или только их студия? Вот уже поставил себе семёрку в виртуалке.

А править посты тут можно? Что-то я кнопочку не нахожу.

[kuzulis]

А ты можешь пока проверить, есть ли сигнал от изчезновения уже открытого порта в венде? На той версии, что уже есть. Ибо у меня пока нет возможности что-то под оной собрать.

Я проверил под виндой. Да, таже проблемка . Но я знаю как решить.. Просто нужно "слушать" другие ветки реестра и все должно быть нормуль.

И, если не сложно, краткое описание того, как вообще в венде собирать что-то. Там gcc вообще есть? make? Или только их студия? Вот уже поставил себе семёрку в виртуалке.

Дык есть описние . Если используешь MinGW, то сборка ничем не отличается. Но если Студию - то там только nmake вместо make. В общем ничего сложного.

А править посты тут можно? Что-то я кнопочку не нахожу.

А для этого нужно набрать сколько то там постов (вроде)

----

В общем проблему понял, идеи есть. Будем решать в ближайшее время

[Гость_leech_*]

Добрый день! Благодарю за отличный класс для работы с компортом!

Возникла долго не решаемая проблема с приёмом данных из порта, после востановления подключения к порту.
Использую приём по сигналу readyRead()

COMport = new AbstractSerial();
connect(COMport, SIGNAL(readyRead()), this, SLOT(slot_COMPortReadyRead()));

void SCPI_Generator::slot_COMPortReadyRead()
{
    qint64 ba_count= COMport->bytesAvailable();        // Количество пришёдших байт в буффере
    QByteArray ba = COMport->read(ba_count);          // Читаем данные из буфера

    inputBuffer.append(ba);
    if (inputBuffer.contains("\n"))                                 // Если пришёл конец строки
    {
        QString ba_str(inputBuffer);
        inputBuffer.clear();
        logText->append(QString("<b>&gt;</b> %1").arg(ba_str));       // Записываем посылаемые данные в лог
    }
}

При запуске программы открывается и настраивается COMпорт

bool SCPI_Generator::ComPortOpen()
{
    COMport->setDeviceName(comPortName);
    if (COMport->open(QIODevice::ReadWrite | QIODevice::Unbuffered))
    {
        COMport->reset();
        COMport->setBaudRate(QString("%1 baud").arg(comBaudRate));
        COMport->setDataBits(QString("%1 bit").arg(comDataBits));
        COMport->setStopBits(comStopBits);
        COMport->setParity(comParity);
        COMport->setFlowControl(comFlowControl);
        return true;
    }
    else // Ошибка открытия COM порта
    {
        QMessageBox::critical(this, tr("Critical error!"),
                                    tr("Error opened serial device %1.\n"
                                       "Select another COM port.").arg(COMport->deviceName()), QMessageBox::Ok);
        return false;
    }
}

пришедшие данные отлично отображаются. ОДнако, если закрыть COM порт и потом снова открыть, при приёме отображается такая ошибка

Windows: NativeSerialEnginePrivate::nativeSelect(int timeout, bool selectForRead) 
 -> function: ::WaitForSingleObject(ovl.hEvent, timeout < 0 ? 0 : timeout), 
 returned: WAIT_TIMEOUT:  258 . Warning!

и данные не читаются. После этого сигнал readyRead() вообще не эмитируется. Зашел пока в тупик. Заранее благодарю за разъяснения!

[kuzulis]

leech

А попробуйте ка использовать версию библиотеки из SVN. Там по сравнению с 0.2.0 много чего изменилось, внимательно посмотрите примеры и abstractserial.h.
Если и там будет такая-же проблема - то будем разбираться.

Из SVN качайте SVN-клиентом. Описание как это делать находится тут: http://fireforge.net/scm/?group_id=199

Ни в коем случае не жмакайте на ссылку: [Загрузить свежую SVN базу репозитория]
т.к. получите не свежий срез - а 2010/04/05. . (какая то ошибка на сервере/сайте)

Т.е. свежак - это использование клиента!

[Гость_leech_*]

Благодарю! Скачал SVN, пересобрал, поправил вызовы в связи с миграцией класса AbstractSerial с QIODevice на QObject, и всё заработало! Проблема решилась.

[Litkevich Yuriy]

kuzulis, отредактируй пожалуйста первое сообщение темы. Чтобы в нём были актуальные ссылки на проект/исходники.
Т.к. новичкам может быть обременительно читать всю тему в поисках ссылок.

[dekar]

Уже удалось отслеживать отключение уже открытого порта?
Если да, то советую сделать новый snapshot.

[kuzulis]

kuzulis, отредактируй пожалуйста первое сообщение темы. Чтобы в нём были актуальные ссылки на проект/исходники.
Т.к. новичкам может быть обременительно читать всю тему в поисках ссылок.

у меня не появляется ссылки типа "редактировать сообщение"

Уже удалось отслеживать отключение уже открытого порта?
Если да, то советую сделать новый snapshot.

да, но пока только под Windows.

Также обнаружились некоторые проблемы при использовании метода waitForReadyRead() .
Сегфолт наблюдается в Win7 при использовании примера /examples/reader.
Там какая-то фигня с WaitCommEvent и т.п. Но вроде уже проблему победил (сделал костыль).
Скоро обновлю срез.

[Litkevich Yuriy]

kuzulis, такой кнопки: под первым сообщением темы нету?

[kuzulis]

Litkevich Yuriy,
не, нету. только зеленые кнопки типа "создать тему", "цитата" и т.п.

dekar,
всё, добавил изменения в SVN. Пробуйте.

[dekar]

Венда у меня только в виртуалке далеко. Завтра попробую.

[panbaraban]

а получение инфы об устройстве (serialdeviceinfo) у всех нормально работает?

[kuzulis]

а получение инфы об устройстве (serialdeviceinfo) у всех нормально работает?

А вы лучше скажите что не работает лично у вас!
Какая ОС ? Что именно не устраивает?

Конкретики пжлста!!! Конкретики!

[panbaraban]

а получение инфы об устройстве (serialdeviceinfo) у всех нормально работает?

А вы лучше скажите что не работает лично у вас!
Какая ОС ? Что именно не устраивает?

Конкретики пжлста!!! Конкретики!

ось -винда хп сп3

запускаю пример serialdeviceinfo, ввожу COM1 например. В результате - пустые строки, и что самое главное isExists=false.
На линуксе ещё не проверял

[kuzulis]

и что самое главное isExists=false.

значит нету COM1

Кстати, этот порт в мамку встроен или это USB\RS-232 конвертер?

[panbaraban]

и что самое главное isExists=false.

значит нету COM1

Кстати, этот порт в мамку встроен или это USB\RS-232 конвертер?

Он есть, проверил все что были. Конвертер USB\RS-485 тоже не определяется

[kuzulis]

и что самое главное isExists=false.

значит нету COM1

Кстати, этот порт в мамку встроен или это USB\RS-232 конвертер?

Он есть, проверил все что были. Конвертер USB\RS-485 тоже не определяется

хм.. о_О. ,

а посмотрите в реестре, по пути:

HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\services\\Serenum\\Enum

есть ли там что нибудь?

[kuzulis]

Да так там и работает. Ловятся любые события от UDEV а потом просто смотрим что изменилось в директории /dev, и если там пропало у-во которое является tty* - то мы сообщаем об этом. Значит при выдергивании порта когда он открыт события не приходят от UDEV. Нужно проверить как нибудь попозже.

---
Резюмирую: чтобы реализовать полностью такую фичу как "отлов втыкания/выдергивания" конвертеров в любых состояниях (открыт или закрыт или что-то там еще) необходимо найти те механизмы в ОС которые позволяли бы обнаружить втыкание/извлечение конвертера.

Вот к примеру, если конвертер (порт) закрыт, то его "втыкание/извлечение" в принципе легко отслеживается. Но, если он открыт и в этот момент его мы "выдернули" - то это проблема ОС ! Если в ней еще сохраняется состояние того что порт присутствует - то виноват "индус" который писал ОС!

Если вы найдете механизм, который четко и однозначно определял наличие порта в системе - то я это реализую. Присылайте патчи.. Я только ЗА всеми руками!

Мы подключаем устройство.

Вот события удева:

CODE

KERNEL[1273928448.612580] add /devices/pci0000:00/0000:00:1d.0/usb2/2-1 (usb)
KERNEL[1273928448.615458] add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0 (usb)
KERNEL[1273928448.622468] add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0/tty/ttyACM0 (tty)
KERNEL[1273928448.622593] add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.1 (usb)
KERNEL[1273928448.622606] add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/usb_device/usbdev2.112 (usb_device)
UDEV [1273928448.626864] add /devices/pci0000:00/0000:00:1d.0/usb2/2-1 (usb)
UDEV [1273928448.627187] add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0 (usb)
UDEV [1273928448.628576] add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.1 (usb)
UDEV [1273928448.640491] add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0/tty/ttyACM0 (tty)
UDEV [1273928448.644527] add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/usb_device/usbdev2.112 (usb_device)

Мы видим, что подключено устройство, связанное с tty

Теперь мы порт открываем, после чего вытаскиваем устройство. Результат:

CODE

KERNEL[1273928469.995045] remove /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0 (usb)
KERNEL[1273928469.995079] remove /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.1 (usb)
KERNEL[1273928469.996906] remove /devices/pci0000:00/0000:00:1d.0/usb2/2-1/usb_device/usbdev2.112 (usb_device)
UDEV [1273928469.996923] remove /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0 (usb)
KERNEL[1273928469.996937] remove /devices/pci0000:00/0000:00:1d.0/usb2/2-1 (usb)
UDEV [1273928469.998121] remove /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.1 (usb)
UDEV [1273928469.999564] remove /devices/pci0000:00/0000:00:1d.0/usb2/2-1/usb_device/usbdev2.112 (usb_device)
UDEV [1273928469.999826] remove /devices/pci0000:00/0000:00:1d.0/usb2/2-1 (usb)

Видно, что ttyACM0 не изчез. Но, если бы мы на прошлой итерации запомнили ещё и /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0/, то тогда мы бы могли сейчас подать сигнал о том, что вынули именно ttyACM0.

Если устройство было подключено до старта watcher'а, то тогда его путь в ядре можно было бы отловить в самом начале, делая табличку интересующих нас устройств, т.е. tty* (да, знаю устройств много. Но, ИМХО, это полезая фича.

только что проверил работу в Linux при таких обстоятельствах и получил это:

[kuzulis@kuzulis release]$ ./serialdevicewatcher
Please remove or insert a serial device (eg USB/Serial controller) to see the notification.
Devices : ("/dev/ttyS0", "/dev/ttyS1", "/dev/ttyS2", "/dev/ttyS3", "/dev/ttyUSB0")
Devices : ("/dev/ttyS0", "/dev/ttyS1", "/dev/ttyS2", "/dev/ttyS3")
Devices : ("/dev/ttyS0", "/dev/ttyS1", "/dev/ttyS2", "/dev/ttyS3", "/dev/ttyUSB1")

т.е. сначала открыл у-во /dev/ttyUSB0 потом запустил Watcher. Он мне выдал первую строку. Потом я выдернул шнурок - он мне выдал вторую строку в которой этот порт пропал. Далее я опять втыкнул шнурок - он мне показал третью строку /dev/ttyUSB1

как видно, у меня на компе все события обрабатываются "корректно" . хм.. непонятно почему у вас проблемы в Linux

[Litkevich Yuriy]

kuzulis, не цитируй целыми сообщениями - читать тяжело

[panbaraban]

хм.. о_О. ,

а посмотрите в реестре, по пути:

HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\services\\Serenum\\Enum

есть ли там что нибудь?

Уменьшено Р Т‘Р С• 89% 847 x 418 (50.5 килобайт)

[kuzulis]

хм. ну должно работать по идее.

а теперь посмотрите в :

HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Enum\\USB\\Vid_067b&Pid_2303\\5&21b58723&0&1

и в:

HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Enum\\USB\\Vid_067b&Pid_2303\\5&21b58723&0&1\\Device Parameters


Сообщение отредактировал kuzulis - 28.5.2010, 7:42

[panbaraban]

хм. ну должно работать по идее.

а теперь посмотрите в :

HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Enum\\USB\\Vid_067b&Pid_2303\\5&21b58723&0&1

и в:

HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Enum\\USB\\Vid_067b&Pid_2303\\5&21b58723&0&1\\Device Parameters

Как то так вот, например

Уменьшено Р Т‘Р С• 88% 825 x 700 (93.24 килобайт)

[kuzulis]

В принципе все должно работать. Пробегитесь дебаггером в SerialDeviceInfo .

[panbaraban]

В принципе все должно работать. Пробегитесь дебаггером в SerialDeviceInfo .

Пасиба, попробую)

[panbaraban]

Ещё такая бага: если порт открыть, а потом закрыть, то снова открыть его уже не получается. Делал полностью из примера reader.
В начале проги создал объект, при закрытии его не удалял. Затем снова вызываем open и всё, порт больше не открывается. Может быть я что-то не так делаю?

[kuzulis]

Ещё такая бага: если порт открыть, а потом закрыть, то снова открыть его уже не получается. Делал полностью из примера reader.
В начале проги создал объект, при закрытии его не удалял. Затем снова вызываем open и всё, порт больше не открывается. Может быть я что-то не так делаю?

этот баг был в версии 0.2.0 (в релизе). в SVN это должно быть уже пофикшено.

к сожалению пока что fireforge.net лежит и невозможно получить срез.

[panbaraban]

этот баг был в версии 0.2.0 (в релизе). в SVN это должно быть уже пофикшено.

к сожалению пока что fireforge.net лежит и невозможно получить срез.

хм, а я качал с svn в конце мая. попробую перекомпилить....

[panbaraban]

Нет, та же ерунда, причем выборочно. На одном порте работает отлично, а другой невозможно открыть повторно.

[kuzulis]

Нет, та же ерунда, причем выборочно. На одном порте работает отлично, а другой невозможно открыть повторно.

Как качали SVN?
Включите отладочные сообщения (раскомментируйте в *.cpp файлах строки вида: #define blablabla_DEBUG) и посмотрите что оно выводить будет.
Пройдитесь дебагером.

[panbaraban]

Да, качал SVN, ревизия 132 кажется, конец мая.

Windows: NativeSerialEnginePrivate::nativeOpen(AbstractSerial::OpenMode mode) 
 -> trying to open device:  "COM6" 
 
Windows: NativeSerialEnginePrivate::nativeOpen(AbstractSerial::OpenMode mode) 
 -> opened device:  "COM6"  in mode:  3  succesfully. Ok! 
 
Windows: NativeSerialEnginePrivate::nativeClose() 
 -> descriptor is invalid. Error! 

Windows: NativeSerialEnginePrivate::nativeClose() 
 -> descriptor is invalid. Error!

не знает чего закрывать

[kuzulis]

Хм... Вот я сделал пример, который открывает и закрывает порт. У меня все нормально.

Раскрывающийся текст

Cnt = 2
Windows: NativeSerialEnginePrivate::nativeOpen(AbstractSerial::OpenMode mode)
-> trying to open device: "COM3"

Windows: NativeSerialEnginePrivate::detectDefaultFlowControl()
-> undefined flow, this->cc.dcb.fOutxCtsFlow is: 0 , this->cc.dcb.fRtsControl
is: 1 , this->cc.dcb.fInX is: 0 , this->cc.dcb.fOutX is: 0

Windows: NativeSerialEnginePrivate::nativeOpen(AbstractSerial::OpenMode mode)
-> opened device: "COM3" in mode: 3 succesfully. Ok!

Serial device "COM3" open in 3
= Default parameters =
Device name : "COM3"
Baud rate : "1200 baud"
Data bits : "7 bit"
Parity : "None"
Stop bits : "1"
Flow : "Flow control undefined"
Char timeout, msec : 10
= New parameters =
Device name : "COM3"
Baud rate : "115200 baud"
Data bits : "8 bit"
Parity : "None"
Stop bits : "1"
Flow : "Disable"
Char timeout, msec : 50
Serial device "COM3" is closed
Cnt = 1
Windows: NativeSerialEnginePrivate::nativeOpen(AbstractSerial::OpenMode mode)
-> trying to open device: "COM3"

Windows: NativeSerialEnginePrivate::detectDefaultFlowControl()
-> undefined flow, this->cc.dcb.fOutxCtsFlow is: 0 , this->cc.dcb.fRtsControl
is: 1 , this->cc.dcb.fInX is: 0 , this->cc.dcb.fOutX is: 0

Windows: NativeSerialEnginePrivate::nativeOpen(AbstractSerial::OpenMode mode)
-> opened device: "COM3" in mode: 3 succesfully. Ok!

Serial device "COM3" open in 3
= Default parameters =
Device name : "COM3"
Baud rate : "1200 baud"
Data bits : "7 bit"
Parity : "None"
Stop bits : "1"
Flow : "Flow control undefined"
Char timeout, msec : 10
= New parameters =
Device name : "COM3"
Baud rate : "115200 baud"
Data bits : "8 bit"
Parity : "None"
Stop bits : "1"
Flow : "Disable"
Char timeout, msec : 50
Serial device "COM3" is closed
Cnt = 0
Windows: NativeSerialEnginePrivate::nativeOpen(AbstractSerial::OpenMode mode)
-> trying to open device: "COM3"

Windows: NativeSerialEnginePrivate::detectDefaultFlowControl()
-> undefined flow, this->cc.dcb.fOutxCtsFlow is: 0 , this->cc.dcb.fRtsControl
is: 1 , this->cc.dcb.fInX is: 0 , this->cc.dcb.fOutX is: 0

Windows: NativeSerialEnginePrivate::nativeOpen(AbstractSerial::OpenMode mode)
-> opened device: "COM3" in mode: 3 succesfully. Ok!

Serial device "COM3" open in 3
= Default parameters =
Device name : "COM3"
Baud rate : "1200 baud"
Data bits : "7 bit"
Parity : "None"
Stop bits : "1"
Flow : "Flow control undefined"
Char timeout, msec : 10
= New parameters =
Device name : "COM3"
Baud rate : "115200 baud"
Data bits : "8 bit"
Parity : "None"
Stop bits : "1"
Flow : "Disable"
Char timeout, msec : 50
Serial device "COM3" is closed

Я прикрепил проект для теста. Попробуйте его у себя и воспроизведите в этом тесте вашу проблему.

Сообщение отредактировал kuzulis - 9.6.2010, 12:37

Прикрепленные файлы

 test.zip ( 43.26 килобайт ) Кол-во скачиваний: 188

 

[panbaraban]

Скомпилил

Уменьшено Р Т‘Р С• 86% 669 x 489 (69.21 килобайт)

[kuzulis]

а добавте в :

bool NativeSerialEnginePrivate::nativeClose()
{
....
....
....
    
    qDebug() << "closeResult = " << closeResult;// ВОТ ЭТО ДОБАВТЕ!
    return closeResult;
}

что будет выводить в консоль?

Сообщение отредактировал kuzulis - 9.6.2010, 14:04

[panbaraban]

closeResult=true

[kuzulis]

Ну значит какой-то касяк: с ОС или самим железом (портом) или драйвером порта, имхо

[panbaraban]

печально, а QextSerialPort корректно работает.

[kuzulis]

Да.. Странно всё это.

Можно попробовать перед закрытием дескриптора порта (т.е. перед CloseHandle(Handle)) вставить ф-ю: CancelIo(Handle) по аналогии с QextSerialPort и посмотреть что будет. Если вам не трудно - то попробуйте и отпишитесь.

Сообщение отредактировал kuzulis - 9.6.2010, 15:53

[panbaraban]

Помогло!!!
добавляем ::CancelIo(this->hd); перед if (::CloseHandle(this->hd) == 0) в bool NativeSerialEnginePrivate::nativeClose()

[kuzulis]

Итак, я обновил на fireforge.net SVN с учетом послелних постов, а также подчистил и исправил код (где возможно).

Качать так: svn checkout svn://scm.fireforge.net/svnroot/qserialdevice

[Гость_juvf_*]

не заработал qserialdevice месячной давности. Библиотека собралась, а в свой проект не смог прикрутить. Сегодня из svn сделал новый checkout.
Теперь вообще не собирается библиотека.

Microsoft Windows XP [Версия 5.1.2600]
(С) Корпорация Майкрософт, 1985-2001.

D:\Work\qt\serportN\trunk>qmake BuildIntegratedLibrary.pro

D:\Work\qt\serportN\trunk>mingw32-make
makefile:287: warning: overriding commands for target `build/lib/qintegratedseri
aldevice/obj/winregkeyreader.o'
makefile:272: warning: ignoring old commands for target `build/lib/qintegratedse
rialdevice/obj/winregkeyreader.o'
g++ -c -O2 -frtti -fexceptions -mthreads -Wall -DUNICODE -DQT_LARGEFILE_SUPPORT
-DQT_NO_DEBUG -DQT_CORE_LIB -DQT_THREAD_SUPPORT -I"c:\Qt\2010.01\qt\include\QtCo
re" -I"c:\Qt\2010.01\qt\include" -I"qserialdevice" -I"qserialdeviceinfo" -I"qser
ialdeviceinfo" -I"qserialdeviceinfo" -I"qserialdevicewatcher" -I"c:\Qt\2010.01\q
t\include\ActiveQt" -I"build\lib\qintegratedserialdevice\moc" -I"c:\Qt\2010.01\q
t\mkspecs\default" -o build\lib\qintegratedserialdevice\obj\abstractserial.o qse
rialdevice\abstractserial.cpp
qserialdevice\abstractserial.cpp:1: error: stray '\239' in program
qserialdevice\abstractserial.cpp:1: error: stray '\187' in program
qserialdevice\abstractserial.cpp:1: error: stray '\191' in program
mingw32-make: *** [build/lib/qintegratedserialdevice/obj/abstractserial.o] Error
 1

D:\Work\qt\serportN\trunk>

Что я делаю не так?

ps qt4.6.1

[Litkevich Yuriy]

qserialdevice\abstractserial.cpp:1: error: stray '\239' in program

это на начало файла показывает, стало быть кодировка файла не правильная - UTF-8 c маркером, а надо без маркера (UTF-8 without BOM).

kuzulis, перекодируй файлы

[kuzulis]

kuzulis, перекодируй файлы

Ок. Этот долбанный QtCreator меня достал! Я замучался уже перекодировать!
По-ходу придется Ru комментарии вообще убрать и оставить только En шоб не мучатся!

Сообщение отредактировал kuzulis - 17.6.2010, 10:18

[Гость_Гость_*]

qserialdevice\abstractserial.cpp:1: error: stray '\239' in program

это на начало файла показывает, стало быть кодировка файла не правильная - UTF-8 c маркером, а надо без маркера (UTF-8 without BOM).

kuzulis, перекодируй файлы

В общем ни чего не перекодировал, просто открыл проект и QTCreator-e и собрал проект. проект собрался, но с 2-мя варнингами

D:/Work/qt/serportM/trunk/makefile:287: warning: overriding commands for target `build/lib/qintegratedserialdevice/obj/winregkeyreader.o'
D:/Work/qt/serportM/trunk/makefile:272: warning: ignoring old commands for target `build/lib/qintegratedserialdevice/obj/winregkeyreader.o'

как варнинги победить?

[kuzulis]

В общем ни чего не перекодировал, просто открыл проект и QTCreator-e и собрал проект. проект собрался, но с 2-мя варнингами

Понятно, а чем до этого и как собирали?

как варнинги победить?

Да пока никак. Они не мешают.

[Гость_Гость_*]

Понятно, а чем до этого и как собирали?

ээээ,,,, до чего "до этого"? тот что я смог месячной давности собрать? или до того как последний релиз собрал без перекодировки? Вообщем в обоих случаях собирал также как в 94-ом сообщении.
в Windows XP в шеле (cmd.exe). с помощью qt4.6.1 и mingw32-make. Но месяц назад всё собралось из шела, а последний релиз только из креатора.

ps

Microsoft Windows XP [Версия 5.1.2600]
(С) Корпорация Майкрософт, 1985-2001.

C:\Documents and Settings\Прог>qmake -v
QMake version 2.01a
Using Qt version 4.6.1 in C:/Qt/2010.01/qt/lib

C:\Documents and Settings\Прог>mingw32-make -v
GNU Make 3.81
Copyright (C) 2006  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

This program built for i386-pc-mingw32

C:\Documents and Settings\Прог>

ну если нужно могу и кофигурацию компа скинуть

[kuzulis]

в Windows XP в шеле (cmd.exe). с помощью qt4.6.1 и mingw32-make. Но месяц назад всё собралось из шела, а последний релиз только из креатора.

вот только это я и хотел узнать