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

[kuzulis]

1. Дать возможность назначать любой BaudRate, у меня например есть железка которая нестандартный использует.

С этим я в принципе согласен, но так просто добавить этот функционал не получится... Получится костыль на костыле... Для красивого решения придется оч хорошо подумать и, может быть, это приведет к изменению API библиотеки.
В общем надо подумать.

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

2. Дать возможность назначать структуру DCB напрямую, не все параметры нашел как менять, а железки некоторые капризные попадаются.

С этим не согласен, т.к. ломается кросс-платформенность и появляются ненужные методы и т.п.
Дайте пример конкретных параметров которые нужны для капризных железяк.

[Гость_Виталий_*]

1. Дать возможность назначать любой BaudRate, у меня например есть железка которая нестандартный использует.

С этим я в принципе согласен, но так просто добавить этот функционал не получится... Получится костыль на костыле... Для красивого решения придется оч хорошо подумать и, может быть, это приведет к изменению API библиотеки.
В общем надо подумать.

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

2. Дать возможность назначать структуру DCB напрямую, не все параметры нашел как менять, а железки некоторые капризные попадаются.

С этим не согласен, т.к. ломается кросс-платформенность и появляются ненужные методы и т.п.
Дайте пример конкретных параметров которые нужны для капризных железяк.

Не все железки можно переконфигурировать, ту с которой мне работать приходится спаял какой то "гений", он же видимо придумал и протокол, таких конечно мало, если есть в одном месте, значит есть и где то еще. Я добавил в исходники нужный мне BaudRate, работает, но заметил одну странность, не могу пока понять из за чего, но может из за правки исходников, завтра проверю.

[Litkevich Yuriy]

Дать возможность назначать структуру DCB напрямую

как ты её в Линухе собираешься использовать?

Виталий не цитируй целыми сообщениями.
Смотри Справку по кнопкам и тэгам форума

[Гость_Виталий_*]

как ты её в Линухе собираешься использовать?

Ну да, вообщем то....а так удобно было бы )

kuzulis
Скачал исходники отсюда, версия 0.2.0
И вот заметил странность, ставлю AbstractSerial::BaudRate115200, а под отладчиком вижу что в setBaudRate он уже AbstractSerial::BaudRate128000 и так для любого BaudRate начиная с 9600, все передаются на одну ступень выше. Думал, что это из за того что добавлял нестандартный BaudRate, но заменил оригинальными исходниками, все пересобрал и тоже самое...может я чего то не понимаю....

[kuzulis]

Скачал исходники отсюда, версия 0.2.0
И вот заметил странность, ставлю AbstractSerial::BaudRate115200, а под отладчиком вижу что в setBaudRate он уже AbstractSerial::BaudRate128000 и

Ну, эт мистика прям какая то.
Я 0.2.0 не поддерживаю. Текущая "типо стабильная" это 0.3.0.. Текущая "типо нестабильная" это 0.4.0, которая master ветка.

[Гость_Гость_*]

Использую порты в схеме мастер-слейв. Windows XP Pro SP3, MinGW 4.5.1, Qt 4.7.0
Возникла проблема: во время отправки данных мастером возникает замораживание GUI на несколько секунд. Поскольку я после определенного периода ожидания отправляю запросы вновь и вновь, то окна оказываются постоянно замороженными. Нашел на этом форуме решение проблемы:

Цитата
Третий вопрос:
Произвожу отправку данных в порт функцией qint64 AbstractSerial::write(const char *data, qint64 maxSize)
Каким образом можно задать таймаут на выполнение данной функции, так как в случае ошибки передачи данных поисходит зависание программы,
например, при разрыве кабеля


Ух... тут это наверное возникает изза "режиме с управлением потоком" . Если это так, то я не сталкивался с этими особенностями и даж не представлю куда копать...
Хотя, попробуйте в методе:

void NativeSerialEnginePrivate::prepareOtherOptions()
{
this->cc.dcb.fBinary = true;
this->cc.dcb.fInX = this->cc.dcb.fOutX = this->cc.dcb.fAbortOnError = this->cc.dcb.fNull = false;
}

для this->cc.dcb.fAbortOnError = true; (вместо false)!!!

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

Это я победил, но осталась другая проблема. Использую VSPE - Virtual Serial Port Emulator - программа виртуальных COM-портов.
Создаю пару портов (Pair) в этой программе.
Запускаю программу-мастер (отправляет запросы слейву) - все нормально - порт открылся, запросы идут, GUI в порядке (использую один поток).
Запускаю программу Terminal.exe - она открывает второй порт пары и отображает полученные запросы (эмулирует слейва, но пока не отвечает) - тоже все нормально.
Отправляю любой набор байт в ответ - программа-мастер зависает на 5 секунд. Как быть? Другие программы подобным недугом не страдают.
Хочу сделать акцент на то, что такая штука возникает с VSPE, а прога очень удобная. Проверял с com0com - все нормально. Теряюсь в догадках. Help!

[Гость_Гость_*]

Еще одно дополнение: использую для чтения данных сигнал readyRead(), в слоте вызываю readAll() и посылаю дальше в программу QByteArray. Может это как-то разъяснит проблему.

[Гость_Гость_*]

Добавил setTotalReadConstantTimeout(1); после открытия порта - проблема вроде бы решилась. Правильно ли я сделал? Можно ли внести это в конструктор класса, как настройку по умолчанию

[kuzulis]

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

Это я победил,

т.е. эта проблема у вас решена? а то я не стал делать this->cc.dcb.fAbortOnError = true; , т.к. тот человек мне так и не ответил, получилось у него или нет.

Возникла проблема: во время отправки данных мастером возникает замораживание GUI на несколько секунд. Поскольку я после определенного периода ожидания отправляю запросы вновь и вновь, то окна оказываются постоянно замороженными.

Так и должно в принципе быть. Вы скорее всего используете режим Unbuffered? Если да - то при чтении данных в этом режиме функция чтения работает в блокирующем режиме, т.е. ждет данных. Поэтому желательно использовать I/O в отдельном потоке или попробовать небуферизированный режим работы или делать processEvent (или как то так).

Отправляю любой набор байт в ответ - программа-мастер зависает на 5 секунд. Как быть? Другие программы подобным недугом не страдают.
Хочу сделать акцент на то, что такая штука возникает с VSPE, а прога очень удобная. Проверял с com0com - все нормально. Теряюсь в догадках.

Попробую разобраться что за беда.

Еще одно дополнение: использую для чтения данных сигнал readyRead(), в слоте вызываю readAll() и посылаю дальше в программу QByteArray. Может это как-то разъяснит проблему.

В смысле?

Добавил setTotalReadConstantTimeout(1); после открытия порта - проблема вроде бы решилась. Правильно ли я сделал? Можно ли внести это в конструктор класса, как настройку по умолчанию

Нет, нельзя. т.к. по умолчанию подразумевается работа в буферизованном режиме, и все таймауты равны 0. Только при работе в режиме Unbuffered они имеют значение (только 0 нельзя в этом режиме ставить). Да и вообще, я специально реализовал эти методы для более гибкой настройки порта и для того, чтобы вручную можно было их подобрать так, чтобы оптимальнее чтение происходило.

Почитайте ка документацию лучше, там я всё это расписал.

[Гость_Гость_*]

т.е. эта проблема у вас решена?

Да, т.е. по всей видимости это правильный способ.

Вы скорее всего используете режим Unbuffered?

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

Почитайте ка документацию лучше, там я всё это расписал.

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