In the scenario I described above, with each new release of their operating system (RT/M for Sigma 5) I had to go through and change any code that masked out the timer interrupts and verify that it did not cause harm in any part of the os. And this was designed to be a real-time os, which it otherwise was.
The delay in the 2ms interrupt caused by masking out the timer interrupt was estimated to be several times the quantization noise, an unacceptable result.
I don't know what the numbers are for Linux, but I would suspect there is a release that provides something workable. I would imagine that there are real-time OSes out there now.
Yes, but keep in mind that a 4mhz PIC is faster than the hardware we were working on then.
And yes, silicon is cheap. The multiplexing A/D converters we were using cost $40,000 each. Today you get the same thing for maybe a dollar, retail quantity one.
And XP is so bad that it can't key morse code reliably through the printer port for just the reasons you mention.
Today the limiting factor is the OS, not the hardware. If your deadlines are long enough, it's surprising how well NT/XP works for low-level tasks. The problem we've had is that when we need deadlines below say 50mS, even a multi GHz Windows box can't guarantee that (XP can't guarantee anything!), so we need a mechanism to detect the missed deadline and continue without a hard failure.
Programming on a consumer-OS like Windows has so many benefits that we prefer to use that as the main platform and offload the sub-millisecond latency hard realtime stuff to smaller processors with code running on bare metal.
Sometimes it's hard coming to grips with the fact that a 4MHz PIC is outperforming a 2+ GHz Windows box, but silicon is cheap!