QSerialDevice - Библиотека для работы с COM-портами Опции

[kuzulis]

По-моему, нет - использую метод open(AbstractSerial::ReadWrite) - как там по умолчанию не знаю. Посмотрю.

Если просто ReadWrite - то вообще никаких тормозов не должно быть.

Читал, но вскользь. Спасибо за ответ и за библиотеку

Да незачто

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

[panbaraban]

Конечно можно!

Просто есть такой касяк/фича в *.nix , которая заключается в том, что при некорректном завершении программы (например при нажатии ctrl^c) библиотека не удаляет lock-файлы. И поэтому при следующем запуске оно не может открыть порт. Но если теперь еще раз запустить приложение - то порты корректно откроются...

Для меня это пока не существенный касяк, поэтому пока не исправляю его.

Просто необходимо перед закрытием приложения делать close() всем открытым портам и тогда всё будет хорошо.

И снова в тред врываюсь я. Есть у меня переходник USB->RS232. Запускаю прогу, открываю порт. При открытом порте выдергиваю переходник, затем делаю close и удаляю порт.
Далее снова создаю порт и пытаюсь подключиться. Получаю кукиш. Могу подключиться только после перезапуска проги (или если удалить из /var/lock, но не пробовал ещё). Так что косяк иногда существенный, приходится прогу перезапускать, чего нехотелось бы. Поправимо ли это? Или же лучше вручную удалять локи, если таковые имеются, дабы не нарушить работу других устройств итд?
З.Ы. В системе только один подобный переходник(один юсб) , другие физически подключить некуда.

[kuzulis]

Могу подключиться только после перезапуска проги (или если удалить из /var/lock, но не пробовал ещё). Так что косяк иногда существенный, приходится прогу перезапускать, чего нехотелось бы. Поправимо ли это?

В принципе всё поправимо. Пройдитесь дебаггером в момент закрытияи и посмотрите где оно косячит.

В принципе я догадываюсь в чем дело:
--------------------------------------
Суть в том, что за lock/unlock отвечает класс TTYLocker. В него передается имя порта для того, чтобы класс создавал соответствующие ему лок файлы в виде major/minor и имени (т.е. "/LCK.%1.%2" и /LCK..%1), т.е. создается сразу два лок-файла.

Для определения major/minor номера устройства используется POSIX функция stat(...) которая принимает два параметра :
один - имя устройства
второй - буфер куда будет записан major/minor.

Так вот, когда мы открыли порт open(), после этого вызывается метод TTYLocker::lock() , который создает два лок файла в которые записывает некоторые параметры.

Теперь мы закрываем порт close(), после этого вызывается метод TTYLocker::unlock(), который удаляет два лок-файла.

Но всё дело в том, что для получения имен лок-файлов, класс TTYLocker использует только имя самого порта!
Т.е. за это отвечают методы:

QString TTYLocker::getLockFileInNumericForm() const
QString TTYLocker::getLockFileInNamedForm() const

Теперь, если мы вызвали метод close(), и при этом, порт присутствует в системе, то метод

QString TTYLocker::getLockFileInNumericForm() const

вернет корректное имя лок-файла и удалит его.

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

QString TTYLocker::getLockFileInNumericForm() const

вернет пустое имя лок-файла, т.к. самого устройства в системе уже нет, и определить его major/minor не представляется возможным.

В данной ситуации TTYLocker удалит только один лок-файл (из двух), связанный только с именем порта, а лок-файл, связанный с major/minor останется в системе.

Теперь, мы вставляем снова шнурок и пытаемся открыть порт.. НО, класс TTYLocker видит, что уже есть лок-файл с major/minor этого порта и PID (идентификатор процесса использующего порт) равен PID-у нашего приложения, а также этот PID активен!
Поэтому TTYLocker "делает вывод" что порт уже занят!

Поэтому если мы перезапустим приложение, то TTYLocker увидит этот же лок-файл, но в нём PID уже не будет равен PID-у нашего приложения.
Поэтому TTYLocker "делает вывод" что порт свободен!
--------------------------------------

Вот вкратце чисто гипотетическое предположение что происходит.
Я пока не решил еще, правильный ли алгоритм у TTYLocker или нет. Но, хочу заметить, что я "передирал" реализацию TTYLocker из других опен сурц проектов, поэтому не думаю, что она некорректна (хотя ХЗ).

Т.е. временное решение - это в коде TTYLocker закомментировать вообще всё что связано с лок-файлом по major/minor, т.е. в итоге нужно чтобы будет создавался один лок-файл связанный только с именем устройства.
Я пока не буду трогать код, но вы для себя можете это сделать.

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

[Гость_Aleksei_*]

Добрый день
Вопрос к многоуважаемому автору.
Есть ли веские доводы при вызове AbstractSerial::close() не делать автоматом AbstractSerial::flush() ?

[kuzulis]

В смысле? Я ничо не понял.

[BRE]

Камрад спрашивает: происходит ли flush при закрытии порта? И почему?

[panbaraban]

А ещё такой вопрос. Одинаково ли работают релиз и дебаг сборки? У меня почему то не открывается порт если я компилю в релиз сборке, точнее открывается, но очень редко.
Upd: Оказывается у меня руки кривые. Не знаю как удалить сообщение(

Сообщение отредактировал panbaraban - 20.12.2010, 17:06

[Гость_Alexk_*]

Руки, понимаю, лечатся долго, я новичок, но никак не получается юзать либу:

Qt 4.7.0, WinXP sp3

Взял исходники из ветки master, отредактировал BuildLibrary.pro, qserialdevice.pro, qserialdeviceenumerator.pro на предмет CONFIG +=dll (+=staticlib закомментировал),
далее - qmake BuildLibrary.pro, mingw32-make (под виндой).
Переписал .dll и .a в Qt\2010.05\qt\lib, положил рядом с exe.

При запуске вылетает сразу с ошибкой 139 - проблема с точкой входа в dll.

Собирал и непосредственно qserialdevice.pro, удаляя makefile - то же самое.

В проекте INCLUDEPATH += C:\Qt\2010.05\sport\src\qserialdevice, LIBS += -lqserialdevice (c d тоже пробовал)

Ну никак! Помогите, плиз!

[kuzulis]

Как надо:
1. Редактировать нужно только в src.pro

...
#CONFIG += staticlib
CONFIG += dll
...

2. Открываем BuildExamples.pro и собираем всё: и библиотеку и примеры.
3. Если хотим запустить /examples/enumerator, то копируем скомпиленную qserialdevice*.dll к екзешке enumerator*.exe
4. Запускаем QtCommandPromt , переходим к enumerator*.exe и запускаем его.

ЗЫ: эти манипуляции справедливы только в Windows.

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

[Гость_Alexk_*]

Библиотека и примеры компилируются, и сразу запускается AnyMaster, если с нуля, ничего не правя и записав qserialdevice-qserialdevice в например C:\Qt\2010.05, открыть QtCreator`ом BuildExamples.pro и нажать, так сказать, большую зеленую кнопку.

.a помещает в Qt\2010.05\BuildExamples-build-desktop\src\build\debug - это так и должно быть, или должно в Qt\2010.05\qserialdevice-qserialdevice\src ?

Пример так работает.

Если поправить CONFIG в src.pro, либа собирается, но примеры уже не компилит -

mingw32-make: Leaving directory `C:/Qt/2010.05/BuildExamples-build-desktop'

obj/anymaster.o: In function `AnyMaster':

C:\Qt\2010.05\BuildExamples-build-desktop\examples\anymaster/../../../qserialdevice-qserialdevice/examples/anymaster/anymaster.cpp:30: undefined reference to `operator<<(QDebug, AbstractSerial::BaudRate)'

и т.д. Вероятно, это нормально.

.dll помещает опять в Qt\2010.05\BuildExamples-build-desktop\src\build\debug.

С полученной .dll моя прога работать не хочет, опять 139 ошибка (там только создание экземпляра класса, больше совсем ничего, и #include <abstractserial.h>, как в примере, и dll лежит рядом с ехе), а примеры проверить не могу.


Охотно проверю любую версию)