Cortex M0,M3 Interrupt Latency?

[lpcware]

Content originally posted in LPCWare by kizerkid on Sat Oct 15 11:13:45 MST 2011
I have tried EXTI (IRQ) Interrupt of LPC1114 (M0-48MHz) and STM32F100 (M3-24MHz) and found some problem about interrupt latency.

From MCU&ARM Documents, I've found that the Interrupt latency of M0 is 16 clocks and M3 is 12 clocks. I try to test their int. latency by out a pulse from one output pin after the EXTI int. is activated by the rising/falling edge  of the input signal on defined EXTI pin. Then I can measure int. latency from the time delay of 1st edge of output pulse after the EXTI input edge.

The result are:  ~1usec for LPC1114(M0) and ~1.8usec for STM32F100(M3)

Are these mean that: LPC1114 has ~48 clock delay = 16 from latency and 32 from some ISR (Interrupt Service Routine) code (may be push, pop etc.)  and STM32F100 also has ~48 clock delay = 12 from latency and 32 from some ISR code ??

I know that, after interrupt is occurred, we must have asm code to push some registers before do any other ISR code...however, I think..is it take all those 32-36 clocks? Is it too much? Actually, my project have to do some process after the rising/falling edge of input signal within ~1.6usec..so..I'm sure that I can't write the code to complete my task within just 0.6usec (for LPC1114)

When I try to see in disassembly panel of CodeRed for any state savingr code after the int. is occured, I just can see about 3-4 lines of asm code for that task..so ..Is it possible that these 3-4 lines take ~32 clock cycles for processing??
Are there any way out to shorten the int. latency? If I write all code in assembly, Can I overcome this problem? (If yes, please give me some example for EXTI Interrupt in asm)

Thank you.

[lpcware]

Content originally posted in LPCWare by kizerkid on Mon Oct 17 23:47:03 MST 2011
For my int. latency test, I've used 'extint' example from 'LPCXpresso Example Projects for LPC1114/302 V2.0' as based project on 'LPCXpresso v4.1.0' suite. The overall code is shown below:

---

Quote:

=====Main===========
int main (void)
{
  GPIOInit();/* Initialize GPIO (sets up clock) */

   /* use port2_1 as input event, interrupt test. */
  LPC_IOCON->PIO2_1  |= 0x08;//pull-down input
  GPIOSetDir( PORT2, 1, 0 );
  GPIOSetInterrupt( PORT2, 1, 0, 1, 0 );//both edge trig
  GPIOIntEnable( PORT2, 1 );

  /* Set LED port line to output (Port0.7)*/
  GPIOSetDir( LED_PORT, LED_BIT, 1 );
  GPIOSetValue( LED_PORT, LED_BIT, LED_OFF );

  while( 1 );
}
=====INT.=======
asm (".equ GPIO0_7DAT,   0x50000200");
asm (".equ GPIO2_IC,    0x5002801C");
void PIOINT2_IRQHandler(void)
{
asm(
"ldr r1,=GPIO0_7DAT;"
"mov r2,#128;"
"str r2,[r1];" //ON LED(P0.7)
"mov r2,#0;"
"str r2,[r1];" //OFF LED(P0.7)

//clear INT.
"ldr r1,=GPIO2_IC;"
"mov r0,#2;"
"str r0,[r1];"
);
  return;
}

---

Actually, my 1.6usec job can be done well with assembly language on ATTINY2313(8bit), but I must overclock it from 20MHz to 25MHz. Thus, I try to find new MCU that can done the task without overclock. After I found LPC Cortex M0, I think this MCU is matched! because of 50MHz operation with almost 1 clock cycle instruction. However, it's quite surprise for me that it can't be done..because of:
1. Interrupt latency
2. Less register
3. Less 1clk instruction and 3clk for branch

Anyway, I think I can do my job with new program that not use interrupt (using polling instead), however I still wish that I can use the interrupt..if I can reduce its response time to about 0.4usec (~20clk)

Thank you :)

[lpcware]

Content originally posted in LPCWare by TheFallGuy on Mon Oct 17 04:08:55 MST 2011
that sounds too high. doing the math, that works out at ~38 cycles. why don't you post your project so we can see what you are doing.

[lpcware]

Content originally posted in LPCWare by kizerkid on Mon Oct 17 01:20:42 MST 2011
Now, I've already set Release option with -O3 optimization. And, of course, I've already checked that the clock is running at 48MHz by measuring CLKOUT frequency. The result is just a little bit better. The latency for LPC1114 is shorten from 1usec to 0.8usec. Are there anything I should to do/check? Or, Can I conclude that 0.8usec is the real total latency time?

Thank you ^^

[lpcware]

Content originally posted in LPCWare by TheFallGuy on Mon Oct 17 00:31:23 MST 2011
One other thing to check - did you set up the clock. IIRC, if you don't, you get to run at 6MHz - that would explain why it seems so slow.

[lpcware]

Content originally posted in LPCWare by kizerkid on Sun Oct 16 09:47:56 MST 2011
Thanks for your comment 'TheFallGuy'. Actually, the thing I have done to measure latency is the same as your recommend "toggling a pin and put a scope on it to see what the 'real' timing is". That's exactly what I have done.

For STM, I used Raisonance Ride7 and had already set -O3, Release compile option, but, for LPC, I've forgot to set to Release and not set any optimization option in Code Red Suite. I'll try it soon and will check the result again.

(FYI: For the toggle pin code in ISR, I use inline assembly (No C code at all) to make sure about the time of pin activation)

[lpcware]

Content originally posted in LPCWare by TheFallGuy on Sat Oct 15 15:12:20 MST 2011
Interrupt latency is the time frmo the interrupt happening to the first useful instruction in your ISR. The figures quoted are normally in 'ideal' conditions, but can be affected by a number of things, including:
- whether there are higher priority interrupts to be services first
- the speed of your flash and ram (wait states)

Of course, when you get into your ISR, its speed is determined by the same things above, and also how optimal the code is (e.g. debug vs release).

As we don't know what you code looks like, and what it is you are actually measuring, it is hard to say where your 'missing cycles' are going, so I'd suggest posting your code (or ideally you whole project) so others can comment.

If you can't do this, try doing something really simple in your ISR, such as toggling a pin and put a scope on it to see what the 'real' timing is. Don't forget to compile your code for Release at least, and maybe even tweak the compiler options to build for -O3 optimization.