FT245R работает со сбоями Опции

[koluna]

Здравствуйте!

Наконец-то дело дошло и у меня до практики и сразу столкнулся с трудностями

Собрал устройство с FT245 включенной по самой простой схеме с питанием от шины.
Использую VCP (скачал с сайта CDM 2.04.14.zip).
Обмен данными с портом программирую на API (Delphi 7) под WinXP.
На кабеле написано следующее: "28 AWG/IP 28AWG/2C HIGH SPEED USB REVISION 2.0 MD".
4 жилы в фольге + провод экрана.
Длина 1.8 м.

"Бусинки" ферритовой на цепь +5 В не нашлось

Сбои следующего рода.
Работает, работает, потом начинаются сбои при записи в порт со стороны ПК... возникает исключение. Далее с портом работать не получается до тех пор, пока не передёрнешь шнур USB... Как я понял, подвисает FT245R.
Сбои возникают спонтанно...

Читал конференцию. Сделал, как советовали:
1. Со стороны устройства экран кабеля повесил на общую цепь через RC-цепочку 1 МОм, 0.1 мкФ.
2. На линии данных USB - конденсаторы 33 пФ на общую цепь (47 пФ не нашлось).

Ситуация не изменилась...
Почему возникают сбои?
Как их можно устранить?

Попутно несколько вопросов.

1. FT245R гарантирует безошибочную доставку данных? Т. е., в пакетах абсолютно точно не будет испорченных, пропущенных и лишних байтов? Читал, что режим BULK USB гарантирует безошибочную доставку данных, а ISOHRONOUS - не гарантирует. Только вот в каком режиме работает данная микросхема?

2. Как при подсоединении к ПК устройства с FT245 запустить своё приложение?


Спасибо заранее!

[stoker]

Здравствуйте!

Наконец-то дело дошло и у меня до практики и сразу столкнулся с трудностями

Собрал устройство с FT245 включенной по самой простой схеме с питанием от шины.
Использую VCP (скачал с сайта CDM 2.04.14.zip).
Обмен данными с портом программирую на API (Delphi 7) под WinXP.
На кабеле написано следующее: "28 AWG/IP 28AWG/2C HIGH SPEED USB REVISION 2.0 MD".
4 жилы в фольге + провод экрана.
Длина 1.8 м.

"Бусинки" ферритовой на цепь +5 В не нашлось

Сбои следующего рода.
Работает, работает, потом начинаются сбои при записи в порт со стороны ПК... возникает исключение. Далее с портом работать не получается до тех пор, пока не передёрнешь шнур USB... Как я понял, подвисает FT245R.
Сбои возникают спонтанно...

Читал конференцию. Сделал, как советовали:
1. Со стороны устройства экран кабеля повесил на общую цепь через RC-цепочку 1 МОм, 0.1 мкФ.
2. На линии данных USB - конденсаторы 33 пФ на общую цепь (47 пФ не нашлось).

Ситуация не изменилась...
Почему возникают сбои?
Как их можно устранить?

Попутно несколько вопросов.

1. FT245R гарантирует безошибочную доставку данных? Т. е., в пакетах абсолютно точно не будет испорченных, пропущенных и лишних байтов? Читал, что режим BULK USB гарантирует безошибочную доставку данных, а ISOHRONOUS - не гарантирует. Только вот в каком режиме работает данная микросхема?

2. Как при подсоединении к ПК устройства с FT245 запустить своё приложение?


Спасибо заранее!

Кабель не причем. У меня кабель 3 метра купленный в АШАНе за 40 рублей, там вообще экрана нету и все равно работает как часы.
По моему у вас кто-то со стороны устройства данные забывает принимать.
1. Данные приходят без ошибки, режим bulk
2. Не совсем понял, о каком приложении идёт речь?

[koluna]

Кабель не причем. У меня кабель 3 метра купленный в АШАНе за 40 рублей, там вообще экрана нету и все равно работает как часы.
По моему у вас кто-то со стороны устройства данные забывает принимать.
1. Данные приходят без ошибки, режим bulk
2. Не совсем понял, о каком приложении идёт речь?

Читал, что кабель может быть очень даже виноват... FT плохо работает в условии помех...
Обмен идёт между ПК и устройством пакетами по 62 байта.
Это просто тест пока... ПК шлёт 62 байта. Устройство принимает и шлёт обратно эти 62 байта. Пока ПК не получит байты, высланные устройством, новые байты он не пошлёт

1. Понятно.

2. Любое своё, вообще любое. Хоть калькулятор

[stoker]

Читал, что кабель может быть очень даже виноват... FT плохо работает в условии помех...
Обмен идёт между ПК и устройством пакетами по 62 байта.
Это просто тест пока... ПК шлёт 62 байта. Устройство принимает и шлёт обратно эти 62 байта. Пока ПК не получит байты, высланные устройством, новые байты он не пошлёт

1. Понятно.

2. Любое своё, вообще любое. Хоть калькулятор

В таком случае советую проверить в каком состоянии находятся WR, RD,TXE, RXF когда устройство "висит".
Что управляет FT?
...
2. Первое вчто приходит на ум, использовать резидентный процесс, который проверяет подключено ли устройство и запускает калькулятор.

[koluna]

В таком случае советую проверить в каком состоянии находятся WR, RD,TXE, RXF когда устройство "висит".
Что управляет FT?

Обязательно проверю, что на этих линиях
при сбое.
Управляет ATmega88.

2. Первое вчто приходит на ум, использовать резидентный процесс, который проверяет подключено ли устройство и запускает калькулятор.

Это само собой. Но хочется стандартными средствами Windows.

[Седой]

Работает, работает, потом начинаются сбои при записи в порт со стороны ПК... возникает исключение ...

Что за исключение? ( exeption)

[koluna]

Что за исключение? ( exeption)

Ну про исключение, я зря сказал
Я его сам генерирую в классе работы с COM-портом.

Просто возникает ошибка при записи в порт...
Программа останавливается. Порт заново не открывается, пока устройство не переткнёшь...
Даже если софт перезагрузить полностью, то устройство работать не начнёт - порт не откроется, пока не переткнёшь устройство...

[Седой]

Ну про исключение, я зря сказал
Я его сам генерирую в классе работы с COM-портом.

Просто возникает ошибка при записи в порт...
Программа останавливается. Порт заново не открывается, пока устройство не переткнёшь...
Даже если софт перезагрузить полностью, то устройство работать не начнёт - порт не откроется, пока не переткнёшь устройство...

Симптомы понятны, нет нормального вызова CloseHandle. Работаете скорее всего с BC или Delphi.
Ошибка в программе, а не в железе.

[bill_vs]

Симптомы понятны, нет нормального вызова CloseHandle. Работаете скорее всего с BC или Delphi.
Ошибка в программе, а не в железе.

Не могли бы Вы пояснить подробно?

[Седой]

Не могли бы Вы пояснить подробно?

Если не сильно вдаваться в детали вызов функции CloseHandle обрабатывается нормальным драйвером следующим образом

1. Драйвер должен отменить все операции ввода/вывода.
2. Освободить ресурсы (память и т.д.), захваченные при обработке CreateFile.
3. ...

Если этого не сделать, последующий вызов CreateFile вернет ошибку. Поэтому и приходиться освобождать ресурсы жестким образом - "передергивать шнур USB".

Почему BC и Delphi - в определенных ситуациях RTL вызвает TerminateThread, что приводит к тому, что ранее запрошенный
потоком I/O запрос в драйвер продолжает работать, он не отменяется, как при нормальном завершении потока вызовом ExitThread - и опять приходится "передергивать шнур USB".

Я сейчас точно не помню, где мне приходилось править RTL в D5, это было году в 2000, c тех пор ее и пользуюсь для написания dll для железа.

[koluna]

Симптомы понятны, нет нормального вызова CloseHandle. Работаете скорее всего с BC или Delphi.
Ошибка в программе, а не в железе.

В Delphi.
У меня алгоритм следующий.
1. Подключаем устройство.
2. Запускаем приложение.
3. Открываем порт.
4. Передаём-принимаем в цикле до нажатия "Стоп". Причём передаём снова только после того как примем ответ. Т. е., Handshake такой получается
5. Закрываем порт.

При ЗАПИСИ В ПОРТ спонтанно возникает ошибка и FT (или драйвера) перестаёт правильно работать.
После переподключения устройства всё начинает работать нормально вновь...

Какая может быть ошибка в программе?

Если этого не сделать, последующий вызов CreateFile вернет ошибку. Поэтому и приходиться освобождать ресурсы жестким образом - "передергивать шнур USB".

Но меня интересует другое! Почему при записи N в порт произошла ошибка, когда запись N - 1 в порт была сделана успешно (шнур мы не дёргали и программу не останавливали)?

Как можно локализовать ошибку?

[Седой]

При ЗАПИСИ В ПОРТ спонтанно возникает ошибка и FT (или драйвера) перестаёт правильно работать.
После переподключения устройства всё начинает работать нормально вновь...

Какая может быть ошибка в программе?

Давайте все-таки код посмотрим, а то может быть глюк и в драйвере.

[Alex11]

Я очень давно использовал FT245. Действительно, в условиях помех связь отъезжает с примерно указанными выше симптомами. Программа при этом была на MS VC. Из рекомендаций - посадите оплетку кабеля на землю устройства толстым проводом. Будет существенно лучше. В моем случае, т.к. помех было очень много и мощных окончательно помог только watchdog, от которого срабатывал полевик, отключающий подтяжку D+ к 3.3В. Устройство отваливалось, после чего его можно было переоткрыть и восстановить работоспособность не выдергивая кабель руками.

[koluna]

Я очень давно использовал FT245. Действительно, в условиях помех связь отъезжает с примерно указанными выше симптомами. Программа при этом была на MS VC. Из рекомендаций - посадите оплетку кабеля на землю устройства толстым проводом.

Компьютер не заземлён. Это не ухудшит ситуацию? Сейчас, как я писал, оплётка у меня через RC-цепь к земле устройства подключена.

Будет существенно лучше. В моем случае, т.к. помех было очень много и мощных окончательно помог только watchdog, от которого срабатывал полевик, отключающий подтяжку D+ к 3.3В. Устройство отваливалось, после чего его можно было переоткрыть и восстановить работоспособность не выдергивая кабель руками.

А почему не RESET использовать? Ведь будет тоже самое или нет?

Давайте все-таки код посмотрим, а то может быть глюк и в драйвере.

USBThread.pas - модуль потока работы с FT245.
COMPort.pas - модуль класса COM-порта.

Прикрепленные файлы

 Soft.rar ( 3.08 килобайт ) Кол-во скачиваний: 52

 

[Седой]

USBThread.pas - модуль потока работы с FT245.
COMPort.pas - модуль класса COM-порта.

На первый взгляд все нормально.
Давайте попробуем отловить ошибку, для этого переделайте немного
вызов генераторов исключений
Вместо XXX_ComPort_Error.Create("Сообщение об ошибке")

Вызывать
XXX_ComPort_Error.CreateFmt("Сообщение об ошибке %x",[GetLastError])

И сообщите значение GetLastError.

[galjoen]

Попробуйте проверить, а не переходит-ли FT в суспенд? Там есть специальная нога, которая сообщает об этом. На ней уровень появляется, какой не помню. Если так, то програмными способами вы ничего не добьётесь. Дело в железе+кабель. Сингфазная помеха прёт.

[koluna]

На первый взгляд все нормально.
Давайте попробуем отловить ошибку, для этого переделайте немного
вызов генераторов исключений
Вместо XXX_ComPort_Error.Create("Сообщение об ошибке")

Вызывать
XXX_ComPort_Error.CreateFmt("Сообщение об ошибке %x",[GetLastError])

И сообщите значение GetLastError.

Хорошо, переделаю

Попробуйте проверить, а не переходит-ли FT в суспенд? Там есть специальная нога, которая сообщает об этом. На ней уровень появляется, какой не помню. Если так, то програмными способами вы ничего не добьётесь. Дело в железе+кабель. Сингфазная помеха прёт.

Уже говорили, что FT именно засыпает (у кого-то). Что у меня - проверим и сообщим!
Нога - PWREN#.
А что конкретно может быть в железе и кабеле?
Кабель недлинный, экранированный. Только вот не знаю - витой или нет внутри...
А почему эта синфазная помеха переводит FT в сон?

[Седой]

Хорошо, переделаю

Забыл вам сказать, что функцию GetLastError нужно вызывать в контексте того потока, значение ошибки которого
вы хотите получить.

[koluna]

Попробуйте проверить, а не переходит-ли FT в суспенд? Там есть специальная нога, которая сообщает об этом. На ней уровень появляется, какой не помню. Если так, то програмными способами вы ничего не добьётесь. Дело в железе+кабель. Сингфазная помеха прёт.

Проверил.
Состояние выводов следующее.

RXF#, TXE#, RD# - 1.
WR - 0.

PWREN# - 1, что говорит о том, что мы спим

Забыл вам сказать, что функцию GetLastError нужно вызывать в контексте того потока, значение ошибки которого
вы хотите получить.

Уже прочитал
Вызывается из модуля COMPort. Из потока USBThread - там все операции с портом.

Ферриты купить не смог. Купил только конденсаторы (потом перепаяю).

У меня какая-то странная ситуация сейчас... несмотря на обработку исключений приложение виснет при ошибке до передёргивания устройства...
Хотя если устройство выдернуть, то ошибка отрабатывается нормально (GetLastError возвращает 1F)... а при ошибке дело до GetLastError не доходит. Такое ощущение, что виснет где-то в WfiteFile...

[Седой]

Проверил.
GetLastError не доходит. Такое ощущение, что виснет где-то в WfiteFile...

Скорее всего не виснет, а ждет завершения передачи, т.е. Port.WriteData(TX_Buf) не возвращается?

Да и установите timeouts для записи.

Сообщение отредактировал Седой - Feb 10 2009, 06:24

[koluna]

Скорее всего не виснет, а ждет завершения передачи, т.е. Port.WriteData(TX_Buf) не возвращается?

Да и установите timeouts для записи.

Я тоже об этом подумал. Но потом локализовал место "зависания" с помощью записи в лог-файл (через каждую интересующую строчку кода).
Понял, что "зависание" происходит в момент попытки закрытия порта (CloseHandle) после возникновения ошибки, появившейся при записи WriteFile.
Приложение крепко "подвисает". Но если отсоединить USB-устройство, то оживает!

Я очень давно использовал FT245. Действительно, в условиях помех связь отъезжает с примерно указанными выше симптомами. Программа при этом была на MS VC. Из рекомендаций - посадите оплетку кабеля на землю устройства толстым проводом. Будет существенно лучше. В моем случае, т.к. помех было очень много и мощных окончательно помог только watchdog, от которого срабатывал полевик, отключающий подтяжку D+ к 3.3В. Устройство отваливалось, после чего его можно было переоткрыть и восстановить работоспособность не выдергивая кабель руками.

Вчера повесил экран кабеля напрямую на общую цепь устройства.
За весь вечер - одна ошибка и то при коммутации/декоммутации приличной нагрузки! Налицо - улучшение!
Сегодня продолжим тестирование.

После WriteFile при ошибке GetLastError возвращает 1F.

Сообщение отредактировал n_bogoyavlensky - Feb 10 2009, 06:58

[vetal]

Налицо - улучшение!

Теперь расскажите нам как вы заземляетесь, делаете развязку цепей управления от исполнительных цепей коммутации и обеспечиваете отсутствие мощных импульсных токов на общем проводе управляющих(информационных) узлов

[koluna]

Теперь расскажите нам как вы заземляетесь,

ПК и устройство с USB не заземлены, к сожалению (не знаю как можно заземлить устройство просто в домашних условиях).
На экране потенциал около 100 В, что, конечно, плохо...
Как писал выше - сейчас экран USB-кабеля соединён напрямую с общей цепью устройства.
Ранее экран кабеля был соединён с общей цепью через последовательную RC-цепь (1 МОм и 0.1 мкФ).

делаете развязку цепей управления от исполнительных цепей коммутации

Как я понял, в моём случае исполнительные цепи коммутации - мой канал DMX512 (RS-485)?
Стоят 2 оптрона 2630 (2 канала на передачу, 1 канал на приём). С одной стороны питание от USB. С другой стороны - DC-DC TMA0505S, который запитывается тоже от USB.
Не знаю, может на вход/выход DC-DC по электролиту повесить следует...

и обеспечиваете отсутствие мощных импульсных токов на общем проводе управляющих(информационных) узлов

Вот тут не совсем понимаю о чём идёт речь...
По питанию каждой из микросхем стоят блокировочные конденсаторы 0.1 мкФ.
Устройство у меня маленькое и простое, состоит из FT245R, ATmega88, HCPL2630 (2 шт.) и MAX485.
К RS-485 подключается одна нагрузка с помощью кабеля несколько метров.
Ферритовые бусинки купить, к сожалению, пока не удалось (для цепей питания и линий данных USB).

Кстати, надо проверить, будут ли "подвисания" с отключенным кабелем RS-485...

С большим удовольствием выслушаю подробную лекцию по борьбе с помехами, получу ссылки по теме

[koluna]

Вот что придумал. А что, если сделать следующим образом.

Мы знаем, что FT при возникновении сбоя "засыпает".
Следовательно, МК может анализировать состояние вывода PWREN# FT и при переходе его в состояние "1" сбрасывать FT, подавая "0" на вывод RESET# FT.

Это альтернатива программному вотчдогу, который обсуждался ранее (от ПК данных не получено определённое время -> наверняка произошёл сбой и FT "спит" -> надо её сбросить).

[Седой]

После WriteFile при ошибке GetLastError возвращает 1F.

Эта ошибка ERROR_GEN_FAILURE - A device attached to the system is not functioning.

Вот теперь понятно, что чип коряво отрабатывает такую ситуацию.

Но передергивать устройство тоже не дело.
Попробуйте после такой ошибки вызвать CancelIO или CancelIOEx, а потом уже CloseHandle - проверим корявость драйвера.

Мы знаем, что FT при возникновении сбоя "засыпает".

Он должен также вполне законно "заснуть" при получение команды Suspend от хоста.

[_3m]

Эта ошибка ERROR_GEN_FAILURE - A device attached to the system is not functioning.

Вот теперь понятно, что чип коряво отрабатывает такую ситуацию.

А чип не при делах, ведь в usb шиной рулит хост - это в хосте неадекватно реализована отработка сбоев.

Но передергивать устройство тоже не дело.

А других вариантов продолжить работу после сбоя просто нет.

Попробуйте после такой ошибки вызвать CancelIO или CancelIOEx, а потом уже CloseHandle - проверим корявость драйвера.

В HID устройствах имеется один в один такая же проблема. Cancel IO порт не развешивает.

Вообще я просто угораю от работы усб, даже в настольных условиях.
Переходник на ft232bm идет обмен. На противоположном конце стола примерно в метре стоит паяльная станция 40-50Вт, включена в другую розетку. Двукратное включение-выключение станции штатным выключателем гарантированно завешивает усб. Причем зависшее приложение (modtab.exe) не убивается даже таск-менеджером пока не передернешь усб.
Я не заю можно ли спроектировать более глючное устройство.
Как это будет жить на объекте даже страшно представить.

Сообщение отредактировал _3m - Feb 10 2009, 12:06

[Седой]

А чип не при делах, ведь в usb шиной рулит хост - это в хосте неадекватно реализована отработка сбоев.


А других вариантов продолжить работу после сбоя просто нет.

Хост кстати ответил правильно - ошибкой транзакции и драйвер FTDI должен адекватно отреагировать на эту ситуацию,
мог бы сделать ResetPort или по крайней мере установить флаг, чтобы при вызове CloseHandle не входить в ступор.

PS.Нужно посмотреть по спецификации USB правила работы хоста и устройства в таких ситуациях.

[koluna]

Эта ошибка ERROR_GEN_FAILURE - A device attached to the system is not functioning.

А откуда это?

Он должен также вполне законно "заснуть" при получение команды Suspend от хоста.

А если это у меня не предусмотрено?

Переходник на ft232bm идет обмен. На противоположном конце стола примерно в метре стоит паяльная станция 40-50Вт, включена в другую розетку. Двукратное включение-выключение станции штатным выключателем гарантированно завешивает усб. Причем зависшее приложение (modtab.exe) не убивается даже таск-менеджером пока не передернешь усб.

Именно, аналогичная ситуация

Кстати, вот ещё что.

Как я понял, сбои возникают только при подсоединённом кабеле DMX к устройству!
Несмотря на развязку!

Т. е., объясняю.
Имеем структуру ПК-конвертор (устройство)-управляемый светодиодный прожектор.
ПК и конвертор соединены USB. Конвертор и прожектор - RS-485 (DMX512).
Так вот, когда кабель от прожектора подсоединён к устройству при операциях с включением/выключением сетево

Кстати, вот ещё что.

Как я понял, сбои возникают только при подсоединённом кабеле DMX к устройству! Несмотря на развязку!

Т. е., объясняю.
Имеем структуру ПК <-> конвертор (устройство) <-> управляемый светодиодный прожектор.
ПК и конвертор соединены USB. Конвертор и прожектор - RS-485 (DMX512).
Так вот, когда кабель от прожектора подсоединён к конвертору, то при операциях с включением/выключением сетевой вилки прожектора (дёргаю её туда-сюда) иногда происходят сбои.
При отключенном кабеле такого не наблюдается.
Т. е., помеха идёт по кабелю в конвертор и как-то проходит через развязку или через DC-DC конвертор, попадая на USB.

[Седой]

А откуда это?

Что значит откуда?

Как я понял, сбои возникают только при подсоединённом кабеле DMX к устройству!
Несмотря на развязку!
.....
Т. е., помеха идёт по кабелю в конвертор и как-то проходит через развязку или через DC-DC конвертор, попадая на USB.

А причем тут развязка.
Посмотрите http://caxapa.ru/lib/emc_immunity.html

[Седой]

Сейчас просмотрел документацию на драйвера FTDI.
Можно же работать не через COM порт, а через D2XX интерфейс и попробовать воспользоваться функцией FT_ResetPort (FT_ResetDevice,FT_CyclePort) для выхода из ошибочного состояния.

[koluna]

Сейчас просмотрел документацию на драйвера FTDI.
Можно же работать не через COM порт, а через D2XX интерфейс и попробовать воспользоваться функцией FT_ResetPort (FT_ResetDevice,FT_CyclePort) для выхода из ошибочного состояния.

Можно попробовать, но я пока рассчитывал только на работу с VCP

Что значит откуда?

Из какого источника? В хелпе я что-то не нашёл кодов ошибок

[Седой]

Из какого источника? В хелпе я что-то не нашёл кодов ошибок

Из документации производителя OS http://msdn.microsoft.com/en-us/library/ms681382(VS.85).aspx

Можно попробовать, но я пока рассчитывал только на работу с VCP

Если делаете USB-DMX под серию и выбрали AVR - посмотрите в сторону AT90USB162, получится и надежней и дешевле.
Мы сделали мультипротокольный (DMX тоже поддерживает) USB-RS485 на C8051F326, драйвер свой, проблем с наводками нет.
Лежит у меня на столе, заканчиваю документацию на ПО.

[koluna]

Если делаете USB-DMX под серию и выбрали AVR - посмотрите в сторону AT90USB162, получится и надежней и дешевле.
Мы сделали мультипротокольный (DMX тоже поддерживает) USB-RS485 на C8051F326, драйвер свой, проблем с наводками нет.
Лежит у меня на столе, заканчиваю документацию на ПО.

Хм...
Как я понял, этот путь существенно более сложный и длительный?
Т. е., драйвер надо писать, знать как с USB работать со стороны МК и ПК...
Это получается наподобие как у Агурова?

[Седой]

Хм...
Как я понял, этот путь существенно более сложный и длительный?

Это вам кажется - затраченное время на стартапе с лихвой окупается в дальнейшем.

Т. е., драйвер надо писать, знать как с USB работать со стороны МК и ПК...

Драйвер можно не писать, воспользоваться готовым, если устраивают его возможности.
А как без знаний!!!????

Это получается наподобие как у Агурова?

По поводу Агурова - ответил в соседней ветке.
Вы же изучаете работу конкретного чипа по его документации (data sheet) от производителя, а не по книжкам.

Сообщение отредактировал Седой - Feb 11 2009, 15:10

[stoker]

Попробуйте использовать драйвер D2XX. Гораздо прощще, там вообще думать не надо. Работаю с ним, проблемм с зависаниями и потерей данных нет вообще. Щас вот 5 метров кабель юзал. Правда у меня все заземлено.
Если он засыпает при помехе, возможно есть сбой в логике управления микрухой. У вас опторазвязка на HCPL-2630?

[Alex11]

Эти драйвера при помехах виснут так же, это у Вас помех не было серьезных.

[koluna]

Решил набросать блок-схему соединений...
Т. е., имеем три блока: персональный компьютер (ПК), USB-DMX конвертор (разделён на две оптически развязанные части) и прожектор.

ПК шлёт с помощью VCP пакеты 62 байта в конвертор. Конвертор принимает пакеты и тут же их отсылает обратно.
По прерыванию от таймера реализовано формирование DMX-пакета для прожектора.
Формируются все 512 каналов.

Следует отметить.
Экран USB кабеля соединён с общей цепью конвертора.
Сбои в основном происходят при подключении и отключении сетевой вилки прожектора.

Это вам кажется - затраченное время на стартапе с лихвой окупается в дальнейшем.

Каковы преимущества данного варианта?

Драйвер можно не писать, воспользоваться готовым, если устраивают его возможности.
А как без знаний!!!????

Из состава ОС или где-то скачать для данного типа микроконтроллеров?

Попробуйте использовать драйвер D2XX. Гораздо прощще, там вообще думать не надо. Работаю с ним, проблемм с зависаниями и потерей данных нет вообще. Щас вот 5 метров кабель юзал. Правда у меня все заземлено.
Если он засыпает при помехе, возможно есть сбой в логике управления микрухой. У вас опторазвязка на HCPL-2630?

Развязка на ней
Т. е., развязка конвертора и объекта управления (смотри схему).
Ну сбоя в логике нет, я думаю...

Сообщение отредактировал n_bogoyavlensky - Feb 12 2009, 19:46

Эскизы прикрепленных изображений

 

[Седой]

Каковы преимущества данного варианта?

Меньше возможность уткнуться в чужую ошибку.

Из состава ОС или где-то скачать для данного типа микроконтроллеров?

В вашем случае я бы использовал winusb от Microsoft.

[stoker]

Питание VCC1 - это на контроллер и FT245R? Просто немного не понятно. Можно попробовать проверить питание на осцилографе - VCC1 относительно GND1 при передёргивании питания прожектора. Мож там питание на время пропадает, или наоборот импульс питания выходит за пределы входного для TMA0505 (у него входное 5В +/-10%)? Питание приходит по 485 кабелю? Какая длина кабеля? Вообще попробуйте запитать отдельно схемку на УСБ с контроллером. На будущее - если питание идёт по линии 485 лучше применять DC/DC с более широким входным напряжением.

[galjoen]

А если это у меня не предусмотрено?

В суспенд ФТДИ переходит если пропускается 3 маркера SOF от хоста. Другими словами - нет никаких вестей от хоста в течении 3х милисекунд. Никаких специальных команд перехода в суспенд не существует. В реальности это означает, что хост просто решил, что ваш девайс выдернут из него.

Как я понял, сбои возникают только при подсоединённом кабеле DMX к устройству! Несмотря на развязку!
Т. е., помеха идёт по кабелю в конвертор и как-то проходит через развязку или через DC-DC конвертор, попадая на USB.

Именно так. Сингфазная помеха проходит через все ваши преграды и воспринимается хостом как сигнал отключения устройства. Поэтому и всяческие заземления экрана помогают (а могут и навредить).
Я уже отвечал абсолютно на такой-же вопрос на этом-же форуме в этом-же разделе. Лень писать заново (и смотреть как называется состояние в USB, вызываемое сингфазной помехой). Поищите. Там WESTxxx (xxx - цифры) вопрос задавал.
Но хаять шину USB за это я бы не стал. Тут вопрос скорее к ФТДИ. Вот мои самодельные девайсы в таких условиях самостоятельно восстанавливают связь с хостом.

[stoker]

В суспенд ФТДИ переходит если пропускается 3 маркера SOF от хоста. Другими словами - нет никаких вестей от хоста в течении 3х милисекунд. Никаких специальных команд перехода в суспенд не существует. В реальности это означает, что хост просто решил, что ваш девайс выдернут из него.

Это вы где прочитали? Или опытным путем обнаружили?

[galjoen]

Это вы где прочитали? Или опытным путем обнаружили?

Про это написано в стандарте USB. Кажется 7я глава - usb.org посмотрите. У меня и на русском есть, только перевод не очень. Я уже здесь выкладывал.

Ещё хочу заметить, что вывести девайс из суспенда со стороны компьютера с помощью всяческих програмных уловок, как здесь предлагалось, невозможно. Хотя м.б. и возможно, но это нужно хостом управлять, а кто вас туда пустит?

[Седой]

Ещё хочу заметить, что вывести девайс из суспенда со стороны компьютера с помощью всяческих програмных уловок, как здесь предлагалось, невозможно. Хотя м.б. и возможно, но это нужно хостом управлять, а кто вас туда пустит?

Вот кстати из реального suspend вывести как раз можно, как и ввести. А то что описали вы - это хаб обнаруживает ошибку и просто отключает порт, а не производит selective suspend. Я как раз и указал псевдокоманду запроса перевода в suspend порта хаба - SetPortFeature(PORT_SUSPEND).

К хосту, кстати, доступ из UserMode тоже есть - пример из DDK usbview.

Сообщение отредактировал Седой - Feb 13 2009, 17:52

[koluna]

Питание VCC1 - это на контроллер и FT245R? Просто немного не понятно.

Старался сделать как можно понятнее
Да, VCC1, GND1 - цепи питания FT245, ATmega88, HCPL2630 (наполовину) и TMA0505S (входное напряжение).
Экран USB-кабеля соединён с GND1.

Можно попробовать проверить питание на осцилографе - VCC1 относительно GND1 при передёргивании питания прожектора. Мож там питание на время пропадает, или наоборот импульс питания выходит за пределы входного для TMA0505 (у него входное 5В +/-10%)?

Проверим. Но что может быть с питанием при передёргивании сетевой вилки?

Питание приходит по 485 кабелю?

Питание чего? Левая часть конвертора питается от USB, правая тоже от USB, только через DC-DC TMA0505S - цепи питания VCC2, GND2.

Какая длина кабеля? Вообще попробуйте запитать отдельно схемку на УСБ с контроллером.

Т. е., запитать всю левую часть от отдельного источника питания, а не от USB, т. е. "self power" для FT?

На будущее - если питание идёт по линии 485 лучше применять DC/DC с более широким входным напряжением.

Спасибо за совет. Но в кабеле RS-485 задействованы только информационные линии.

[galjoen]

Вот кстати из реального suspend вывести как раз можно, как и ввести. А то что описали вы - это хаб обнаруживает ошибку и просто отключает порт, а не производит selective suspend. Я как раз и указал псевдокоманду запроса перевода в suspend порта хаба - SetPortFeature(PORT_SUSPEND).

Согласен. Ошибся в терминах. Это для девайса суспенд получается. А для хоста там не ошибка получается, а просто хост думает, что девайс из порта вытащили. На то, что линии перекошены из-за резистора 1,5 кОм он внимания не обращает - SOF слать перестаёт. И никаких попыток связь восстановить не предпринимает. Я имел ввиду, что програмно заставить его девайс поискать не удастся.
Это примерно тот-же глюк, как если компьютер в слип кнопкой ввести, а потом разбудить. В этом случае все USB девайсы кроме мыши и клавы (для них сделали исключение) пропадут. И поможет только их перетыкание.

К хосту, кстати, доступ из UserMode тоже есть - пример из DDK usbview.

Так там вроде только читать можно. Хотя спорить не буду - давным-давно с этим разбирался.

[koluna]

Именно так. Сингфазная помеха проходит через все ваши преграды и воспринимается хостом как сигнал отключения устройства. Поэтому и всяческие заземления экрана помогают (а могут и навредить).
Я уже отвечал абсолютно на такой-же вопрос на этом-же форуме в этом-же разделе. Лень писать заново (и смотреть как называется состояние в USB, вызываемое сингфазной помехой). Поищите. Там WESTxxx (xxx - цифры) вопрос задавал.

http://electronix.ru/forum/index.php?showtopic=42549

"Это у вас, скорее всего, такая мощная сингфазная помеха прёт, что и D+ и D- нулями становятся (на короткое время). А это эквивалентно выдёргиванию устройства. А хаб к которому устройство подключено этого не замечает. И о новом подключении сообщения не посылает. А компьютер, раз устройства нет, в этот USB разъём SOF слать перестаёт ( вот FTDI режим Suspend и показывает). Попробуйте продольный трансформатор на шнур USB поставить. Несколько витков вокруг подходящего ферритового колечка (достаточно большого). Если повлияет - в этом дело."

Что такое продольный трансформатор и как его ставить? Как подобрать колечко?

[Седой]

На то, что линии перекошены из-за резистора 1,5 кОм он внимания не обращает - SOF слать перестаёт. И никаких попыток связь восстановить не предпринимает. Я имел ввиду, что програмно заставить его девайс поискать не удастся.

А ResetPort пробовали.

Это примерно тот-же глюк, как если компьютер в слип кнопкой ввести, а потом разбудить. В этом случае все USB девайсы кроме мыши и клавы (для них сделали исключение) пропадут. И поможет только их перетыкание.

А может просто драйвера не отрабатывают соответсвующие IO.

Так там вроде только читать можно. Хотя спорить не буду - давным-давно с этим разбирался.

Можно впрямую послать запрос в endpoint0.И в другие тоже, только предварительно открыв.

Что такое продольный трансформатор и как его ставить? Как подобрать колечко?

Да попробуйте любое, главное чтобы устройство определилось.

http://electronix.ru/forum/index.php?showtopic=42549

[i]"Это у вас, скорее всего, такая мощная сингфазная помеха прёт, что и D+ и D- нулями становятся (на короткое время). А это эквивалентно выдёргиванию устройства. А хаб к которому устройство подключено этого не замечает. И о новом подключении сообщения не посылает. А компьютер, раз устройства нет, в этот USB разъём SOF слать перестаёт

Хаб не замечает, а компьютер замечает, ну вы даете.

Открыть драйвер менеджер и посмотреть есть ли там "замеченное","выдернутое" устройство ...

Сообщение отредактировал Седой - Feb 13 2009, 19:22

[galjoen]

А ResetPort пробовали.

Нет. Так это вроде к хосту команда. А мы про устройство говорим.

А может просто драйвера не отрабатывают соответсвующие IO.

Не похоже. Хиды, принтеры, телефоны, камеры и т.д. что все забыли про это дело?

Можно впрямую послать запрос в endpoint0.И в другие тоже, только предварительно открыв.

Так это только на уровне драйвера так можно, а приложение так не может. Это в линуксе так можно (если разрешить).

А продольный трансформатор - это трансформатор с двумя (или больше) одинаковыми обмотками, включенными так, что сингфазный сигнал ослабляется, а дифференциальный не изменяется. Но USB и сингфазные сигналы использует. Поэтому только на данные его (больше какого-то размера) ставить нельзя. Такие в некоторых флешках стоят. А вот всем кабелем кольцо обмотать можно - хуже не будет. Нашлёпки на концах кабелей (не только USB) это и есть продольные трансформаторы с одним витком. Но индуктивность квадрату числа витков пропорциональна. 10 витков - в 100 раз больше индуктивность.

[Седой]

Нет. Так это вроде к хосту команда. А мы про устройство говорим.
.....
Так это только на уровне драйвера так можно, а приложение так не может. Это в линуксе так можно (если разрешить).

Ну зачем вы делаете скоропалительные выводы - см. http://msdn.microsoft.com/en-us/library/aa476347.aspx

[galjoen]

Открыть драйвер менеджер и посмотреть есть ли там "замеченное","выдернутое" устройство ...

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

Ну зачем вы делаете скоропалительные выводы - см. http://msdn.microsoft.com/en-us/library/aa476347.aspx

Не делаю я выводы. Где не уверен - пишу вроде и т.п. Если так можно делать, то прекрасно. Но когда я разбирался (давно) у меня так не получилось (хотя сильно и не упирался т.к. решил работать через HID).
А вы пробовали? У вас получилось? В смысле можете-ли вы отправить устройству пакет SETUP с полями, заполненными по своему усмотрению, работая под win на уровне приложения?

Вообще я девайсы не требующие установки к.л. драйверов делаю. Т.е. драйвера для них уже установлены д.б. Фактически это MassStorage, HID и всё.

[Седой]

Да нет там этого устройства. В диспечере устройств посмотреть - это первое, что на ум приходит. И после слипа тоже-самое. И

Если нет, тогда вы правы.
Ну тогда отловить программно такую ситуацию довольно просто - обработкой сообщения WM_DEVICE.

у топикстартера наверняка так-же.

А вот у него и спросим.

Но когда я разбирался (давно) у меня так не получилось (хотя сильно и не упирался т.к. решил работать через HID).

Тогда эта возможность не была документирована.

Сообщение отредактировал Седой - Feb 13 2009, 20:11

[Седой]

Пока проверил только IOCTL_USB_HUB_CYCLE_PORT - detach и последующий attach устройства - прекрасно работает из UserMode c драйвером хаба.

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

[koluna]

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

После возникновения ошибки устройство не пропадает из диспетчера устройств.

[Седой]

После возникновения ошибки устройство не пропадает из диспетчера устройств.

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

[galjoen]

Пока проверил только IOCTL_USB_HUB_CYCLE_PORT - detach и последующий attach устройства - прекрасно работает из UserMode c драйвером хаба.

Работает. Странно. А у меня что-то в своё время не получилось. А точно срабатывает?
Что с портом после detach происходит? SOF-то пропадает? Девайс в суспенд переходит?

После возникновения ошибки устройство не пропадает из диспетчера устройств.

Совсем интересно. Видимо это какой-то другой случай... И ошибок никаких в диспетчере не показывается? А SOF продолжает идти? Его осциллографом отлично видно, да и тестер покажет частоту 1 кГц. Только тыкаясь щупами можно случайно девайс разбудить. Тогда эксперимент некорректным будет. Ещё рекомендую на ножку, которая суспенд показывает, светодиод повесить.

[Седой]

Работает. Странно. А у меня что-то в своё время не получилось. А точно срабатывает?
Что с портом после detach происходит? SOF-то пропадает? Девайс в суспенд переходит?

Работает также как и IOCTL_INTERNAL_USB_CYCLE_PORT, вызванный из драйвера.
Как написано в комментарии usbioctl.h:
"
This IOCTL will simulate a plug/unplug on the drivers upstream
port. The device will be removed and re-added by PnP.
"
В драйвер менеджере вижу удаление и появление драйвера.
В устройстве вижу полный цикл энумерации.
Проверил на MT-Link, USB-COM (один свой на CP2103, второй покупной на Prolific),
своих двух платах(одна на С8051F326, вторая PDIUSBD + AVR),
на Olimex LPC-P2148 и MLPC2368 от StarterKit.

Следует обратить внимание, что документирован этот запрос неверно, делать нужно как написано
в usbioctl.h, а именно:
1. Вызывать для драйвера хаба, а не хоста.
2. Передавать в качестве входного параметра указатель на DWORD c номером порта, начинающегося с 1.

Сообщение отредактировал Седой - Feb 14 2009, 13:44

[galjoen]

В драйвер менеджере вижу удаление и появление драйвера.
В устройстве вижу полный цикл энумерации.

Очень интересно!
А что если попробовать всё это дело после пропадания устройств, вызванных входом самого компьютера в слип? Для этого нужно чтобы во время засыпания компьютера на USB девайсы продолжало поступать +5 вольт, но SOF пропадал. Т.е. девайсы в суспенд попадали бы. Тогда после пробуждения компьютера USB девайсы пропадут (они останутся в суспенде). Можно-ли с помощью detach/attach к хабу заставить компьютер их найти?

[Седой]

Очень интересно!
А что если попробовать всё это дело после пропадания устройств, вызванных входом самого компьютера в слип? Для этого нужно чтобы во время засыпания компьютера на USB девайсы продолжало поступать +5 вольт, но SOF пропадал. Т.е. девайсы в суспенд попадали бы. Тогда после пробуждения компьютера USB девайсы пропадут (они останутся в суспенде). Можно-ли с помощью detach/attach к хабу заставить компьютер их найти?

Я уже тут писал, что проблема в драйверах этих устройств или настройках драйверов или в самих устройствах, ведь переход в suspend не изменяет device state и после resume реэнумерация не нужна.

Сообщение отредактировал Седой - Feb 14 2009, 18:33

[koluna]

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

Попробуем.

Работает. Странно. А у меня что-то в своё время не получилось. А точно срабатывает?
Что с портом после detach происходит? SOF-то пропадает? Девайс в суспенд переходит?

Совсем интересно. Видимо это какой-то другой случай... И ошибок никаких в диспетчере не показывается? А SOF продолжает идти? Его осциллографом отлично видно, да и тестер покажет частоту 1 кГц. Только тыкаясь щупами можно случайно девайс разбудить. Тогда эксперимент некорректным будет. Ещё рекомендую на ножку, которая суспенд показывает, светодиод повесить.

Ошибок не показывается.
Попробуем в понедельник!

[koluna]

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

Так, а что конкретно отключить, а потом задействовать?
Последовательный порт или USB Serial Convertor?
После выбора из списка "Отключить" и того и другого винда предлагает перезагрузиться...
Может, я не там отключаю?

Совсем интересно. Видимо это какой-то другой случай... И ошибок никаких в диспетчере не показывается? А SOF продолжает идти? Его осциллографом отлично видно, да и тестер покажет частоту 1 кГц. Только тыкаясь щупами можно случайно девайс разбудить. Тогда эксперимент некорректным будет. Ещё рекомендую на ножку, которая суспенд показывает, светодиод повесить.

SOFа нету, пропадает он после сбоя, хорошо это вижу
USBDP - "1",
USBDN - "0",
PWREN# - "1".

Т. е., конвертор спит, и хост ему ничего не шлёт...

Докладываю о следующих экспериментах!

Ниже перечисленные эксперименты производил без прожектора и его кабеля. К сожалению, прожектор забрали не неопределённое время. А сбои оставили

1. Запитал вторую половину конвертора (смотри структурную схему выше) от внешнего источника питания (трансформатор + линейный стабилизатор). В месте подключения провода от источника к плате установил электролит 100.0 и керамику 0.1.
Сбоить не перестало. Тыркаем вилку источника питания - иногда сбоит. Т. е., для возникновения сбоя совсем не обязательно наличие огромного пускового тока 30 А AC-DC моего прожектора...

2. Попробовал включать источник питания через автоматический выключатель - ситуация не изменилась.

3. В настройках микросхемы (EEPROM) установил вместо "USB 2.0" "USB 1.1". Скорость обмена упала раз в пять, сбои не прекратились.

[galjoen]

Так, а что конкретно отключить, а потом задействовать?
Последовательный порт или USB Serial Convertor?
После выбора из списка "Отключить" и того и другого винда предлагает перезагрузиться...
Может, я не там отключаю?

Судя по тому, что IOCTL к хабу из юзермоде вызывается, я предложил бы вам попробовать отключить-включить соответствующий "корневой USB концентратор". Тот в который воткнут ваш девайс. Его можно найти по тому, что после втыкания вашего девайса, во вкладке питание появляется XX ма (возможно и название Serial.. - непомню), соответствующее вашему девайсу. Кстати очень интересно, а после сбоя там эта цифра продолжает оставаться?

SOFа нету, пропадает он после сбоя, хорошо это вижу
USBDP - "1",
USBDN - "0",
PWREN# - "1".

Т. е., конвертор спит, и хост ему ничего не шлёт...

Ну всё указывает на мою версию, но девайс не пропадает из списка...

Т. е., для возникновения сбоя совсем не обязательно наличие огромного пускового тока 30 А AC-DC моего прожектора...

Чтоб возникла сингфазная помеха достаточно не всю вилку, а только ОДИН её контакт в розетку втыкать.

[Седой]

Последовательный порт или USB Serial Convertor?
После выбора из списка "Отключить" и того и другого винда предлагает перезагрузиться...

На самом деле можно любой - USB Serial Convertor является родительским устройством для устройства последовательного порта, а требование перезагрузиться - привет от разработчиков драйверов FTDI.

Ну всё указывает на мою версию, но девайс не пропадает из списка...

По вашей версии должен произойти detach - но устройство в списке - значит произошел attach + последующая реэнумерация устройства + работает SOF. Но SOF нет, вывод - версия не верна.

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

[koluna]

Судя по тому, что IOCTL к хабу из юзермоде вызывается, я предложил бы вам попробовать отключить-включить соответствующий "корневой USB концентратор". Тот в который воткнут ваш девайс. Его можно найти по тому, что после втыкания вашего девайса, во вкладке питание появляется XX ма (возможно и название Serial.. - непомню), соответствующее вашему девайсу. Кстати очень интересно, а после сбоя там эта цифра продолжает оставаться?

Продолжает оставаться. 100 мА у меня. Я даже "Обновить" нажимал...

Далее.
1. При неработающем приложении (порт не открыт) отключаю и задействую обратно "Корневой USB-концентратор" и мой конвертор после этого не работает! Приходится дёргать за шнурок...

2. При работающем приложении (порт открыт и идёт обмен) после отключения и задействования ... винда предлагает перезагрузиться. Соответственно отключение и задействование ... без перезагрузки никакого влияния на устройство не оказывают.

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

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

По вашей версии должен произойти detach - но устройство в списке - значит произошел attach + последующая реэнумерация устройства + работает SOF. Но SOF нет, вывод - версия не верна.

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

С помощью D2XX можно это всё сделать?
Я не понимаю почему приложение наглухо виснет до передёргивания шнурка?

[galjoen]

По вашей версии должен произойти detach - но устройство в списке - значит произошел attach + последующая реэнумерация устройства + работает SOF. Но SOF нет, вывод - версия не верна.

По моей версии из-за синхфазной помехи происходит detach и всё. Никакого attach после этого не было. В своё время я с этим разбирался - вешал сниффер на хаб и смотрел какие сообщения он шлёт. Так вот: в аналогичном по симптомам случае, хаб говорил что устройство извлечено из него И ВСЁ. По моей версии сингфазная помеха приводит к тому, что при ОТСУТСТВИИ обмена на шине обе линии и D+ и D- на короткое время =0 становятся (т.е. никаких ошибок нет). Вроде 16-ти полноскоростных бит достаточно. И хаб об отключении девайса сообщает, а вот о последующем подключении почему-то не сообщает. И всё - девайс потерянным оказывается.
Только сейчас подумал - а м.б. у топикстаркера HIGH спид девайс?!? Там вроде подругому. Я с HIGH спид не разбирался - пока не надо было. М.б. из-за этого из списка он не пропадает?

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

Мне это кажется крайне маловероятным. Этож какая помеха д.б. чтобы 3 попытки перепосылки собой закрыть!

Кстати всё это легко проверить. Если просто девайс подключить и никакого обмена с ним не вести, а вот выключателем-то пощёлкать. И в таких условиях отключение с переходом в слип проверить. Если обмена с девайсом никакого не будет, а девайс всё равно отключится, то версия об ошибках сама-собой отпадёт.

[Седой]

Далее.
1. При неработающем приложении (порт не открыт) отключаю и задействую обратно "Корневой USB-концентратор" и мой конвертор после этого не работает! Приходится дёргать за шнурок...

Ну точно FTDI накосячил.

С помощью D2XX можно это всё сделать?
Я не понимаю почему приложение наглухо виснет до передёргивания шнурка?

Попробуйте. Они документируют функции FT_CyclePort, FT_ResetPort, FT_ResetDevice.
Про FT_CyclePort так и пишут:
"The effect of this function is the same as disconnecting then reconnecting the device from USB. Possible use of this function is situations where a fatal error has occurred and it is difficult, or not possible, to recover without unplugging and replugging the USB cable. ... "

PS to n_bogoyavlensky. Отредактируйте своё сообщение - в качестве цитаты привели не моё высказывание.

[stoker]

У вас все устройство питается от УСБ? Сколько хавает? Мож попробовать внешний источник?

[Седой]

Мне это кажется крайне маловероятным. Этож какая помеха д.б. чтобы 3 попытки перепосылки собой закрыть!

При чем тут 3 перепосылки, я говорю об ошибках Babble and Loss of Activity

[_3m]

По моей версии из-за синхфазной помехи происходит detach и всё. Никакого attach после этого не было. В своё время я с этим разбирался - вешал сниффер на хаб и смотрел какие сообщения он шлёт. Так вот: в аналогичном по симптомам случае, хаб говорил что устройство извлечено из него И ВСЁ. По моей версии сингфазная помеха приводит к тому, что при ОТСУТСТВИИ обмена на шине обе линии и D+ и D- на короткое время =0 становятся (т.е. никаких ошибок нет). Вроде 16-ти полноскоростных бит достаточно. И хаб об отключении девайса сообщает, а вот о последующем подключении почему-то не сообщает.

снял сниффером логи при сбое и при выдергивании.
Сравните
[attachment=29818:ft232bm_...se_fault.html] - ft232bm сбой от помехи (6294) во время обмена, устройство в девайс менеджере присутствует и числится исправным даже после обновления
[attachment=29819:ft232bm_..._Removal.html] - вытаскивание шнурка во время обмена

[galjoen]

При чем тут 3 перепосылки, я говорю об ошибках Babble and Loss of Activity

Т.е. о появление ложного SOP как следствие помехи.
Но это д.б. помеха которая заставит ОБА ПРОВОДА В ВИТОЙ ПАРЕ поменять своё состояние на ПРОТИВОПОЛОЖНОЕ И РАЗНОЕ. D+ должен изменить состояние с 1 на 0 и ОДНОВРЕМЕННО D- с 0 на 1. Что это за помеха такая???
Гораздо более вероятно, что под влиянием помехи ОБА провода в одинаковое состояние перейдут. Было D+ =1, D- =0, а станет D+ =0 и D- =0. И всё это продлится 2.5 микросекунды (вполне нормальная помеха) т.е. 30 бит на фул спид, а не 16 как я писал. Иначе это вроде ложный EOP будет, а там ничего страшного не произойдёт.
Но конечно всё это пока только рассуждения. Нужно реальные данные посмотреть. Что там хаб в на GET_STATUS вернул? Чему равно слово wPortStatus после ошибки?
Когда я с этим разбирался (с помощью снифера), там вроде PORT_CONNECTION=0 был, но за давностью лет могу и напутать. А м.б. у меня тогда другой случай был.
Хорошо бы если бы топикстартер у себя сниффером посмотрел.

[galjoen]

снял сниффером логи при сбое и при выдергивании.

Что-то я не понял ничего. Ваш снифер видимо данные не показывает. Мне лично SnoopyPro нравится. Он халявный и хороший - рекомендую скачать и пользоваться. Единственный недостаток - логи отправлять нельзя/у меня что-то не получается. Но самому смотреть самое то.
1. На хаб в который девайс будете вставлять его натравите.
2. Хаб в диспетчере устройст выключите/включите.
3. Пакеты к хабу он начнёт показывать (штук 30), но вы их пока не смотрите (что-то у меня чтобы посмотреть останавливать приходится).
4. Вставте ваш девайс в порт. При этом ещё штук 30 пакетов пройдёт.
5. Вытащите (ещё 30) и теперь пакеты смотрите.
Другой вариант - сбоя дождитесь.
Интересовать вас должен собственно:
SetupPacket
a3 00 00 00 0x 00 04 00 (где x N порта) - это GET_STATUS к хабу. Хаб в ответ должен 4 байта вернуть (0400 - длина). Биты в этих байтах - состояние (и изменение состояния) данного порта. Об этом в главе 11 написано. Вот значение именно этих битов нас и интересуют.
А у вас какое-то огромное число пакетов в логе. Там видимо и к девайсу пакеты в куче. Тут что-то в районе 100 пакетов быть должно всего. И это с учётом включения самого хаба.

[Седой]

...Иначе это вроде ложный EOP будет, а там ничего страшного не произойдёт....

Кроме как в конце фрейма, перед стартом следующего, что приводит к disable порт.

[galjoen]

Кроме как в конце фрейма, перед стартом следующего, что приводит к disable порт.

Где вы это прочитали? Ссылку если можно (глава и пункт). Я что-то ничего такого про EOP не знаю. Да это и совершенно не логично. Это, наоборот, ложный SOP действует так как вы описали.

[Седой]

Где вы это прочитали? Ссылку если можно (глава и пункт). Я что-то ничего такого про EOP не знаю. Да это и совершенно не логично. Это, наоборот, ложный SOP действует так как вы описали.

USB 2.0
11.2.5 EOF1 and EOF2 Timing Points
...At the EOF2 point, any port that has upstream connectivity will be disabled as a babbler....

[_3m]

Интересовать вас должен собственно:
SetupPacket
a3 00 00 00 0x 00 04 00 (где x N порта) - это GET_STATUS к хабу. Хаб в ответ должен 4 байта вернуть (0400 - длина). Биты в этих байтах - состояние (и изменение состояния) данного порта. Об этом в главе 11 написано. Вот значение именно этих битов нас и интересуют.

snoopypro у меня винду ронят в бсод если я мониторю корневой хаб.
usblyzer все показывает, только приходится мышой по пимпочкам жмакать, я выловил то что вы хотели увидеть

В ответ на Get Port Status к хабу (a3 00 00 00 номер_порта 04 00)
возвращаются данные 01 01 02 00
В сответствии с таблицами 11-20 и 11-21 получается:

wPortStatus :
* A device is present on this port
* This port is not in the Powered-off state

wPortChange :
* Over-Current Status has changed

сразу после этого посылается Clear Port Feature - C_PORT_ENABLE (23 01 00 11 00 01 00 04)
затем вечно и безуспешно долбит Sync Reset Pipe and Clear Stall

[galjoen]

USB 2.0
11.2.5 EOF1 and EOF2 Timing Points
...At the EOF2 point, any port that has upstream connectivity will be disabled as a babbler....

Но там-же написано, что хаб как-раз EOP не дождался, а конец кадра уже наступает... Т.е. именно SOP ложный был.
Смысл (как я понял) там такой: если хаб всё ещё в состоянии WFEOP (т.е. получил SOP и EOP ожидает) в момент EOF2 (завершения одномиллисекундного кадра - скоро уже следующий SOF прийдёт) - вот тогда хаб disable порт и делает.

А вы как поняли? Только жел-но по русски.

В ответ на Get Port Status к хабу (a3 00 00 00 номер_порта 04 00)
возвращаются данные 01 01 02 00
В сответствии с таблицами 11-20 и 11-21 получается:

wPortStatus :
* A device is present on this port
* This port is not in the Powered-off state

wPortChange :
* Over-Current Status has changed

Что-то у меня совсем другие данные получаются. 01 01 - это значит wPortStatus=b0000000100000001. Т.е. начиная с младшего бита:
b0=1 - устройство присутствует на этом порте
b1=0 - порт заблокирован!
b2=0 - не в суспенде
b3=0 - сверхтока нет
b4=0 - сигнала сброса (Port_Reset) нет
b8=1 - на этот порт питание подано
b9=0 - full спид девайс подсоединён к этому порту
Аналогично для wPortChange=b0000000000000010
b0=0 - нет изменения в состоянии соединения
b1=1 - произошло изменение в заблокировании/разблокировании порта
b2 и т.д. =0 - не произошло больше никаких изменений.

сразу после этого посылается Clear Port Feature - C_PORT_ENABLE (23 01 00 11 00 01 00 04)

Тут вы видимо что-то напутали. Что за килобайт данных (00 04 в конце)?

Если больше ничего не попутано, то вроде выходит, что действительно это не то случай, который у меня был. У меня в wPortStatus b0=0. В этом случае похоже "Седой" прав. Действительно babble произошёл (лишний SOP). Теперь нужно подумать как с этим бороться...

[stoker]

Народ, вы что то грузитесь. По-моему проблемму не там ищите. У меня 5 устройств лежит на FT есть с высоковольткой и ШИМом, все работают без нареканий. Автор темы даже пропал, наверное все почнил. Я все же думаю все из-за питания через усб.

[AndreyS]

Народ, вы что то грузитесь. По-моему проблемму не там ищите. У меня 5 устройств лежит на FT есть с высоковольткой и ШИМом, все работают без нареканий. Автор темы даже пропал, наверное все почнил. Я все же думаю все из-за питания через усб.

Вы не правы.
Само собой виновата разводка и качество исполнения платы. Но уметь на программном уровне данную проблемум обойти тоже хорошо бы знать.
Мне лично интересно чем закончится данная ветка по теме.

[stoker]

Вы не правы.
Само собой виновата разводка и качество исполнения платы. Но уметь на программном уровне данную проблемум обойти тоже хорошо бы знать.
Мне лично интересно чем закончится данная ветка по теме.

Можно конечно и обойти программно, но "болезнь нужно лечить, а не убивать симптомы..."

[TriD]

AndreyS +1
Скорее всего это именно разводка проводников от разъема USB до микросхемы, сам наступал на эти грабли

[_3m]

Можно конечно и обойти программно, но "болезнь нужно лечить, а не убивать симптомы..."

Вы неправы, впрочем как и многие дугие заявляющие "поменяй шнурок на менее китайский и не парься" или "у меня ничего не виснет, поэтому проблемы не существует".
Бороться защитами и разводкой с помехой дело безнадежное. Всегда найдется помеха, которая пролезет через самую навороченную защиту и завесит вашу систему в самое неподходящее время.
Интерфейс для индустриальных применений должен обеспечивать:
* защиту от помех (фильтрация, развязка, разводка)
* автоматическое восстановление работы после воздействия мощной помехи (или софтверного сбоя) при условии что оборудование не вышло из строя. Вот с этим у usb боо-льшие проблемы!

Можно проводить примитивный тест: замкнуть пинцетом D+ и D- во время обмена с устройством, это совершенно безопасно для оборудования, но сразу выводит софт на чистую воду. Хочется добиться чтобы устройство продолжило работу после такого издевательства. Если зависнет - ему в индустрианых делах не место.

[galjoen]

...
* автоматическое восстановление работы после воздействия мощной помехи (или софтверного сбоя) при условии что оборудование не вышло из строя. Вот с этим у usb боо-льшие проблемы!
...
Если зависнет - ему в индустрианых делах не место.

+1 (и это только класс B будет!)
Мне приходится по 2 девайса (самодельные переходники USB-CAN) на одну линию CANа в разные её концы вешать чтобы:
1. Если ОДНО зависнет - всё работать продолжало.
2. Если линию (USB или CAN безразлично) в ОДНОМ месте рубануть - всё работать продолжало.

Насчёт SnoopyPro. У меня он хабы без проблем смотрит. Он что-то там в реестре оставляет если некорректно выйти. Питание вырубить или вроде даже просто uninstal и uninstal service перед выходом не сделать. Сам сталкивался с тем, что комп виснуть начинал после этого. Очень интересная ситуация происходила - втыкаешь девайс с определёнными VID PID - полный вис. В свай девайс такие VID PID прописал - тоже виснет.

А меня тут 2 крамольные мысли посетили:
1. Про FTDI (Надеюсь любителей этого девайса здесь нет).
А м.б. это такое исключительное гуано, что под воздействием помехи у него ВНУТРЕ что-то сбивается и SOP оно шлёт? С другими девайсами (процессоры с USB функциями и просто внешние USB интерфейсы) такой картины ведь не наблюдается.
2. Про ложные EOP.
А м.б. стоит самому ложные EOP формировать? В конце кадра когда все посылки завершены. Ничему ведь тут вроде не повредишь? А если в пределах кадра ложный SOP случился, то ложный EOP его скомпенсирует и всё работать продолжит. В смысле никакого babble и LOA не случится! Минус на минус дают плюс! Сейчас у меня девайса, на котором такое попробовать можно под руками нет, но как будет - попробую.

[AndreyS]

Интерфейс для индустриальных применений должен обеспечивать:
* защиту от помех (фильтрация, развязка, разводка)
* автоматическое восстановление работы после воздействия мощной помехи (или софтверного сбоя) при условии что оборудование не вышло из строя. Вот с этим у usb боо-льшие проблемы!

Добрый день.

Я с вами полностью согласен.

Хотелось бы теперь вернуть всех к теме разговора

Как вы можете прокомментировать ответ galjoen?

Для galjoen: И какие мысли появились у самого galjoen?
Долго я письмо писал. Уже ответили.

А меня тут 2 крамольные мысли посетили:
1. Про FTDI (Надеюсь любителей этого девайса здесь нет).
А м.б. это такое исключительное гуано, что под воздействием помехи у него ВНУТРЕ что-то сбивается и SOP оно шлёт? С другими девайсами (процессоры с USB функциями и просто внешние USB интерфейсы) такой картины ведь не наблюдается.

Неа. Это относится как минимум еще к CY7C68013.
У меня подобное наблюдается когда рядом (за стенкой) кто-то начинает баловаться пуском двигателей (короче когда начинают работать станки и силовые установки). Причем это происходит судя по всему не по питанию (фазы физически разные).
Устройство лежит в железном, заземленном ящике. Вот только USB хвост торчит. Пробовали мы различные способы заземления экрана USB, но пока в данном случае наилучший результат дала короткая связь от разъема USB к заземляющему концу (без резистора и конденсатора) самого прибора. Защитные диоды по сигнальным проводам не спасают от этого. Применяли мы и специальные USB 2.0 шнуры с ферритовыми кольцами.
Такое (зависание USB устройства, засыпание его) происходит редко, но метко (пользователям надоедает именно процесс выдергивания шнурка).
Устройство имеет собственное питание и для отвиса приложения достаточно выдернуть воткнуть шнур. Попытка остановить устройство и пустить его снова приводит к сообщению винды о презапуске (короче на лету не отсоединяет драйвер при таком состоянии устройства). Но такое происходит исключительно на скорости High-Speed при отключении хаба с USB2.0 и соответствующем перевешивании устройства системой на Full-speed такой зависимости не наблюдается. А у народа ведь есть USB флешки Вот они USB2.0 обратно и включают.

Сообщение отредактировал AndreyS - Feb 18 2009, 15:51

[_3m]

1. Про FTDI (Надеюсь любителей этого девайса здесь нет).
А м.б. это такое исключительное гуано, что под воздействием помехи у него ВНУТРЕ что-то сбивается и SOP оно шлёт? С другими девайсами (процессоры с USB функциями и просто внешние USB интерфейсы) такой картины ведь не наблюдается.

Наблюдается.
У меня с разной степенью вероятности виснут все устройства, нужно только внимательно за ними наблюдать. Устройства с внешними подключениями в целом виснут чаще чем usb свистки, устройства обмен с которыми осуществяется изредка виснут намного реже устройств которые обмениваются информацией непрерывно. Low speed устройства виснут очень редко. Симптомы зависания во многом схожи с тем что обсуждается в этой ветке.
Впрочем если предположить что помеха воздействует на хаб так и должно быть.

Сообщение отредактировал _3m - Feb 18 2009, 15:26

[AndreyS]

А меня тут 2 крамольные мысли посетили:
1. Про FTDI (Надеюсь любителей этого девайса здесь нет).
А м.б. это такое исключительное гуано, что под воздействием помехи у него ВНУТРЕ что-то сбивается и SOP оно шлёт? С другими девайсами (процессоры с USB функциями и просто внешние USB интерфейсы) такой картины ведь не наблюдается.

В догонку. Не успел по времени дописать.

Причем (как нам показалось, а может это так и есть) такое наблюдается практически всегда на машинах с Intel ICH5 (чипсет 865) и чипсетом 945 (какой там мост я уже не помню) и никогда на машинах с Intel ICH4 и VIA (именно по этому мы это засекли только на клиентских машинах, у нас то VIA. Мы их по всякому били, но стабильно все работало).

[galjoen]

Наблюдается.

Да отошёл я как-то в сторону от таких USB проблем. Как стал свой девайсы лепить, которые в такой ситуации сами о себе заботятся, так и интерес ко всему этому потерял т.к. думал, что хабом управлять невозможно. А зря. Если, как пишет "Седой", из юзермоды можно хабу SetupPacket отправлять, то вроде всё это просто решается.
По моему мнению нужно хабу такой SetupPacket отправить:
a3 01 04 0n 00 00 00 00 (n - N порта)
Т.е. SET_FEATURE + PORT_RESET к тому порту того хаба, в который наш девайс подключен.

Кстати что там у вас с "Clear Port Feature - C_PORT_ENABLE (23 01 00 11 00 01 00 04)". Там ведь точно что-то напутано.

В догонку. Не успел по времени дописать.

Причем (как нам показалось, а может это так и есть) такое наблюдается практически всегда на машинах с Intel ICH5 (чипсет 865) и чипсетом 945 (какой там мост я уже не помню) и никогда на машинах с Intel ICH4 и VIA (именно по этому мы это засекли только на клиентских машинах, у нас то VIA. Мы их по всякому били, но стабильно все работало).

Из моего опыта - имеются два типа хостов. Один который соглашениям о HID удовлетворяет, а другой нет. Основное различие в том, что если при работе HID через контрольный канал NAK хосту вернуть, то одни (соответствующие) следующую транзакцию только в следующем кадре начнут (через милисекунду), а другие (несоответствующие) сразу-же. Вначале были только соответствующие хосты, и когда появились несоответствующие у меня с ними все работать перестало (ну очень плохо работало). В основном несоответствующие с AMD процессором шли. Мне даже пришлось один такой купить чтобы разобраться в чём дело. Он PCI, у него NEC на чипе написано. И VIA вроде к несоответствующим тоже относились (за давностью забыл). М.б. эти китайцы не только на один (HID) стандарт наплевали, но и на другой? Или наоборот?

[Седой]

Озвучу свое видение проблемы по итогам обсуждения и собственного опыта:

1. Одной из причин "непонятного поведения" программ, работающих с USB устройствами (не только на основе FTDI) является перевод порта хаба, к которому подключено устройство в disable state, при этом устройство остается подключенным.
2. Алгоритм работы стека используемых USB драйверов не производит выхода из такой ситуации, что приводит к "зависанию" программы.
3. Возможно алгоритм так и должен работать, так как предполагает, что такая ситуация является ненормальной и следует избавляться от причин, ee вызвавших.
4. Вероятность появления ненормальной ситуации не равна 0.

Как можно видоизменить работу алгоритма:

Драйвер устройства:
1. Драйвер устройства должен читать статус порта (IOCTL_INTERNAL_USB_GET_PORT_STATUS)
2. При появлении ситуации disable port направить запрос IOCTL_INTERNAL_USB_ENABLE_PORT
3. Если IOCTL_INTERNAL_USB_ENABLE_PORT вернет ошибку, то произвести
IOCTL_INTERNAL_USB_RESET_PORT.

Firmware устройства:
Должно уметь различать USB_RESET, полученные в состояниях Configured и Powered, и правильно их обрабатывать.

PS. Судя по документации WDK и тексту заголовочных файлов действия, производимые драйвером, можно сделать и из UserMode, обращаясь к драйверу хаба и/или хоста. Но это нужно проверять.
PS2. Да, кстати, забыл дать ссылку на предлагаемый алгоритм
http://download.microsoft.com/download/5/b...SBdrv-tips2.ppt
обратите внимание на Recommended URB error recovery steps

Сообщение отредактировал Седой - Feb 18 2009, 18:29

[koluna]

Попробуйте.

Попробуем.

PS to n_bogoyavlensky. Отредактируйте своё сообщение - в качестве цитаты привели не моё высказывание.

Извиняюсь. Только я не пойму, как его отредактировать?

Кстати всё это легко проверить. Если просто девайс подключить и никакого обмена с ним не вести, а вот выключателем-то пощёлкать. И в таких условиях отключение с переходом в слип проверить. Если обмена с девайсом никакого не будет, а девайс всё равно отключится, то версия об ошибках сама-собой отпадёт.

Проверим.

У вас все устройство питается от УСБ? Сколько хавает? Мож попробовать внешний источник?

Схему привёл.
Левая часть устройства питается от USB.
Потребление не должно быть большим... проверим.

Хорошо бы если бы топикстартер у себя сниффером посмотрел.

Я не знаю что такое "сниффер" и с интерфейсом USB пока знаком очень поверхностно

Народ, вы что то грузитесь. По-моему проблемму не там ищите. У меня 5 устройств лежит на FT есть с высоковольткой и ШИМом, все работают без нареканий. Автор темы даже пропал, наверное все почнил. Я все же думаю все из-за питания через усб.

Автор не пропал, он здесь
Попробуем запитаем не от USB ещё и левую часть...

Вы не правы.
Само собой виновата разводка и качество исполнения платы. Но уметь на программном уровне данную проблемум обойти тоже хорошо бы знать.
Мне лично интересно чем закончится данная ветка по теме.

Хм... я не думаю, что сделал плату плохо...
Вот, вид сверху (фотография) и картинка из OrCAD'а - верх и низ платы.

Жду замечаний по качеству разводки

Да. Вот ещё что.
Экран USB-кабеля соединён с общей цепью устройства (левая часть на приведённой мною схеме).
На нижней стороне ПП распаяны на общую цепь конденсаторы 47 пФ (в сантиметре от разъёма) и электролит по питанию +5 В (100.0).

AndreyS +1
Скорее всего это именно разводка проводников от разъема USB до микросхемы, сам наступал на эти грабли

Вот здесь вот поподробнее, пожалуйста

Даю верхний и нижний слои ПП отдельно, чтобы было лучше видно...

Эскизы прикрепленных изображений

 

[galjoen]

Драйвер устройства:
1. Драйвер устройства должен читать статус порта (IOCTL_INTERNAL_USB_GET_PORT_STATUS)
2. При появлении ситуации disable port направить запрос IOCTL_INTERNAL_USB_ENABLE_PORT
3. Если IOCTL_INTERNAL_USB_ENABLE_PORT вернет ошибку, то произвести
IOCTL_INTERNAL_USB_RESET_PORT.

В принципе согласен, но хочу заметить, что можно улучшить данный алгоритм (хотя и этот м.б. будет работать). Если посмотреть таблицу 11-1, то там видно, что нужно делать в каждом состоянии порта. Т.к. состояние порта нам доступно через IOCTL_INTERNAL_USB_GET_PORT_STATUS, то можно не делать лишних попыток, а сразу предпринимать нужные действия. И ещё я думаю, что IOCTL_INTERNAL_USB_ENABLE_PORT ни при каких условиях не будет возвращать ошибку. Откуда там может появиться ошибка? Только в одном случае - хаб на Setup вернёт STALL, а больше ни при каких условиях. Но хаб никогда не будет STALL возвращать. Просто порт останется в состоянии disable и всё. Нужно просто после подачи команд хабу проверять его состояние - опять же IOCTL_INTERNAL_USB_GET_PORT_STATUS.
На мой взгляд наибольшие сложности доставит поиск хаба и порта в который воткнут наш девайс. И ещё нужно как-то разделить ситуацию когда девайс действительно выдернули, и когда ошибка. Кол-во попыток восстановления ограничить что-ли?

Firmware устройства:
Должно уметь различать USB_RESET, полученные в состояниях Configured и Powered, и правильно их обрабатывать.

Я так думаю, что при IOCTL_INTERNAL_USB_ENABLE_PORT USB_RESET не происходит. Просто девайс выйдет из Syspended и всё. А при IOCTL_INTERNAL_USB_RESET_PORT резет произойдёт. Кстати его вроде нужно подавать только если порт в состоянии Disconnected (хаб думает что девайс выдернут из порта). Но вот восстановить настройки в девайсе, а именно это, я думаю, имелось ввиду под правильной обработкой, может и программа на компьютере. Особенно это актуально для девайсов на базе FTDI и т.п. В них ведь невозможно ничего изменить внутре.

PS. Судя по документации WDK и тексту заголовочных файлов действия, производимые драйвером, можно сделать и из UserMode, обращаясь к драйверу хаба и/или хоста. Но это нужно проверять.

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

[_3m]

1. Одной из причин "непонятного поведения" программ, работающих с USB устройствами (не только на основе FTDI) является перевод порта хаба, к которому подключено устройство в disable state, при этом устройство остается подключенным.
2. Алгоритм работы стека используемых USB драйверов не производит выхода из такой ситуации, что приводит к "зависанию" программы.

От драйвера зависит.
Я снял лог при замыкании D+ и D- на HID устройстве на базе pic18f2550.
[attachment=29876:hid_tst.html]
Оно таки само развесилось, в логе видно что реакция на сбой сильно отличается от ftdi и действия гораздо более осмысленные. Впрочем замыкания более 2-3 секунд HID тоже не переносит - виснет без каких либо сообщений об ошибках также как и ftdi.

3. Возможно алгоритм так и должен работать, так как предполагает, что такая ситуация является ненормальной и следует избавляться от причин, ee вызвавших.

Может с точки зрения usb.org и должен, но нас такое поведение категорически не устраивает.

PS. Судя по документации WDK и тексту заголовочных файлов действия, производимые драйвером, можно сделать и из UserMode, обращаясь к драйверу хаба и/или хоста. Но это нужно проверять.

насчет действий из UserMode - это отдельная интересная тема.
Я перезапуск силами PC делал как в исходнике devcon.

Сообщение отредактировал _3m - Feb 18 2009, 19:37

[stoker]

Сразу что мне не понравилось в разводке - толщина цепи питания. Там на месте кабеля я так понимаю дожен быть разъём? А где кондер на 4-й ноге? Тантал бы ещё по питанию и катушку на 5 В. хорошо бы поставить после УСБ разъёма.
Оффтоп: Похоже свою ФТ я убил замыканиями пинцетом ног D+, D-. Видимо случайно не то замкнул. Теперь она все время висит в суспенде. А винда ругается что устр-во не опознано.

[galjoen]

От драйвера зависит.
Я снял лог при замыкании D+ и D- на HID устройстве на базе pic18f2550.
[attachment=29876:hid_tst.html]
Оно таки само развесилось, в логе видно что реакция на сбой сильно отличается от ftdi и действия гораздо более осмысленные. Впрочем замыкания более 2-3 секунд HID тоже не переносит - виснет без каких либо сообщений об ошибках также как и ftdi.

Да, Pic здесь ни при чём. Надо отдать должное - майкрософт видимо над HID хорошо поработал. Ещё-бы - это ведь их изобретение. Хотя и MassStorage, когда я его исследовал, мне очень понравился. Ну на 1 треть запросов отвечаешь, на 2-ю треть не отвечаешь, а на 3-ю - вообще STALL посылаешь и всё работать продолжает! На реальные флешки смотришь (самые китайские) - там такой бардак, а всё работает. Никто ничего не замечает! Единственно вот с составным устройством там у них глюк. Если из-за ошибок в одном из интерфейсов энумерация происходит - другой теряется.

А что там за Clear Port Feature (3, Enable/Disable Change) в логе? Какой SetupPacket ему соответствует? Наверное подобным образом сделать следует.

Может с точки зрения usb.org и должен, но нас такое поведение категорически не устраивает.

Не должен. По логу это видно. Set Port Feature (3, Reset) - это видимо и есть IOCTL_INTERNAL_USB_RESET_PORT, который мы собираемся использовать. Хотя с уверенностью утверждать не могу - на сам пакет тоже не мешало бы посмотреть.

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

[Седой]

От драйвера зависит.
Я снял лог при замыкании D+ и D- на HID устройстве на базе pic18f2550.
Оно таки само развесилось, в логе видно что реакция на сбой сильно отличается от ftdi и действия гораздо более осмысленные.Впрочем замыкания более 2-3 секунд HID тоже не переносит....

Драйвер Microsoft делал (но 3 сек не учел)

Я перезапуск силами PC делал как в исходнике devcon.

Вызовом Class Intstallera - вполне правильный и легальный способ и рекомендуемый Microsoft, кстати недели две назад
на форуме Microsoft спрашивали: почему IOCTL_USB_HUB_CYCLE_PORT не работает из UserMode - драйверописатель из Microsoft от ответа ушел - предложил вышеуказанный способ.

[galjoen]

Драйвер Microsoft делал (но 3 сек не учел)

М.б. не 3, а 5? Тогда они всё по стандарту сделали, если в течении 5 секунд не удаётся ошибку исправить - всё.

[Седой]

М.б. не 3, а 5? Тогда они всё по стандарту сделали, если в течении 5 секунд не удаётся ошибку исправить - всё.

Но зависать-то зачем - сделал remove device и всё.

[koluna]

Сразу что мне не понравилось в разводке - толщина цепи питания.

Каюсь. Забыл увеличить. Было в планах
Неужели может повлиять?
Можно проволокой сверху потолще...

Там на месте кабеля я так понимаю дожен быть разъём?

Да. Но с разъёмом я немножко напутал или не нашёл... поэтому впаял прямо кабель.

А где кондер на 4-й ноге?

Нету его. Подвесим.

Тантал бы ещё по питанию и катушку на 5 В.

Тантал есть (снизу платы, 100 мкФ). Правда далеко стоит, ближе к DC-DC.
Нету ферритовой бусины, как на рисунке 6.1 в даташите.
Какую катушку лучше и как включить?

Оффтоп: Похоже свою ФТ я убил замыканиями пинцетом ног D+, D-. Видимо случайно не то замкнул. Теперь она все время висит в суспенде. А винда ругается что устр-во не опознано.

Там же резисторы внутри, не должно...

[stoker]

Да. Но с разъёмом я немножко напутал или не нашёл... поэтому впаял прямо кабель.

Просто от микрухи до оплетки линии далековато получается. Хотя в принципе это не high speed.

Тантал есть (снизу платы, 100 мкФ). Правда далеко стоит, ближе к DC-DC.
Нету ферритовой бусины, как на рисунке 6.1 в даташите.
Какую катушку лучше и как включить??

Тантал лучше ближе к микрухе.
Катушку у себя поставил 2,2мкГн, но думаю и без неё тоже будет работать.

Там же резисторы внутри, не должно...

Я походу не только +/-D замкнул. Видимо что то ещё.

[_3m]

А что там за Clear Port Feature (3, Enable/Disable Change) в логе? Какой SetupPacket ему соответствует? Наверное подобным образом сделать следует.

Код

3946-3945:
Clear Port Feature
This request resets a value reported in the port status.
Offset Field Size Value Description
0 bmRequestType 1 23h  
4..0: Recipient  ...00011  Port
6..5: Type  .01.....  Class
7: Direction  0.......  Host-to-device
1 bRequest 1 01h Clear Port Feature
2 wValue 2 0011h Feature: Enable/Disable Change
4 wIndex 2 0003h Port
6 wLength 2 0000h

Не должен. По логу это видно. Set Port Feature (3, Reset) - это видимо и есть IOCTL_INTERNAL_USB_RESET_PORT, который мы собираемся использовать. Хотя с уверенностью утверждать не могу - на сам пакет тоже не мешало бы посмотреть.

Код

3959-3958:
Set Port Feature
This request sets a value reported in the port status.
Offset Field Size Value Description
0 bmRequestType 1 23h  
4..0: Recipient  ...00011  Port
6..5: Type  .01.....  Class
7: Direction  0.......  Host-to-device
1 bRequest 1 03h Set Port Feature
2 wValue 2 0004h Feature: Reset
4 wIndex 2 0003h Port
6 wLength 2 0000h

[galjoen]

Получается, что Clear Port Feature (3, Enable/Disable Change) это CLEAR_FEATURE + C_PORT_ENABLE. Её два раза вызывают чтобы изменить и сделать как было.
А Set Port Feature (3, Reset) это SET_FEATURE + PORT_RESET. Это видимо самое кардинальное лекарство от всех болезней, типа гильотины. Напоследок приберегли.

[AndreyS]

Хм... я не думаю, что сделал плату плохо...
Вот, вид сверху (фотография) и картинка из OrCAD'а - верх и низ платы.

Жду замечаний по качеству разводки

Да. Вот ещё что.
Экран USB-кабеля соединён с общей цепью устройства (левая часть на приведённой мною схеме).
На нижней стороне ПП распаяны на общую цепь конденсаторы 47 пФ (в сантиметре от разъёма) и электролит по питанию +5 В (100.0).

Добрый день.

Ну первое что лично мне не понравилось это несимметричная линия D+ и D-. Зачем нужно было ставить два переходных отверстия?? Да еще и с поворотом в 90 градусов, хотя и без прямых углов. Куда именно посажен SHELL разъема?? В какую точку земли? От этого тоже зависит устойчивость. Я бы поставил ее к общему проводу в районе источника питания. Там же поставил шунтирующих емкостей (керамику 0.1 и тантал на десяток uF). Потом что-то не помню я чтобы у FTDI были внутренние последовательные резисторы по шине D+ и D- (везде вешали внешние), но быть может уже все и изменилось. Поставил бы еще по шине D+ и D- защитные диоды. LC фильтр и варистор по USB питанию.

Попробуйте немного поиграться с переносом точки земления экрана кабеля и установкой защитного диода по питанию USB (ну варистор поставьте).
Еще хороший вариант (в качестве эксперимента) положить вашу плату в железную коробочку. Корпус объединить с общим проводом и до кучи его заземлить (в землю). Экран кабеля так же подключить к корпусу. И дальше в таком исполнении поиграться на предмет устойчивости. При этом всю схему питать уже не от USB, а от собственного источника, который будет сидеть на другой фазе по отношению к компьютеру. На мой взгляд если сбоить будет, то это уже точно помеха прикладываемая к USB хабу (неустойчивая работа хаба). Что в принципе сейчас в этой ветке и обсуждается(лось).

Вот такое мое мнение.

[koluna]

Следующий доклад

1. Порт закрыт. Обмена нет. Тыркаю вилкой - иногда возникает сбой. Т. е., ни ПК с портом не работает, ни МК в конверторе с FT245R не работает, а сбои возникают...
2. Ток потребления от USB левой части конвертора (по схеме) - не более 43 мА в режиме обмена.
3. Электролит по питанию переставил почти вплотную к распаянному на плату USB-кабелю.
4. Существенно утолщил цепь +5 В от USB-кабеля (пропаял приличным проводом сверху по дорожкам).
5. На вывод VCCIO FT245R повесил 0.1 мкФ (около 5 мм от вывода, ближе не получилось).
6. Сбои возникают даже при незапитанной правой части конвертора, т. е., кабель питания к разъёму питания конвертора не подключен. Вилкой источника питания дёргаем как обычно туда-сюда (напоминаю, что правая часть у меня сейчас запитана через обычный источник питания БПС 5-0.5).
7. Попробовал работать на рядом стоящем компьютере, подключенном к той же розетке, что и первый компьютер. Сбоев нет!

Ну первое что лично мне не понравилось это несимметричная линия D+ и D-. Зачем нужно было ставить два переходных отверстия?? Да еще и с поворотом в 90 градусов, хотя и без прямых углов.

Для USB это критично?
Что значит "несимметричная"?
Всё объясняется просто
Плата собственного изготовления, без металлизации отверстий. Предполагал ставить USB-разъём. А разъём можно распаять только с обратной стороны платы...
Разъём не поставил, впаял в плату USB-кабель...

Куда именно посажен SHELL разъема?? В какую точку земли?

Распаян на общий сразу за проводами. Провода без экрана - около 8 мм.

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

Левая часть конвертора (смотри схему) питается от USB. Внешний источник питания используется только для правой части конвертора.

Потом что-то не помню я чтобы у FTDI были внутренние последовательные резисторы по шине D+ и D- (везде вешали внешние), но быть может уже все и изменилось.

У микросхем с индексом "R" всё изменилось

Поставил бы еще по шине D+ и D- защитные диоды. LC фильтр и варистор по USB питанию.

Какие именно, любые? Катодами на линии, а анодами на общую цепь?
Ёмкость возле +5 В кабеля уже 100.0 стоит. Можно, индуктивность поставить. До конденсатора или после?
А варистор как выбрать? Какой, например?

Попробуйте немного поиграться с переносом точки земления экрана кабеля и установкой защитного диода по питанию USB (ну варистор поставьте).

Смущает то, что на рядом стоящем компьютере (более простом и старом) работает без сбоев (по крайней мере весь вечер).
А на первом компьютере - со сбоями. Я уже наловчился сбой с первого раза вызывать: выдёргиваешь вилку из удлиннителя и получаешь приличный зависон!

Еще хороший вариант (в качестве эксперимента) положить вашу плату в железную коробочку. Корпус объединить с общим проводом и до кучи его заземлить (в землю). Экран кабеля так же подключить к корпусу. И дальше в таком исполнении поиграться на предмет устойчивости. При этом всю схему питать уже не от USB, а от собственного источника, который будет сидеть на другой фазе по отношению к компьютеру. На мой взгляд если сбоить будет, то это уже точно помеха прикладываемая к USB хабу (неустойчивая работа хаба). Что в принципе сейчас в этой ветке и обсуждается(лось).

Где бы её ещё взять, другую фазу-то
А если неустойчивая работа хаба, то что же делать-то... не компьютер же бегать подбирать...

Вот такое мое мнение.

Спасибо всем большое за их мнения! Надеюсь, сообща разберёмся!