Interrupt Latency Measurement

Post your cool example code here.
victor_pv
Posts: 1746
Joined: Mon Apr 27, 2015 12:12 pm

Re: Interrupt Latency Measurement

Post by victor_pv » Sun Aug 27, 2017 3:16 pm

I bet those are due to the USB port interrupts, the USB code takes a really long path in any of the cores.
Did you try rising the EXTI interrupt priority over most of everything else?

User avatar
Pito
Posts: 1628
Joined: Sat Mar 26, 2016 3:26 pm
Location: Rapa Nui

Re: Interrupt Latency Measurement

Post by Pito » Sun Aug 27, 2017 3:27 pm

Yep, it seems those larger latencies come from USB. Here is BPill (INT_IN PB3) under STM32GENERIC, while printing results every 1000th interrupt:

Code: Select all

INTR Latency MIN=986ns MAX=26486ns AVER=991ns OVER=532
1       263468
2       256
3       0
4       274
5       1
6       0
7       0
8       0
9       0
10      0
11      0
12      0
13      0
14      0
15      0
16      0
17      0
18      0
19      0
20      0
21      0
22      0
23      0
24      0
25      0
26      0
27      1
28      0
29      0
30      0
31      0
32      0
33      0
34      0
35      0
I did not mess with priorities yet.. (how to change them, btw?).
Pukao Hats Cleaning Services Ltd.

victor_pv
Posts: 1746
Joined: Mon Apr 27, 2015 12:12 pm

Re: Interrupt Latency Measurement

Post by victor_pv » Sun Aug 27, 2017 6:51 pm

This libmaple function should do it:
https://github.com/leaflabs/libmaple/bl ... nvic.c#L48

The interrupt lines are listed here:
https://github.com/leaflabs/libmaple/bl ... nvic.h#L46

You can use the number, but is probably easier to read the code if you use those names. I believe at same priority setting, the one with the lower ID has priority. I.e. By default EXTI0 to 4 should have higher priority than USB, but EXTI9-5 and 15-10 would have a lower priority.

You can test that by using a pin from 0 to 4 in any port as the input.

But still the code before the interrupt is triggered can be interrupted (the digitalWrite part, etc), so the best way to measure without the other interrupts affecting is possibly to disable USB interrupts from before reading the start time, to after the delay. I believe any pending interrupt should be serviced as soon as they are enabled again, but perhaps we have to do something else than disable them, perhaps some masking, but to be honest I don't remember the details on how the NVIC works.
I remember if you disable interrupts completely, like Steve is doing in the SPI code, they get services as soon as enabled again, but that is a global disable, and if you used it, the pin interrupt would not be serviced either.

User avatar
Pito
Posts: 1628
Joined: Sat Mar 26, 2016 3:26 pm
Location: Rapa Nui

Re: Interrupt Latency Measurement

Post by Pito » Mon Aug 28, 2017 8:12 pm

For fun I've done following experiment: BPill as an external 1mil pulses generator (500us period incl. 100us jitter) and MapleM counting pulses (rising edges) via its interrupt (INT_IN PB3, Libmaple), while measuring the interrupt latency - latency capture via polling the flag

Code: Select all

..  while (flag != 1) start = CpuGetTicks();
  flag = 0;
  ..
while actual latency processing in the isr:

Code: Select all

// ISR
void intrfun() {
  flag = 1;
  elapsed =  CpuGetTicks() - start;
  if (elapsed <= lat_min) lat_min = elapsed;
  if (elapsed >= lat_max) lat_max = elapsed;
  n++;
}
When MapleM counts n>999999 it prints out the min, max latency and number of rising edges - result

Code: Select all

INTR Latency MIN=791ns MAX=3137ns INT#=1000000
With previous method I got about 480ns min, the +300ns here is the overhead I have not subtracted.
Pukao Hats Cleaning Services Ltd.

dannyf
Posts: 167
Joined: Wed May 11, 2016 4:29 pm

Re: Interrupt Latency Measurement

Post by dannyf » Tue Aug 29, 2017 8:26 pm

that approach under-counts the latency, by the execution of CpuGetTicks().

Post Reply