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

[kuzulis]

Если я правильно понимаю, смена ветки нужна для корректного слежения за физически подключенными портами в системе?

Нет. Это нужно для этого, пример:

1. Допустим либа 0.2.0
1.0. Запустили SerialDeviceWatcher.
1.1. Открыли порт методом open и работаем с ним.
1.2. Выдернули физически сам usb/serial конвертер из USB порта компутера.

Результат: SerialDeviceWatcher не зафиксирует событие о том что порт извлечен, т.к. записи в реестре для этого порта по путям (в 0.2.0.) останутся неизменными.

2. Допустим либа Git
2.0. Запустили SerialDeviceWatcher.
2.1. Открыли порт методом open и работаем с ним.
2.2. Выдернули физически сам usb/serial конвертер из USB порта компутера.

Результат: SerialDeviceWatcher зафиксирует момент извлечения устройства, т.к. записи по путям (в Git) автоматически удалятся!!!

Может это конечно и лучше, но для каждого нового типа порта вам придется править программу...что тоже не есть хорошо

Ну, за все нужно платить. Это закон природы: в чемто выигрываем, а в чем то проигрываем.
На то и имеются исходники чтобы добавлять туда поддержку новых девайсов.
Тем более, их не стопицот тыщ, а с несколько десятков.
Тем более, если вы соберете библиотеку как *.dll/*.so то вам не придется перекомпилировать все приложение, а только библиотеку!

ethernet2com - это moxa nport 5210 - в диспетчере устройств его нет

ну так и не будет значит и либа детектить эти порты!

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

[good835]

Из документации MOXA NPORT
"Обратите внимание, что виртуальные порты MOXA НЕ отображаются в списке последовательных
портов в «Диспетчере Устройств» Windows. Это нормальное поведение для виртуальных COM-
портов: они не будут отображены в списке устройств Windows, но, при корректной настройке, будут
доступны для работы любому приложению." ???

[kuzulis]

Из документации MOXA NPORT
"Обратите внимание, что виртуальные порты MOXA НЕ отображаются в списке последовательных
портов в «Диспетчере Устройств» Windows. Это нормальное поведение для виртуальных COM-
портов: они не будут отображены в списке устройств Windows, но, при корректной настройке, будут
доступны для работы любому приложению." ???

Ну, имхо, тогда никак не получится.

[kuzulis]

Сегодня добавил новый класс SerialDeviceEnumerator который в будущем должен заменить два класса: SerialDeviceWatcher+SerialDeviceInfo (т.е. я их планирую удалить вообще). В новом классе по идее должны работать любые девайсы.. Прошу потестить.

[Litkevich Yuriy]

класс SerialDeviceEnumerator который в будущем должен заменить два класса: SerialDeviceWatcher+SerialDeviceInfo (т.е. я их планирую удалить вообще)

не согласен с именованием и объединением.
Название SerialDeviceEnumerator удачно и привычно. Он может заменить SerialDeviceInfo
А вот SerialDeviceWatcher всё-таки должен быть автономным (пусть внутри он и обращается к перечислителю портов, его можно сделать дружественным для перечислителя).

[kuzulis]

не согласен с именованием и объединением.

Я тоже сомневался. Просто я "существенно" изменил алгоритм и реализацию SerialDeviceInfo и поэтому "пришлось" их объединить.

А вот SerialDeviceWatcher всё-таки должен быть автономным (пусть внутри он и обращается к перечислителю портов, его можно сделать дружественным для перечислителя).

Поподробнее пжлста.

Сообщение отредактировал kuzulis - 12.8.2010, 20:56

[Litkevich Yuriy]

Поподробнее пжлста.

Я не знаю как он у тебя работает/должен_применятся.
Я думаю, что по аналогии с QFileSystemWatcher. Т.е. подключился к его сигналу, если сигнал сработает, то приложение как-то на него реагирует.

При статической сборке с приложением, если не нужен этот класс, можно его подключать - удобно

[kuzulis]

Я не знаю как он у тебя работает/должен_применятся.

Ну так исходники SerialDeviceEnumerator же есть !

Фишка в том, что в реализации SerialDeviceEnumerator теперь всЁ упрощего и унифицировано, т.е.
при изменении (втыкании/вытыкании) порта теперь автоматом перечисляются все оставшиеся устройства в системе и обновляется инфа о них в мапе

QMap<QString, SerialInfo>

т.е. для получения инфы об нужном у-ве мы в данном случае просто берем уже готовую инфу для интересующего у-ва из мапы и нет необходимости для ее получения вызывать OS API. т.е. если у-во в наличии в мапе - то оно, естественно, в наличии и в ОС!!!

Получается еще удобнее чем было раньше.
Ну подумаешь, что теперь SerialDeviceEnumerator включает в себя Watcher + Info ... Ну и что с того?

Если делать как ты говоришь, то все-равно придется в Watcher включать код от Info и т.п. так какая разница?

[good835]

2 kuzulis,
если можно есть пара вопросов:
1. не получается обработать ошибку установки параметров скорости для порта, для порта на плате задаю скорость которую он не поддерживает 230400 бод, естественно возникает ошибка установки
Windows: NativeSerialEnginePrivate::nativeSetBaudRate(AbstractSerial::BaudRate baudRate)
-> function: ::SetCommConfig(this->m_descriptor, &this->cc, sizeof(COMMCONFIG)) returned: 0. Error
для обработки ошибки делаю так (как у вас в доке)
MyDevice = new AbstractSerial();
MyDevice->enableEmitStatus(true);
connect(MyDevice, SIGNAL(signalStatus(сonst QString,QDateTime)), this, SLOT(DisplayError(QString,QDateTime)));
и
void MyThread::DisplayError(QString& message, QDateTime cur_time){
qDebug() << "State: " << message << ", in time: " << cur_time.time().toString(); }
но в слот DisplayError я не попадаю, скорее всего, что это мой косяк, но пока не понимаю где...

2. можно ли сформировать список скоростей передачи поддерживаемых портом, аналогичный Диспетчер Устройств/Последовательный порт/Свойства/Параметры/Скорость передачи, что бы дать выбор при задании параметров порта, а не отлавливать ошибки при задании неверной конфигурации?

[kuzulis]

2 good835

1.

не получается обработать ошибку установки параметров скорости для порта,

Т.е. вообще никакие ошибки не отлавливаются или только при установке скорости?

2.

можно ли сформировать список скоростей передачи поддерживаемых портом, аналогичный Диспетчер Устройств/Последовательный порт/Свойства/Параметры/Скорость передачи, что бы дать выбор при задании параметров порта, а не отлавливать ошибки при задании неверной конфигурации?

Попробуйте использовать Win32 API ф-ю: GetCommProperties или что-нибудь подобное. Но не факт что оно получится. Иного решения я не знаю.
Но это не кроссплатформенное решение и поэтому я не буду это реализовывать (по крайней мере пока)