Jump to content

    

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

 

 

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

Share this post


Link to post
Share on other sites
Здравствуйте!

 

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

 

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

Share this post


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

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

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

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

 

 

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

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

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

 

1. Понятно.

 

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

Share this post


Link to post
Share on other sites
Читал, что кабель может быть очень даже виноват... FT плохо работает в условии помех...

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

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

 

1. Понятно.

 

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

 

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

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

...

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

Share this post


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

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

 

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

при сбое.

Управляет ATmega88.

 

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

 

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

Share this post


Link to post
Share on other sites
Работает, работает, потом начинаются сбои при записи в порт со стороны ПК... возникает исключение ...

 

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

Share this post


Link to post
Share on other sites
Что за исключение? ( exeption)

 

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

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

 

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

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

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

Share this post


Link to post
Share on other sites
Ну про исключение, я зря сказал :)

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

 

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

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

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

 

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

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

Share this post


Link to post
Share on other sites
Симптомы понятны, нет нормального вызова CloseHandle. Работаете скорее всего с BC или Delphi.

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

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

Share this post


Link to post
Share on other sites
Не могли бы Вы пояснить подробно?

 

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

 

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

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

3. ...

 

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

 

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

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

 

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

Share this post


Link to post
Share on other sites
Симптомы понятны, нет нормального вызова CloseHandle. Работаете скорее всего с BC или Delphi.

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

 

В Delphi.

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

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

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

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

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

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

 

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

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

 

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

 

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

 

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

 

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

Share this post


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

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

Share this post


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

 

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

 

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

 

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

 

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

 

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

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

Soft.rar

Share this post


Link to post
Share on other sites
USBThread.pas - модуль потока работы с FT245.

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

 

 

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

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

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

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

 

Вызывать

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

 

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this