Проблемы с VCP в Windows

[juvf]

Программа через USB-VCP общается с железкой. Для СОМ порт используется QSerialPort.
Подключил железку по USB, в винде появился COM порт,  запустил программу, открыл порт - работаешь. Закрыл порт, закрыл программу.... Всё прекрасно... до тех пор, пока не дёрниш USB при открытом порте в программе.
Естественно в программе прекращается обмен данными. А вот дальше проблема: закрыл компорт в программе (остановил обмен), подключил USB обратно, снова появился VCP, в программе пытаюсь открыть СОМ порт - получаю ошибку открытия порта.
Запускаю другую программу, пытаюсь открыть порт - ошибка открытия порта. В общем в системе (в диспетчере устройств) СОМ порт есть, но ни одна программа его открыть не может.

1) Как это лечится?
2) Можно как-то автоматически определить в программе (в QSerialDevice) что открыты СОМ порт более в системе не существует и сделать принудительное закрытие порта?

ps Windows 7 64

[juvf]

ну да ладно.... не хочешь работать по СОМ30, переименовать в СОМ31 и открыть СОМ31....
такое чувство, что после закрытия QSerialPort и самой программы компорт продолжает оставаться открытым

[kuzulis]

Вендопроблемы.

Из моего опыта, выдернутый ком порт остается "занятым" некоторое время (по крайней мере в течении минуты или как то так). Хотя, хз, многое зависит от драйвера.

Как вариант - кикать "зависшее" у-во программно через WinAPI функции, но для этого нужны права админа... Но это дичь какая то.

[tux]

При выдергивании железки из порта, порт остаётся "занятым" не только в оффтопике. В Linux такая же проблема. Разве что интервал "отпускания" другой.

[Old]

При выдергивании железки из порта, порт остаётся "занятым" не только в оффтопике. В Linux такая же проблема. Разве что интервал "отпускания" другой.

В linux устройство сразу исчезает из /dev и момент отключения можно отловить и закрыть порт/прекратить обмен. А после подключения устройства его можно спокойно открыть вновь.

[tux]

В linux устройство сразу исчезает из /dev и момент отключения можно отловить и закрыть порт/прекратить обмен.

Не всегда. Особенно, если в момент выдёргивания был обмен. Какой нибудь /dev/ttyUSBX остаётся на некоторое время. Через некоторое время да, пропадёт. Одно время раздражало, потом плюнул.
gentoo - если интересна OS.

[Old]

Не всегда. Особенно, если в момент выдёргивания был обмен. Какой нибудь /dev/ttyUSBX остаётся на некоторое время. Через некоторое время да, пропадёт. Одно время раздражало, потом плюнул.
gentoo - если интересна OS.

Странно, никогда не сталкивался.

[tux]

Странно, никогда не сталкивался.

Я бы тоже на слово не поверил. Но у меня это наблюдается на домашней машине и на рабочей. Система одинаковая, железка - преобразователь USB-TTL.
Возможно, что время "отваливания" настраивается.

[juvf]

через WinAPI функции

Точно! WinAPI!!!

Запустил свою старую утилиту, там компорт поднят на WinAPI. кагбэ в 3-х строчках код такой

Код:

if(openPort(cbSerialPorts->currentText())
{
   do
   {
      ReadFile(port, buffer, 1, &BytesCnt, NULL);//читаем из порта 1 байт
      if(BytesCnt == 1)
         good();
   }while(timeOut);
    closePort();//закрыть порт
}

timeOut заряжен на 10...100 секунд. компорт в WinAPI заряжен на 1...10 сек

Код:

COMMTIMEOUTS  ct; 
ct.ReadTotalTimeoutConstant=1000;//10000

Если дернуть усб во время ReadFile, то через ReadTotalTimeoutConstant миллисекунд ReadFile() вернёт 0 в BytesCnt. потом, по do повторный вызов ReadFile().... через ReadTotalTimeoutConstant мс ReadFile() возвращяет 0 в   BytesCnt.... и так по кругу, пока через timeOut не выйдем из do-while. После этого порт закрывается closePort().
Если воткнуть железку обратно и опять запустить прогу (хоть на WinAPI, хоть на QSerialPort), то компорт ни кем не занят, открывается и работает.

Т.е. при использовании WinAPI таких траблов в маздае нет, а с QSerialPort есть. (((

[kuzulis]

Т.е. при использовании WinAPI таких траблов в маздае нет, а с QSerialPort есть. (((

Ну, как бы QSerialPort юзает то самое винапи... Сейчас оно юзает ReadFileEx/WriteFileEx ф-ции...
Ты попробуй с ними, а также открой в overlapped режиме, чтоб честно было ))

ЗЫ: Я больше не занимаюсь сериал портом, не сопровождаю его. Так что спрашивай у кутешников
теперь к ним все претензии (они там вроде хотели кишки под винду подшаманить). Там наверно
теперь кто-то из них должен тянуть этот модуль (ну, или выкинут его вообще)

[juvf]

ЗЫ: Я больше не занимаюсь сериал портом, не сопровождаю его. Так что спрашивай у кутешников
теперь к ним все претензии

Я знаю, что ты съехал с сериалПорт-а, это притензия не к тебе, да и вообще это не притензия, это проблема, и может кто уже с такой проблемой сталкивался и как-то её решил?

[juvf]

и как-то её решил?

Вобщем сделал свой QSerialPort с блэкджетом и *юхами обернул WinAPI в QObject-класс. Переопределил только те функции, которые используются в проекте. Кому интересно - пользуйтесь (нехватающие методы можно доопределить). Несколько часов работы  - полёт нормальный. Задергал USB шнурок... - ни разу ком порт "незалип".

[kuzulis]

А попробуй ка пошаманить в COMMTIMEOUTS через QSerialPort::handle(), естественно, после открытия и настройки порта

[juvf]

JSerialPort тоже залип. Сейчас наблюдаю и QSerialPort и WinAPI одинаковое поведение. Нашел алгоритм 100% залипания компорта

1) вткаем железку в ПК
2) открываем компорт
3) выдергиваем усб, тут теряется связь
4) втыкаем усб, порт продолжает быть открытым, связь естественно не востанавливается
5) закрываем компорт
6) открываем компорт - ВСЁ!!! Порт залип. Занят др. приложением.
Можно задергать шнурок - порт не освободиться.

Вычислил танец с бубном, который 100% отлипает компорт
7)выдергиваем усб
8 ) открываем компорт на выдернутом усб. получаем ошибку, такого порта нет. после этого действия порт "освобождается"
9) втыкаем усб
10) открываем порт, работаем.

Т.е. порт залипает если, грубо говоря, вызвать close() на дескриптор порта, который отваливался и сейчас опять есть.