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]

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

[AndreyS]

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

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

[stoker]

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

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

[_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]

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

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

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