¿El consumo de energía del microcontrolador está directamente relacionado con su tiempo de operación?

Tengo que decidir una forma de medir la eficiencia de un algoritmo que se ejecuta en un microcontrolador/microprocesador.

Mi idea es que puedo usar el tiempo de ejecución del algoritmo para completar una determinada tarea como una medida indirecta de cómo se compara el consumo de energía de ese algoritmo con el consumo de energía de otro algoritmo. Sin embargo, esto solo tendría sentido si el tiempo de operación del microcontrolador estuviera directamente relacionado con su consumo de energía. ¿Es cierta esta suposición?

El microcontrolador funciona exactamente en las mismas condiciones con cada algoritmo, los mismos periféricos, etc.

Yo pensaría: obviamente no. Digamos que el algoritmo tarda 2 ms en ciclos de reloj y un periférico genera una interrupción cada 5 ms. Luego, en un momento el algoritmo no se interrumpe y finaliza en 2 ms, en otro momento el algoritmo es interrumpido por el periférico y finaliza en 3 ms.
Estoy totalmente de acuerdo contigo @Huisma. Pero imagina que solo nos preocupa el tiempo de ejecución del algoritmo en un entorno de prueba controlado, sin interrupciones externas ni variables no controladas que actúen sobre el microcontrolador. ¿Sería entonces una opción viable la suposición de que el tiempo de operación es proporcional al consumo/eficiencia de energía?

Respuestas (2)

Hay muchas cosas que alteran el consumo de energía del dispositivo, pero suponiendo que solo esté calculando un algoritmo con todos los periféricos no utilizados apagados, por ejemplo, ADC (corriente pulsante en cada muestra), GPIO (cambiar de estado consume una pequeña cantidad de corriente), circuito de vigilancia deshabilitado (ejecuta un reloj y activa una interrupción),

Entonces, sí, cuanto más tarde algo en computarse, más energía habrá consumido, existe un equilibrio entre la velocidad del reloj y el consumo total de energía (para la mayoría de los dispositivos que funcionan a la velocidad de reloj más alta durante el menor tiempo, se usa menos energía que un reloj más lento). durante más tiempo), sin embargo, nuevamente suponiendo que todo permanece igual, más tiempo = más potencia

Si desea comenzar a incluir otros periféricos, hacia la parte inferior de la hoja de datos de su dispositivo, encontrará un gráfico tras otro que describen cuál es el consumo de energía para su caso de uso particular y varias otras relaciones, por ejemplo, si tiene el pin pullup si lo deja encendido, cuánto tiempo cambia ese pin bajo aumenta el consumo, si está conduciendo algo más en la señal, consumirá algo en los estados alto y bajo, si está usando ADC, entonces los búferes de entrada tendrán un consumo de corriente no lineal dependiendo en el voltaje de entrada. (usualmente los deshabilitarías)

¿Importaría el tipo de instrucciones? P.ej. si la multiplicación usa más potencia que la suma, puede ser beneficioso tres sumas en lugar de una multiplicación por 3, la primera aumentando el tiempo de operación
Por lo general, el consumo de energía de la ALU es consistente por reloj, como multiplicar y agregar funciones de hardware de un solo ciclo, probablemente no haya mucho que ahorrar allí, escalando sus divisiones para que se multipliquen por alguna constante y luego se dividan por potencia de 2 latas ahorre una gran cantidad de ciclos de reloj si la división no está implementada en el hardware, igualmente usando los tamaños y tipos de datos correctos probablemente le ahorrará ciclos de reloj, por ejemplo, un micro de 16 bits toma 2 ciclos para cambiar dentro o fuera de un valor de 32 bits.
Otras cosas pueden ser mirar el ensamblaje subyacente, las bibliotecas matemáticas y el compilador pueden no brindarle la mejor implementación para una tarea especializada,
Otras cosas, si su interés es que la mayoría de los microcontroladores tienen algunos registros de hardware de repuesto a los que puede acceder y realizar operaciones con instrucciones más cortas que si se colocaran en la RAM (dirección de 8 bits frente a una dirección de 16 bits una vez pasados ​​los primeros 256 bytes en el mapa de memoria) , ya que cada 2 bytes leídos del código del programa en un micro de 16 bits también es un ciclo de reloj. combine esto con el conocimiento de la notación de pulido inverso (configurando las matemáticas para que los valores nunca tengan que salir de la ALU) y puede eliminar algunos ciclos adicionales
Sin embargo, las optimizaciones de las que habla aquí deben ser realizadas por el compilador, asumiendo que se usa un lenguaje de nivel superior como C.
No siempre, y si quiere que las cosas sean lo más rápido posible, no está de más mirar lo que se le ocurrió al compilador, a veces funciona con suposiciones diferentes a las suyas. por ejemplo, 16 bits * 16 bits deben = resultado de 32 bits, si no conoce los límites, pero si sabe que nunca los excederá, entonces solo tomar el resultado de 16 bits puede ser más rápido.
@Reroute Multiply con frecuencia no es una función de un solo ciclo, dependiendo de qué tan avanzado sea el procesador en cuestión.

¿El consumo de energía del microcontrolador está directamente relacionado con su tiempo de operación?

Un poco. Lo que atrae más corriente es el reloj de la CPU y cualquier periférico de hardware activo como GPIO. Los periféricos de hardware son una historia propia, ya que cada uno tiene características únicas de consumo de energía.

Por supuesto, existe una relación directa entre los ciclos de reloj de la CPU necesarios y la longitud del código de máquina ejecutado, por lo que también existe una relación entre los ciclos de reloj de la CPU y el consumo de corriente.

Esto dado que utiliza los modos de suspensión cuando no está ejecutando ningún código, o de lo contrario, no tiene sentido hablar del consumo actual del algoritmo.

La eficiencia del algoritmo, la "eficiencia del código" de la CPU y el consumo de corriente del hardware por marca juegan un papel importante. La eficiencia del código en este caso significa cuántos tics de CPU se necesitan para ejecutar una determinada pieza de código de programa de capa superior (código C, etc.).

Por ejemplo, algunas personas argumentan que las MCU de 8 bits aún deberían usarse porque consumen menos corriente que las de 32 bits. Esto tiende a ser cierto si observa el consumo máximo de corriente, pero no necesariamente si observa el consumo actual a lo largo del tiempo.

my_uint32 = u32a + u32b;Tome algo como el código C. La CPU promedio de 32 bits ejecutará esa línea en unas pocas instrucciones del ensamblador, lo que quizás signifique alrededor de 10-20 tics de CPU. Sin embargo, una MCU de 8 bits necesitará cientos de instrucciones de ensamblador en forma de bibliotecas de software para ejecutar el mismo código. Tal vez 500-1000 tics de CPU, contados de manera muy aproximada. Por lo tanto, podría tomar el 8 amargo tanto como alrededor de 100 veces más velocidad de ejecución/consumo de corriente para ejecutar el mismo código. Y luego, de repente, es irrelevante que la MCU consuma menos corriente por tic en comparación con los 32 amargos.