ATtiny consumo de energía con reloj prescaler

Estoy diseñando un dispositivo sensor conectado por radio alimentado por batería que requiere una larga vida útil. Debido a los requisitos del proyecto, tengo muy poca energía a bordo para trabajar; una sola celda tipo moneda es la fuente probable y el requisito de por vida es de al menos una semana.

Mis principales ahorros de energía provendrán de colocar el dispositivo en un modo de suspensión profunda y activarlo con un temporizador cada diez minutos más o menos para tomar una lectura y transmitirla. Esto significa que solo el 0,5% del tiempo el dispositivo consume una potencia significativa; durante el estado de suspensión, el consumo estará en unidades de microamperios como máximo.

El proceso propuesto es el siguiente:

  1. MCU está encendido.
  2. El MCU enciende el sensor y se otorga un tiempo de gracia de un segundo. La MCU se coloca en un estado de suspensión hasta que transcurre el período de gracia.
  3. La MCU se comunica con el dispositivo a través de I2C o SPI y obtiene una lectura.
  4. El sensor es apagado por la MCU.
  5. El MCU enciende el circuito del transmisor.
  6. La lectura se transmite.
  7. El MCU apaga los circuitos del transmisor.
  8. La MCU activa un dispositivo temporizador externo de baja potencia (rango nA) que está configurado para retrasar aproximadamente diez minutos.
  9. La MCU se pone en modo de apagado para ahorrar energía.
  10. El dispositivo de temporizador externo activa un pulso a un pin GPIO, lo que genera una interrupción de activación en la MCU y nos devuelve al paso 1.

El ATtiny44A tiene múltiples modos de reloj (sección 6.2): ​​un reloj interno calibrado de 8MHz, un reloj interno de baja precisión de 128kHz y soporte para fuentes de reloj y cristales externos. A continuación, se pueden reducir utilizando el preescalador de reloj (consulte la fig. 6-1 y la sección 6.3 para obtener una descripción). Estaré ejecutando la MCU a 3.3V.

Como los procesos realizados por la MCU no son particularmente críticos en cuanto al tiempo, estoy tratando de decidir cuál de las siguientes estrategias es más óptima para un bajo consumo de energía:

  • Utilice el reloj de 8 MHz calibrado interno tal como está, sin ajuste de escala previo, para minimizar el tiempo durante el cual se encenderá la MCU. Esto tiene la ventaja de acelerar los pocos cálculos que estoy haciendo en el chip y acelerar el IO con los dispositivos de sensor y transmisor. Sin embargo, una desventaja potencial es que otros relojes internos están funcionando a una frecuencia más alta y permanecerán funcionando durante el período de gracia de un segundo en el paso 2. Mi instinto dice que esta es una mala elección ya que cualquier energía ahorrada por un cálculo más rápido será empequeñecido por el segundo de funcionamiento del reloj en inactivo.
  • Utilice la fuente de reloj interna de baja precisión de 128 kHz. Esto aumenta el tiempo de cálculo y de E/S, pero puede ahorrar energía durante el período de gracia.
  • Utilice el reloj de 8 MHz calibrado interno con el preescalador configurado en 1/64, produciendo una velocidad de reloj de 125 kHz, emulando el reloj interno de baja precisión. No estoy seguro de si esta es una opción útil.
  • Utilice el reloj de 8 MHz calibrado interno con el preescalador configurado en 1/256 (el máximo), lo que produce una velocidad de reloj de 31,25 kHz. Nuevamente, no estoy seguro de si esto ahorrará energía.

¿Cuál de estos, en el escenario descrito anteriormente, resultará en el menor consumo de energía?

Esto depende de muchas cosas; voltaje de suministro, periféricos habilitados, chips externos (¿estos también están apagados?), etc. La única forma de obtener respuestas definitivas para esto es construir su circuito y medir el consumo de energía de los diversos enfoques. Véase también mi respuesta a una pregunta similar.
@marcelm Como señalé en mi pregunta, el voltaje de suministro es de 3,3 V y los circuitos integrados externos (aparte del circuito integrado del temporizador) se encienden solo durante el período de detección cada diez minutos.

Respuestas (2)

El capítulo 21 de la hoja de datos de ATtiny44 tiene mucha información sobre el consumo frente a la frecuencia y la tensión de alimentación.

Una mirada casual indica que la frecuencia de reloj más baja conducirá al consumo total más bajo.

La Tabla 21-2 contiene información sobre cuánto consumo adicional agrega de los distintos módulos según la frecuencia, lo que nuevamente indica que una velocidad más baja le dará un consumo neto más bajo.

Dependiendo de qué tan rápido necesite que se realice el cálculo, es posible que pueda salirse con la velocidad del reloj de 128 kHz.

No he examinado los módulos I2C y SPI en detalle, pero es posible que no funcionen correctamente a una frecuencia tan baja, por lo que podría considerar aumentar la velocidad antes de realizar cualquier comunicación con esos periféricos.

El ATtiny44A aparece como totalmente síncrono, por lo que sospecho que los módulos I2C y SPI deberían funcionar bien siempre que los periféricos sean lo suficientemente resistentes a los relojes lentos. Los valores típicos de consumo de energía en la tabla 21-1 son útiles ya que brindan algunos valores aproximados a 3V. Sin embargo, la sección 21.2 parece ideal; No había visto eso antes. 50uA parece típico para ~ 125 kHz, independientemente de si opto por el enfoque de preescala o el reloj sin procesar de 128 kHz.
Acabo de encontrar esto, el ATtiny es un poco diferente del ATmega en este aspecto: Capítulo 14.3.6 Consideraciones sobre la velocidad del reloj La frecuencia máxima para SCL y SCK es fCK / 2.

Hay algunas opciones que veo.

1) Ejecute el dispositivo con una configuración de preescala de reloj más rápida cuando esté activo y cambie a una preescala más baja antes de ir a dormir.

2) Si el chip tiene un registro de habilitación de energía para los periféricos, apague la habilitación de energía para esos periféricos cuando esté inactivo. No consumirán energía cuando estén deshabilitados.