Extienda la batería de su circuito durmiendo su PIC

[Rajendra Bhatt] escribió para compartir lo último de una serie de tutoriales de PIC que cubren el modo de suspensión del microcontrolador, una herramienta muy útil para limitar el consumo de corriente en aplicaciones de batería.

Discute cómo poner el PIC en modo de suspensión, así como una serie de errores comunes a los que debe estar atento, como permitir accidentalmente que los pines de E / S se hundan o que salte corriente durante el sueño. [Rajendra] también pasa por las diversas formas en que se puede admitir PIC desde el modo de suspensión, y centra la mayor parte de su tutorial en el temporizador de vigilancia de la mcu.

Usando PIC16F628A, construye un circuito de prueba que le permite mostrar los ahorros de energía obtenidos usando el modo de suspensión en lugar de la función de retardo incorporada del microcontrolador. El circuito simplemente parpadea un LED cada 4,3 segundos, utilizando el temporizador de vigilancia durante los primeros 2,3 segundos y una llamada de retardo () durante el resto del tiempo.

Los ahorros de energía son bastante grandes, similares a los resultados que vimos con los microcontroladores AVR hace unas semanas. [Rajendra] descubrió que el uso de la función de reposo limitaba el consumo de corriente a aproximadamente el 4,5% del flujo utilizado cuando se llamaba a la función de retardo de la mcu: un gran ahorro.

  • KNfLrPn dice:

    Cabe señalar que el microcontrolador no tiene una función de retardo incorporada (hardware implícito). delay () se realiza en el software haciendo un gran bucle de NOP y deja el uC completamente operativo y activo; de ahí el mayor consumo de energía que el modo de suspensión.

    • cgimark dice:

      A veces es mejor usar los comandos inactivos del procesador en lugar de suspender la CPU. Es mucho más fácil de programar y las ganancias entre el procesamiento inactivo y a máxima velocidad son bastante significativas.

  • steve dice:

    Tengo un poco la impresión de que la gente de aquí da conferencias sin estar en primer lugar ...

    • ewertz dice:

      "Crecí en los 80 comenzando ... pero siempre asumí que alguien tenía que ser una especie de genio del lenguaje ensamblador para hacer eso".

      Querido, ¿estabas en coma la década en la que reinó BASICStamp?

      De todos modos ... ¡bienvenido!

      • XBMC ^ N dice:

        Sí, miré el sello básico en 2006, pero era mucho más caro, mucho menos flexible y mucho peor en cuanto a rendimiento que lo que estaba disponible para los PIC. Tampoco quería invertir dinero y tiempo en una plataforma que pronto crecería demasiado. No lo siento.

  • XBMC ^ N dice:

    No soy un ingeniero eléctrico, solo alguien que creció en los 80, usando el LOGOTIPO de Apple, luego el BASIC, luego Turbo Pascal y Turbo C ++. Me alejé un poco del pasatiempo antes de que la programación orientada a objetos (con razón) se convirtiera en la norma.

    Siempre he soñado con jugar con sistemas integrados, construir robots, domótica, etc., pero siempre asumí que alguien tenía que ser una especie de genio del lenguaje ensamblador para hacer eso. Cuando descubrí que hay un compilador para BASIC disponible para microcontroladores PIC (picbasic pro, http://melabs.com), decidí que valía la pena intentarlo.

    Compré un desarrollador de Pic barato (Pickit 2), pedí algunos componentes de digikey, descargué un montón de hojas de datos y manuales ... Y pasé mis vacaciones de verano tratando de descubrir cómo construir circuitos básicos, hacer que los LED parpadeen, etc.

    Mi segundo proyecto fue un reloj que se interconectaba con un panel LCD. Fue increíblemente satisfactorio, excepto que no sabía nada sobre la relativa inexactitud de los osciladores integrados, por lo que el reloj era muy inexacto (aumentaba o perdía de 10 a 15 minutos al día). Sin embargo, en última instancia, esto era cuestionable, ya que consumiría una batería de 9 V en menos de 4 horas. He recorrido un largo camino desde entonces.

    Estoy muy agradecido por publicaciones como esta; la mayoría de estas cosas son obvias para los ingenieros, pero para los aficionados medianos principiantes como yo, estos artículos son muy útiles.

    • cgimark dice:

      Aún mejor para ingresar fotos es un pez espada. Es un compilador básico gratuito y muy fácil de aprender y viene con bibliotecas para soportar todo el hardware.

      http://www.sfcompiler.co.uk/swordfish

  • Agent24 dice:

    Este es un artículo hermoso y útil.

    Pero aunque no tengo ninguna duda de que el PIC en modo de suspensión consumirá menos corriente, desconfío un poco de la precisión de las mediciones aquí.

    En todas las fotos el multímetro muestra el símbolo de advertencia de batería baja, y algunos medidores pueden dar errores bastante grandes con una batería 'descargada'.

    • vtl dice:

      Muy cierto, también el multímetro parece estar directamente en serie con la batería. Al medir cosas en el rango de uA, el valor de la resistencia de derivación es bastante alto y le da una caída de voltaje significativa llamada "voltaje de carga". Realmente debería tener el problema vinculado a un suministro variable para compensar la caída de voltaje, de lo contrario, sus medidas podrían ser inexactas.

  • Otacon2k dice:

    El autor usó una escala de 1: 128 en el temporizador de vigilancia para extender los 18 ms que el WDT tarda en rodar a aproximadamente 2,3 s (0,018 s * 128 = 2,304 s). Luego espera otros 2 segundos usando un bucle de retardo (desperdiciando energía en esos 2 segundos).
    4.3s / 0.018s = 238, ... rollos. ¿No sería absolutamente posible dejar que el perro guardián ruede cada 18 ms, aumentar el contador y verificar si es mayor (o igual a) 238, luego calcular el número de despertares en lugar del tiempo y luego pasar los últimos milisegundos usando un bucle de retardo?
    Teniendo en cuenta que el procesador también desperdicia energía durante el despertar, de lo contrario, ¿podría obtener un mejor bucle de suspensión / retardo usando otra preescala? Por ejemplo, usando una preescala de 64, el tiempo de cruce sería 0.018s * 64 = 1.152s. Deje que el procesador se despierte 2 veces sin hacer nada, quedándose dormido nuevamente. En la tercera tirada, se pasarán 3 * 1152 s = 3,456 s, por lo que solo quedan 4,3 s-3,456 s = 0,844 s para gastar en un bucle de retardo. Más de un segundo de bucles de retardo ahorrados a costa de 2 despertadores más. ¿Ahorra energía? Seguramente, lo asumiría.
    (Por cierto, todavía no me gustan los perros guardianes, solo como garantía. perro guardián-novato si quieres eso).

    • Noctolater dice:

      Creo que el propósito de esto era más mostrar cuánta energía se ahorra que implementarlo de la mejor manera. En su punto, ¿por qué no dormir al perro dos veces a los 2,3 segundos, lo que lleva a 4,6 segundos de tiempo de sueño? Dado que solo enciende un LED durante 0,5 segundos al final del ciclo, un retraso adicional de 0,3 segundos no es terrible. Pero, de nuevo, creo que fue solo para decir '¡mira cuánta energía puede ahorrar el modo de suspensión!'

  • RB dice:

    El autor usó Delay_ms (2000) para medir el consumo de corriente cuando el software retrasa el PIC para poder compararlo con el flujo del modo de suspensión (los primeros 2,3 segundos del intervalo total de 4,3 segundos).

  • tiu1ulo dice:

    En la universidad, una de las prácticas de laboratorio que hicimos en una clase de circuito fue construir un detector simple que se despertara en X segundos cuando colocaba una tarjeta de índice frente a él. De hecho, el desafío del laboratorio era ser el grupo que pudiera cumplir con todos los requisitos con el menor uso de energía (mayor duración de la batería). Fue un concurso entre unos 10 grupos y finalmente ganamos usando un PIC de baja potencia eliminando un simple divisor / seguidor de voltaje de 9V. Creo que aprendí más sobre el consumo de electricidad en ese laboratorio que cualquier otra cosa que hice en la universidad.

Joel Carrasco
Joel Carrasco

Deja una respuesta

Tu dirección de correo electrónico no será publicada.