What is the reaction time of the Arduino interrupt?

The Propeller microcontroller can respond to input changes with a granularity of 12.5ns and a delay
or about 100ns if you dedicate an entire cog to watching that pin. Since the design philosophy of
that machine is about guaranteed cycle-accurate timing and uses multiple cores in place of interrupts,
it is a good match to a problem that would normally require special hardware.

Interrupt handling in most chips has jitter (it depends on the timing of the instructions being
interrupted - a divide instruction typically takes more clocks than an add for instance, so delays
the interrupt longer). Also in most architectures a new stack frame is started (so a couple
of registers are written to stack and stack pointer altered) before your ISR code even starts running,
so there is a definite delay involved. ISRs that react within 10 machine cycles would normally be
thought "ultra-fast". In a full-blown CPU you'd expect the interrupt latency to be measured in
hundreds/thousands of cycles and timing completely at the mercy of the cache and memory
subsystem. It doesn't matter what the OS policy is, you do not get +/-10ns repeatability from
an interrupt handler in a modern CPU...

I suspect you need some specialised hardware and an ISR to accomplish your task - though its
not impossible that one of the timer units can be pressed into service if you can clock it
externally and route one of its output compares to a pin too.

Some more information about what you are trying to do would help...

arduinoaleman:
I love Arduino, so it hurts me when i have to recommend you a Raspberry Pi when it comes to higher speed or higher level programming.

Unfortunately, the Pi comes with a lot of other baggage, and I suspect it is also incapable of the sort of timings required by the OP.

-horn-:
I ask, because I want to trigger it with a 1 pulse per second GPS chip with a +-10 nanoseconds jitter and it must trigger faster than 250 nano seconds and then pulling up a pin from low to high.

From what I can gather this signal is pulsing at the rate of one per second with a +-10 nanoseconds jitter. That means that the pulse can be 10 nanoseconds early or 10 nanoseconds late. Given that I am not sure what you want to do or why you want to do it.

it must trigger faster than 250 nano seconds and then pulling up a pin from low to high.

What and when does this pin go from a high to a low?

In ignorance, the Due or Teensy 3.1? Both use an ARM Cortex running at a clock speed considerably faster than a 16MHz Arduino without the baggage of Linux on a Pi.

A flip flop does seem simpler, depending on what you intend on doing with this time-sensitive information.

High Resolution PulsePosition library on the Teensy 3.1

PulsePosition Library

PulsePosition can transmit and receive PPM (Pulse Position Modulated) signals commonly used to control RC aircraft and servo motors. Up to 8 simultaneous input and/or output PPM streams may be used, with each stream conveying up to 16 signals.
PulsePosition is in beta testing. Please get the latest code from GitHub:
GitHub - PaulStoffregen/PulsePosition: Multiple High-Res Input & Output PPM Encoded Signal Streams on Teensy 4.x, 3.x & LC

PulsePosition is designed for 0.02 µs accuracy (approx 24X better than most Arduino implementations using AVR Timer1) with tolerance for significant interrupt latency caused by other libraries. All output waveforms are generated by hardware timer compare and all input waveforms are read using hardware timer input capture, for extremely precise timing. Pin change interrupts, which add error due to interrupt latency, are never used.

So, 20ns accuracy.

polymorph:
In ignorance, the Due or Teensy 3.1? Both use an ARM Cortex running at a clock speed considerably faster than a 16MHz Arduino without the baggage of Linux on a Pi.

Doesn't mean it will respond to interrupts any faster... It has a lot more hardware baggage (an
instruction cache I think, as well as lots of registers).

Well, PulsePosition library claims 20ns response times. That's what I'm going by.

Good point about interrupt speed.

If it is Linux or something else ... interrupts will be handled immediately (within a few clock cycles). The new Raspberry Pi runs at 900 MHz having 4 cores. Only one of them is needed to handle the interrupt routine.

And when it comes to speed - 900 MHz vs 16 MHz is just like comparing a Ferrari with a bycicle.

arduinoaleman:
If it is Linux or something else ... interrupts will be handled immediately (within a few clock cycles). The new Raspberry Pi runs at 900 MHz having 4 cores. Only one of them is needed to handle the interrupt routine.

Show us the scope/logic analyser traces.

I tried out the timer idea I had, assuming an Atmega328 based "Arduino". It looks like it actually works although it's not that straightforward. Because the timer compare output is double buffered, getting it to generate a signal in one clock cycle (and then clearing the latch afterward) required feeding it internal clock pulses, then switching over to the external source. I don't have an oscilloscope, so to measure the delay I used a second Atmega328 and slowed the target processor down to 1/256 it's normal clock rate so I had enough measurement resolution.

I never saw it take more than 2.7 clocks, which at 16MHz would be about 170ns. Now maybe there is additional delay that my timing method couldn't capture. But I think it would work. Atmel says 3.5 clocks worst case. That would be 219ns.

This is the code (with the clock division code I used for testing deleted):

#define T1_INPUT_PIN          5   // 328 pin 11
#define OC1A_OUTPUT_PIN       9   // 328 pin 15

void setup()
{
  pinMode(OC1A_OUTPUT_PIN, OUTPUT);  // OC1A timer 1 compare output, digital pin 9, chip pin 15
  pinMode(T1_INPUT_PIN, INPUT);
  
  TCCR1A = 0;           // Reset timer
  TCCR1B = 0;
  OCR1A = 1;            // Output compare = 1
  TCCR1A = 0xC0;        // set 0C1A on compare match
  TCCR1B = 0x0F;        // CTC, external clock T1, clock on rising edge
  TCNT1 = 0;            // counter = 0
}

void loop()
{
  if (digitalRead(OC1A_OUTPUT_PIN)) {
    // Do something...
    // Instead of polling this could be interrupt driven via the timer 1 compare ISR

    delay(100);  // just a placeholder

    // When whatever we're driving with this pin needs to go low again, do this:
    //
    resetLatch();
  }
}

void resetLatch()
{
  TCCR1A = 0x40;    // toggle OC1A on compare match
  TIFR1 = 0x02;     // clear compare flag
  TCCR1B = 0x0C;    // CTC, internal clock, prescaler = 256
  while ((TIFR1 & 0x02) == 0) {}  // wait for toggle
  TCCR1B = 0;       // disable clock
  TCCR1A = 0;

  OCR1A = 1;            // output compare = 1
  TCCR1A = 0xC0;        // set 0C1A on compare match
  TCCR1B = 0x0D;        // CTC, prescaler = 1024
  TCNT1 = 0;
  delayMicroseconds(64+8);  // clock period is 64us, make sure we get one clock
  TCCR1B = 0x0F;	// CTC, external clock T1, clock on rising edge
}

It's still probably simpler to use a 7474 or whatever the modern version of that part is.

It is NOT the operating system that controls the time until an interrupt is handled. Why do you not have a look at the datasheet of the ARM Cortex-A7 Quad?

When an interrupt comes in, the microprocessor will finish the current instruction, save the return address on the stack and start immediately to handle the interrupt routine.

This usually requires only 3 to 5 clock cycles.

And if one chip runs at 16MHz and the other one at 900MHz - which one do you think will start and finish the interruprt routine faster?

When an interrupt comes in, the microprocessor will finish the current instruction, save the return address on the stack and start immediately to handle the interrupt routine.

You missed out the vectors there.

Like I said, show us the logic analyser or scope trace.

arduinoaleman:
It is NOT the operating system that controls the time until an interrupt is handled.

Actually, it is. An operating system like Linux is free to mask interrupts as it pleases. Which includes prioritizing interrupt handling and even outright ignoring interrupts.

In any case, you are proposing @-horn- write a Linux kernel interrupt service routine. I have no doubt, given enough time / money / interest, @-horn- is up to the task.

However, the effort is surely a waste given the fact that a readily available part costing significantly less than $1 is a perfect solution for the task.

However, the effort is surely a waste given the fact that @jboyton's, now publicly available, proposal has merit.

However, the effort is surely a waste given the fact that SAM-based Arduino compatible boards are readily available at a reasonable price.

However, the effort is surely a waste given the fact that the Propeller is readily available at a reasonable price.

arduinoaleman:
And when it comes to speed - 900 MHz vs 16 MHz is just like comparing a Ferrari with a bycicle.

I'm pretty sure that my bicycle can get a front wheel across the white line at the traffic lights before the Ferrari, and that's the speed that we're talking about here. Yes, the Ferrari might be 50m down the road before my back tyre crosses the line but the bike got there first.

A Ferrari is also much more difficult to get up onto the kerb and onto bike paths.

I guess someone will have to test these.

I cannot imagine you wrote your answer on a PC/notebook that runs with less than 1 GHz. When it comes to speed, the MHz and GHz do count.

Your example (traffic light) is only valid when booting a system. A Ferrary can reach 100 km/h in less than 4 seconds. How many meters will you be able to cover in 4 seconds?

I do love my two Arduinos.

However, when it comes to real speed, the Arduino might not be the proper solution.

Going back to what the original poster asked, I'd agree that a flip flop is the right chip for the job, without knowing anything else about what he/she is trying to do.

-horn-:
Hi there,

I couldn't find an answer to my question on the internet, so I would like to ask heere.

What is the reaction time of the interrupt, if programmed with the arduion code?

I ask, because I want to trigger it with a 1 pulse per second GPS chip with a +-10 nanoseconds jitter and it must trigger faster than 250 nano seconds and then pulling up a pin from low to high.

I hope you have an answer for me :).

Best regards,

Andreas

Absolutely right, as long as no code execution is required.

The GHz doesn't matter in this case. If the operating system has a higher-priority interrupt then your incoming interrupt is going to get delayed by a random amount. The whole purpose is accurate timing, which is not possible when the computer has other jobs to do.

And that's before you consider multitasking, which will add all sorts of delays to unload and load register contexts.

If you're on the wrong on-ramp on the freeway interchange then a Ferrari will get you to the correct one very fast, but it would be quicker if you had got on the correct on-ramp in the first place.