Последовательная связь с низкой задержкой в ​​.Net

Question

Я изучал различные сторонние библиотеки и подходы к последовательным коммуникациям с низкой задержкой в ​​.Net. Я прочитал достаточно, что теперь я прошел полный круг и знаю так же мало, как я, когда начал, из-за множества противоречивых мнений.

Например, функциональность в Framework была исключена из-за некоторых убедительных статей, в которых говорилось: «Решение, предоставленное Microsoft, не было стабильным во всех версиях Framework и отсутствует функциональность».

Я нашел статьи, в которых разбиты многие старые библиотеки на основе COM. Я нашел статьи, выдвигающие идею о малой задержке .Net-приложения в целом из-за сборки мусора.

Я также читал статьи, демонстрирующие, как недопустимы функции P / Invoking Windows API для связи с низкой задержкой.

ЭТО ПРАВИЛА ТОЛЬКО О ЛЮБОМ ПОДХОДЕ, КОТОРЫЙ Я МОГУ ДУМАТЬ!

Я был бы очень признателен за некоторые слова из тех, кто был там / сделал этот опыт. В идеале я мог бы найти надежную библиотеку / партнера, и мне не пришлось бы создавать библиотеку коммуникаций самостоятельно. У меня есть следующие простые цели:

• Серийный номер с низкой задержкой общение в C # / VB.Net
• 32/64 бит
• Хорошо задокументировано (если решение стороннее)
• Относительно незатронутый (коммуникация и задержка) сборкой мусора.
• Гибкость (я понятия не имею, с чем мне придется взаимодействовать в будущем!) Единственное требование, которое у меня есть, это то, что мне нужно иметь возможность взаимодействовать со многими различными промышленными устройствами, такими как линейные приводы на основе RS485, датчики на основе последовательных / микроконтроллеров и устройства ModBus (также RS485).

Будем очень благодарны за любые комментарии, идеи, мысли или ссылки на статьи, которые могут сгладить мое замешательство!

Answer 1

Задержка не является проблемой на современных машинах. Последовательные порты работают медленно, а 19,2 килобода - это арахис, класс .NET SerialPort прекрасно с ними справляется. Событие DataReceived доставляется асинхронно потоком пула потоков, который выполняет ожидание блокировки с WaitCommEvent (), вы не можете идти быстрее, чем это.

Answer 2

У меня есть .NET-приложение, которое работает на сервере с 16 COM-портами, около 11 из которых в настоящее время подключены к различным устройствам, некоторые RS485, многие RS-232. (Диаграмма здесь: http://blog.abodit.com/2010/03/home-automation-block-diagram/). Большинство из этих устройств работают только на 9600 бод, и у большинства нет очень жестких требований к синхронизации. У меня есть поток на устройство, обрабатывающий получение, и хотя он работает с обычным приоритетом потока, все остальные потоки без связи работают с более низким приоритетом (как вы должны делать для большинства фоновых задач в любом случае). У меня не было проблем с этой настройкой. И, кстати, он также воспроизводит музыку на трех звуковых картах одновременно, используя потоки с высоким приоритетом из управляемого кода и 1-секундных буферов DSound, все без сбоев.

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

GC не такой злой, как это было задумано. В правильной системе приоритетов с многопоточностью с хорошим управлением размерами и временем жизни объектов и достаточной буферизацией (UARTS / Звуковые буферы и т. Д.) Она может работать очень хорошо. Microsoft также постоянно совершенствует его, и .NET Framework 4 теперь обеспечивает фоновую сборку мусора. Эта функция заменяет одновременную сборку мусора в предыдущих версиях и обеспечивает более высокую производительность. См. MSDN.

Answer 3

.NET, как правило, плохой выбор для типа приложения, которое вы описываете. Такого рода вещи потребуют нативный код и язык, такой как C ++, по крайней мере для части, которая требует малой задержки.

Answer 4

Класс последовательного порта .Net потребляет слишком много ресурсов ЦП при отправке небольших пакетов на высоких частотах. Это также, кажется, пропускает некоторые события. Так как мне нужно было иметь возможность отправлять и получать 16-байтовые пакеты в 1000 раз быстрее, я собрал воедино что-то на основе Windows API и теперь могу легко запускать 1000 маленьких пакетов в секунду, потребляя при этом почти нет ЦП. Я перепробовал почти все библиотеки, доступные для библиотеки, и для этой простой задачи все они потерпели неудачу из-за чрезмерной загрузки ЦП или пропущенных событий.

Answer 5

Лично мне нравится мой BBUSB интерфейс. При переключении в режим бит-бэнга он позволяет напрямую включать / выключать управление 8 контактами, которые можно установить для ввода или вывода.

"Но мне нужен последовательный порт." Ты говоришь. Это вполне возможно. Просто подключите контакты к 9-контактному штыревому последовательному порту, и все готово.