Medición del rendimiento del firmware

Estoy usando el compilador C y los controladores PIC. Me he estado preguntando acerca de cómo medir el rendimiento del código f/w que escribimos. Tengo dos versiones de estructuras para el mismo código:

Primero : usandowhile

main()
  {..
   .. 
  initialization;

  while(check for conditions)
  {...
  ..
  .
  }

}

Segundo : Uso de estados secuenciales, o máquinas de estado.

main()
    {..
     .. 
    initialization;

    switch(state n)
    {...
    ..
    .
     }

    }

Bueno, mi duda es que si lo hago de cualquier manera, ¿cómo mediré cuál es la mejor manera de avanzar? Me di cuenta de que la función de sondeo del primer método se usa a menudo en sistemas integrados simples. Mientras que las máquinas de estado del segundo se utilizan principalmente para sistemas integrados de un solo procesador.

  • ¿Cómo puedo medir qué firmware es mejor?
  • ¿Cómo puedo monitorear las estadísticas y los datos de rendimiento relacionados?
  • ¿El compilador produce datos valiosos para verificar, o son los depuradores los que debo confiar?
  • ¿Cuáles son las herramientas comunes disponibles para medir el rendimiento de un firmware?
  • ¿Es posible con un depurador como Pickit3 /ICD3? Tengo un pickkit3 a mano.

Estaré sumamente agradecido si comparte su conocimiento sobre el manejo de firmwares y aclara mi duda.

¿Por qué no compilar ambos y comparar el desmontaje?
¿Qué detalles obtengo del desmontaje? Nunca lo he hecho antes.
Obtiene las instrucciones exactas que se convertirán a código de máquina. En otras palabras, las instrucciones exactas que ejecutará el núcleo.
Y si está utilizando la versión gratuita del compilador XC8, realmente no importará porque insertará 3 o 4 instrucciones de bifurcación entre cada instrucción real.
Definición de "rendimiento". No estoy siendo tímido. Necesitas saber lo que estás midiendo antes de poder comparar algo.

Respuestas (5)

Si usa MPLAB, simplemente simule con la función "Cronómetro".

Puede insertar puntos de interrupción y perfilar el código, con precisión para el ciclo. muy útil

Por supuesto, puede mirar el Indicador de uso de memoria y ver el tamaño del código cuando se compila.

También es útil mirar el código desensamblado, como han sugerido otros, especialmente en ISR estrechos.

ingrese la descripción de la imagen aquí

En términos de rendimiento de velocidad, recomendaría encarecidamente utilizar el rey indiscutible de la evaluación comparativa de firmware: el osciloscopio. Realmente no puedes ser un desarrollador de firmware profesional sin tener acceso a uno.

La pelusa de medición de rendimiento de su IDE o enlazador puede ser útil, pero al final aún tendrá que probar y verificar su tiempo en el mundo real, fuera del IDE.

¿Cuál es su medida de "rendimiento" - tasa de votación? latencia algo mas? Si el rendimiento significa sondeos por segundo, es decir, simplemente quiere el bucle más rápido posible, puede alternar un bit de salida y medir su frecuencia con un osciloscopio o un medidor de mano que pueda medir la frecuencia.

Hago esto a menudo; es una muy buena tecnica

¿Qué detalles obtengo del desmontaje? Nunca lo he hecho antes.

¿El compilador produce datos valiosos para verificar, o son los depuradores los que debo confiar?

Deberá familiarizarse con el lenguaje de máquina de su PIC en particular si desea comenzar a incursionar en la optimización. Muy a menudo, verá algún código que parece bastante inocente en C, pero en términos de cuántas instrucciones de lenguaje de máquina necesita, bueno...

El ejemplo canónico del poder del compilador PIC24 XC16:

_LATA0 ^= 1;            // toggle a bit

se convierte en esto en lenguaje de máquina:

mov.b _LATA,W0
and.b W0,#1,W0
btg W0,#0
and.b W0,#1,W0
and.b W0,#1,W2
mov.w #0x02c4,W1
mov.b [W1],W1
mov.b #0xfe,W0
and.b W1,W0,W0
ior.b W0,W2,W0
mov.b W0,0x02c4

a pesar de que hay una instrucción de lenguaje de máquina de alternancia de bits btg . ¿Por qué pasó esto? Los compiladores de C a menudo no aprovechan el hardware especial en sus micros de destino a menos que los autores del compilador apunten específicamente a ese hardware.

Su primer paso en la optimización (antes de medir) debe ser una exploración rápida del desmontaje. Vea qué instrucciones C se traducen a la mayor cantidad de instrucciones en lenguaje de máquina. Pruebe diferentes enfoques del problema y vea cuál produce la menor cantidad de instrucciones. Rápidamente adquirirá algo de experiencia con los patrones de código que debe evitar y con los que debe mantenerse.

¿Cómo puedo medir qué firmware es mejor?

¿Cuáles son las herramientas comunes disponibles para medir el rendimiento de un firmware?

¿Es posible con un depurador como Pickit3 /ICD3? Tengo un pickkit3 a mano.

Como han dicho otros, las formas más fáciles son generalmente:

  • alternando físicamente algunas líneas de E/S y midiendo con un osciloscopio
  • mediante el uso de la herramienta de simulador y cronómetro disponible en MPLAB

Usted 'envuelve' su código de destino con los cambios de bits (o puntos de interrupción) y mide cuánto tiempo lleva la ejecución. Luego, si encuentra un problema de rendimiento, vuelva a su desensamblaje, descubra qué código está tardando mucho y refactorícelo, luego vuelva a probar.

+1 para alternar una línea IO y medir con alcance. ¡Ese método incluso me llevó a descubrir que la macro para alternar pines (PORTn ^= PINnBIT) era mucho más lenta que escribir PINnBIT en los registros PINnSET/PINnCLEAR!

Me gusta mirar en términos de si mi sistema puede hacer lo que necesita hacer en el tiempo que tiene. Alterno los bits en lugares críticos y me aseguro de tener suficiente espacio libre para realizar una tarea. En otros lugares, hago un uso liberal de las banderas, para asegurarme de que las cosas están en forma para una rutina cuando se llama, y ​​una vez en la rutina, saldré con un código de error si no es así.

En los sistemas integrados, lo bueno es definitivamente el enemigo de lo bueno en lo que respecta a la optimización. El mejor firmware es el firmware que A) funciona y B) hace lo que necesita que haga, mientras que C) sigue siendo comprensible y algo compatible. Optimizar más allá de eso puede ser una mala dirección de un recurso precioso.

Esto ciertamente es exagerar la situación, tal vez "hiperbólico" sea un buen término para ello. En el Capítulo 8 (Hacer más con menos) del gran libro de O'Reilly de Elicia White " Making Embedded Systems ", ella dice:

En última instancia, la optimización es un problema económico. Comienza con una cartera de activos asociados con su sistema... Su activo más líquido es el tiempo de desarrollo, así que piense en eso como dinero. Una vez que invierte (o asigna) (sic) estos activos a partes del sistema, pierde la oportunidad de usarlos en otros sistemas...

Al considerar diferentes estrategias de optimización, considere también el alto costo de oportunidad que implica invertir sus activos. Comprar futuros es casi siempre más barato que esperar hasta el último minuto y darse cuenta de que está seriamente endeudado y no tiene una forma fácil de recuperarse.

Por lo tanto, asegurarse de comenzar con suficiente sistema para hacer el trabajo es la mayor parte de la batalla, y si lo hace lo suficientemente bien, no necesitará exprimir el rendimiento de su sistema.

Medición del rendimiento del firmware
RespuestasAquíPolítica de privacidad1y, 0v