toweroff 1 14 июля, 2016 Опубликовано 14 июля, 2016 · Жалоба Добрый день! Как определить на уровне девайса, "отвалился" (или "что-то зависло") он или нет? В смысле есть какие-то проблемы со связью, драйвером и т.д.? Может быть, SOF перестают приходить или еще что? Нужно в такие моменты "передергивать" устройство Из функционала есть определение USB_5V, коммутация резистора 1.5кОм на +3V3 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
esaulenka 7 14 июля, 2016 Опубликовано 14 июля, 2016 · Жалоба Винда загоняет "неисправное" устройство в suspend, обычно у железки-девайса есть такой статус. SOF'ы в этом случае тоже пропадают, насколько я помню. С не-виндой не экспериментировал. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
HardEgor 71 14 июля, 2016 Опубликовано 14 июля, 2016 · Жалоба Как определить на уровне девайса, "отвалился" (или "что-то зависло") он или нет? В смысле есть какие-то проблемы со связью, драйвером и т.д.? Ну дык, надо прочитать флаги чипа USB. Если чип назовёте, то можно и флаги посмотреть/подсказать. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
toweroff 1 14 июля, 2016 Опубликовано 14 июля, 2016 · Жалоба Ну дык, надо прочитать флаги чипа USB. Если чип назовёте, то можно и флаги посмотреть/подсказать. ну дык все ж примерно то же самое, хочется суть понять а так - NXP да STM, USB у них от модели к модели вроде одинаковое Винда загоняет "неисправное" устройство в suspend, обычно у железки-девайса есть такой статус. SOF'ы в этом случае тоже пропадают, насколько я помню. я примерно так и думал, про Suspend не знал, спасибо Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
GetSmart 0 14 июля, 2016 Опубликовано 14 июля, 2016 (изменено) · Жалоба В (каком-то) режиме ожидания, то бишь в варианте нормы, SOFы не отправляются хостом. Давно читал документацию. Многое не помню. Но предпологаю, что перед входом хоста в такой режим он таки сообщает девайсу об этом. Если не сообщил, то логично считать, что связь нарушилась. А если хост при "нежелании" работать с девайсом по каким-то своим причинам загоняет устройство в такое же ожидание, то как отличить нормальную работу (ожидание) от сбоя связи или чего-то ещё в хосте - вопрос интересный. Изменено 14 июля, 2016 пользователем GetSmart Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
toweroff 1 14 июля, 2016 Опубликовано 14 июля, 2016 · Жалоба В (каком-то) режиме ожидания, то бишь в варианте нормы, SOFы не отправляются хостом. вот у меня и не было зависаний устройств (работают все-таки "в ручном" режиме, SOF видел всегда опять же suspend - это режим ошибки или хост может вгонять девайс в этот режим с дельнейшим выводом из этого состояния? давненько не перечитывал спецификацию :( Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
esaulenka 7 14 июля, 2016 Опубликовано 14 июля, 2016 · Жалоба вот у меня и не было зависаний устройств (работают все-таки "в ручном" режиме, SOF видел всегда опять же suspend - это режим ошибки или хост может вгонять девайс в этот режим с дельнейшим выводом из этого состояния? давненько не перечитывал спецификацию :( Хост может вогнать устройство в suspend, если устройство ему скажет "я умею энергосбережение". Ну и вернуть, соответственно. Я таких устройств не делал :-) Более того, виндовс любит делать suspend на долю секунды при считывании дескрипторов. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
HardEgor 71 14 июля, 2016 Опубликовано 14 июля, 2016 · Жалоба ну дык все ж примерно то же самое, хочется суть понять Хост каждую 1 мс послылает SOF, насколько я помню если 3 раза он не пришел взводится ESOF Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tarbal 4 15 июля, 2016 Опубликовано 15 июля, 2016 · Жалоба На каждое событие в драйвере есть обработчик. Вам нужно посылать из обработчика suspend сообщение апликации. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
toweroff 1 17 июля, 2016 Опубликовано 17 июля, 2016 · Жалоба Хост может вогнать устройство в suspend, если устройство ему скажет "я умею энергосбережение". Ну и вернуть, соответственно. Я таких устройств не делал :-) Более того, виндовс любит делать suspend на долю секунды при считывании дескрипторов. я вот тоже suspend event никак не обрабатываю... Хост каждую 1 мс послылает SOF, насколько я помню если 3 раза он не пришел взводится ESOF ну в эту сторону и смотрю, если не приходят SOF - пора "передергиваться" вопрос в другом - сумеет ли стороннее приложение "на лету" понимать, что COM-порт пропал и находить его заново насколько я помню, Вин7 со стандартным драйвером может и синими соплями расплакаться при открытом порте и вынимании "шнурка" USB-COM :( На каждое событие в драйвере есть обработчик. Вам нужно посылать из обработчика suspend сообщение апликации. причем тут драйвер? я говорю об железяке-девйсе. Драйвер стандартный системный и от железки не зависит по сути, можно, наверное, в вин вкрутить и libusb для CDC, не пробовал. А то бывают проблемы (см. выше) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
=AK= 12 18 июля, 2016 Опубликовано 18 июля, 2016 · Жалоба Хост каждую 1 мс послылает SOF, насколько я помню если 3 раза он не пришел взводится ESOF По спецификации USB может терять до 5 SOF подряд. В реальной жизни бывает и 10 раз подряд теряет, беспричинно, в самых обычных условиях, на столе в оффисе. Что при этом делает Винда - толком неизвестно. Замечено только, что иногда она удаляет виртуальный СОМ порт из реестра. Я не нашел, какими штатными средствами можно было бы надежно детектировать потерю связи. Использую свой вочдог на базе регулярного поллингa устройства со стороны РС. Если запросов долгое время нет, то связь считается потерянной. Восстановить удаленный СОМ порт программным способом невозможно. Поэтому мы перестали пользоваться CDC, используем WinUSB. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 18 июля, 2016 Опубликовано 18 июля, 2016 · Жалоба Восстановить удаленный СОМ порт программным способом невозможно. Поэтому мы перестали пользоваться CDC, используем WinUSB. Неверно все таки не удаляет, а меняет его номер. Для этого есть способы искать номер COM порта по VID и PID и использовать событие WM_DEVICECHANGE Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 215 18 июля, 2016 Опубликовано 18 июля, 2016 · Жалоба По спецификации USB может терять до 5 SOF подряд. В реальной жизни бывает и 10 раз подряд теряет, беспричинно, в самых обычных условиях, на столе в оффисе. Что при этом делает Винда - толком неизвестно. Замечено только, что иногда она удаляет виртуальный СОМ порт из реестра. Помнится несколько лет назад, в одном проекте, использовавшем CypressUSB-драйвер, была большая проблема под WinXP: потери изохронных кадров при некоторых событиях в винде. Конкретно: всегда к таким потерям приводило развёртывание/свёртывание произвольных окон приложений под виндой. Что только ни делал пытаясь победить: и повышал приоритет процесса и тредов до максимальных, и менял установки буферизации изохронной точки - ничего не помогало. Под более старшими виндами проблема не проявлялась, только под WinXP. При развёртывании/свёртывании стабильно происходила потеря изохронных запросов IN-кадров на время до 100мсек (до 100 кадров подряд). Ничего не помогло - пришлось увеличить буферизацию, размер точки и за счёт этого делать "нагон" передачи после такой потери. Насчёт SOF уже не помню - шли они во время такой паузы или нет. Хотя это я думаю скорее баг в драйвере CyUSB. Эти проблемы были с разными устройствами, на разных МК и разных USB-стеках, а проблема аналогичная. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
=AK= 12 18 июля, 2016 Опубликовано 18 июля, 2016 · Жалоба Неверно все таки не удаляет, а меняет его номер. Удаляет. Было, скажем, два ком порта в системе, СОМ1 и СОМ10, а через неделю вдруг остался один СОМ1. Помнится несколько лет назад, в одном проекте, использовавшем CypressUSB-драйвер, была большая проблема под WinXP: потери изохронных кадров при некоторых событиях в винде. Да бог с ними, с изохронными, им разрешено теряться, это изначально заложено в USB и отражено во всей документации. А вот когда балк теряется или портится, это гораздо хуже. А он теряется и портится, причем не на уровне обещанных 10-12, а чуть ли не на уровне 10-6. Причем, насколько я могу судить, порча происходит в микрософтовских драйверах, где-то в глубинах WinUSB. Мы свои пакеты данных покрываем CRC, чтобы обеспечить хоть мало-мальски сносный BER. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 215 18 июля, 2016 Опубликовано 18 июля, 2016 · Жалоба Да бог с ними, с изохронными, им разрешено теряться, это изначально заложено в USB и отражено во всей документации. Это с чего это им разрешено теряться??? Если аппаратная помеха, то да - может. Но при отсутствии помех - с какой стати разрешено?? Где Вы такое углядели в доках? Согласно докам, хост обязан инициировать изохронную транзакцию каждую 1 мс (для USB full speed). И не должен их терять. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
