¿Por qué no debería fuerza bruta PWM?

Así que he estado jugando con un ATtiny45, y se me ocurre que probablemente podría usar PWM de fuerza bruta al preescalar un temporizador a sysclock/64, luego ejecutar un código ISR que enciende o apaga manualmente las salidas dependiendo de las variables globales establecidas en otro lugar en código o vía IO. A una velocidad máxima de sysclock de 20 MHz, debería obtener una resolución decente, y podré usar todos mis pines IO como PWM en lugar de los dos que proporciona el chip, así que la gran pregunta es... ¿por qué no? Aparte de usar muchos ciclos de sysclock, realmente no veo desventajas... ¿alguien podría darme algunas?

Intenté hacer esto una vez (pero con un controlador diferente). En la práctica no obtienes un pulso limpio. En cambio, varía según el tiempo del ciclo del reloj y se ralentiza si el controlador está ocupado con otra cosa.
también se siente feo: se necesita muy poco hardware para un solo canal pwm; puede ser literalmente un contador binario reiniciable xored y nored a un registro, además de alguna lógica de división de reloj y posiblemente también una configuración similar para el pulso de apagado. El bit banging adolece de una temporización inconsistente y difícil de predecir con precisión, así como un uso de recursos (relativamente) intenso: ejecución de código, canales de interrupción, relojes del sistema (que pueden tener más funciones que los relojes PWM), todo para una función tan simple. ¿Por qué necesitas más canales? puede haber una manera más barata.
¿El ATtinyX5 no proporciona 3 comparadores de salida, OC0A, OC0B/OC1A (compartido en PB1), OC1B?

Respuestas (6)

Las tres desventajas son el consumo de energía, atar un temporizador e interrumpir otro código. Si no le importan los modos de bajo consumo, no necesita el temporizador y no tiene un código crítico que no pueda soportar algunos ciclos de reloj para dar servicio a la interrupción, no hay ninguna desventaja. Algunos proyectos son bastante simples y no consumen ni una décima parte de la potencia del microcontrolador, así que no dejes que nadie te diga que lo estás haciendo mal aprovechando los temporizadores de esa manera. El software PWM está bien si se ajusta a sus necesidades.

Por consumo de energía, quiere decir que un temporizador con ISR usa más energía que una solución puramente de software, ¿verdad? Un temporizador con ISR debería tener aproximadamente el mismo consumo de energía que el uso del hardware PWM dedicado.
@MathEE Cuando la CPU no está ejecutando instrucciones, puede indicarle que ingrese en un modo de suspensión de bajo consumo. Esto significa que el dispositivo consumirá mucha menos energía durante un tiempo determinado. Para algunos modos de suspensión, el PWM controlado por temporizador seguirá funcionando, pero, por supuesto, el PWM golpeado por bits no lo hará. Las interrupciones son un método común para salir del modo de suspensión.
@jippie Sí, entiendo que uno puede usar interrupciones para salir del modo de suspensión para ahorrar energía, una ventaja. Estaba tratando de entender el comentario de Passerby de que el consumo de energía es una desventaja. Estoy seguro de que Passerby tenía algo en mente, pero no me queda claro si el hardware PWM consumiría menos energía que un contador combinado con ISR. Después de todo, el módulo PWM es solo un contador con hardware adicional.
@MathEE Cuando usa hardware/temporizador PWM, no necesita la CPU y puede convertirla en suspensión. Eso ahorraría una buena cantidad de energía. Él asume que la CPU está inactiva cuando se usa PWM controlado por temporizador (y, por lo tanto, se puede poner a dormir), en lugar de contar los ciclos de instrucción cuando se hace PWM con bits.
Una interrupción saca al microcontrolador del modo de bajo consumo para dar servicio al código. Un módulo PWM de hardware puede manejar todo de manera mucho más eficiente, sin sacar el chip de LPM. Si todo el mcu se utiliza principalmente para PWM con la interacción ocasional del usuario, es un gran éxito en el consumo de energía.
PWM vincula un temporizador en muchas plataformas
El uso de un PWM de software también puede aumentar el consumo de energía al requerir que la CPU se ejecute a una velocidad de reloj más rápida de lo que sería necesario.
Tenga en cuenta que toda esta charla sobre "ahorro de energía" es irrelevante si está encendiendo tenuemente un solo LED.
@nickt por el contrario, esas aplicaciones de baja corriente como atenuar un solo led se benefician más de la conservación de energía. Si su objetivo es 3 mAh, un promedio de 2 mAh por activar constantemente el mcu es un gran éxito. Por otro lado, un golpe de 2 mAh en una aplicación pwm de motor de 500 mA es minúsculo.
@Passerby, suenas contrario. Entonces, en ese sentido, la MCU no puede dormir si los temporizadores aún están funcionando. Lo mejor que puede hacer es cambiar al modo inactivo, que en el ATtiny ahorra alrededor de 3,8 mA (pero si realmente le importara la energía, estaría funcionando a 1,8 V, en cuyo caso solo ahorra 0,2 mA), así que si Ejecutando alegremente un solo LED discreto a una "tenue" 2 mA, diría que, si bien está seguro, sus ahorros son "estadísticamente significativos", son irrelevantes desde una perspectiva de ingeniería.
@nickt no está de acuerdo con su suposición falsa.

Recientemente he estado jugando con un montón de cosas de fuente de alimentación de conmutación PWM, y tienes razón, hay razones perfectamente válidas para "bit bang" señales moduladas por ancho de pulso. Pero una de las principales fallas de este método es cuando necesita un control de retroalimentación inmediato del ciclo de trabajo generado.

Incluso con un reloj integrado de 20 MHz, el tiempo de ciclo es de 50 nanosegundos. Computacionalmente, tendría que adquirir la señal que se está monitoreando, restarla del nivel de referencia y luego reanudar la generación del ciclo de trabajo. Esto creará "inestabilidad" donde el ciclo de trabajo es inconsistente. El uso de un DAC integrado no está descartado, pero consume ciclos. Para reducir esto, puede agregar un DAC externo, pero luego ha asignado quizás 8 o 12 pines del microcontrolador al DAC externo para una lectura rápida (dependiendo de la resolución que desee). Luego, debe preocuparse por el retraso adicional en la propagación de la señal a través de los componentes de conmutación.

Si lo que desea es un control de retroalimentación rápido, es difícil vencer a un IC de ciclo de trabajo independiente. El retraso del amplificador de error integrado es tan pequeño que le preocupa más el cambio de ganancia a altas frecuencias. La propagación de la señal a través de la conmutación sigue siendo el mismo riesgo, por supuesto, y debe diseñarse en torno a ella.

También vale la pena señalar que muchos paquetes PWM IC tienen funciones de apagado y entradas de control de tiempo muerto que pueden hacer cosas realmente ingeniosas cuando se combinan con un microcontrolador, todo en un paquete de 8 o 16 pines.

Depende de usted decidir si el método de explosión de bits puede satisfacer sus necesidades. En realidad, puede aumentar la frecuencia bastante alto si usa un preescalador más bajo. El ciclo de trabajo que obtenga mostrará un error de cuantización, pero eso puede no ser un gran problema dependiendo de lo que esté haciendo y qué tan alta tome la resolución; pero, de nuevo, una mayor resolución tiene el costo de una menor frecuencia. Si no necesita un control de retroalimentación instantáneo y su aplicación puede manejar cierta fluctuación, entonces el bit-banging puede ser el camino a seguir.

El objetivo de tener dispositivos de hardware en el chip es liberar el procesador para otras tareas. Si usa hardware PWM, puede realizar simultáneamente otras tareas del microcontrolador.

Ahora creo que se ha dado cuenta de esto porque está preguntando sobre el uso de un ISR en lugar de ejecutar un contador de fuerza bruta de bucle for/while, pero nuevamente es la misma respuesta. Si no cambiamos el ancho del pulso, ¿por qué querríamos interrumpir nuestras otras tareas innecesariamente?

Porque queremos más de 3 canales PWM sin agregar a la lista de materiales.
@Ignacio Tal vez estoy leyendo mal la pregunta, pero la leí porque el OP quería usar PWM de fuerza bruta y luego, como bonificación, obtiene más canales PWM. Tienes razón si el OP quiere hacerlo porque necesitan más canales.

Puedes hacer fácilmente lo que dices, lo he hecho varias veces. Es más útil si desea cambiar su PWM en momentos predecibles; puede hacer esto contando la cantidad de ciclos de PWM, y necesitaría un temporizador para hacerlo de todos modos.

Sin embargo, existe una compensación entre la resolución de PWM/# de salidas frente a la cantidad de tiempo de procesador libre. Llegará a un punto en el que no tendrá suficiente CPU libre para que funcione.

Recomiendo conectar un alcance a un pin libre y luego configurar ese pin alto al comienzo de la ISR y bajo al final. Esto le permitirá ver la proporción del tiempo que está usando su rutina.

El software PWM no tiene que hacer un uso intensivo de la CPU si se hace de la manera correcta, como usar la modulación de código binario . Con esta técnica agradable y simple, puede tener muchos canales SoftPWM sin una gran sobrecarga de CPU.

Nit menor: PWM se refiere a algunos esquemas de modulación particulares en los que un nivel de salida constante estará representado por una onda de pulso con un cierto ciclo de trabajo, y la frecuencia de la onda es independiente del nivel representado; los esquemas varían solo en cómo se representarán los cambios en el nivel de salida. La modulación de código binario es miembro de una clase más general de esquemas de modulación de ciclo de trabajo .
La implementación enlazada de modulación de código binario tiene la desventaja de que una salida cuyo valor cambia de 127 a 128 será baja durante 255 pulsos consecutivos, y una cuyo valor cambia de 128 a 127 será alta durante 255 ciclos consecutivos. Además, si el dispositivo que se controla tiene un comportamiento de encendido/apagado no uniforme, PWM se comportará linealmente en la mayor parte de su rango, mientras que BCM no lo hará. Algunas variaciones de BCM pueden ser útiles, pero a menudo será necesario reconocer y tratar sus limitaciones.
Aunque notó bien que BCM no es una solución para todo, se manejará bastante bien con la mayoría de los dispositivos y con un uso de CPU muy bajo. Lo más común probablemente será la atenuación de los LED. Si se necesita linealidad de brillo en este caso, tanto PWM como BCM necesitarían una tabla de corrección.
He usado variaciones de BCM para LED, y están bien para niveles sólidos, pero el enfoque dado parpadeará mal si el nivel de brillo alterna entre 127 y 128. Un enfoque alternativo para PWM de 256 niveles es tener una ejecución de interrupción por ejemplo, una vez cada 256 ciclos, y haga que cada interrupción escriba los LED dos veces, con 16 ciclos de diferencia. En la mitad de los ciclos (alternados), escriba el bit 3 y luego el bit 7. En la mitad del resto, escriba el bit 2 y luego el 6, etc. En 1/16, simplemente escriba cero y realice otro procesamiento.

Personalmente, descubrí que los PWM del temporizador son más rápidos y consistentes (en el rango completo de 256, si no necesita esa resolución, el software ["fuerza bruta"] puede ser más rápido), y cuando he necesitado más de 2 I probé el PWM suave junto con los PWM duros y no fue muy fluido, así que opté por hacer todo el PWM en el software y resultó genial.
Lo único es que cuando se realizan cálculos/procesamientos/interrupciones intermedias que toman un poco de tiempo, el PWM suave se detiene y puede ser muy notorio.

¿Por qué no debería fuerza bruta PWM?
RespuestasAquíPolítica de privacidad1y, 0v