Tiempo de ejecución de STM32

Estoy trabajando con una placa de descubrimiento STM32F4 y quiero calcular cuánto tiempo lleva realizar algunas tareas. Estoy usando Atollic con un depurador SW4STM32. No puedo averiguar cómo hacerlo.

He leído algo sobre enviar mensajes a la consola y luego medir ese tiempo, pero no sé cómo enviar mensajes a la consola. ¿Me puedes ayudar? ¡Gracias!

Usualmente uso un osciloscopio, pero la unidad DWT en el núcleo de Cortex es excelente para esto: Embeddedb.blogspot.com/2013/10/… ... A menudo lo uso para registrar los tiempos de ejecución máximos y mínimos de mi ciclo principal cuando hago mi análisis de tiempo de firmware. También es útil para crear esos horribles retrasos fijos que a menudo se usan en exceso.
Estás preguntando dos cosas diferentes. ¿Con qué parte realmente necesitas ayuda? ¿Midiendo el tiempo o imprimiendo a la consola?
pruebe el systick o el dwt timer, evite las bibliotecas hal al realizar la medición, ya que agregan incógnitas a la medición. Use nops en el arranque para ajustar la alineación de búsqueda y acercarse a un mínimo/máximo en el tiempo. Pruebe ram vs rom si necesita más rendimiento, la rom es a menudo el primer cuello de botella para el rendimiento, con un STM32, aunque tienen almacenamiento en caché que no puede desactivar (con algún término de marketing) que hace que la rom parezca ser más rápida de lo que es. recomendaría probar en ram, luego degradar ese número por algún factor y luego ejecutar en rom.
el rendimiento no es necesariamente lineal en estos dispositivos, particularmente si usa un HAL, pruebe la configuración de frecuencia de su candidato, si cambia, vuelva a probar.
como el temporizador, si usa un alcance en un gpio, usar HAL para configurar el gpio está bien (aunque es mucho más fácil no hacerlo), pero la tienda para cambiar el estado de gpio no desea usar un hal para reducir cuánto afecta el rendimiento.

Respuestas (3)

Además de otras respuestas, puede usar un osciloscopio si tiene uno.

Al comienzo de su tarea, configure un pin no utilizado (o un LED, etc.) alto. Luego configúrelo bajo directamente después de que se complete la tarea. El o-scope puede mostrarle la duración.

Tenga en cuenta que si accede a las funciones pin a través de HAL o a través de una función, tendrá algunos relojes fuera de lugar para todas las instrucciones que deben suceder saltando dentro y fuera de la función. (Si eso tiene algún sentido)
¡Muy cierto, @laptop2d! No sé si está contando nanosegundos o milisegundos :) O segundos completos, supongo...
¡Es una buena idea! Solo quiero saber cuanto tiempo se tarda en hacer algun proceso. Creo que la idea más simple es configurar un temporizador en 0, ejecutar el proceso y luego leer el valor de mi temporizador. ¡Gracias por su consejo!

1) Use el generador de perfiles incluido con su compilador (si tiene uno)
2) Use uno de los temporizadores, inicie el temporizador justo antes y después del código que desea cronometrar.
3) Mire el código ensamblador y comience a contar los ciclos de reloj buscándolos en el manual de programación y encontrando cuántos ciclos de reloj se utilizarán, obtenga el número total de ciclos de reloj y multiplíquelo por la frecuencia central.

Tenga cuidado con el ciclo del reloj que cuenta con chips de corteza. Debe verificar los estados de espera en sus autobuses y, en algunas situaciones, las paradas en la canalización de instrucciones. Aunque se puede hacer.
El conteo no funciona, ya que las instrucciones están en la cola y se encuentran en diferentes etapas de decodificación/ejecución.
@PeterJ Si la ruta del código tiene ramas o instrucciones que toman varios ciclos de reloj, tendrá que tenerlo en cuenta.
@laptop2d hay más a tener en cuenta: cualquier evento activado (como una interrupción) vaciará el caché, etc., etc. ¡El conteo de ciclos de reloj no funciona en dispositivos ARM!
Así que apague las interrupciones en la sección que está contando y déjelas así.
es trivial demostrar que las instrucciones de conteo no funcionan. obtener alineación, almacenamiento en caché, cargar/almacenar frente a no cargar/almacenar, ram frente a rom, etc. Tomando el mismo segmento de código de máquina, puede ver que se ejecuta a diferentes velocidades en la misma CPU, sin interrupciones u otras interferencias similares, esas solo hacerlo menos consistente.
temporizadores internos, no necesita el dwt, el sysstick está bien u otros, y usar un alcance si tiene uno y un gpio puede ayudar, pero al mismo tiempo afecta el rendimiento midiendo el rendimiento.
Sí, un osciloscopio es una referencia de tiempo externa, tiene que degradar el rendimiento por la precisión del cristal, o probar muchas partes y encontrar la peor, etc. Una vez que obtiene una medida en unidades de relojes, aún tiene que ajustar en función de la precisión de la referencia del reloj a la hora del reloj de pared.

Por lo general, alterno un pin y mido el tiempo usando un osciloscopio. Este es el método menos propenso a errores. Si desea hacerlo en código, le sugiero que use el temporizador systick configurado con una precisión de microsegundos (SystemCoreClock / 1000000). Sin embargo, esto siempre tiene una deriva dependiendo de la precisión del cristal principal, por lo que es posible que desee usar rtc para contar exactamente cuántos ciclos obtiene en 1s y luego escalar sus resultados en consecuencia.

el temporizador del sysstick se desplaza o no funciona con el mismo reloj que la CPU central, por lo que es el más preciso (el DWT es solo otro temporizador en el mismo reloj, por lo que también puede funcionar). De acuerdo, si hay otros dominios de reloj en otras referencias de reloj, entonces debe lidiar con eso.
El temporizador de marca del sistema es tan preciso como su cristal LSE, que puede desviarse de las especificaciones en varios %. Puede tener fácilmente escenarios en los que obtiene 1100000us en un segundo. Por lo tanto, debe compensar absolutamente esta imprecisión escalando el contador de microsegundos a la cantidad de microsegundos medidos en un segundo de acuerdo con el periférico del reloj en tiempo real que funciona con el cristal de 32768 khz que está diseñado específicamente para ser preciso, pero no le brinda una precisión de microsegundos. .
la cpu no puede ejecutar más instrucciones porque el reloj es lento. la deriva en el reloj no es relevante para los ciclos de reloj necesarios para realizar una tarea específica (todos los demás factores se mantienen constantes). Entonces, el tiempo del reloj de pared solo mide los matices de un chip, no el tiempo que se tarda en hacer algo. Más tarde, una vez que optimice la cantidad de instrucciones, puede compensar el jitter en el reloj o la precisión del cristal. dependiendo del reloj puedes tener variaciones durante el transcurso de un día o una hora que no verá ciclos por tarea.
interno y externo al mismo tiempo está bien, pero no descuides lo interno. Desafortunadamente, las malas mediciones son muy comunes en cualquier método de medición y conducen a malas suposiciones y experimentos.
un rtc es tan preciso como el reloj que usa, no se puede decir genéricamente que un RTC es más preciso que un temporizador mcus, ya que ambos son simplemente temporizadores tontos que se desconectan de un reloj. tenga en cuenta que algunos mcus (STM32 y otros) tienen RTC, por lo que puede confundir el OP si usan un HAL y el RTC interno, es posible que no estén mejor dependiendo de los relojes. si tienen conectado el cristal más preciso, a veces pueden simplemente usarlo sin el trabajo adicional para usar el rtc. básicamente, un rtc no es automáticamente más preciso que un osciloscopio u otra medida.
Tiempo de ejecución de STM32
RespuestasAquíPolítica de privacidad1y, 7v