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

Question

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

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

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

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

Answer 4

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

Answer 5

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