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

Приветствую вас, коллеги!
Хочу с вами посоветоваться, ибо мне кажется, что я делаю это не совсем правильно, либо что-то не учёл...
Делаю обмен данными с устройством через COM-порт (RS-232) по алгоритму: послал команду в порт (через .Write(...)), поставил задержку (Threading.Sleep(200)), читаю ответ (через .Read(...)). И вот тут меня смущает эта самая задержка. Если ответные пакеты приходят большие (ну например более 60 байтов), то что бы вычитать весь буфер, этой задержки как буд-то не хватает, пакет получаю не весь. Если увеличиваю задержку, то буфер весь вычитывается, однако, во-первых, буфера могут быть разной длины, и для каждого так подбирать задержки - не реально, во-вторых, если с устройством есть возможность обмениваться на разных скоростях (бод), это вообще дур-дом и всякая актуальность, например, выбора более высокой скорости обмена теряется, т.к. задержки будут одинаковыми, если их так железно задавать... В-третьих, когда такая функция обмена, с железно заданным Sleep'ом (подобранным на вскидку, чтоб не потерять большие пакеты), в цикле, например, ведёт обмен, то для более мелких пакетов, такая задержка, опять же, становится не актуальной, т.к. увеличивается драгоценное время простоя, и обмен происходит дольше, чем мог бы быть... Вот по этому я и задаюсь вопросом: как в таком случае правильно следует поступать? Не ужели чем длиннее ответный пакет, тем дольше его нужно ждать, чтоб он вычитался? Как избежать таких диких задержек? У кого был подобный опыт с обменом по СОМ-порту с устройствами, подскажите, пожалуйста, или поделитесь идеями, кто хотя бы понял суть вопроса.

P.S. слышал что-то про подход асинхронного чтения данных из порта, но пока не понял что это и с чем это едят, и мой ли это вообще случай. Если да, то расскажите про такой подход, кто в курсе вообще. Только по понятнее пожалуйста, с примерами, если можно, а то про асинхронные приёмы работы пока вообще не в теме... Особо не доводилось использовать.

0

Сообщение от Cha1000000 каким образом передавать управление основному потоку из потока чтения

Для передачи данных в основной поток используйте BeginInvoke.

0

Сообщение от Storm23 используйте BeginInvoke

За всё время, что пишу на C# мне пока почти не приходилось использовать асинхронные методы, за исключением тасков с async и await, по этому с применением Invoke (во всех его вариациях) пока не сталкивался и не знаком. От слова "совсем". Покурил в сети описания этих методов, но пока как-то не совсем догоняю, как в данном случае (на примере моего кода выше) эти инвоки применять ... Буду признателен, если сможете наглядно это показать.

Я вот тут так поразмыслил, а что, если преобразовать метод static void com_OnReceiving(object sender, RTSerialCom.DataStreamEventArgs e) в асинхроныый, добавив ему ключевое слово async, а потом в функции SendCommand, после Transmit, вызывать его через await? В таком случае, по идее, можно будет вообще избавиться от Thread.Sleep между посылкой и ожиданием получения ответа... Т.к. await должен сам по себе заставить вызывающий поток подождать, пока отработает вызываемый метод, а за тем уже продолжить дальше свои действия. Что думаете на этот счёт?

Добавлено через 15 часов 34 минуты
Если я правильно разобрался в применении BeginInvoke/EndInvoke, то мой код должен измениться так (наверное):

Судя по отладчику, событие отрабатывает до конца и после Transmit, а потом выполнение идёт дальше по коду функции SendCommand, но на сколько всё верно будет работать, проверить смогу только в понедельник. Ибо дома нет самого устройства для обмена. Надеюсь я всё правильно понял...

0

Storm23, нет, всё же что-то я таки не так сделал, или не дописал... Сдаётся мне, что в параметры BeginInvoke нужно что-то другое а не null передать, как минимум первый параметр типа object мне кажется нужно передать, но я не знаю как правильно это сделать, ибо this не передаётся т.к. эти функции у меня находятся в основном статическом классе Program.cs
Или же я в принципе не правильно понял подход?

0

В общем вся затея псу под хвост. Видимо моя задумка утопична.
Как ни пробовал добиться передать уведомление основному потоку, что событие случилось и обработка в нём отработала, всё тщетно. То ли я не правильно эти механизмы синхронизации применяю, то ли в принципе подход не верный, либо действительно, от слипов между посылкой пакета и перехватом ответа не обойтись (чего я собственно и пытаюсь отчаянно добиться).

0

Сообщение от Cha1000000 Как ни пробовал добиться передать уведомление основному потоку

Вы на форуме-то пробовали искать? Тема избитая.

0

Сообщение от Rius Вы на форуме-то пробовали искать?

Ну вот пока то, что мне подошло бы не нашёл.

0

Процент загрузки e.ProgressPercentage строка 109
Я такой применяю способ. Но он не единственный существующий и не единственно верный.

0

Rius, Чуть позже ознакомлюсь с этой ссылкой. Спасибо.
А пока поделюсь своими наблюдениями в этой проблеме... Такое чувство, что решение у меня под носом, но я чего-то не доделываю... Или недопонимаю...
Я покажу что имею. И объясню где что пытаюсь получить, но не получается))
Есть класс с реализацией методов по обмену данных СОМ-порта. В нём есть событие, возникающее в момент получения данных в порт и метод этого события.
classA.cs
В основном же своём классе, Program.cs, где у меня находится моя глобально использующаяся в проекте функция обмена,
я в этой функции подписываюсь на это событие, а в методе подписанном на него, делаю обработку полученных данных.

Program.cs
Далее в этом же классе в самой функции обмена, после отправки пакета, это событие срабатывает, но получается так, что оно срабатывает в фоне, а код функции обмена при этом независимо идёт дальше. В результате бывает так, что он отрабатывает быстрее, чем успевает дёрнуться в флаг внутри обработчика, сообщающий об успешно обработанном ответе. Тем более, что возникновение этого события происходит с разной задержкой, в зависимости от размера вычитываемого пакета. По этому раньше мне приходилось для ответных пакетов разного размера, подбирать свои слипы между посылкой и получением данных. От этого я хочу уйти! По этому, если бы можно было бы как-то приостанавливать основной поток ровно на то время, пока ответ придёт в порт и событие сработает, и соответственно обработчик тоже разберёт полученное... Вот этого я добиваюсь...

0

Сообщение от Cha1000000 он отрабатывает быстрее, чем успевает дёрнуться в флаг внутри обработчика, сообщающий об успешно обработанном ответе

А зачем вам этот флаг необходим?

0

Сообщение от Rius А зачем вам этот флаг необходим?

Ну, чтоб как-то указать, что буфер получен, и успешно обработан. Типа признак успешного обмена. В дальнейшем я по этому флагу проверяю выполнять следующие команды или нет. Т.е. например если есть несколько команд, посылаемых по очереди, одна за другой, то если, допустим, уже первая команда не отработала (получила битый ответ, или неправильная контрольная сумма ответа, или вообще ответ не пришёл), то я устанавливаю флаг признака ошибки в true, проверяю его, после каждого посыла команды, и если он true, значит делаю return и не посылаю следующие команды... Ну и для других подобных проверок...

Добавлено через 16 минут
Кстати, var task = Task.Factory.StartNew(...); я тоже пробовал. Пробовал даже через task.Wait(); чтоб дождаться, как я надеялся, срабатывания события и выполнения обработчика... Но почему-то так всё равно не сработало...

0

Cha1000000,
одно дело передать в поток UI что-то принятое;
а другое - удостовериться в принятии ответа и послать новый запрос.
Эти вещи не обязаны выполняться в одном месте.
Оставьте поток UI в покое и в качестве флага применяйте что-то типа AutoResetEvent. Его и из потока можно установить, и ожидать установки можно.

0

Сообщение от Rius в качестве флага применяйте что-то типа AutoResetEvent

ООО да!!! Это сработало! Большое спасибо! Теперь обмен просто летает (ну по крайней мере по сравнению с предыдущими версиями)! Нет не слипов между отправкой и приёмом, и тайм-аутов тоже нет.

Storm23, Вам ещё раз отдельное спасибо за предложенные примеры рабочих проектов!

0