Создаю библиотеку для работы с последовательными портами. [УШЕЛ ИЗ ПРОЕКТА].

[Old]

Не прокатит. Слишком сложно, да и не пропустят, по крайней мере до Qt 5.3 или Qt 6

Ну это были больше мысли в слух, ну может в далекую перспективу...
А вот попробовать организовать свой нотификатор вполне реально.
И по хорошему, Qt пора переводить с select на epoll и сразу вынести эту обработку в отдельную сущность, что бы в будущем легко можно было менять/расширять.

[b-s-a]

задержка должна зависеть от скорости порта. Например: тебе известно, что за 1 секунду может максимум придти 1000 байт. Предыдущий эвент сработал 0.3 секунды назад. Если сейчас пришло ~300 байт, то передача скорее всего не окончена, поэтому можно "пропустить". Если пришло меньше этого количества, то передача скорее всего закончена (или прерывалась) и нужно уведомить пользователя.

[chagovets]

Столкнулся с такой проблемой: при использовании библиотеки в приложении, запускаемом через удалённый рабочий стол (RDP), срабатывание сигнала readyRead происходит всего один раз. После этого ни какой реакции com-порта. После перезапуска приложения ситуация повторяется.
При локальном запуске приложения подобная ситуация не наблюдается - всё работает как надо.
Сервер Windows Server 2008 R2 Enterprise SP1 x64.
Клиент Windows 7 (64 bit, 32 bit).
Qt 4.8.5
Кто-нибудь сталкивался с подобным?

[Phoenix]

Столкнулся с проблемой с библиотекой, скачанной 27.04.2014.
В WinXP данные отправляются, но не принимаются. Если заменить эту библиотеку на ранее скачанную (кажется 29.03.2014), то все работает.
Еще не пойму почему вызов waitForBytesWritten выдает false, errorString выдает "Протекает наложенное событие ввода/вывода".

[Alex_K]

Аналогично, скачал недавно 5.3RC, перестала работать отправка данных. Первый пакет отправляется, а дальше - Протекает наложенное событие ввода/вывода. При этом слоты не подключены, только 2 раза write и waitForBytesWritten.
Если подкинуть этот исполняемый файл к либам 5.2.0, то работает. Прога, скомпилированная под комплектом 5.2.0, соответственно тоже работает.

[kuzulis]

Пробуйте патч: https://codereview.qt-project.org/#change,78274

1. Устанавливаем Git отсюда: http://git-scm.com/
2. Делаем правый клик мышкой и в контекстном меню выбираем "Git bash here"
3. Из гитовой консоли делаем:

git clone git://gitorious.org/qt/qtserialport.git
cd qtserialport
git fetch https://codereview.qt-project.org/p/qt/qtserialport refs/changes/74/78274/3 && git checkout FETCH_HEAD

3. Смотрим, что изменения появились
4. Пересобираем и устанавливаем QtSerialPort как написано тут: https://qt-project.org/wiki/QtSerialPort#e290b0f84383a96ecdf7f6b720b72092
5. проверяем работу waitForBytesWritten()

[Alex_K]

Почти чудо - заработало сразу после сборки и установки библиотеки с патчем.
В 5.2 имелись еще проблемы такого рода: данные отправлялись, но ответ приходил только после следующего пакета. Это поведение не могу воспроизвести у себя, отпишусь, исправилось ли это в 5.3 с патчем на тех машинах, где было.
В 5.3 заработал вывод приложения под Андроидом, так что более эффективно продолжу эксперименты с подключением к устройству по последовательному порту через блютус.

[kuzulis]

Почти чудо - заработало сразу после сборки и установки библиотеки с патчем.

Тогда, если waitForBytesWritten() заработал, то отпишись плиз здесь: https://bugreports.qt-project.org/browse/QTBUG-36758

Тогда в релиз 5.3.0 можно успеть с этим патчем.. Иначе только в 5.3.1..

[Alex_K]

Отписался, что патч работает, в комментах (больше не нашел, где).

[kuzulis]

Ага, спасибо.

[kuzulis]

Тогда в релиз 5.3.0 можно успеть с этим патчем.. Иначе только в 5.3.1..

Баг закрыт, выйдет в следующей 5.3.1, т.к. в 5.3.0 уже не успеется.

[Alex_K]

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

Что интересно: при первом и последнем подходах у меня на 6 машинах (2 из них виртуальные, есть 32 и 64, от XP до все отрабатывает на ура, но есть 2 машины не у меня, на которых ответ приходит только после посылки второго пакета данных - то есть вместо того, чтобы произвести запрос-ответ я посылаю запрос - пустая команда - и только тогда получаю ответ, сколько ни жди после первой команды. Менял драйвера (FT232), менял версии библиотеки - все то же. А у меня стабильно работает, как на машине с Qt, так и на всех других просто запускается из папки с нужным набором библиотек.

Сегодня выяснил, что на одной из неработающих машинах стояли Касперский (согласно Хабру использующий Qt) и еще программа на Qt, все снес, но результата нет. Система примерно та же, что у меня - Core i3. Вот в упор не вижу отличий и корня проблемы.

Поискал файлы Qt на компьютере - вроде после удаления тех программ файлов нет. Однако файлы от Касперского я так и не нашел, где-то прячет.

Вопрос - может, ты сталкивался с таким поведением? Что можно предпринять?

[kuzulis]

Эмм.. если используются waitForReadyRead()/waitForBytesWritten() (windows), то они некорректно работают, вплоть до qt5.3.0.
Их работа пофикшена (вроде как) в текущем "stable" бранче Git-а (который готовится для qt 5.3.1).

Но последний патч, фиксирующий waitForReadyRead() (т.к.  waitForReadyRead снова отвалился ) еще не принят.
Поэтому можете самостоятельно пересобрать QtSerialPort с этим патчем и проверить работу:

Код:

$ git clone git://gitorious.org/qt/qtserialport.git
$ cd qtseriaport
$ git fetch https://codereview.qt-project.org/p/qt/qtserialport refs/changes/19/86319/2 && git checkout FETCH_HEAD

[Alex_K]

Да тут вот дело в том, что оно не то, что бы совсем не работает, а работает с особенностью - ответ на первый запрос приходит после второго запроса, на второй - после первого и т.д.
Главное - что эта особенность стабильная, т.е. и только с WaitFor..., и с только сигналами/слотами без WaitFor.., и с объектом порта в GUI и не в GUI потоке она соблюдается. Какая-то, вероятно, не зависящая от QSerialPort ошибка, вопрос только в том, что это может быть.
Может ли быть, что где-то зашито срабатывание приема, если таймаута почему-то нет, по следующему пакету?
Ставил буфер чтения в 1 байт, пробовал разные режимы контроля потока (Hard|Soft|No) - без результата.
Не пробовал только вручную ставить RTS/CTS перед отправкой пакета.

UPD почитал описание патча - попробую его, отпишусь.

[Alex_K]

Попробовал патч - результат тот же. Первый ответ от устройства приходит после посылки 2 команды. На 7 машинах в моем доступе все ок, а на 2 вне - такая ерунда.