C++ 便携式硬实时C或C++；原始以太网协议库

我正在尝试创建一个爱好者便携式机器人库（Windows和Linux），它具有硬实时功能。它应该能够通过标准以太网连接到微控制器，将固件上载到该设备，通过现场总线连接到其他设备，并将固件上载到运行专用控制器的其他微控制器。如果需要硬实时，NIC将是RTnet支持的NIC。我希望典型的伺服速率至少为1千赫，但最好为2千赫或更高。它将运行一个完全定制的协议（不是TCP或IP上的UDP），这样开销最小，高速现场总线可以在不接收或发送帧的情况下饱和。然后，以太网帧中的有效负载可以被解释或发送到连接的设备

<> 1）我更喜欢C++中的协议，但是知道使用“新”关键字对实时编程是不起作用的。如果选择使用C++语言而不是将项目转换成C，我会遇到什么其他限制？人们推荐书籍或网站，教你如何利用C++，满足硬实时期限吗？我相信这是可能的，我希望能够继续使用C++，因为OroCoS项目使用实时C++。我宁愿不使用C代码

2） 为了保持便携式协议库的通用性，程序应该如何处理在非实时以太网适配器和RTnet以太网适配器上同时运行的协议

我有一个特别的问题，比如一个可以使用boost或Xenomai互斥的可移植互斥类

问题2的解决方案1可能如下：如果应用程序也使用Xenomai库编译，则可以使用布尔标志构建互斥体，以说明在运行时为锁定和解锁包装哪些方法（boost或Xenomai）。如果库是为Xenomai编译的，它可能包含boost互斥体和Xenomai互斥体。我不喜欢这个解决方案，因为如果这个项目是为Xenomai编译的，那么它将包含boost和Xenomai的互斥体的私有变量，这似乎是一种不太优雅的方式，而仅仅拥有所需的互斥体

问题2的解决方案2可以如下：将两个不同的派生类从纯虚拟接口方法的抽象类写入互斥体，一个用于boost，另一个用于Xenomai。我更喜欢这种方式，但是告诉运行时使用哪个类是很麻烦的。我可能需要一个boost和Xenomai互斥体池。这是大多数硬实时C++程序如何解决这个问题的吗？ 我提出的这个问题不仅仅是一个互斥，而是希望得到反馈，因为我不想从一开始就复制糟糕的设计模式

3） 我相信Beckoff的TwinCAT在Windows7下实时运行EtherCAT。在Windows7或更高版本下，支持至少一个具有硬实时功能的NIC的业余爱好者是否有任何东西是不会接触不到的？也许有一个开源的虚拟机监控程序项目

---

4） 另外，人们如何加载系统，使他们的四核计算机使用100%的每个核，这样他们就可以知道他们的系统是否在硬实时运行？

一个细节：如果你想要伺服系统的1khz刷新周期，为什么要使用硬实时？软实时（即，以root用户身份运行，但使用纯用户空间，但将调度程序策略设置为该进程的FIFO级别，将所有内容锁定到内存中，禁用swapspace…），在整个运行年内，您将轻松从中获得1khz的信息，而不会丢失任何消息

在这一点上，只需为以太网协议使用一个原始套接字，就可以了

---

至于与此无关的问题，以太网CD/CA目前正在硬件中实现。忽略这些问题。

你应该把这些问题分成几个小而简洁的问题。这太难理解了。网络堆栈的哪一层指定冲突检测和避免？我很难理解一个使用普通随机等待CD/CA的系统是如何做出硬实时保证的。要做任何“硬实时”的事情，你需要“硬实时”操作系统。Windows和Linux都不属于这一类。只有当新的以太网设备上线并使系统在一段时间内不实时时，才会发生冲突。选择的协议避免了任何其他冲突。不需要一个以上的以太网设备，因为我不希望大多数爱好者需要连接一个以上的以太网微控制器来提供高速现场总线。在一个以太网端口上需要多个高速现场总线的复杂机器人需要接受我的设计中的一个非实时故障，但我看不到一个简单的解决方法。@dcmkee:CD/CA随着交换机和全双工链路的出现而几乎不复存在。只有在使用非交换集线器时才会发生冲突。相反，您需要担心交换机中的队列深度，但这是一个更容易处理的问题。这有助于开始软实时。在运行后台进程时，它通常在小于100 uS的延迟下工作。硬实时技术现在正在发挥作用，Xenomai和RTnet似乎在没有对内核设置进行太多调整的情况下，有大约50个uS的上限。