Measuring AVR interrupt latency

Go To Last Post
3 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Since I released my first AVR bit-bang UART several years ago, I've had a number of requests for interrupt-driven receive.   For the best accuracy, an interrupt-driven bit-bang rx routine needs to factor the response time from the beginning of the start bit until the interrupt code runs.  Since the the datasheet is unclear about the operation of the pin change interrupt synchronizers, I decided to do some testing on the t13 and t85 before writing the interrupt-driven receive code.  I determined that the PCINT latency is 2 cycles longer than INT0, but only when the CPU clock is running.  For any sleep mode, the synchronizer is not active.

 

http://nerdralph.blogspot.com/20...

 

I have no special talents.  I am only passionately curious. - Albert Einstein

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nice work.

In the past I have used (I never need the sleep function) to read the timer (that generate the ISR), and then make the flow after that. That way you can stay consistent 10 clk (as I remember) after ISR. 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:

Nice work.

In the past I have used (I never need the sleep function) to read the timer (that generate the ISR), and then make the flow after that. That way you can stay consistent 10 clk (as I remember) after ISR.

 

I've done that before too.  For external interrupts the only ways I've come up with for single-cycle timing is sleep, or using the input capture pin on parts that have it.

 

I have no special talents.  I am only passionately curious. - Albert Einstein