¿Cómo determinar una frecuencia de reloj razonable para una MCU?

Si su código no funciona, ya que la velocidad del reloj disminuye, suena como si estuviera manteniendo vivas todas las fuentes interrumpidas (interrupciones anidadas) cuando realiza el mantenimiento de una rutina interrumpida. Con todas las interrupciones habilitadas todo el tiempo, saltará de algún código y entrará en una interrupción de orden superior si se produce una, y solo regresará a una interrupción de orden inferior una vez que haya finalizado la orden más alta.

Esto puede llevar a problemas importantes de tiempo si las prioridades de interrupción no se administran adecuadamente, especialmente con puertos de comunicación como UART & TARJETA SD. Si se asume que las GPIO están conectadas al exterior de su caja, entonces las interrupciones de GPIO sucederán "a voluntad" en un registrador de datos y no se pueden predecir, por lo que es ventajoso mantener estas rutinas muy cortas.

Esto puede llevar a establecer una tasa de conmutación GPIO máxima para estos pines externos, por lo que su código seguirá siendo válido (máximo 100Hz en cualquier pin de entrada externo, y un máximo de 2 KHz en todas las entradas, por ejemplo).

Si desea reducir la corriente, entonces se ejecuta en modo activo a una velocidad de reloj más alta, modificando el código para que todas las rutinas sean activadas por eventos y entren en modo de espera o espera durante el resto del tiempo para reducir el suministro. corriente. Algunos microcontroladores tienen modos de espera de corriente extremadamente bajos en un 75% del modo activo (CPU apagada, periféricos encendidos), pero la mayoría solo reduce la corriente en un ~ 20-30% del modo activo.

Uno o dos micro vendedores pueden incluso mantener los periféricos funcionando en modo de sueño profundo con activación rápida, pero la mayoría de los microemprendedores normalmente apagan todos los periféricos en sueño profundo y solo permiten el GPIO, WDT, POR, BOR o un RTC para despertar un micro.

Siempre que no tenga que pasar mucho tiempo esperando en la CPU, el consumo total de carga (energía) por parte del núcleo de la CPU será una función del número total de instrucciones que necesita ejecutar, en lugar de la velocidad del reloj en Los cuales son ejecutados. La cantidad de energía gastada por un núcleo de CPU que está activo el 10% del tiempo a 24MHz a menudo será aproximadamente comparable a la de un núcleo de CPU que está activo el 20% del tiempo a 12Mhz.

Si el chip tiene un VDD interno programable, y solo puede operar a velocidades más altas con configuraciones de VDD más altas, el uso de esas configuraciones más altas probablemente aumentará el consumo de carga por instrucción independientemente de la velocidad a la que se ejecute la CPU esas instrucciones . Por lo tanto, aumentar la CPU más allá de un umbral que requiere un VDD más alto tendrá un efecto mucho mejor en el consumo de carga que hacerlo hasta un punto justo por debajo de dicho umbral.

Mi recomendación sería averiguar aproximadamente la velocidad que necesita, averiguar qué VDD y otras configuraciones necesitará, y configurar el reloj de la CPU para que sea lo más rápido posible dadas esas restricciones. Luego, una vez que hayas hecho eso, enfócate en hacer que la CPU esté inactiva la mayor cantidad de tiempo posible.

supercat es más o menos lo que hubiera sugerido, pero también revise su circuito en busca de otros consumidores que consuman corriente cuando no lo necesitan.

• Si hay circuitos integrados externos, vea si proporcionan un modo de apagado (un candidato es su UART: si tiene un cambiador de nivel, es posible apagarlo al menos parcialmente durante la suspensión).
• Divisores de tensión, pull-ups o pull-downs, comprobar cualquier cosa. Los componentes pasivos a menudo se ignoran porque "no hacen nada", pero sí dibujan corriente.

Siempre que tenga componentes externos, es probable que consuman más corriente que su microcontrolador incluso antes de que haya optimizado el voltaje, la frecuencia y el tiempo activo. Si esto es solo un prototipo, vea si puede rediseñarlo para optimizar el consumo de energía.

Con un ciclo de trabajo de 10:90 ciclos a 12MHz, entonces aproximadamente 1,2 MHz debe proporcionar un ciclo de trabajo del 100% sin margen de error. Elija un factor de seguridad dentro de su nivel de comodidad y multiplíquelo por 1.2MHz.

Si 10:90 es una estimación, podría aumentar un bit de salida cuando la MCU se active y volver a bajarla justo antes de que se apague. Luego puede encontrar el tiempo de ejecución con un alcance o un DVM que pueda medir la frecuencia y el ciclo de trabajo. Realice el ajuste anterior y mida nuevamente. Repita hasta que cumpla con su ciclo de trabajo, consumo de energía u otro objetivo.

Mi estrategia de elección cuando se trata de este tipo de aplicación, es hacer que el código sea controlado por eventos (o asíncrono) y no preocuparse demasiado por la frecuencia del reloj. Si maneja el sistema con interrupciones (por ejemplo, a través de temporizadores o periféricos), es posible que pueda reducir el nivel de energía de las MCU a algún tipo de configuración de hibernación como acción predeterminada y solo hacer otra cosa en caso de interrupciones. Varias de las MCU de Atmel tienen niveles de suspensión que habilitarán / deshabilitarán ciertas interrupciones para la activación. Las MCU de ARM Cortex serie M también tienen capacidades avanzadas de interrupción que van bien con el ahorro de energía.

Cuando la cola de eventos esté vacía, realice la acción predeterminada: vaya al modo de bajo consumo durante un tiempo. De esa manera, la frecuencia del reloj no es importante, ya que solo tienes energía y energía cuando tienes algo que hacer.