Jump to content

    
Sign in to follow this  
Веталь+5v

Отсоединение ft232bm во время работы программы

Recommended Posts

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Так получается проблема существует,а все молчат.

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

 

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

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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Подскажите плиз что за терминал такой ZOC.

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Проблема с передергиванием ФТДИшек существует. Давайте решать вместе.

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

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Обычно для опроса состояния порта используеться функция API (в паскалевской нотации)

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

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

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

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

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this