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

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



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

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

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

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

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



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

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

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

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

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

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

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



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

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

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

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

ПК и устройство с 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) не убивается даже таск-менеджером пока не передернешь усб.
Я не заю можно ли спроектировать более глючное устройство.
Как это будет жить на объекте даже страшно представить.

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

Хост кстати ответил правильно - ошибкой транзакции и драйвер 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) для выхода из ошибочного состояния.