What is the reaction time of the Arduino interrupt?

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

Check the interrupts section of the datasheet, it tells you how many clock cycles that takes - but with 250ns, you have only 4 clock cycles to do it in, which I don't think is enough, no matter how you do it.

It may be possible to just barely do it using timer 1, assuming you're using an Atmega328 or something similar. What I think might work is to feed the PPS signal into the timer 1 external clock pin and configure the timer so that a single clock pulse will cause it to generate an output compare, thus setting the OC1A pin. According to the data sheet, the external clock pin is sampled each system clock cycle and then there is a delay of up to 3.5 clock cycles before the timer is clocked. So it might just get you under that 250ns requirement. Maybe. :slight_smile:

It would probably be easier to add some external logic.

I think you are looking for a flip-flop, not a microcontroller...

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.

I agree with MarkT - what you need is a discrete part with the necessary speed to do the converting of the pulse to a pin transition - since presumably you need to do more than that, you could then use an Arduino alongside it, to do the other stuff (and enable/disable that part, etcetera).

I don't think this calls for a Pi, since you don't need fast processing, just fast reaction to a pulse, which is easy to do with a separate IC or two.

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.

Don't think it is up to the task either...
https://www.raspberrypi.org/forums/viewtopic.php?f=44&t=9207

The Raspberry Pi is very poor at responding to interrupts due to Linux constantly interrupting any code. If you did want to use a Pi then you would have to run it as a Bair Metal system.

I can't see why you don't want to use a T-flip flop like the other poster suggested. That part is just about as cheap as you can get and can be had in pretty much any package.

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?