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

[Bepec]

Мб проблема в их буферах?

У меня вон тоже была проблема с usb конвертером - его встроенный FIFO задерживал и рвал данные с линии. После его отключения, положение выправилось.

PS тот же uport с этими дровами, при интенсивной передаче/приёме БСОД вызывает. Устраивали тут спарринги - посылали друга на друга данные, у кого первого БСОД - тот проиграл

[kuzulis]

Да ХЗ в чем проблема.

А ты каким образом FIFO вырубал?

[kuzulis]

2 Верес, спасибо за участие.

Похоже, проблема так и осталась, см тут и тут, по крайней мере для конвертеров типа:

- USB-SERIAL CH340 wch.cn
- Arduino MEGA 2560 boards (Arduino driver)
- PL2303

Такое впечатление, что там говно-драйвера используются, хотя, может это баг QWinEventNotifier...

PS: А может и мои "кривые"руки

Кстати, для PL2303 проблема вроде бы решилась установкой нового драйвера от Prolific,
логин Guest пароль Guest для доступа на их сайт.

Кто нить, у кого есть этот чип (или любой чип) от Prolific, может протестировать у себя?

[klon4uk]

помогите, скачал qtserial, а как щас его в систему установить не знаю, пробовал собирать , дак ругаеться...
есть у кого нить инструкция ?

[kuzulis]

http://qt-project.org/wiki/QtSerialPort_Russian

[klon4uk]

читал make не делаеться , что надо с qmake сделать не понял

[b-s-a]

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

[kuzulis]

читал make не делаеться , что надо с qmake сделать не понял

Откройв креаторе и собери, раз непонятно.

[Phoenix]

Здравствуйте. Использую последнюю версию QtSerialPort, загруженную с git, и у меня возникает проблема. Упрощенно код выглядит так:

Код:

serialPort.write(buff);
serialPort.waitForBytesWritten(50);
if (serialPort.waitForReadyRead(100)) buff2 = serialPort.readAll();

Через некоторое время (от нескольких минут, до нескольких часов) работы программа выдает segfault. Ошибка появляется только в Linux (в windows не появляется). Вывод отладчика в моент segfault:

0   raise   /lib64/libc.so.6   0   0x7ffff5ac3b05   
1   abort   /lib64/libc.so.6   0   0x7ffff5ac4f86   
2   __libc_message   /lib64/libc.so.6   0   0x7ffff5afe9f7   
3   malloc_printerr   /lib64/libc.so.6   0   0x7ffff5b03ec6   
4   free   /lib64/libc.so.6   0   0x7ffff5b08d4c   
5   QtAddOn::SerialPort::UnixSerialPortEngine::setWriteNotificationEnabled   serialportengine_unix.cpp   878   0x7ffff7bd324d   
6   QtAddOn::SerialPort::SerialPortPrivate::flush   serialport.cpp   140   0x7ffff7bcc164   
7   QtAddOn::SerialPort::SerialPortPrivate::canWriteNotification   serialport.cpp   290   0x7ffff7bcc653   
8   QtAddOn::SerialPort::SerialPort::waitForBytesWritten   serialport.cpp   1306   0x7ffff7bcdb37   
...

т.е. ошибка появляется при вызове waitForBytesWritten->canWriteNotification->flush->setWriteNotificationEnabled->"m_writeNotifier->setEnabled(enable)"
Переменная m_writeNotifier - это QSocketNotifier. Получается что ошибка в Qt или в libc?

Когда я использовал QSerialDevice 2.0, вместо serialPort.waitForBytesWritten(50) было msleep(7), но с QtSerialPort через некоторое время работы это приводит к 100% загрузке одного ядра процессора (и в linux и в windows).
Посоветуйте в каком направлении копать.

Моя конфигурация:
- последовательный порт на материнской плате;
- дистрибутив Calculate 12 (Gentoo)
- ядро linux 3.4.5
- Qt 4.8.2
- glibc 2.14.1-r3

[kuzulis]

Получается что ошибка в Qt или в libc?

вполне возможно

Посоветуйте в каком направлении копать.

Попытаться не использовать методы waitForXXX, они необходимы только если у вас в отдельном потоке крутится I/O и вы не используете сигналы\слоты.

UPD: а вообще, текущая архитектура библиотеки еще несколько кривовата.., планирую в скором времени представить на рассмотрение в Gerrit несколько иную, где не должно быть загрузок CPU и т.п.

[Phoenix]

Попытаться не использовать методы waitForXXX, они необходимы только если у вас в отдельном потоке крутится I/O и вы не используете сигналы\слоты.

У меня в отдельном потоке. Сигналы/слоты удобно использовать когда устройство само шлет данные, или когда обмен идет между двумя программами. В моем случае запрос/ответ, и ответ может сильно запаздывать (и приходить кусками). Еще я думаю что сигналы/слоты будут медленнее чем работа в потоке, возможна я ошибаюсь. Подумаю, может действительно сделаю на сигналах/слотах, но какое преимущество?

планирую в скором времени представить на рассмотрение в Gerrit несколько иную, где не должно быть загрузок CPU и т.п.

Когда одно ядро нагружается на 100%, то программа перестает получать данные. Я думаю что где-то что-то зацикливается, но найти не могу т.к. программа не вылетает и отладчик не выдает место сбоя. Когда все работает нормально, то нагрузка 0%...1%. А чем новая архитектура будет принципиально отличаться? Просто интересно.

[Phoenix]

Сделал на сигнала/слотах и появилась другая неприятность. Как только в GUI прокручиваю мышкой большую таблицу - сразу падает скорость обмена с устройством. Решил оставить версию программы с потоком.

[kuzulis]

Подумаю, может действительно сделаю на сигналах/слотах, но какое преимущество?

Такое, что загрузка CPU может снизиться и креши перестать появляться

А чем новая архитектура будет принципиально отличаться? Просто интересно.

Внутри приватная имплементация изменилась:
- выкинут слой Engine
- выкинут WinCE
- выкинут Symbian
- под *nix переписана подсистема нотификации аналогично тому как они в сокетах написаны, практически 1:1
(но все-равно при использования "нативного" порта на материнской плате при передаче данных загрузка CPU
растет до 10%, если передавать по 256 байт каждые 100 мс)
- под Windows также переписана подсисиема нотификации, теперь она уж точно полностью асинхронная, даже
для ReadFile/WriteFile, теперь вообще 0 ресурсов тратится на I/O (по крайней мере у меня)

Решил оставить версию программы с потоком.

ну ты можешь оставить поток, но использовать сигналы/слоты

[Phoenix]

У меня появилось предположение почему сегфолтится. Я перечитал документацию по потокам Qt, и понял что потоку принадлежат только те объекты, которые созданы в функции run. Объекты созданные в любом другом месте в классе, унаследованном от QThread принадлежат главному потоку. В моем случае получается, что в функции run вызывается объект, созданный в другом потоке, отсюда и проблемы. QObject и все его подклассы не потокобезопасны.

[Phoenix]

ну ты можешь оставить поток, но использовать сигналы/слоты

Сделал, не помогло. Делал так:
1. В функции run создаю объект класса SerialPort, открываю порт.
2. Соединяю сигнал readyRead этого объекта со слотом readData потока.
3. В функции run запускаю цикл обработки событий exec().
Скорость обмена так же падает в момент прокрутки большой таблицы. Не пойму почему. Нагрузка на процессор при этом 10% (эту нагрузку создает таблица, а не порт). Прога работала всю ночь и не упала.