Interrupt Timing Conundrum

Go To Last Post
59 posts / 0 new

Pages

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

How have you tested that?

That's been detailed in rather excruciating detail in this thread, four years ago.  I used a similar method for my tests on the m328p today.

 

Basically, I set up a timer to set an interrupt flag every CPU cycle, and constructed an ISR which toggles an I/O pin.  Non-interrupt code is deliberately starved by inserting an SEI before the RETI in the ISR.  The pin toggles at a rate equal to one cpu cycle less than expected.  The cycle-length of all other instructions used in the ISR (OUT, SEI, RETI) have been verified, so the only possible conclusion is that the the frist step (where the PC is pushed onto the stack and execution is transferred to the appropriate vector) takes 1 cycles less than expected.

 

I tested with a variety of other timer periods both less than, equal to, and greater than the expected and observed ISR round-trip time, with the non-interrupt tread toggling a different pin (if it doesn't get starved).  In all cases, the evidence points to an interrupt response time of 3 cycles, not 4 as stated in the data sheet.

 

Apparently it is 3 cycles for the vectoring and 1 cycle of delay between the actual event and the start of the vectoring. I guess this delay cycle has something to do with the "always execute one more instruction before servicing a pending interrupt". And because the main code is executed during this delay cycle, you don't notice it with the kind of test the OP has done.

Please read the (admittedly lengthy) thread for an understanding of how the testing was conducted.

 

I'm open to the possibility that the test methodology is flawed in some way (e.g. making unwarranted assumptions), or that the interpretation of the test results are in error somehow.  I have yet to see compelling examples of either.

 

As mentioned 4 years ago, I'm curious to hear from Amtel/Microchip on this matter.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

joeymorin wrote:
That's been detailed in rather excruciating detail in this thread, four years ago.
I have to admit that I did not read the entire thread in detail, but all I have read seems to completely ignore what "response time" actually means. It is the time between the interrupt event (setting the flag) and the start of code execution at the vector. This time consists of two parts:

1) A variable number of cycles before the jump to the vector is happening.

2) The fixed number of cycles the jump to the vector takes.

 

In a normal program the part 1 cycles are spent within the main code. In your extreme test case here

Quote:
Basically, I set up a timer to set an interrupt flag every CPU cycle, and constructed an ISR which toggles an I/O pin. Non-interrupt code is deliberately starved by inserting an SEI before the RETI in the ISR.
they are spent within the ISR. Your test does NOT measure any response time at all. It only measures the time needed for the jump to the vector (part 2 of the response time).

 

So obviously the (fixed) part 2 of the response time is 3 cycles. When the datasheet states that the minimum response time is 4 cycles, it basically says that part 1 is always at least 1 cycle. I do not know whether that is correct or not, but I do know I haven't seen a test here (*) that actually measures the minimum response time.

 

(*): Again admitting I haven't read everything. But I probably will read it in more detail later in the day.

Stefan Ernst

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

I have to admit that I did not read the entire thread in detail, but all I have read seems to completely ignore what "response time" actually means. It is the time between the interrupt event (setting the flag) and the start of code execution at the vector. This time consists of two parts:

 

1) A variable number of cycles before the jump to the vector is happening.

2) The fixed number of cycles the jump to the vector takes.

I assume by your '1)' you mean a variable amount of time between when an event occurs and when the flag is set.  In the case of the timer interrupt used in the tests, at least, that is not relevant.  The flag is set every cpu cycle, so as soon as an invocation of the ISR has begun, the flag is once again set, so that when the ISR exits the conditions necessary for triggering the next invocation have already been established.  There is no variable element.  Neither are any instructions from main allowed to execute as is the norm.  In these tests, main is completely starved of machine cycles by the insertion of an sei before the reti in the ISR.

 

The interrupt response time normally refers to the sum of 1) the time to push the PC onto the stack and change the PC point to the appropriate vector, and 2) the time to execute the vector (usually a jmp or rjmp).

 

With these tests, the ISR is placed directly in the vector table, obviating the jmp/rjmp, so the interrupt response time here means exclusively the PC->stack step.

 

 

they are spent within the ISR.

While its true that the normal '1-instruction' rule is effectively circumvented by the sei before the reti, the reti itself will never be anything other than a 4-cycle instruction, so this is a non-variable element.

 

If you're suggesting that the hardware is able to 'get a head start' on the PC->stack step while the reti is underway, I see no support for that hypothesis.  Where that the case, then a 3-, 2-, or 1-cycle instruction in its place should allow less time for the hardware to 'get a head start', and tests would show different times for the PC->stack step.  These tests and others show this not to be the case.

 

Your test does NOT measure any response time at all. It only measures the time needed for the jump to the vector

The test is measuring the entire round-trip time of the ISR:

  1. PC->stack, PC=vector_table_entry
  2. out
  3. sei
  4. reti

 

The cycle times (as claimed in the datasheet) of the above are:

  1. 4
  2. 1
  3. 1
  4. 4

 

So the total round-trip time of the ISR should be 10 cycles, and the I/O pin toggled by the out could show a period of 20 cycles.  Instead it shows a toggle rate of 18 cycles, with two identical 9-cycle half-periods.  Other tests confirm with no doubt that out and sei are both 1-cycle instruction, and that reti is a 4-cycle instruction.  The conclusion seems, inescapably, to be that PC->stack, PC=vector_table_entry takes 3 cycles.  Not 4 as claimed.

 

So obviously the (fixed) part 2 of the response time is 3 cycles. When the datasheet states that the minimum response time is 4 cycles, it basically says that part 1 is always at least 1 cycle. I do not know whether that is correct or not, but I do know I haven't seen a test here (*) that actually measures the minimum response time.

Aha.  That is a novel interpretation of the 4-cycle interrupt response time claimed in the datasheet.  In retrospect, it seems reasonable, since under 'normal' circumstances a pending interrupt would be subject to the '1-instruction' rule, that the minimum instruction length of 1-cycle be included in the the claimed 'four clock cycles minimum'.  I find it somewhat misleading, however.  A clearer passage in the datasheet would have been helpful.

 

but I do know I haven't seen a test here (*) that actually measures the minimum response time.

That is in fact >>precisely<< what these tests have been constructed to measure, and I believe they are in fact correctly doing so.  However, the insight you've provided into an interpretation of the datasheet's claim of 'four clock cycles minimum' now including the normal '1-instruction' guarantee, with the minimum length of that instruction being 1 cycle, makes the math add up.

 

I'm confident now that the PC->stack step is in fact only 3 cycles for a 16-bit PC, that the test methodology is sound, and that the test results have been correctly interpreted.  I believe now that the error was in the interpretation of the datasheet.

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

joeymorin wrote:
I assume by your '1)' you mean a variable amount of time between when an event occurs and when the flag is set.
No, I mean the cycles between "flag is set" and "jump to the vector code starts to happen".

 

joeymorin wrote:
The flag is set every cpu cycle, so as soon as an invocation of the ISR has begun, the flag is once again set
And exactly because of that the test is inappropriate. Any Part 1 extra cycle is hidden within the ISR code.

 

joeymorin wrote:
The interrupt response time normally refers to the sum of 1) the time to push the PC onto the stack and change the PC point to the appropriate vector, and 2) the time to execute the vector (usually a jmp or rjmp).
  For me it is the total amount of time between the interrupt event and the start of the corresponding code execution, and I have never seen/heard a different definition. In case of your timer test the real response time is 3 cycles plus almost all cycles spent in the ISR and is therefore far away from being "minimal".

Stefan Ernst

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

No, I mean the cycles between "flag is set" and "jump to the vector code starts to happen". 

That is not what these tests were meant to measure.

 

And exactly because of that the test is inappropriate. Any Part 1 extra cycle is hidden within the ISR code.

On the contrary, it clearly reveals where the 4 cycles are spent.  It is the datasheet which is 'inappropriate' by not making it clear that the 'four clock cycle minimum' includes the minimum 1-clock-cycle instruction being interrupted.

 

For me it is

That is in most cases non-deterministic, obviously.  The tests were not meant to examine this.  Rather, the interesting bit for me is the question: 'With a pending interrupt (no matter how far in the past the interrupt >>became<< pending) how long does it take to get to the vector table once the hardware is in a position to service the interrupt (i.e. I bit changes from 0 to 1, and the '1-instruction' has been executed)?'  That's the only part I care about.  For any given app, the method of WCE timing calculations will not change, but the the number I slot in to the PC->stack step will now correctly be 3.  One cycle isn't much, but when you're counting cycles, it can make a difference.

 

EDIT: sp

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Tue. Jul 31, 2018 - 07:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Unfortunately the images from the original thread were not transferred when Atmel introduced the new forum software.

 

The following are for the ATmega32U2.  The ISR duration matched with what was expected, but the events (outputs D0 and D2)

did not align correctly with the instructions.

 

What was discovered was that the ISR vectoring took 3 cycles not 5 and RETI used 4 cycles not 5.

 

Any cpu cycle used by the ISR is taken away from the main thread.

The start of the ISR can be determined by aligning the change in D2 with the out instruction in the ISR.

 

 

 

 

 

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

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

I came across something similar recently. I don't have time to dig out my notes right now but it came down to recent datasheets being wrong.

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

Pages