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

[kuzulis]

Обнадёжьте хотя бы тем, что позже вы попытаетесь найти решение.

Увы, это будет костыль. Тем более, в

возьмите очень старые исходники библиотеки на fireforge.net

это было.

Смотрите, разбирайтесь.

[pastor]

Скачал тарбол qserialdevice_30122010_DTR_RTS.zip и что-то ненахожу я вызова функции SetupDiOpenDevRegKey, наверное по той причине что SerialDeviceEnumerator отсутствует в данном тарболе

[kuzulis]

Скачал тарбол qserialdevice_30122010_DTR_RTS.zip

Ненене. Не качайте вообще ничего с вложений в этой теме, т.к. я на первую страницу (первый мой пост) заливаю промежуточные результаты при добавлении/тестировании новых фич сидя на работе.
Просто у нас (на работе) доступ к TCP/IP портам SVN или GIT закрыт и мне приходится сидя на работе (когда есть свободное время) что-то новое выкладывать таким образом, чтобы потом придя домой взять это отсюда и закоммитить в Git. 

Вот такая беда-беда.

А речь шла про старые исходники библиотеки в  https://fireforge.net/projects/qserialdevice/
там изначально были реализованы уведомления (и всё всё всё) без SetupDiOpenDevRegKey.

[xokc]

Так откуда всё-же брать последние работоспособные версии?

[kuzulis]

Так откуда всё-же брать последние работоспособные версии?

http://gitorious.org/qserialdevice

[b-s-a]

При ознакомлении с кодом библиотеки я обратил внимание на излишнюю ее сложность. Что заставляет очень много сил тратить на поиск нужных функций.
1. Зачем миллион приватных классов? (я так понимаю, класс сдирался с QAbstractSocket, который упоминается троллями, как пример неудачного проектирования)
2. Почему головной класс содержит слово Abstract? Как-будто им пользоваться напрямую нельзя и предполагается несколько вариантов реализации.
3. Зачем QSerialEnumerator следит за изменением списка доступных портов? Неужели это кому-то может быть нужно?!?

[lit-uriy]

п.3 - обсуждался выше

[kuzulis]

1. Зачем миллион приватных классов? (я так понимаю, класс сдирался с QAbstractSocket, который упоминается троллями, как пример неудачного проектирования)

Да, сдирался.
Насчет упоминания о неудачном проектировании ссылочку пжлста.
Насчет милиона приватных классов - пусть пока будет так, хотя, если предложите иной рабочий варант (или хотя бы общую структуру файлов/классов)  я только за.
В принципе, я согласен что их многовато - но пока альтернативы откуда скопипастить нет , тем более, у меня был очень долгий путь к анализу и понимания работы и устройства QAbstractSocket со всеми его плюшками. Не хотелось городить самодельный огород, а хотелось взять готовое и сделать по аналогии, чтобы и поведение совпадало и т.п., тем более ИМХО, QAbstractSocket подходил для этого как никакой другой класс.

2. Почему головной класс содержит слово Abstract? Как-будто им пользоваться напрямую нельзя и предполагается несколько вариантов реализации.

Опять же копипаста и аналогия с сокетами, а также я думал, что кто-нить сможет отнаследоваться от AbstractSerial и реализовать что-нить специфическое. Я даже сам представить не могу что это может быть, но оставил на всякий случай.

3. Зачем QSerialEnumerator следит за изменением списка доступных портов? Неужели это кому-то может быть нужно?!?

Да, нужно. Например чтобы в ГУЕ заполнить именами QComboBox и обновлять его при втыкании/выдергивании USB/Serial конвертера к примеру.
Также некоторые просили реализовать получение Vod, Pid и других вещей для отображения в ГУЕ.


 

[b-s-a]

1. ссылочка
Я не сильно разбираюсь в специфике работы порта под Windows, поэтому могу не учитывать ее особенности. Из-за сильной усложненности QSerialDevice, я начал писать свою реализацию (работает только под *nix).
QSerialPort : QIODevice
QSerialPortPrivate (имеет вариант под *nix и под win32) : QSerialPortPrivateData (общий)
QSerialPortInfo - содержит описание устройства и статический метод получения списка портов
QSerialPortInfoPrivate (имеет вариант под *nix и под win32)
Делал по аналогии с QPrinter.
Задача автоматического уведомления о подключении/отключении устройств не стоит из-за бесполезности. Кому надо, тот может поставить таймер на пол секунды с опросом списка устройств.
2. без комментариев.
3. а стоит ли оно того? На счет deviceId и vendorId я не спорю, может кому-то и пригодится. А вот слежение...


Итак, почему я начал писать свою реализацию всего этого дела? Мне необходимы жесткие временные характеристики и четность Space/Mark. Основная ОС у меня GNU/Linux. По ТЗ я должен отправлять посылки первый байт с битом четности равным 1, остальные с 0. При приеме у меня ограничение в 5 мс между байтами и 20 таймаут ответа. Вроде ничего страшного да? Но вот ядро Linux, например, при выполнении команды tcdrain() делает минимальное ожидание порядка 16 мс, если данные еще не ушли. А мне необходимо поставить четность Mark, отправить первый байт, дождаться завершения отправки, поставить четность Space, отправить остальные данные... Это еще что, а что делать на других *nix, когда четность менять нужно при отправке почти каждого байта (эмуляция Space/Mark через even/odd)?
Под Windows у меня сделать не очень получается. Там как-то оочень заморочено. Тем более, что я не просто хочу не игнорировать существование понятия ошибки четности, а еще дать возможность пользователю задавать способ ее обозначения: пропускать, обнулять, игнорировать, маркировать. Но судя по документации это как-то очень будет сделать нетривиально.

[kuzulis]

1. ссылочка

Прочитал по ссылке.
И не увидел ничего страшного. Вот если Nokia переделает свою реализацию - тогда и я вслед за ними на их примере... По крайней мере это лучше, ИМХО, чем изобретать собственный велосипед и не факт что он будел лучше. Все-таки в Nokia не одна голова трудится над этим - а коллектив.

Также не увидел по ссылке вообще "положительные" отзывы Nokia о реализации каких-нибудь IO классах (унасдедованных от QIODevice), если бы был пример с чего брать - то тогда уже другой разговор.

 

QSerialPort : QIODevice
QSerialPortPrivate (имеет вариант под *nix и под win32) : QSerialPortPrivateData (общий)
QSerialPortInfo - содержит описание устройства и статический метод получения списка портов
QSerialPortInfoPrivate (имеет вариант под *nix и под win32)
Делал по аналогии с QPrinter.

Можно ссылочку на исходники? Или это проприетарщина?

Задача автоматического уведомления о подключении/отключении устройств не стоит из-за бесполезности. Кому надо, тот может поставить таймер на пол секунды с опросом списка устройств.
...
а стоит ли оно того? На счет deviceId и vendorId я не спорю, может кому-то и пригодится. А вот слежение...

Это то все понятно, но таймер это лишняя трата ресурса и процессорного времени (ИМХО).

Я не сильно разбираюсь в специфике работы порта под Windows, поэтому могу не учитывать ее особенности. Из-за сильной усложненности QSerialDevice, я начал писать свою реализацию (работает только под *nix).

Ну, если бы стояла конкретная задача (как у вас) - это одно дело... А вот если стоит задача сделать унифицированный кроссплатформенный класс который бы позволял в "любой" ОС выполнять аналогичные задачи - это другое дело.

ЗЫ: но ИМХО, сколько людей - столько мнений.

[b-s-a]

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

Раз ты прочитал, что было по ссылке написано, то мог обратить внимание на другие требования к коду. В частности, про минимализм интерфейса. Сейчас интерфейс QAbstractSocket содержит методы, настраивающие по текстовым названиям настроек. Это вещь конечно нужная, но при попытке включить в состав Qt ее потребуют удалить.
То что в Nokia целый коллектив трудится, это еще ничего не говорит об отсутствии ошибок. Ошибки будут всегда, даже когда будет трудиться миллион людей. Кто-то поленится подумать на 2 хода вперед, кто-то в силу своих особенностей не сможет...

[juvf]

Может вопрос уже поднимался ...... Как установить у AbstractSerial скорость обмена 230400?

[kuzulis]

Может вопрос уже поднимался ...... Как установить у AbstractSerial скорость обмена 230400?

Код:

...
setBaudRate(230400);
...

Теперь оно должно работать, я недавно добавил возможность устанавливать пользовательскую скорость обмена. Хотя я не проверял, негде проверить.
Попробуйте и отпишитесь.

--
Упс, отставить! Эта скорость является стандартной, поэтому должно без проблем установиться.

[juvf]

Попробуйте и отпишитесь.

Отписываюсь. Попробывать так и не удалось. Я использовал библиотеку 0.2.0. Там нет 230400. Обновился до 0.4.0. Там в справке не увидел 230400, но в *.h вроде есть. но слишлом уж 0.4 отличается от 0.2. Код не компиляется. Придется код перелопатить. Первый косяк... в 0.2 была функция
bool AbstractSerial::setCharIntervalTimeout(int), в 0.4 такой нет, вместо неё есть void AbstractSerial::setCharIntervalTimeout(int). Смотрю хелпник

void AbstractSerial::setCharIntervalTimeout  ( int  usecs = 0 )  

Устанавливает время ожидания прихода символа в приемный буфер последовательного устройства.

Аргументы:
[in] usecs Желаемое время ожидания прихода символа, в мксек.  

Возвращает:
False в случае ошибки.
См. определение в файле abstractserial.cpp строка 1346

Перекрестные ссылки ESetCharIntervalTimeout.

функция по объявлению возвращаяет void, а в хелпе "Возвращает: False в случае ошибки. Не понятно??? могу конечно её использовать как void, но вдруг это ошибка и в следующем релизе эта функция уже будет bool.

[juvf]

Ну и до кучи ещё вопросы

Код:

01346 void AbstractSerial::setCharIntervalTimeout(int usecs)
01347 {
01348     Q_D(AbstractSerial);
01349     if (this->isOpen())
01350         d->serialEngine->setCharReadTimeout(usecs);
01351     else
01352         this->emitStatusString(ESetCharIntervalTimeout);
01353 }

в 0.2 по возвращаемуму булу судил о том, установлен ли таймаут. если ошибка - вываливал юзеру MessageError. Как сейчас это проверяется? В  d->serialEngine->setCharReadTimeout() есть сигнал какой-то?

смотрю сигналы у AbstractSerial

Код:

void AbstractSerial::signalStatus  ( const QString &  status,  
  QDateTime  current  
 )  [signal] 

Этот сигнал автоматически испускается при изменении статуса AbstractSerial. 
Изменение статуса может быть вызвано следующими причинами:

•При ошибках конфигурировании устройства.
•При его открытии/закрытии.
•При ошибках I/O.

Допустим при  открытии/закрытии не нужно не чего делать, а вот при ошибках конфигурировании устройства или при ошибках I/O нужно что-то сделать и пользователя сообщением уведомить. Как отличить излучился сигнал из-за ошибки или из-за открытия/закрытия? Парсить QString&  status?