# What is STM8 hardware and software interrupt latency?

Just have a first look over the STM8 lineup to compare its performance to AVR which is well know for me now.

One of my the big complain to AVR was the slow reaction to interrupts especially in C compiled code. To describe the problem please see the C code:

ISR(INT0_vect){
array_p = (array_p+1) & 0x0F;
array[array_p] = TCNT0;
}


This compiles to a huge ASM:

ISR(INT0_vect){
b6:   1f 92           push    r1
b8:   0f 92           push    r0
ba:   0f b6           in  r0, 0x3f    ; 63
bc:   0f 92           push    r0
be:   11 24           eor r1, r1
c0:   8f 93           push    r24
c2:   ef 93           push    r30
c4:   ff 93           push    r31
array_p = (array_p+1) & 0x0F;
c6:   e0 91 00 01     lds r30, 0x0100
ca:   ef 5f           subi    r30, 0xFF   ; 255
cc:   ef 70           andi    r30, 0x0F   ; 15
ce:   e0 93 00 01     sts 0x0100, r30
array[array_p] = TCNT0;
d2:   86 b5           in  r24, 0x26   ; 38
d4:   f0 e0           ldi r31, 0x00   ; 0
d6:   ef 5f           subi    r30, 0xFF   ; 255
d8:   fe 4f           sbci    r31, 0xFE   ; 254
da:   80 83           st  Z, r24
}
dc:   ff 91           pop r31
de:   ef 91           pop r30
e0:   8f 91           pop r24
e2:   0f 90           pop r0
e4:   0f be           out 0x3f, r0    ; 63
e6:   0f 90           pop r0
e8:   1f 90           pop r1
ea:   18 95           reti


As you can see there are a lot of 'extra' pushes and pops.

To this inefficient (in my opinion) code I should add 7 more cycles of core latency:

I hope that STM8 can be faster for some reasons:

• hardware support of nested interrupts with programable priority,
• hardware (hopefully) support of accumulator, status, X and Y registers preservation.

In the reference datasheet I found these words:

So as I can see - those pushes will be performed by the hardware so it will be hopefully faster. But there is no informations about how much cycles it will take.

I wasn't able to find this information in the Internet as well.

So the questions are:

1. What is the actual hardware latency of interrupt response for the STM8 CPUs (the value estimated as 7 cycles for AVR)?
2. What is the typical C code latency? More sharply: can I hope that STM8 C compiled code will be more efficient than AVR one at this point?
• Since this question is about performance, have you looked at 32-bit microcontrollers? – Tut Mar 24 '16 at 12:04
• @Tut this was question not about speed itself rather it was regarding performance per MHz or if you like - per uW of power. As I need to have a small micropower cheap device I will need something small (however ARM can be as small as 32TQFP), slow clocked (1-2 MHz) and operated at low voltage. I think 32-bit MCU will not feet those requirements at all. – Roman Matveev Mar 24 '16 at 12:11
• I think your assumptions about 32bit MCUs are incorrect: here is an example of a Cortex-M0+ which can be clocked at 1-2MHz, runs "down to 76uA/MHz in run mode", operates as low as 1.65V, and comes in WLCSP25 which is tiny. Also, instead of running it continuously at ~2MHz, you can run it at ~20MHz and sleep most of the time. – uint128_t Mar 24 '16 at 14:13
• @uint128_t, 76uA/MHz - that's impressive! I took a glance at this CPU - it looks very impressive in many ways. The only thing I don't like is the price - about 1.5 USD in quantities. Which is 2-4 times more expensive than ATmega48PA (I'm currently on) and STM8 (which looks even cheaper). However thank you for suggestion - I will take a closer look on 32-bit CPUs! But I still need the answer on the main question... – Roman Matveev Mar 24 '16 at 14:24
• Well, if price is a concern, take a look at Freescale (now NXP) MCUs, specifically, the KL03 family. They have some options around \$0.70 with similar performance/power/size characteristics. This is one of the cheapest: 0.50USD @ 100ct. – uint128_t Mar 24 '16 at 14:43