[jcxz 235]

3 часа назад, mantech сказал:

Отваливается соединение при интенсивном потоке.

А есть уверенность, что проблема именно на стороне драйвера на ПК, а не на стороне МК?

И о каком именно потоке речь? В цифрах?

[mantech 49]

3 часа назад, jcxz сказал:

а не на стороне МК?

Это было уже давно, выяснял, что комп переставал отправлять запросы. После перезагрузки винды все восстанавливалось. Что там происходило - х.з. не спец по потрохам винды, просто поставил FT232RL и забыл об этой проблеме, но там появились другие, но это уже к теме не относится...

[jcxz 235]

37 минут назад, mantech сказал:

Это было уже давно, выяснял, что комп переставал отправлять запросы.

...возможно потому, что прошивка МК не ответила или неправильно ответила на очередной запрос. Или передала не все данные ответа на этот запрос и драйвер просто ждёт оставшихся данных.

Обвинять драйвер, не разобравшись в проблеме - неуместно. Вот если-б вы предоставили лог обмена, однозначно показывающий причину..... А иначе - баги в первую очередь следует искать в своём коде. Да и во вторую очередь - там же. "Не разобрался" == "баг у меня коде".

[GenaSPB 11]

13 hours ago, mantech said:

выяснял, что комп переставал отправлять запросы

Однозначно не ответило/не ответило вовремя/т никогда больше. С bulk endpoints так и будет.
Ситуация легко моделируется. 
Кстати, при перетыкании USB device открытый приложением компорт надо закрывать. Невыполнением этого могу объяснить то что перехзагружаете.

[mantech 49]

1 час назад, GenaSPB сказал:

Кстати, при перетыкании USB device открытый приложением компорт надо закрывать.

Да, я в курсе, но никто тогда ничего не перетыкал, устройство как было вставлено, так и стояло. Обмен прекращался, прога по таймауту перегружала винду, после перезагрузки обмен шел дальше...

1 час назад, GenaSPB сказал:

Однозначно не ответило/не ответило вовремя/т никогда больше.

Устройство отвечало, т.к. если б оно зависало, то перезагрузка компа ничего бы не решила, а давать запросы обязан мастер, т.е. комп.

[GenaSPB 11]

Serial port обслуживается всегда. Вне зависимости от прогоамм. Если ep0 не ответит тоже беда

Короче сутками пашет. 

[GenaSPB 11]

Устройство млогло ответвить с боооольшой задержкой - драйвер говорит хана.
Кстати в W7 гораздо нежнее драйвер чем в 10-ке

[jcxz 235]

1 час назад, mantech сказал:

Да, я в курсе, но никто тогда ничего не перетыкал, устройство как было вставлено, так и стояло. Обмен прекращался, прога по таймауту перегружала винду

Это какое-то крайне странное решение. ...если не сказать больше. А почему к примеру устройство не делало программное отключение/подключение к хосту? Как делают в подобных случаях другие устройства.

ЗЫ: Устройство, которое по своей прихоти, без видимой необходимости, перегружает винду, вызывает одно единственное желание - отправить его в мусорную корзину. Уж извините - говорю как есть.

[mantech 49]

2 часа назад, jcxz сказал:

вызывает одно единственное желание - отправить его в мусорную корзину. Уж извините - говорю как есть.

Вот и отправил, сделал по-другому, на другом железе...

2 часа назад, jcxz сказал:

А почему к примеру устройство не делало программное отключение/подключение к хосту?

Потому, что так нельзя...

 

5 часов назад, GenaSPB сказал:

при перетыкании USB device открытый приложением компорт надо закрывать.

 

[jcxz 235]

3 часа назад, mantech сказал:

Потому, что так нельзя...

Опять как-то странно. Получается что:

7 часов назад, mantech сказал:

Обмен прекращался, прога по таймауту перегружала винду

Прога "перегрузить винду" - может, а по такому же таймауту просто закрыть COM-порт - нет.

Странно это как-то....  

 

К тому-же: работать через CDC - это выбор ваш (или того, кто вам ТЗ готовил). USB вроде как одним CDC не ограничивается. И если выбрать другой способ обмена (не CDC), то и COM-порта закрывать не придётся.

[mantech 49]

2 часа назад, jcxz сказал:

И если выбрать другой способ обмена (не CDC), то и COM-порта закрывать не придётся.

ТЗ просили CDC, но после того, как поняли, что оно "как-то не так работает", решили, что мне, как разработчику виднее, я поставил FT232, с ней стало на порядок стабильнее, потом тему закрыли, в смысле с контроллером на винде и данный вопрос больше не возникал к моему счастью. В последствии, когда нужно было использовать усб, все делал только с HID классом, что мне понравилось куда лучше, в смысле драйверов...

2 часа назад, jcxz сказал:

Прога "перегрузить винду" - может, а по такому же таймауту просто закрыть COM-порт - нет.

Ничего странного, перезагрузка срабатывала всегда, а с открытием\закрытием порта бывали проблемы, вот и выбрал более стабильный способ.

[_3m 7]

В 19.10.2022 в 21:12, jcxz сказал:

Прога "перегрузить винду" - может, а по такому же таймауту просто закрыть COM-порт - нет.

Зависший USB-COM порт нельзя закрыть 😞 В половине случаев помогает передергивание устройства а в остальных спасает только ребут винды.

[jcxz 235]

33 минуты назад, _3m сказал:

Зависший USB-COM порт нельзя закрыть 😞 В половине случаев помогает передергивание устройства а в остальных спасает только ребут винды.

А вы прочитали о чём идёт разговор? "Зависший" по какой причине? По той причине, которая обсуждается здесь - можно.

А таких USB-COM, которые для возобновления работы требуют перезагрузки винды, я за десятилетия работы с ними не встречал ни одного. А работаю с ними постоянно, если что... Или назовите конкретный пример такого USB-COM?

[mantech 49]

1 час назад, jcxz сказал:

я за десятилетия работы с ними не встречал ни одного.

Значит с пролификами не работали, повезло! А мне вот их подсовывали изрядно регулярно, на мой вопрос почему, "дак дешего же!", и вот они могли запросто завесить не то, что ком порт, а весь комп... Причем,если иногда он "повисев" секунд 10-15 сам оживал, то в других случаях только BSOD... Вот такие дела, хотите верьте, хотите нет - дело ваше))

Изменено 21 октября, 2022 пользователем mantech

[GenaSPB 11]

Пролифк это не cdc acm...