Экспериментатор (09.09.2017 23:58, просмотров: 7624)-
- О, родилась мысль по поводу надежной связи через USB. Ставим адаптер Ethernet-RS232, ставим USB хост от FTDI, ну собственно дивайс. Контроллер дивайса сбрасывает отдельно стоящий хост и информирует приложение через второй эзернетовский адаптер. Ну vllv(33 знак., 11.09.2017 12:59)
- Не поможет. - PlainUser(11.09.2017 07:31)
- А бывают ли случаи, когда FTDI (FT232RL) входит в "клинч", не выходя из него даже после сброса питания? А то она у меня после неудачно поставленного драйвера опознается, но передает одни лишь бинарные нули на любом baud rate. И перенос на другой Ксения(88 знак., 10.09.2017 16:02 - 16:45)
- Не, это драйвер поддельную микруху раком поставил. Пути исправления есть. - POV_(10.09.2017 16:14,
)
- Правильно ли я вас поняла, что бывает такой "рак", который от отключения питания не исчезает? - Ксения(10.09.2017 16:47)
- Не, это драйвер поддельную микруху раком поставил. Пути исправления есть. - POV_(10.09.2017 16:14,
- Я так понимаю молчание, что общее представление о глючности USB сделано на основе негативного опыта использования шнурков, где разрешение ошибок оставлено полностью на чипе USB-COM и софте хоста. Улучшить ситуацию своими средствами никто здесь не Экспериментатор(210 знак., 10.09.2017 12:16, )
- Виновата всегда сторона компьютера. Со стороны железки логика тупая и там виснуть нечему. Драйвер устройства в случае VCP можно перезагрузить без перезапуска компа, закрытием COM порта на компе и отключением устройства. ASDFS(192 знак., 10.09.2017 12:31)
- +1, у меня такие же впечатления - 0men(11.09.2017 12:40)
- Я перепробовал все чипы, под виндой большой разницы между ними нет. Насчет компьютера не согласен, так как если программа при разрывесвязи делает переинициализацию порта, то во многих случаях связь удается восстановить. Передергиваньем шнурка Экспериментатор(70 знак., 10.09.2017 13:04, )
- со стороны софта такая последовательность действий: 1. закрыть порт. 2. отключить устройство (которое USB). 3. обновить список устройств 4. подключить порт и продолжить работу. Клинч как правило происходит из-за того, что железка пропала, софт AVF(117 знак., 10.09.2017 13:11)
- У меня без пунктов 2 и 3 работает, но иногда не помогает. Не хватает данных, что в оставшихся случаях виновато. Наверное, проверить самому будет быстрее, чем тут спрашивать. Модератор совсем ошалел, что-то здесь еще писать желания уже не возникает. - Экспериментатор(10.09.2017 13:30, )
- usb hid рулит. - AVF(10.09.2017 13:32)
- usb hid бывают точно такие же проблемы что и с VCP. По видимому трабла не в самих кастомных драйверах от производителей чипов а в корневых USB драйверах Виндов. - ASDFS(10.09.2017 13:44)
- с Hid подвисаний в 10 раз меньше по сравнению с vcp. У M$ в драйвере hid реализованы изощренные процедуры автоматического восстановления работоспособности после сбоя тогда как VCP рушится после единичного сбоя. (смотрел Usb сниффером). - 3m(10.09.2017 15:53)
- usb hid бывают точно такие же проблемы что и с VCP. По видимому трабла не в самих кастомных драйверах от производителей чипов а в корневых USB драйверах Виндов. - ASDFS(10.09.2017 13:44)
- usb hid рулит. - AVF(10.09.2017 13:32)
- У меня без пунктов 2 и 3 работает, но иногда не помогает. Не хватает данных, что в оставшихся случаях виновато. Наверное, проверить самому будет быстрее, чем тут спрашивать. Модератор совсем ошалел, что-то здесь еще писать желания уже не возникает. - Экспериментатор(10.09.2017 13:30,
- со стороны софта такая последовательность действий: 1. закрыть порт. 2. отключить устройство (которое USB). 3. обновить список устройств 4. подключить порт и продолжить работу. Клинч как правило происходит из-за того, что железка пропала, софт AVF(117 знак., 10.09.2017 13:11)
- Виновата всегда сторона компьютера. Со стороны железки логика тупая и там виснуть нечему. Драйвер устройства в случае VCP можно перезагрузить без перезапуска компа, закрытием COM порта на компе и отключением устройства. ASDFS(192 знак., 10.09.2017 12:31)
