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

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

Собрал устройство с 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. Не совсем понял, о каком приложении идёт речь?

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

1. Понятно.

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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



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



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

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

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

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

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

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



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

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

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

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

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



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

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

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

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

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

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



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

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

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

ПК и устройство с 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...

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

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

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

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

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

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

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








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

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


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


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

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

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

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

А откуда это?



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



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

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

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

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

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

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

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

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



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

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

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



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

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



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

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

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


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


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

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

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

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

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

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



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



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



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

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



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

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

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

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

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

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

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

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

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

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



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



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



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



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

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

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

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

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

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

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


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



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




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



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

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

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

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

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

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

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

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


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

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