Go Down

Topic: What is the reaction time of the Arduino interrupt? (Read 8280 times) previous topic - next topic

polymorph

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

Good point about interrupt speed.
Steve Greenfield AE7HD
Drawing Schematics: tinyurl.com/23mo9pf - tinyurl.com/o97ysyx - https://tinyurl.com/Technote8
Multitasking: forum.arduino.cc/index.php?topic=223286.0
gammon.com.au/blink - gammon.com.au/serial - gammon.com.au/interrupts

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.

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




If your questions are not precise, nobody can help you.

AWOL

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.
"Pete, it's a fool (who) looks for logic in the chambers of the human heart." Ulysses Everett McGill.
Do not send technical questions via personal messaging - they will be ignored.
I speak for myself, not Arduino.

jboyton

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):

Code: [Select]
#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.

arduinoaleman

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?





If your questions are not precise, nobody can help you.

AWOL

Quote
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.
"Pete, it's a fool (who) looks for logic in the chambers of the human heart." Ulysses Everett McGill.
Do not send technical questions via personal messaging - they will be ignored.
I speak for myself, not Arduino.

Coding Badly

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.


MorganS

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.
"The problem is in the code you didn't post."

polymorph

Steve Greenfield AE7HD
Drawing Schematics: tinyurl.com/23mo9pf - tinyurl.com/o97ysyx - https://tinyurl.com/Technote8
Multitasking: forum.arduino.cc/index.php?topic=223286.0
gammon.com.au/blink - gammon.com.au/serial - gammon.com.au/interrupts

arduinoaleman

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.


If your questions are not precise, nobody can help you.

polymorph

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.

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
Steve Greenfield AE7HD
Drawing Schematics: tinyurl.com/23mo9pf - tinyurl.com/o97ysyx - https://tinyurl.com/Technote8
Multitasking: forum.arduino.cc/index.php?topic=223286.0
gammon.com.au/blink - gammon.com.au/serial - gammon.com.au/interrupts

arduinoaleman

Absolutely right, as long as no code execution is required.
If your questions are not precise, nobody can help you.

MorganS

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.
"The problem is in the code you didn't post."

Go Up