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

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

Собрал устройство с 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.