[Веталь+5v 0]

Привет ВСЕМ! Есть проблема с преобразователем usb-com. Проблема возникает когда программа с девайсом работает как с ком портом ,а девайс выдергивают из компьютера.Тогда комп начинает тормозить,и может даже зависнуть если не убить процесс программы.Эта проблема проявляется не только с чипом ft232bm ,но и с pl2303hx.А вот с cp2102 таких проблем нет.Подскажите плиз как вылечить эту проблему.Заранее благодарен.

[IV_K 0]

драйвер похоже кривой. при пользовании стандартного виндового usbser.sys, я проверял на AT91SAM7S, такие же проблемы.

[Веталь+5v 0]

Так получается проблема существует,а все молчат.Напрашивается вывод - зачем такие девайсы в виде виртуальных портов,которые вешают машину при удалении.Получается,что человек который пишет программу работающую с ком портом,может контролировать наличие порта лишь на стадии открытия.А в процессе работы программы ,когда порт открыт закрыть отвалившийся порт уже поздно.Может я чего-то не понимаю,может есть какой нибудь выход из сложившейся ситуации.Заранее благодарю всех откликнувшихся.

[Aleks17 0]

А не пробовали при работе с портом timeout-ы задавать? Сдаётся мне тут проблема не драйверов а ПО верхнего уровня.

[Веталь+5v 0]

Проблема ведь не с тайм-аутами , а с тем что порт открыт программой, она с ним работает,а тут его резко вырубают.С таймингами я игрался- никакого эффекта.Тем более я использовал и свой софт и других производотелей.Результат одинаковый.А вот cp2102 прекрасно работает.То есть при выдергивании девайса машина вообше не тормозит.

[zltigo 0]

Так получается проблема существует,а все молчат.

Личный опыт - проблемы c зависанием в связке с терминалом ZOC нет.

 

Выход из положения с Ваших слов решается прибиванием _приложения_ (не названного) работающего с портом. А виноватым Вы называете драйвер.

Не слишком убедительно. Для локализации:

1. Пробуете протестировать с вышеупомянутым терминалом.

2. Ставите оба ( и COM порта тоже) свежих драйвера от производителя.

[Веталь+5v 0]

Приходиться прибивать приложение,но реакция системы на три пальца очень медленная(порядка 2-5 минут).По поводу драйверов - я пробовал и новые и старые - результат нулевой. Подскажите плиз что за терминал такой ZOC.

[zltigo 0]

Подскажите плиз что за терминал такой ZOC.

Как только наберете в google поиск ZOC, сразу найдете в первой срочке и дюжине последующих...

Вообще - самая лучшая и многофунциональная терминальная программа, практически на все случаи

жизни. Использую с незапамятных времен.

[khach 33]

Проблема с передергиванием ФТДИшек существует. Давайте решать вместе.

Т.к зависает приложение, то позволю спросить- как у вас происходит общение с ком-портом:

пуллинг или евенты? Исполь зуеться ли отдельный поток для приема из порта? Вываливаетесь ли по таймауту или остаетесь в вечном цикле? Чему равен дескриптор (хендл) порта после "вываливания"?

Мы используем CPort3 by Dejan Crnila. Валиться одинаково хорошо как с FTDI, так и с Prolific.

Интересно вообще, как с точки зрения программы корректно обрабатывать состояние "потери" порта?

С терминалами проще- они обычно непрерывно "пулят" состояние порта, забирая все байты, что окажутся во входном буффере. Попутно обрабатывая все ошибки. Если же обмен идет по событиям ( например прием пакета с ожиданиме символа 00 или CR как признака конца пакета) то возврата по таймауту непроисходит. Похоже, что хендл после отваливания порта становиться равен -1 и каллбек евента никогда невызываеться.

[Веталь+5v 0]

Я пользуюсь компонентой ASYNC TMS32 .И на сколько я понимаю ,то она работает через события.Пробовал ZOC - он при выдёргивании не зависает,но постоянно опрашивает порт.А вот CP2102 работает нормально-при отключении программа даже не видит ,что порта уже нет в системе.А по поводу фтдишек и пл то у них чего то там с дровами и мне кажется,что надо обрабатывать исключение(отказано в доступе) и тогда будет всё ок,но это теория и надо попробовать на практике.

[Harbour 0]

Проблема с передергиванием ФТДИшек существует. Давайте решать вместе.

Т.к зависает приложение, то позволю спросить- как у вас происходит общение с ком-портом:

пуллинг или евенты? Исполь зуеться ли отдельный поток для приема из порта? Вываливаетесь ли по таймауту или остаетесь в вечном цикле? Чему равен дескриптор (хендл) порта после "вываливания"?

Мы используем CPort3 by Dejan Crnila. Валиться одинаково хорошо как с FTDI, так и с Prolific.

Интересно вообще, как с точки зрения программы корректно обрабатывать состояние "потери" порта?

С терминалами проще- они обычно непрерывно "пулят" состояние порта, забирая все байты, что окажутся во входном буффере. Попутно обрабатывая все ошибки. Если же обмен идет по событиям ( например прием пакета с ожиданиме символа 00 или CR как признака конца пакета) то возврата по таймауту непроисходит. Похоже, что хендл после отваливания порта становиться равен -1 и каллбек евента никогда невызываеться.

Проблемы у Вас в криво написанной библиотеке для работы с комами. Драйвера и ОС тут не причем. Если либу не можете написать сами - юзайте for ex. от мохи или commoncpp - в частности перед aRead без суеты вызываем isPending(pendingError) и будет Вам счастье ...

[khach 33]

Обычно для опроса состояния порта используеться функция API (в паскалевской нотации)

function ClearCommError(hFile: THandle; var lpErrors: DWORD; lpStat: PComStat): BOOL; stdcall;

Можно расшифровать это

isPending(pendingError)

? Какие функции АПИ оно вызывает? И где ее вызывать, если я ожидаю события по ивенту в течении десятков секунд и за это время порт может "отвалиться"?

Если алгоритм поведения в ожидании отвала будет описан "лопатологично" то внести соответствующие изменения в пакет привычных коммуникационных компонет несоставит труда.

[Веталь+5v 0]

У меня получилось победить фтди. Я при операциях с портом начал обрабатывать исключения ,происходящие при отключении девайса и проблема решилась .

[Harbour 0]

Обычно для опроса состояния порта используеться функция API (в паскалевской нотации)

function ClearCommError(hFile: THandle; var lpErrors: DWORD; lpStat: PComStat): BOOL; stdcall;

Можно расшифровать это

isPending(pendingError)

? Какие функции АПИ оно вызывает? И где ее вызывать, если я ожидаю события по ивенту в течении десятков секунд и за это время порт может "отвалиться"?

Если алгоритм поведения в ожидании отвала будет описан "лопатологично" то внести соответствующие изменения в пакет привычных коммуникационных компонет несоставит труда.

Я вообще делал потоками - стандартные producer/consumer thread'ы, так удобнее и быстрее произвольный траффик обрабатывать. В случае однопоточного варианта тоже нет проблем, так как вторым параметром идет max время ожидания события.