Перейти к содержанию
    

FT245R работает со сбоями

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

 

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

 

Собрал устройство с 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 запустить своё приложение?

 

 

Спасибо заранее!

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Кабель не причем. У меня кабель 3 метра купленный в АШАНе за 40 рублей, там вообще экрана нету и все равно работает как часы.

По моему у вас кто-то со стороны устройства данные забывает принимать.

1. Данные приходят без ошибки, режим bulk

2. Не совсем понял, о каком приложении идёт речь?

 

 

Читал, что кабель может быть очень даже виноват... FT плохо работает в условии помех...

Обмен идёт между ПК и устройством пакетами по 62 байта.

Это просто тест пока... ПК шлёт 62 байта. Устройство принимает и шлёт обратно эти 62 байта. Пока ПК не получит байты, высланные устройством, новые байты он не пошлёт :)

 

1. Понятно.

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Читал, что кабель может быть очень даже виноват... FT плохо работает в условии помех...

Обмен идёт между ПК и устройством пакетами по 62 байта.

Это просто тест пока... ПК шлёт 62 байта. Устройство принимает и шлёт обратно эти 62 байта. Пока ПК не получит байты, высланные устройством, новые байты он не пошлёт :)

 

1. Понятно.

 

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

 

В таком случае советую проверить в каком состоянии находятся WR, RD,TXE, RXF когда устройство "висит".

Что управляет FT?

...

2. Первое вчто приходит на ум, использовать резидентный процесс, который проверяет подключено ли устройство и запускает калькулятор.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В таком случае советую проверить в каком состоянии находятся WR, RD,TXE, RXF когда устройство "висит".

Что управляет FT?

 

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

при сбое.

Управляет ATmega88.

 

2. Первое вчто приходит на ум, использовать резидентный процесс, который проверяет подключено ли устройство и запускает калькулятор.

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Работает, работает, потом начинаются сбои при записи в порт со стороны ПК... возникает исключение ...

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

Ну про исключение, я зря сказал :)

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

 

Просто возникает ошибка при записи в порт...

Программа останавливается. Порт заново не открывается, пока устройство не переткнёшь...

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ну про исключение, я зря сказал :)

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

 

Просто возникает ошибка при записи в порт...

Программа останавливается. Порт заново не открывается, пока устройство не переткнёшь...

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

 

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

Ошибка в программе, а не в железе.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Ошибка в программе, а не в железе.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

 

1. Драйвер должен отменить все операции ввода/вывода.

2. Освободить ресурсы (память и т.д.), захваченные при обработке CreateFile.

3. ...

 

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

 

Почему BC и Delphi - в определенных ситуациях RTL вызвает TerminateThread, что приводит к тому, что ранее запрошенный

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Ошибка в программе, а не в железе.

 

В Delphi.

У меня алгоритм следующий.

1. Подключаем устройство.

2. Запускаем приложение.

3. Открываем порт.

4. Передаём-принимаем в цикле до нажатия "Стоп". Причём передаём снова только после того как примем ответ. Т. е., Handshake такой получается :)

5. Закрываем порт.

 

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

После переподключения устройства всё начинает работать нормально вновь...

 

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

 

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

После переподключения устройства всё начинает работать нормально вновь...

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

 

Будет существенно лучше. В моем случае, т.к. помех было очень много и мощных окончательно помог только watchdog, от которого срабатывал полевик, отключающий подтяжку D+ к 3.3В. Устройство отваливалось, после чего его можно было переоткрыть и восстановить работоспособность не выдергивая кабель руками.

 

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

 

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

 

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

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

Soft.rar

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

 

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

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

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

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

 

Вызывать

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...