(On machines with software step generation, software PWM, or software encoder counting, there's also a "fast thread" which does low-level I/O at rates of up to 50kHz or so. In that case, "read inputs from external hardware" consists of latching counters maintained by the fast thread, and "write outputs" consists of updating registers such as step frequency registers which are then used staring in the next invocation of the fast thread)
In some RTOSes, a greater range of APIs may be called. For example, in LinuxCNC 2.7 with "uspace" realtime, practical experience shows that it is feasible to use `send()` and `recv()` POSIX API calls in realtime threads to send and receive UDP packets on a dedicated network interface.
LinuxCNC. While various ways to allow external buffering have been proposed, working code has never been submitted. With external buffering, some features will simply not work. This includes closing the PID loop in the PC, spindle synchronized moves, homing, and other items.
LinuxCNC's servo loop runs at a nominal 1kHz, and so does an externally initiated read of feedback position. However, the actual periods are 990Hz and 1000Hz. The two frequencies will beat at 10Hz. At its worst, the new feedback value will come just after a new command value, causing the motor to seem to move as little as 1% as far as PID commanded it to. This variable phase shift might produce a completely untunable system; at best it will provide a difficult to tune system.
Some external hardware has started incorporating a DPLL to provide most of the benefit of an externally-initiated read while conforming to the HAL timing model. The DPLL tracks the actual read time (with a relatively low gain to smooth out latency) and latches encoder counts a fixed time before the DPLL predicts LinuxCNC will request the information.
EPP, 50 bytes can be transferred in 200us.
If the read and write is not "fairly fast", two problems occur. First, there is less time left over for linux userspace programs such as the user interface. Second, the time from read to write represents a phase shift which (even though it is roughly constant) can still hurt the tunability of the system.
LinuxCNC supports two different styles of realtime, kernel-space realtime with RTAI and user-space realtime with PREEMPT-RT (called "uspace"). In RTAI, Linux hardware drivers cannot be used from the realtime context, so it is not possible to reuse them. "uspace" is new in LinuxCNC 2.7. For this reason, almost all hal hardware drivers have been written in the lowest possible terms: inb(), outb() and the like.
In principle, the RTAI realtime kernel has a network interface, RTnet. However, no one has ever submitted a driver that uses RTnet. It is not clear whether RTnet as written will work with HAL's timing model.
(Note: A working ethernet HAL driver using RTNet is currently being developed, see rt-8p8c.)
rt-usb. However, no one has ever submitted a driver that uses rt-usb. It is not clear whether USB can meet HAL's timing model.
With "uspace" realtime and the hm2_7i90 driver, USB ethernet dongles fail to work reliably at a 1ms servo cycle time.
because it breaks the idea of the project - LinuxCNC as a machine controller.
If you wished to do rigid tapping with your USB-based controller - you would have to add the tapping code to your microcontroller.
USB will not allow reliable communication between the motion controller (LinuxCNC) and the motor controller (your micro).
Multiply that by other options and now you have basically made your micro controller into a motion controller.
This has been done in a fork of LinuxCNC - USB to a mesa 7i43 card in the araisrobo project (now uses machinekit AFAIK).
Now if someone added some cool option to LinuxCNC's motion controller you wouldn't be able to use it until you added it to your motion controller.
It also doesn't allow LinuxCNC's built-in scope and meters access to the micro controller's internal test points.
By using relatively 'dumb' hardware, we avoid that scenario - whatever LinuxCNC can do it can do with all hardware that supports the basic requirements.
You can even run an analog servo using the parallel port - just the performance would be low.
So is it a waste of time for simple I/O stuff? Yes, I guess you could say that - but when you look at the bigger picture it makes sense - LinuxCNC does a lot more than just simple step driven mills.
We prefer that the motion controller is in one place - LinuxCNC.
Now if you could figure out how to get USB3 to be low latency relatime...now you are talking!