[galjoen 0]

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

[koluna 0]

На первый взгляд все нормально.

Давайте попробуем отловить ошибку, для этого переделайте немного

вызов генераторов исключений

Вместо XXX_ComPort_Error.Create("Сообщение об ошибке")

 

Вызывать

XXX_ComPort_Error.CreateFmt("Сообщение об ошибке %x",[GetLastError])

 

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

 

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

 

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

 

Уже говорили, что FT именно засыпает (у кого-то). Что у меня - проверим и сообщим! :)

Нога - PWREN#.

А что конкретно может быть в железе и кабеле?

Кабель недлинный, экранированный. Только вот не знаю - витой или нет внутри...

А почему эта синфазная помеха переводит FT в сон?

[Седой 0]

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

 

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

вы хотите получить.

[koluna 0]

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

 

Проверил.

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

 

RXF#, TXE#, RD# - 1.

WR - 0.

 

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

 

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

вы хотите получить.

 

Уже прочитал :)

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

 

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

 

У меня какая-то странная ситуация сейчас... несмотря на обработку исключений приложение виснет при ошибке до передёргивания устройства...

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

[Седой 0]

Проверил.

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

 

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

 

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

Изменено 10 февраля, 2009 пользователем Седой

[koluna 0]

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

 

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

 

Я тоже об этом подумал. Но потом локализовал место "зависания" с помощью записи в лог-файл (через каждую интересующую строчку кода).

Понял, что "зависание" происходит в момент попытки закрытия порта (CloseHandle) после возникновения ошибки, появившейся при записи WriteFile.

Приложение крепко "подвисает". Но если отсоединить USB-устройство, то оживает!

 

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

 

Вчера повесил экран кабеля напрямую на общую цепь устройства.

За весь вечер - одна ошибка и то при коммутации/декоммутации приличной нагрузки! Налицо - улучшение! :)

Сегодня продолжим тестирование.

 

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

Изменено 10 февраля, 2009 пользователем n_bogoyavlensky

[vetal 0]

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

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

[koluna 0]

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

 

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

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

 

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

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

 

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

[Седой 0]

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

 

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

 

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

 

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

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

 

 

 

 

 

 

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

 

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

[_3m 4]

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

 

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

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

 

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

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

 

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

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

 

Вообще я просто угораю от работы усб, даже в настольных условиях.

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

Я не заю можно ли спроектировать более глючное устройство.

Как это будет жить на объекте даже страшно представить.

Изменено 10 февраля, 2009 пользователем _3m

[Седой 0]

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

 

 

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

 

Хост кстати ответил правильно - ошибкой транзакции и драйвер FTDI должен адекватно отреагировать на эту ситуацию,

мог бы сделать ResetPort или по крайней мере установить флаг, чтобы при вызове CloseHandle не входить в ступор.

 

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

[koluna 0]

Эта ошибка 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.

[Седой 0]

А откуда это?

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

 

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

Несмотря на развязку!

.....

Т. е., помеха идёт по кабелю в конвертор и как-то проходит через развязку или через DC-DC конвертор, попадая на USB.

 

А причем тут развязка.

Посмотрите http://caxapa.ru/lib/emc_immunity.html

[Седой 0]

Сейчас просмотрел документацию на драйвера FTDI.

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