Ber*_*ers 5 .net serial-port communication low-latency
我一直在研究各种第三方库和 .Net 中低延迟串行通信的方法。我读了足够多的书，现在已经回到原点，由于各种相互冲突的观点，我所知道的和刚开始时一样少。
例如，框架中的功能被排除，因为一些令人信服的文章指出：“微软提供的解决方案在框架版本之间不稳定，并且缺乏功能。”
我发现文章抨击了许多旧的基于 COM 的库。我发现一些文章抨击了由于垃圾收集而导致整个 .Net 应用程序低延迟的想法。
我还读过一些文章，展示了如何为了低延迟通信的目的而调用 Windows API 功能是不可接受的。
这排除了我能想到的任何方法！
我真的很感谢那些经历过/经历过这种经历的人的一些话。理想情况下，我可以找到一个可靠的库/合作伙伴，而不必自己构建通信库。我有以下简单的目标：
非常感谢任何可能消除我的困惑的评论、想法、想法或文章链接！
我有一个 .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。
| 归档时间： |
|
| 查看次数： |
4427 次 |
| 最近记录： |