Not quite. Its more about the difficulty of writing the code. A lot of OSes aren't realtime which can be part of the problem, but a careful administrator can tune Windows or Linux to be "more realtime".
Consider this: most hardware is set up to DMA to RAM through the northbridge. It never touches the CPU, the hardware just writes the data directly to RAM (indeed: this is a good thing. When the CPU is executing from L1 cache, it isn't touching the RAM anyway).
Then, the CPU gets an interrupt, and then it can read from RAM.
Exactly what "received signal" exists inside of a CPU's L1 cache and register?
In practice, any I/O of a modern CPU / Microprocessor is going to run through the Northbridge and most likely be dumped into DDR3 / DDR4 RAM. That's already 60ns of delay minimum that you've introduced into the system and you haven't even done any math yet!
Building a digital system that responds within nano-seconds is difficult, while a purely passive LRC filter... taught in maybe ~2nd year or ~3rd year Electrical Engineering classes, can indeed respond within nanoseconds!
--------------
I guess what I'm saying is... building Digital systems that respond within nanoseconds is certainly possible, but its specialized knowledge and requires specialized CPUs (aka: a Digital Signal Processor). Most programmers don't need to do that after all (write a damn login page again)
I'm not exactly an expert on the ways of the DSP. I just know people who moved in that direction. Its an intriguing field and takes lots of study to be effective.
I don't think we were talking about DSP... at least when I originally replied I was making the official point that a high frequency CPU doing single-clock-cycle reads of GPIOs, can respond in nanoseconds. I think you are talking about something different...
The GPIOs are pins that are directly attached to the CPU. They are accessible by the CPU without requiring access to cache.
Not denying that it's hard to do on a general purpose Intel CPU with its absurdly high clock rate. But anybody with a fast oscilloscope can tell you that fast microcontrollers have that kind of response time, too (10s of ns), because ops take a clock cycle, and 100MHz = 1ns.
They tried this on an AM335x, a modern ARM Cortex A8 used on the BeagleBone Black for example. Clocked at 1 GHz and doing nothing else other than toggle a GPIO pin - it took 200 ns. This is for a fully integrated SoC. Merely due to various levels of interconnect within the CPU.
Not quite. Its more about the difficulty of writing the code. A lot of OSes aren't realtime which can be part of the problem, but a careful administrator can tune Windows or Linux to be "more realtime".
Consider this: most hardware is set up to DMA to RAM through the northbridge. It never touches the CPU, the hardware just writes the data directly to RAM (indeed: this is a good thing. When the CPU is executing from L1 cache, it isn't touching the RAM anyway).
Then, the CPU gets an interrupt, and then it can read from RAM.
It takes roughly 60 ns alone to access DRAM on a modern processor (https://software.intel.com/sites/products/collateral/hpc/vtu...), plus whatever time it took for the DMA to happen.
NOW the CPU finally has the data in its cache and can start calculating.
------------
To fix this issue, you DMA directly onto the CPU's cache itself.
http://www.intel.com/content/dam/www/public/us/en/documents/...
That takes special device drivers, a lot of optimizing, a lot of thinking about latency.