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:
- What is the actual hardware latency of interrupt response for the STM8 CPUs (the value estimated as 7 cycles for AVR)?
- 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?