[andrewlekar 0]

Сейчас у нас штатно используется COM порт таким образом: софт открывает порт и общается с железом. Если железка перезапускается или просто физически выткнута из порта и воткнута обратно, то ничего страшного не происходит - обмен продолжается с момента подключения железки обратно.

Теперь хотим перетащить железку на USB, сделали USB CDC - всё работает прекрасно. Но если железку рестартануть, то она не может создать уже открытый в софте порт и обмена не происходит. Неужели USB CDC не предназначен для работы в таких условиях? Сделать что-то можно?

[kovigor 5]

Сделать что-то можно?

Если нужна надежность, то о USB лучше сразу забыть. Только настоящий COM - порт на материнке или мультипортовке ...

P.S. У меня вообще создалось впечатление, что USB подходит только для систем с оператором. Например, завис в офисе принтер. Ну и что ? Подошла секретарша и передернула разъем. А вот для систем, которые должны работать автономно, USB не годится ...

[andrewlekar 0]

Ну USB у нас как дополнительный функционал - не основной. Всё же хочется, чтобы пусть и не сильно надёжно, но хотя бы идентично стандартному COM порту работало.

[Сергей Борщ 128]

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

[esaulenka 7]

Сделать что-то можно?

 

а) контора Thesycon делает свой собственный драйвер CDC. Там есть возможность сохранять виртуальный ком-порт при пропадании устройства. (если что - полной версии у меня нету).

б) видел рекомендации отпускать хэнд ком-порта при пропадании устройства, а потом пытаться открыть его обратно. Но это либо не работает совсем, либо наши программисты сделали всё неправильно :)

Грабля от MS: если проделывать эти манипуляции после того, как устройство подключилось обратно, работать ничего не будет - не получится открыть хэндл. Закрывать надо перед тем, как устройство появится обратно.

в) можно перезапускать драйвер CDC. Тоже не самый прямой способ (довольно медленно, требует админских прав).

 

 

Всё вышесказанное - в предположении, что используется Windows.

[Сергей Борщ 128]

Например, завис в офисе принтер.

Вот что у нашей секретарши принтер включен в сервер через USB и работает круглосуточно, что у меня к машине принтер подключен по USB, машина не выключается уже три года и лишь перегружается примерно раз в месяц когда Биллины обновления скопом ставлю, вот ни ей ни мне за все это время ни разу не приходилось передергивать разъем. Что мы делаем не так?

 

[andrewlekar 0]

контора Thesycon делает свой собственный драйвер CDC.

Да, я уже попробовал поставить этот драйвер. Стало работать очень медленно и результата не дало.

видел рекомендации отпускать хэнд ком-порта при пропадании устройства, а потом пытаться открыть его обратно.

Может быть и сработает, но со стороны устройства останется проблема - если есть открытый порт с его номером, то у него енумерация криво проходит. Наверное чинится повторными енумерациями в цикле, но пробовать надо.

[Flexz 0]

Если нужна надежность, то о USB лучше сразу забыть. Только настоящий COM - порт на материнке или мультипортовке ...

Ну не так уж категорично, лучше сказать "если нужна надежность то о USB-CDC лучше сразу забыть" :)

В свое время хватило косяков с ним связанных, начиная от "отваливания" порта и кончая бсодами. Лучше сразу взять libusb - потратить немного времени на изучение, и забыть CDC как страшный сон. С libusb потеря/восстановление связи отрабатываются без проблем (получили таймаут или ошибку - закрываем порт, ждем когда наш девайс пройдет энумерацию, подключаемся снова).

[Сергей Борщ 128]

Лучше сразу взять libusb

Тогда уж лучше libusbx, как развивающееся продолжение libusb. Но это ставит крест на совместимости софта со старыми устройствами, подключающимися через "железный" COM.

 

[=AK= 11]

Но если железку рестартануть, то она не может создать уже открытый в софте порт и обмена не происходит. Неужели USB CDC не предназначен для работы в таких условиях? Сделать что-то можно?

CDC ни причем. Проблема в самой винде, иногда она отмечает устройство как "мертвое", после этого приходится выдернуть устройство из USB и воткнуть снова, тогда винда его заново обнюхает и воспримет.

 

Реальная проблема с CDC состоит в том, что в виндовом драйвере класса сидит тупой детский баг - при передаче массивов длиной более 8 кбайт данные рано или поздно испортятся. А вот драйвер Thesycon работает правильно, с его помощью можно качать массивы любой длины, я проверял.

[andrewlekar 0]

Есть мысль переделать на USB-HID, а COM порт реализовать утилитой снаружи. Как на такой вариант смотрите? Будет не очень шустро, но мне достаточно будет 19200 или около того.

[esaulenka 7]

Тогда уж лучше libusbx, как развивающееся продолжение libusb.

Там вроде б только бэкэнд к "старому" libusb или новому WinUsb от Microsoft.

Надо будет порыть эту тему...

 

 

Вообще, кто какие протоколы поверх USB использует? CDC, действительно, работает... неидеально.

Просто создать своё собственное устройство, вне стандарта, и работать напрямую с bulk'ами?

[andrewlekar 0]

Просто создать своё собственное устройство, вне стандарта, и работать напрямую с bulk'ами?

Я решил делать поверх HID устройства. Без драйверов - утилитой буду создавать вирутальный COM порт и эмулировать обмен. Исходники выложу, когда будет всё готово - может кому пригодится.

 

Я вот только не пойму, если правда присутствует проблема открытия занятого приложением порта, то как сделано общение USB 3G модема с PPP дозвонщиком, например от Мегафона? Если при открытой сессии выдернуть свисток и воткнуть заново он ведь нормально запустится? Или приложение успевает закрыть порт до повторной энумерации?