koluna 0 6 февраля, 2009 Опубликовано 6 февраля, 2009 · Жалоба Здравствуйте! Наконец-то дело дошло и у меня до практики и сразу столкнулся с трудностями :( Собрал устройство с 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 запустить своё приложение? Спасибо заранее! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
stoker 0 6 февраля, 2009 Опубликовано 6 февраля, 2009 · Жалоба Здравствуйте! Наконец-то дело дошло и у меня до практики и сразу столкнулся с трудностями :( Собрал устройство с 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. Не совсем понял, о каком приложении идёт речь? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
koluna 0 6 февраля, 2009 Опубликовано 6 февраля, 2009 · Жалоба Кабель не причем. У меня кабель 3 метра купленный в АШАНе за 40 рублей, там вообще экрана нету и все равно работает как часы. По моему у вас кто-то со стороны устройства данные забывает принимать. 1. Данные приходят без ошибки, режим bulk 2. Не совсем понял, о каком приложении идёт речь? Читал, что кабель может быть очень даже виноват... FT плохо работает в условии помех... Обмен идёт между ПК и устройством пакетами по 62 байта. Это просто тест пока... ПК шлёт 62 байта. Устройство принимает и шлёт обратно эти 62 байта. Пока ПК не получит байты, высланные устройством, новые байты он не пошлёт :) 1. Понятно. 2. Любое своё, вообще любое. Хоть калькулятор :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
stoker 0 6 февраля, 2009 Опубликовано 6 февраля, 2009 · Жалоба Читал, что кабель может быть очень даже виноват... FT плохо работает в условии помех... Обмен идёт между ПК и устройством пакетами по 62 байта. Это просто тест пока... ПК шлёт 62 байта. Устройство принимает и шлёт обратно эти 62 байта. Пока ПК не получит байты, высланные устройством, новые байты он не пошлёт :) 1. Понятно. 2. Любое своё, вообще любое. Хоть калькулятор :) В таком случае советую проверить в каком состоянии находятся WR, RD,TXE, RXF когда устройство "висит". Что управляет FT? ... 2. Первое вчто приходит на ум, использовать резидентный процесс, который проверяет подключено ли устройство и запускает калькулятор. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
koluna 0 6 февраля, 2009 Опубликовано 6 февраля, 2009 · Жалоба В таком случае советую проверить в каком состоянии находятся WR, RD,TXE, RXF когда устройство "висит". Что управляет FT? Обязательно проверю, что на этих линиях при сбое. Управляет ATmega88. 2. Первое вчто приходит на ум, использовать резидентный процесс, который проверяет подключено ли устройство и запускает калькулятор. Это само собой. Но хочется стандартными средствами Windows. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Седой 0 7 февраля, 2009 Опубликовано 7 февраля, 2009 · Жалоба Работает, работает, потом начинаются сбои при записи в порт со стороны ПК... возникает исключение ... Что за исключение? ( exeption) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
koluna 0 7 февраля, 2009 Опубликовано 7 февраля, 2009 · Жалоба Что за исключение? ( exeption) Ну про исключение, я зря сказал :) Я его сам генерирую в классе работы с COM-портом. Просто возникает ошибка при записи в порт... Программа останавливается. Порт заново не открывается, пока устройство не переткнёшь... Даже если софт перезагрузить полностью, то устройство работать не начнёт - порт не откроется, пока не переткнёшь устройство... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Седой 0 7 февраля, 2009 Опубликовано 7 февраля, 2009 · Жалоба Ну про исключение, я зря сказал :) Я его сам генерирую в классе работы с COM-портом. Просто возникает ошибка при записи в порт... Программа останавливается. Порт заново не открывается, пока устройство не переткнёшь... Даже если софт перезагрузить полностью, то устройство работать не начнёт - порт не откроется, пока не переткнёшь устройство... Симптомы понятны, нет нормального вызова CloseHandle. Работаете скорее всего с BC или Delphi. Ошибка в программе, а не в железе. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
bill_vs 0 7 февраля, 2009 Опубликовано 7 февраля, 2009 · Жалоба Симптомы понятны, нет нормального вызова CloseHandle. Работаете скорее всего с BC или Delphi. Ошибка в программе, а не в железе. Не могли бы Вы пояснить подробно? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Седой 0 7 февраля, 2009 Опубликовано 7 февраля, 2009 · Жалоба Не могли бы Вы пояснить подробно? Если не сильно вдаваться в детали вызов функции CloseHandle обрабатывается нормальным драйвером следующим образом 1. Драйвер должен отменить все операции ввода/вывода. 2. Освободить ресурсы (память и т.д.), захваченные при обработке CreateFile. 3. ... Если этого не сделать, последующий вызов CreateFile вернет ошибку. Поэтому и приходиться освобождать ресурсы жестким образом - "передергивать шнур USB". Почему BC и Delphi - в определенных ситуациях RTL вызвает TerminateThread, что приводит к тому, что ранее запрошенный потоком I/O запрос в драйвер продолжает работать, он не отменяется, как при нормальном завершении потока вызовом ExitThread - и опять приходится "передергивать шнур USB". Я сейчас точно не помню, где мне приходилось править RTL в D5, это было году в 2000, c тех пор ее и пользуюсь для написания dll для железа. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
koluna 0 7 февраля, 2009 Опубликовано 7 февраля, 2009 · Жалоба Симптомы понятны, нет нормального вызова CloseHandle. Работаете скорее всего с BC или Delphi. Ошибка в программе, а не в железе. В Delphi. У меня алгоритм следующий. 1. Подключаем устройство. 2. Запускаем приложение. 3. Открываем порт. 4. Передаём-принимаем в цикле до нажатия "Стоп". Причём передаём снова только после того как примем ответ. Т. е., Handshake такой получается :) 5. Закрываем порт. При ЗАПИСИ В ПОРТ спонтанно возникает ошибка и FT (или драйвера) перестаёт правильно работать. После переподключения устройства всё начинает работать нормально вновь... Какая может быть ошибка в программе? Если этого не сделать, последующий вызов CreateFile вернет ошибку. Поэтому и приходиться освобождать ресурсы жестким образом - "передергивать шнур USB". Но меня интересует другое! Почему при записи N в порт произошла ошибка, когда запись N - 1 в порт была сделана успешно (шнур мы не дёргали и программу не останавливали)? Как можно локализовать ошибку? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Седой 0 7 февраля, 2009 Опубликовано 7 февраля, 2009 · Жалоба При ЗАПИСИ В ПОРТ спонтанно возникает ошибка и FT (или драйвера) перестаёт правильно работать. После переподключения устройства всё начинает работать нормально вновь... Какая может быть ошибка в программе? Давайте все-таки код посмотрим, а то может быть глюк и в драйвере. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Alex11 3 7 февраля, 2009 Опубликовано 7 февраля, 2009 · Жалоба Я очень давно использовал FT245. Действительно, в условиях помех связь отъезжает с примерно указанными выше симптомами. Программа при этом была на MS VC. Из рекомендаций - посадите оплетку кабеля на землю устройства толстым проводом. Будет существенно лучше. В моем случае, т.к. помех было очень много и мощных окончательно помог только watchdog, от которого срабатывал полевик, отключающий подтяжку D+ к 3.3В. Устройство отваливалось, после чего его можно было переоткрыть и восстановить работоспособность не выдергивая кабель руками. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
koluna 0 8 февраля, 2009 Опубликовано 8 февраля, 2009 · Жалоба Я очень давно использовал FT245. Действительно, в условиях помех связь отъезжает с примерно указанными выше симптомами. Программа при этом была на MS VC. Из рекомендаций - посадите оплетку кабеля на землю устройства толстым проводом. Компьютер не заземлён. Это не ухудшит ситуацию? Сейчас, как я писал, оплётка у меня через RC-цепь к земле устройства подключена. Будет существенно лучше. В моем случае, т.к. помех было очень много и мощных окончательно помог только watchdog, от которого срабатывал полевик, отключающий подтяжку D+ к 3.3В. Устройство отваливалось, после чего его можно было переоткрыть и восстановить работоспособность не выдергивая кабель руками. А почему не RESET использовать? Ведь будет тоже самое или нет? Давайте все-таки код посмотрим, а то может быть глюк и в драйвере. USBThread.pas - модуль потока работы с FT245. COMPort.pas - модуль класса COM-порта. Soft.rar Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Седой 0 8 февраля, 2009 Опубликовано 8 февраля, 2009 · Жалоба USBThread.pas - модуль потока работы с FT245. COMPort.pas - модуль класса COM-порта. На первый взгляд все нормально. Давайте попробуем отловить ошибку, для этого переделайте немного вызов генераторов исключений Вместо XXX_ComPort_Error.Create("Сообщение об ошибке") Вызывать XXX_ComPort_Error.CreateFmt("Сообщение об ошибке %x",[GetLastError]) И сообщите значение GetLastError. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться