Hola, descubrimos la solución a tu pregunta, has scroll y la verás aquí.
Solución:
¿Por qué esto parece estar bien en un microcontrolador, pero generalmente no se desea en un microprocesador?
Tampoco es deseado en un microcontrolador por la misma razón: desperdicia energía.
¿Estoy en lo cierto al pensar que el ATmega está funcionando al 100%?
Correcto.
¿Y que debido a que tiene tan poca potencia no causa ningún problema de calor obvio?
Correcto. Sin embargo, si ejecuta su microcontrolador en pilas, entonces tienes que pensar seriamente en no desperdiciar poder. En una CPU pequeña como AtMega328P no causará problemas de calor, pero definitivamente acortará la vida útil de la batería.
Todas las CPU, ya sean potencias de escritorio o pequeños microcontroladores, utilizan los mismos métodos:
1- Reducir la velocidad o el voltaje del reloj.
2- Apague el hardware innecesario.
3- Vaya a dormir y despierte en un evento (este es un caso especial de apagar hardware innecesario, en este caso la CPU se apaga).
En el AtMega328P también puede implementar esto. Puede usar un reloj más lento si no necesita toda la increíble potencia del núcleo de 8 bits, puede apagar los periféricos innecesarios … y lo más importante es el modo de suspensión.
Debe leer el manual para obtener más detalles, ya que hay varios modos de suspensión que difieren en las latencias de activación, qué periféricos permanecen en línea y pueden activar la CPU, si los datos de RAM se conservan o se pierden, etc. Pero básicamente la idea es: cuándo en modo de suspensión, la CPU se detiene, por lo que consume mucha menos energía. Cuando ocurre una interrupción, esto despierta la CPU y procesa la interrupción.
Por supuesto, debe usar el modo de suspensión adecuado y configurarlo correctamente para que el periférico que necesita reactivar la CPU (por ejemplo, un temporizador o una interrupción GPIO) no se apague. Si todo está apagado, tendrá que usar NMI o incluso Reset para reactivarlo, en este último caso reiniciándolo.
Si todo lo que hace su aplicación es esperar las interrupciones, como:
-
Interrupción de cambio de clavija (PCI) para detectar la pulsación de un botón o una señal entrante
-
Temporizador
-
Datos recibidos por UART o USB
-
etc
Entonces no es necesario girar el bucle principal. Después de configurar todo en el arranque, iniciaría el ciclo principal con una instrucción “ir a dormir”. La siguiente instrucción se ejecutará después de que la CPU se active, procese todas las interrupciones pendientes y regrese al bucle principal. Luego, el bucle principal puede, si es necesario, hacer algo con los eventos recibidos, si no fueron manejados por completo por el código de interrupción … y luego volver a dormir.
Incluso si no está usando baterías, tener una corriente de espera baja puede hacer que una red eléctrica alimente la fuente de alimentación conmutada para omitir ciclos y desperdiciar mucha menos energía también.
En un microcontrolador (más específicamente, en una placa Arduino Uno que usa el microcontrolador ATmega 328P) normalmente usaría un bucle infinito para verificar las entradas, etc. (en la tierra de Arduino, esta es normalmente la función loop ()). Sin embargo, si dejo esta función en blanco, no causa ningún problema.
Patrón de programación clásico, que tiene un bucle principal …
En una computadora de escritorio / computadora portátil con una CPU Intel i7, etc., si ejecutaba un bucle infinito similar (sin nada que hacer o muy poco que hacer), fijaría la CPU en ~ 100% y generalmente haría girar los ventiladores, etc. (un retraso podría agregarse para evitar esto, por ejemplo).
… podríamos estar escribiendo diferentes bucles principales.
Este mismo bucle principal también sería una mala práctica en un microcontrolador, porque eso también ejecuta la CPU a plena carga, lo que consume energía. No hagas eso, especialmente si tienes batería.
Los núcleos de CPU modernos tienen mecanismos de sincronización. Eso permite a las personas implementar algo como “dejar que la ejecución de este bucle duerma hasta que haya pasado 1 ms, o hasta que esta condición haya cambiado”.
Eso es básicamente el núcleo de cualquier sistema operativo multitarea, y básicamente todos los sistemas operativos que merecen ese nombre ya lo están. En los microcontroladores, a menudo encontrará los llamados RTOS (sistemas operativos en tiempo real), que garantizan qué tan seguro puede estar de que la ejecución de algo ha comenzado después de tantos nanosegundos, porque eso es típico del caso de uso. de microcontroladores, mientras que en equipos de escritorio y CPU de servidor normalmente encontrará SO de multiprocesamiento simultáneo completo que ofrecen menos garantías de sincronización, pero ofrecen un conjunto mucho mayor de funcionalidades y abstracción del entorno de hardware y software.
No conozco el entorno de ejecución de Arduino lo suficientemente bien como para hacer declaraciones calificadas al respecto, estoy investigando esto mientras escribo: Arduino parece no estar diseñado para esto, realmente espera que gire muy ocupado. Dado que no tiene la función de “rendimiento”, la “limpieza” que hace entre llamadas a su loop no puede ser llamado cuando usa el incorporado delay función. ¡Puaj! Mal diseño.
Lo que harías en un diseño de potencia y / o latencia, usarías un RTOS para tu microcontrolador: FreeRTOS es bastante popular, para la serie ARM Cortex-M, mbed tiene mucha tracción, personalmente me gusta ChibiOS (pero no creo que sea una buena opción cuando se cambia de bocetos de Arduino), la Fundación Linux está presionando a Zephyr (por lo que estoy en conflicto); Realmente, hay una gran cantidad de opciones y el fabricante de su microcontrolador generalmente admite uno o varios a través de sus IDE.
¿Por qué esto parece estar bien en un microcontrolador, pero generalmente no se desea en un microprocesador?
Realmente no está bien, es un patrón de diseño inusual, de hecho, para microcontroladores, que normalmente hacen cosas a intervalos regulares o reaccionan a estímulos externos. No es habitual que desee “utilizar tanta CPU como pueda” en un microcontrolador de forma continua.
Hay excepciones a ese patrón, y existen tanto en la MCU como en el mundo de los procesadores de servidor / escritorio; cuando sepa que prácticamente siempre tiene, por ejemplo, datos de red para procesar en un dispositivo de conmutación, o cuando sepa que su juego siempre podría precalcular un poco del mundo que podría o no necesitar en unos momentos, entonces encontrará estos bucles de giro. En algunos controladores de hardware, encontrará “bloqueos de giro”, lo que significa que la CPU consulta continuamente un valor hasta que ha cambiado (por ejemplo, el hardware ha terminado de configurarse y se puede usar ahora), pero generalmente es solo una solución de emergencia, y tendrá que explicar por qué está haciendo eso al intentar introducir dicho código en Linux, por ejemplo.
¿Estoy en lo cierto al pensar que el ATmega de hecho funciona al 100% y que, debido a que tiene tan poca potencia, no causa ningún problema de calor obvio?
Si. El ATMega no es, según los estándares modernos, de baja potencia, pero es lo suficientemente baja como para que el calor no se convierta en un problema.
¿Estoy en lo cierto al pensar que el ATmega de hecho funciona al 100% y que, debido a que tiene tan poca potencia, no causa ningún problema de calor obvio?
Sí, normalmente funciona al 100% todo el tiempo, pero tiene tan poca potencia que no se calienta significativamente.
En una computadora de escritorio / computadora portátil con una CPU Intel i7, etc., si ejecutara un bucle infinito similar (sin nada que hacer o muy poco que hacer), fijaría la CPU en ~ 100% y, en general, haría girar los ventiladores, etc.
Cuanto más rápido se sincroniza una CPU, más energía consume, porque cada vez que cambia un nivel lógico, debe cargar las capacitancias de los transistores en las puertas. Las CPU modernas están diseñadas para funcionar lo más rápido posible, en realidad más rápido de lo posible. Incluso después de hacer que los transistores sean lo más pequeños posible, usar el voltaje más bajo posible y aplicar un disipador de calor enorme, aún no pueden funcionar lo suficientemente rápido como para satisfacer la “necesidad de velocidad” del usuario de PC. Por lo tanto, confían en el hecho de que el sistema operativo y los programas de aplicación pasan la mayor parte del tiempo esperando que sucedan cosas (entrada del usuario, hardware periférico, etc.).
Si intentara ejecutar todos los núcleos en un i7 continuamente a la frecuencia máxima, se derretiría. Para evitar esto, los núcleos no utilizados se apagan y cuando no se requiere la velocidad máxima (es decir, la mayor parte del tiempo), los núcleos activos funcionan a una frecuencia más baja. Cuando está inactivo, el sistema operativo no solo ejecuta un bucle ocupado ejecutando instrucciones continuamente, sino que pone la CPU en un estado ralentizado o detenido mientras espera interrupciones, etc. Varias partes de la CPU también pueden apagarse cuando no se utilizan.
El ATmega también se puede poner en modos de menor consumo y los periféricos individuales se pueden apagar cuando no se necesitan. Si el reloj del sistema se cambia a una frecuencia más baja, como 32,678 kHz, y se apagan todos los periféricos innecesarios, puede funcionar (lentamente) con solo unos pocos μA, no para reducir la temperatura, sino para que dure más con una batería pequeña.
También es posible “overclockear” muchos chips Atmega. He ejecutado un ATmega1284p (clasificado para 20MHz como máximo a 5V) a 30MHz y funcionó bien, pero se calentó bastante.
Aquí puedes ver las reseñas y valoraciones de los usuarios
Tienes la opción de añadir valor a nuestro contenido informacional contribuyendo tu veteranía en las anotaciones.