Obtener un rendimiento rápido de una MCU STM32

La pregunta aquí realmente es: ¿cuál es el código de máquina que está generando a partir del programa C y en qué se diferencia de lo que esperaría?

Si no tuvieras acceso al código original, esto habría sido un ejercicio de ingeniería inversa (básicamente algo que comenzara con: radare2 -A arm image.bin; aaa; VV), pero tienes el código, así que esto lo hace todo más fácil.

Primero, compílelo con la -gbandera agregada a CFLAGS(mismo lugar donde también especifica -O1). Luego, mire el ensamblado generado:

arm-none-eabi-objdump -S yourprog.elf

Tenga en cuenta que, por supuesto, tanto el nombre del objdumpbinario como el archivo ELF intermedio pueden ser diferentes.

Por lo general, también puede omitir la parte en la que GCC invoca al ensamblador y simplemente mirar el archivo de ensamblaje. Simplemente agregue -Sa la línea de comandos de GCC, pero eso normalmente romperá su compilación, por lo que probablemente lo haga fuera de su IDE.

Hice el ensamblaje de una versión ligeramente parcheada de su código :

arm-none-eabi-gcc 
    -O1 ## your optimization level
    -S  ## stop after generating assembly, i.e. don't run `as`
    -I/path/to/CMSIS/ST/STM32F3xx/ -I/path/to/CMSIS/include
     test.c

y obtuve lo siguiente (extracto, código completo en el enlace de arriba):

.L5:
    ldr r2, [r3, #24]
    orr r2, r2, #1024
    str r2, [r3, #24]
    ldr r2, [r3, #40]
    orr r2, r2, #1024
    str r2, [r3, #40]
    b   .L5

Que es un bucle (observe el salto incondicional a .L5 al final y la etiqueta .L5 al principio).

Lo que vemos aquí es que nosotros

• primero ldr(registro de carga) el registro r2con el valor en la ubicación de memoria almacenada en r3+ 24 Bytes. Ser demasiado perezoso para buscar eso: muy probablemente la ubicación de BSRR.
• Luego, ORel r2registro con la constante 1024 == (1<<10), que correspondería a establecer el bit 10 en ese registro, y escribir el resultado en r2sí mismo.
• Luego str(almacene) el resultado en la ubicación de memoria que hemos leído en el primer paso
• y luego repita lo mismo para una ubicación de memoria diferente, por pereza: muy probablemente BRRla dirección de .
• Finalmente b(rama) de vuelta al primer paso.

Así que tenemos 7 instrucciones, no tres, para empezar. Solo bsucede una vez y, por lo tanto, es muy probable que esté tomando un número impar de ciclos (tenemos 13 en total, por lo que en algún lugar debe provenir un recuento impar de ciclos). Dado que todos los números impares por debajo de 13 son 1, 3, 5, 7, 9, 11, y podemos descartar cualquier número mayor que 13-6 (suponiendo que la CPU no puede ejecutar una instrucción en menos de un ciclo), sabemos que btoma 1, 3, 5 o 7 ciclos de CPU.

Siendo quienes somos, miré la documentación de instrucciones de ARM y cuántos ciclos toman para el M3:

• ldrtoma 2 ciclos (en la mayoría de los casos)
• orrtoma 1 ciclo
• strtoma 2 ciclos
• blleva de 2 a 4 ciclos. Sabemos que debe ser un número impar, por lo que debe tomar 3, aquí.

Todo eso se alinea con tu observación:

$$\begin{align} 13 &= 2\cdot(&c_\mathtt{ldr}&+c_\mathtt{orr}&+c_\mathtt{str})&+c_\mathtt{b}\\ &= 2\cdot(&2&+1&+2)&+3\\ &= 2\cdot &5 &&&+3 \end{align}$$

---

Como muestra el cálculo anterior, difícilmente habrá una manera de hacer que su ciclo sea más rápido: los pines de salida en los procesadores ARM generalmente están asignados a la memoria , no a los registros del núcleo de la CPU, por lo que debe pasar por la rutina habitual de carga, modificación y almacenamiento si quieres hacer cualquier cosa con esos.

Por supuesto, lo que podría hacer es no leer ( |=implícitamente tiene que leer) el valor del pin en cada iteración del bucle, sino simplemente escribirle el valor de una variable local, que simplemente cambia en cada iteración del bucle.

Tenga en cuenta que creo que podría estar familiarizado con los micros de 8 bits y que intentaría leer solo valores de 8 bits, almacenarlos en variables locales de 8 bits y escribirlos en fragmentos de 8 bits. No. ARM es una arquitectura de 32 bits, y extraer 8 bits de una palabra de 32 bits puede requerir instrucciones adicionales. Si puede, simplemente lea la palabra completa de 32 bits, modifique lo que necesite y vuelva a escribirlo completo. Si eso es posible, por supuesto, depende de lo que esté escribiendo, es decir, el diseño y la funcionalidad de su GPIO mapeado en memoria. Consulte la hoja de datos/guía del usuario de STM32F3 para obtener información sobre lo que se almacena en los 32 bits que contienen el bit que desea alternar.

---

Ahora, traté de reproducir su problema con el período "bajo" cada vez más largo, pero simplemente no pude: el bucle se ve exactamente igual -O3que -O1con mi versión del compilador. ¡Tendrás que hacerlo tú mismo! Tal vez esté utilizando alguna versión antigua de GCC con soporte ARM subóptimo.

Los registros BSRRy BRRson para establecer y restablecer bits de puerto individuales:

Registro de establecimiento/reinicio de bit de puerto GPIO (GPIOx_BSRR)

...

(x = A..H) Bits 15:0

BSy: Puerto x establece bit y (y= 0..15)

Estos bits son de solo escritura. Una lectura de estos bits devuelve el valor 0x0000.

0: ninguna acción en el bit ODRx correspondiente

1: establece el bit ODRx correspondiente

Como puede ver, la lectura de estos registros siempre da 0, por lo que su código

GPIOE->BSRRL |= GPIO_BSRR_BS_10;
GPIOE->BRR |= GPIO_BRR_BR_10;

efectivamente es GPIOE->BRR = 0 | GPIO_BRR_BR_10, pero el optimizador no lo sabe, por lo que genera una secuencia de LDRinstrucciones en lugar ORRde STRuna sola tienda.

Puede evitar la costosa operación de lectura, modificación y escritura simplemente escribiendo

GPIOE->BSRRL = GPIO_BSRR_BS_10;
GPIOE->BRR = GPIO_BRR_BR_10;

Puede obtener alguna mejora adicional al alinear el bucle con una dirección divisible por 8. Intente poner asm("nop");las instrucciones de uno o modo antes del while(1)bucle.

Para agregar a lo que se ha dicho aquí: ciertamente con Cortex-M, pero prácticamente con cualquier procesador (con canalización, caché, predicción de bifurcación u otras características), es trivial tomar incluso el ciclo más simple:

top:
   subs r0,#1
   bne top

Ejecútalo tantos millones de veces como quieras, pero haz que el rendimiento de ese ciclo varíe ampliamente, solo esas dos instrucciones, agrega algunos nops en el medio si lo deseas; no importa.

Cambiar la alineación del ciclo puede variar drásticamente el rendimiento, especialmente con un ciclo pequeño como ese, si toma dos líneas de búsqueda en lugar de una, se come ese costo adicional, en un microcontrolador como este, donde el flash es 2 más lento que la CPU. o 3 y luego, al aumentar el reloj, la relación se vuelve aún peor 3 o 4 o 5 que agregar búsqueda adicional.

Es probable que no tenga un caché, pero si lo tuviera, ayuda en algunos casos, pero duele en otros y/o no hace la diferencia. La predicción de bifurcación que puede o no tener aquí (probablemente no) solo puede ver hasta donde está diseñada en la tubería, por lo que incluso si cambió el ciclo para ramificarse y tuvo una bifurcación incondicional al final (más fácil para un predictor de bifurcación use) todo lo que hace es ahorrarle muchos relojes (el tamaño de la tubería desde donde normalmente buscaría hasta qué tan profundo puede ver el predictor) en la próxima búsqueda y/o no hace una búsqueda previa por si acaso.

Al cambiar la alineación con respecto a las líneas de búsqueda y caché, puede afectar si el predictor de bifurcación lo está ayudando o no, y eso se puede ver en el rendimiento general, incluso si solo está probando dos instrucciones o esos dos con algunos nops .

Es algo trivial hacer esto, y una vez que comprenda eso, luego tomando el código compilado, o incluso el ensamblado escrito a mano, puede ver que su rendimiento puede variar ampliamente debido a estos factores, agregando o ahorrando algunos hasta un par de cientos por ciento, una línea de código C, un nop mal colocado.

Después de aprender a usar el registro BSRR, intente ejecutar su código desde RAM (copiar y saltar) en lugar de flash, lo que debería brindarle un aumento instantáneo de rendimiento de 2 a 3 veces en la ejecución sin hacer nada más.

¿Se espera este comportamiento de este MCU?

Es un comportamiento de su código.

1. Debe escribir en los registros BRR/BSRR, no leer-modificar-escribir como lo hace ahora.

2. También incurre en una sobrecarga de bucle. Para obtener el máximo rendimiento, replique las operaciones de BRR/BSRR una y otra vez → cópielas y péguelas en el ciclo varias veces para pasar por muchos ciclos de configuración/reinicio antes de que un ciclo se sobrecargue.

editar: algunas pruebas rápidas bajo IAR.

un salto a través de la escritura a BRR/BSRR requiere 6 instrucciones con una optimización moderada y 3 instrucciones con el nivel más alto de optimización; hojear RMW'ng toma 10 instrucciones / 6 instrucciones.

extra de sobrecarga de bucle.