Компонент SerialPort завешивает форму

Доброй ночи!
Есть компонент SerialPort. На него пересылаю данные из внешнего устройства. Если в момент пересылки данных устройством попытаться закрыть порт - форма фризится намертво и с концами. Причем в Try - Catch ничего не приходит... Собственно в такой отлов ошибок у меня заключены все операции с компонентом порта да бы избежать "исключений".
Каким образом закрыть порт так, чтобы в любом случае оно все закрыло и нигде не зависло?
Спасибо.

0

В данной ситуации при зависании в системе возникает ошибка которая пишется в протокол Windows (независимо от TryCatch программы). Хотелось бы узнать что там написанно?

0

Вот:
https://msdn.microsoft.com/ru-... .110).aspx

Может помажет.

0

Splinter_Cell, что это за протокол такой и где это все можно посмотреть?

Добавлено через 3 минуты
17Vasya17, был на этой странице триста раз... Там написано о методе .Close(). Им то я как раз и закрываю порт.
Пишут что перед использованием .Open лучше подождать пока порт закроется... Но меня то это не касается... Пишут про исключения, но, как я и написал выше, туда ничего не приходит...
Больше там ничего не написано.

0

Подробнее здесь: http://www.oszone.net/10680

0

Stass48, Не закрывать порт, пока буфер передачи не будет пуст.

0

Splinter_Cell, Может я чего-то не досмотрел, конечно, но все же в журнале пусто. Нет никаких событий на время зависания формы...
jkrnd, а подробнее?
Я вот судя по Вашему совету сделал так (по теме строки 2 и 3):
Но все равно если дрючить его кнопками "Открыть" и "Закрыть", то где-то на десятый раз повисло
Если это не то, что Вы имели ввиду, то напишите пожалуйста подробнее, если можно с кодом...

Вообще странно, что в Майкрософт хреново сделали эту процедуру закрытия порта. Погуглив по Интернету – проблема далеко не единичная. Но решения я так и не нашел...

Добавлено через 5 минут
Добавлю заранее, да бы исключить дальнейшее недопонимания:
Кнопки открытия и закрытия порта у меня реализованы с защитой от повторных вхождений. То есть, нельзя нажать на закрытие порта пока сам порт не будет открыт и наоборот. Так же, нельзя открыть еще раз порт пока он открывается и точно так же с закрытием.

Какие еще у кого будут мысли?

1

Stass48, На работу с Com-портом с помощью элемента управления угробил кучу времени и отказался от его использования. Его поведение в некоторых случаях непонятно, проще и надёжнее использовать класс SerialPort.
Добавлено через 1 минуту
это нарыто в сети (не моё творчество). У меня проблем подобных Вашей не было.

1

источник информации

Вложения

Access-Serial-Ports.pdf (7.00 Мб, 27 просмотров)

1

jkrnd, проверил все намного раньше, но написать могу только сейчас. В общем, дела такие.
Класс работает еще хуже, чем порт, видимо, компонент продуман получше класса (что и логично, так как используя класс, тебе дают больше возможности писать код самому). В моем случае проблема лежит скорее всего гораздо глубже. В своем устройстве, которое "общается" с компьютером, в качестве интерфейса-пеобразователя TTL/UART->USB я использую микросхему от Prolific. Точнее, китайский переходник на базе этой микросхемы. Сама же микросхема – китайская подделка и не работает с последними версиями официальных драйверов (так как в них уже ввели проверку подлинности чипа и этот чип ее, естественно, не проходит). Работает оно только когда ставишь драйвера постарее (где данной проверки еще нет). Но это драйвера еще времен Windows 7, как Вы понимаете с тех времен уже давно могли устранить все баги. К слову, даже когда я тупо выдергиваю USB, в диспетчере устройств ничего не пропадает, ком-порт так там и остается. Всунул еще раз и высунул – оп, пропал. Когда порт остается в системе при вытянутом устройстве, программа спокойно может его открывать и, по-моему, даже закрывать... Короче полный бред.
Я вижу только два пути решения этой проблемы:
1) Очевидный. Идти в магазин и заказывать оригинальные чипы вплоть до FTDI, цены на которые, увы, не радуют и паять на базе них нормальный преобразователь.
2) А что если этот порт не закрывать вообще? Суть моей программы заключается просто в управлении компьютером с моего внешнего устройства и ведении логов всех действий. То есть эта программа будет помещена в автозагрузку и стартовать при запуске системы. Закрывать ее никто и никогда не будет (по идее). Закрываться она будет только при завершении работы винды. Но разве винда такая тупая что не закроет все порты сама перед выключением?)

Короче, ребята, мне важно ваше, более опытное мнение по этому поводу. Активничайте, не стесняйтесь

Добавлено через 54 минуты

Сообщение от Splinter_Cell В данной ситуации при зависании в системе возникает ошибка которая пишется в протокол Windows

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

1

Сообщение от Stass48 А что если этот порт не закрывать вообще?

Проблема есть и она всплывёт, когда это меньше всего будет нужно.

Помимо Prolific, у FTDI большой выбор чипов. И есть ещё Silicon Labs CP210x.

Можно взять чип от ST со встроенным USB, тогда никакой USB-UART мост вообще не понадобится.

2

Да уже понял что FTDI это самый "жирный" вариант хотя и недешевый. Но что поделать?
Да, у них большой выбор чипов и как я понял цена в основном зависит от скорости. Мне же нужно просто принять на комп несколько команд Uart (с ADC и прерывания по кнопке контроллера Atmega8A), то есть скорость тут как я думаю, мне не сильно важна. Поглядываю в строну FT232RL, но может быть есть что подешевле из этой линейки, которое мне подойдет?
Если нет, возьму преобразователь на этой микре, благо на Космодроме пишут что у них преобразователи на оригинальных чипах...
По поводу ST, я никогда не делал ничего на других чипах, кроме AVR, под них есть Bascom AVR на котором можно состряпать прошивочку. Уж сильно люблю VB
Хотя данный язык имеет ряд недостатков (попробовать только дизассемблировать этот код, много лишнего ).

1

Итак, проблема решена!
Купил у себя рядышком в городе FDTI FT232RL, спаял на коленке преобразователь. Работает и ничего нигде не виснет! Хоть двадцать раз тыкай и во время пересылки данных! Судя по слухам в Интернете, с FTDI тоже есть проблемы в плане подделок. Но, судя по тому что у меня она завелась с официальными драйверами с сайта (драйвера если видят подделку – выводят ее со строя), то я купил именно оригиналки!
Вывод: Китайцы – пи*орасы!

1

UPDATE !!!

Как бы не так! Преобразователь здесь не причем, хотя все равно настоятельно рекомендую использовать только оригинальные чипы, а не китайский ширпотреб. Да, дорого, но это того стоит!

Дело в БАГЕ класса SerialPort! Баг этот известен уже очень давно, с годов так 2007-х. Microsoft признала баг, но устранять его почему-то не захотела. Видимо, потому, что его можно обойти!

Мне удалось найти два пути решения проблемы. Но о них позже. Сначала, давайте разберемся, почему форма зависает.

При выполнении ожидает завершения операций чтения из порта.
То есть, он ждет окончания операции ReadLine()

Самое первое, что приходит в голову человеку при использовании класса или компонента (не важно) SerialPort, так это просто взять событие DataReceived и поместить в него инвок с выводом куда-то, например так:

Инвок ждет пока запишутся данные в текстбокс (то есть, myPort.ReadLine() не закончит свое выполнение до тех пор, пока текст не запишется в TextBox).

Если мы в это время вызовем myPort.Close(), то мы завесим поток формы, а так как ReadLine() тоже будет ждать пока данные не запишутся в текстбокс, то вот он – ДЕДЛОК!

Теперь о решениях.
1) Можно использовать вместо метода Invoke, метод BeginInvoke. В этом случае ReadLine() не будет дожидаться реакции от основного потока и спокойно сможет завершиться даже если основной поток формы будет приостановлен. Следовательно, зависания не произойдет.
Однако, любые попытки работы ReadLine() асинхронно, работают как-то нестабильно. Где-то раз на 100 или даже 1000 чтений, читает либо две строки в одной, либо только часть строки, в общем, как я понял, лучше все таки синхронно (пробовал Producer-Consumer в реализации через BlockingCollection). Поэтому, метод 2.

2) Вызвать метод MyPort.Close() не из основного потока формы, а из постороннего. В таком случае метод Close() не будет блокировать поток формы и дедлока не произойдет.

Вопрос лишь в том, как написать некоторую надстройку типа:

Которую можно было бы выполнить синхронно как в коде, так и по закрытию формы.

Уже неделю бьюсь, не могу осилить! Всё либо костыли, либо криво. В общем, мне не понравилось.
Может кто другой осилит?

0

Stass48, просто не используйте ни ReadLine, ни DataReceived.
Чтение с последовательного порта без использования Sleep

1

Rius, может быть в каких-то серьезных задачах Ваше решение и имеет право на существование, но, конкретно в моем случае, считаю, что это уж слишком заморочно и неоправданно сложно. Единственное, в чем я сомневаюсь (хотя наверное я ошибаюсь), так как событие DataReceived срабатывает по нескольку раз за строку, а ReadLine() стопорит выполнение до момента получение символа NewLine, то у нас может начать копиться очередь из событий DataReceived. Одновременно этой моей паранойе успокаивает мысль, что в момент, когда строка все таки получена, а новая передаваться еще не начала, то программа бегом успевает прогнать всю очередь. Так что скорее всего, она не должна накапливаться постоянно.
В крайнем случае, у ReadLine() есть возможность таймаута. Это чтобы уж совсем наверняка.

Вместо Ваших методов, предлагаю свой вариант решения. Прикрепляю проект (кому надо, тот по аналогии сможет использовать этот код или написать класс). Дрюкал порт как мог кнопками открыть-закрыть одновременно передавая данные с FT232RL и в результате смог обнаружить только два вида порчи данных:
1) Когда приходит только концовка. Что не удивительно, ведь внешнее устройство уже начало передачу данных, а мы только открыли порт и начали принимать данные. Понятное дело, что мы сможем принять только то, что успеем. Пример:
Передавали "Sample", получили "mple" или подобное.

2) Очень и очень редко, но получалось так, что соединяло часть первой строки с полностью второй строкой. Пример:
"SampSample". Это я объяснить не смог. Но вроде бы после того как я ввел принудительную очистку буфера при открытии порта, этот глюк прекратился.

Напомню, что все, что написано выше, происходит только при открытии и закрытии порта и одновременно этому – передачи данных. Поэтому:
1) Глюки вполне оправданы
2) Последствия глюков легко можно обрабатывать в функции, которая будет парсить принятые данные (такая функция будет присутствовать в 99% проектов, разве что кто-то будет писать свое приложение-терминал).

После того как порт открыт, никаких глюков и артефактов при приеме данных замечено не было. Хотя от них никто не застрахован и все равно скорее всего вы будете на это рассчитывать в своем приложении, корректно обрабатывая подобные случаи в своем коде.

По желанию можно ввести таймаут на получение строки (писал выше), так как микроконтроллер – не человек, он либо передает строку довольно быстро, либо значит что-то уже пошло не так и данные не принялись или не дошли.

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

P. S.: Прошу модераторов отметить этот пост как "лучший ответ", так как он является одним из вариантов решения данной проблемы.

Вложения

SerialPort_Probe.zip (62.9 Кб, 27 просмотров)

1

Сообщение от Stass48 1) Глюки вполне оправданы 2) Последствия глюков легко можно

Короче, здесь костыли, так как другие проблемы в корне и не решены. А может и не встречены пока.
Через ваш вариант я проходил годы назад, в ходе отладки разнообразных способов.
Но, как говорится, моё дело предложить, ваше - отказаться.

1

Сообщение от Rius Короче, здесь костыли, так как исходная проблема в корне и не решена. Через ваш вариант я проходил годы назад, в ходе отладки разнообразных способов. Но, как говорится, моё дело предложить, ваше - отказаться.

Говорю сразу, ссориться и спорить не буду!

Но... Читайте внимательно.
Первое – вообще не глюк! Как можно претендовать на данные, которые были переданы раньше, чем был открыт порт?
Второе – сейчас существует скорее только у меня в голове, так как я сколько не пробовал, то не смог воспроизвести данный глюк повторно (после корректировки кода).

Костыли будут в любом случае, так как исходную проблему "в корне", как Вы говорите, смогут решить только авторы класса. Наша задача – обойти проблему. Но сделать это нужно грамотно и как можно менее костыльно (полностью некостыльно и в то же время просто – не получится). У Вас ведь тоже те же костыли, согласитесь и это нормально, потому что выбора нам с Вами разработчики не оставили и нашего мнения не спросили

Не забывайте, что речь идет о методе, который позволяет корректно принять ТОЛЬКО ЦЕЛУЮ СТРОКУ, а не каждый символ или бит по отдельности (как например, когда мы вводим данные с клавиатуры в терминале вручную или передаем файл по ком-порту)! Может быть, Ваши методы имеют возможность работать идеально во всех условиях, но какой смысл усложнять код ради получение возможности, которая никогда не будет использоваться (по крайней мере у меня)?
Данные передаются и принимаются исправно, проверено! Все работает очень стабильно...

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

Огромное спасибо за Ваши труды, но такое усложнение, конкретно в моем случае будет просто не рациональным, неоправданно сложным, если быть точнее.

Подведем итоги:
В данной теме была представлена проблема случайного зависания приложения при выполнении метода SerialPort.Close(). Проблема была детально изучена, приведены причины и объяснения почему она возникает. Так же, приведены варианты решения данной проблемы, а так же, конкретные примеры готовой реализации. Каждое решение по-своему хорошо и не претендует на истинность, предоставляется "как есть".

0