Portable hard real-time C or C++ raw Ethernet protocol library

Question

I am trying to create a hobbyist portable robotics library (Windows and Linux) that has hard real-time capabilities. It should be able to connect over standard Ethernet to a microcontroller, upload firmware to that device, connect to other devices over a fieldbus, and upload firmware to those other microcontrollers that run dedicated controllers. NICs will be those supported by RTnet if hard real-time is desired. I will want typical servo rates of at least 1 kHz but preferrably 2 kHz or higher. It will be running a completely custom protocol (not TCP or UDP over IP) so that the overhead is minimal and the high-speed fieldbus can be saturated while not receiving or transmitting frames. The payload in the Ethernet frame can then be interpreted or sent to connected devices.

1) I prefer to keep the protocol in C++ but know that using the "new" keyword won't work for real-time programming. What other limitations will I run into if I choose to use the C++ language rather than converting the project into C? Do people recommend books or websites that teach how to utilize C++ and meet hard real-time deadlines? I beleive it's possible and I hope to be able to go ahead with using C++ because the Orocos project uses real-time C++. I would prefer not to use C code.

2) In order to keep the portable protocol library general purpose how should the program handle the protocol running simultaneously on both a non-realtime Ethernet adapter and say an RTnet Ethernet adapter?

A specific question that I have would be a question about say a portable Mutex class that can use either a boost or a Xenomai mutex.

Solution 1 to problem 2 could be the following: If the application has also been compiled with the Xenomai libraries then a mutex could be constructed with a boolean flag to say which methods (either boost or Xenomai) would be wrapped at runtime for lock and unlock. It could contain the boost mutex and a Xenomai mutex if the library was compiled for Xenomai. I don't like this solution because if the project is compiled for Xenomai then it will contain private variables of a mutex for boost and Xenomai, which seems like a less elegant way then having just the mutex that one needs.

Solution 2 to problem 2 could be the following: Write 2 different derived classes from an abstract class of pure virtual interface methods to the mutex, one for boost and one for Xenomai. I like this way better but then telling which class to use at run-time is cumbersome. I'd maybe have to have pools of a boost and Xenomai mutexes. Is this how most hard real-time C++ programs address the issue?

I have this issue coming up with more than just a mutex but would like to receive feedback since I don't want to replicate bad design patterns from the start.

3) I believe TwinCAT from Beckoff runs EtherCAT in real-time under Windows 7. Is there anything that will be coming out that would not be out of reach of the hobbyist that supports at least one NIC with hard real-time under Windows 7 or later? Maybe there is an open source Hypervisor project.

4) Also, how do people load the system so that their quad-core computers are using 100 % of each of the cores so that they can tell if their system is not running in hard real-time?

Answer 1

One detail : if you want a 1khz refresh cycle for servos, why are you using hard real-time ? Soft real-time (ie. run as root, but pure userspace but set scheduler policy to FIFO levels for that process, lock everything into memory, disable swapspace ...) and you'll easily get 1khz out of it without missing a single message in an entire year of running.

At this point, just use a raw socket for your ethernet protocol and call it a day.

As to the unrelated question ethernet CD/CA are implemented in hardware these days. Just ignore them.