Simplemente eche un vistazo por primera vez a la línea STM8 para comparar su rendimiento con el AVR, que es muy conocido para mí ahora.
Uno de mis grandes reclamos al AVR fue la reacción lenta a las interrupciones, especialmente en el código compilado en C. Para describir el problema, consulte el código C:
ISR(INT0_vect){
array_p = (array_p+1) & 0x0F;
array[array_p] = TCNT0;
}
Esto se compila en un ASM enorme:
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
Como puede ver, hay un montón de "extra" push es y pop s.
A este código ineficiente (en mi opinión) debería agregar 7 ciclos más de latencia central:
EsperoqueSTM8puedasermásrápidoporalgunasrazones:
- soportedehardwaredeinterrupcionesanidadasconprioridadprogramable,
- soportedehardware(consuerte)delacumulador,estado,conservaciónderegistrosXeY.
Enlahojadedatosdereferenciaencontréestaspalabras:
Así que, como puedo ver, esos empujes serán realizados por el hardware, por lo que se espera que sean más rápidos. Pero no hay información sobre la cantidad de ciclos que tomará.
Tampoco pude encontrar esta información en Internet.
Así que las preguntas son:
- ¿Cuál es la latencia real del hardware de la respuesta de interrupción para las CPU STM8 (el valor estimado como 7 ciclos para AVR)?
- ¿Cuál es la latencia típica del código C? Más agudamente: ¿puedo esperar que el código compilado de STM8 C sea más eficiente que el AVR en este momento?