ATtiny13A - No se puede generar software PWM con modo CTC

Un PWM de software mínimo podría verse así:

volatile uint16_t dutyCycle;


uint8_t currentPwmCount;

ISR(TIM0_COMPA_vect){
  const uint8_t cnt = currentPwmCount + 1; // will overflow from 255 to 0
  currentPwmCount = cnt;
  if ( cnt <= dutyCyle ) {
    // Output 0 to pin
  } else {
    // Output 1 to pin
  }
}

Su programa establece dutyCycleel valor deseado y el ISR emite la señal PWM correspondiente. dutyCyclees a uint16_tpara permitir valores entre 0 y 256 inclusive; 256 es mayor que cualquier valor posible de currentPwmCounty, por lo tanto, proporciona un ciclo de trabajo completo del 100 %.

Si no necesita el 0 % (o el 100 %), puede reducir algunos ciclos usando un ciclo uint8_tde 0trabajo de 1/256 y 255100 % o 00 % y 255un ciclo de trabajo de 255/ 256.

Todavía no tienes mucho tiempo en un ISR de 38kHz; utilizando un pequeño ensamblador en línea, probablemente pueda reducir el recuento de ciclos del ISR entre 1/3 y 1/2. Alternativa: ejecute su código PWM solo cada dos desbordamientos del temporizador, reduciendo a la mitad la frecuencia PWM.

Si tiene varios canales PWM y los pines que está utilizando PMW están todos en el mismo PORT, también puede recopilar todos los estados de los pines en una variable y finalmente enviarlos al puerto en un paso que luego solo necesita la lectura de- port, and-with-mask, or-with-new-state, write-to-port una vez en lugar de una vez por pin/canal .

Ejemplo:

volatile uint8_t dutyCycleRed;
volatile uint8_t dutyCycleGreen;
volatile uint8_t dutyCycleBlue;

#define PIN_RED (0) // Example: Red on Pin 0
#define PIN_GREEN (4) // Green on pin 4
#define PIN_BLUE (7) // Blue on pin 7

#define BIT_RED (1<<PIN_RED)
#define BIT_GREEN (1<<PIN_GREEN)
#define BIT_BLUE (1<<PIN_BLUE)

#define RGB_PORT_MASK ((uint8_t)(~(BIT_RED | BIT_GREEN | BIT_BLUE)))

uint8_t currentPwmCount;

ISR(TIM0_COMPA_vect){
  uint8_t cnt = currentPwmCount + 1;
  if ( cnt > 254 ) {
    /* Let the counter overflow from 254 -> 0, so that 255 is never reached
       -> duty cycle 255 = 100% */
    cnt = 0;
  }
  currentPwmCount = cnt;
  uint8_t output = 0;
  if ( cnt < dutyCycleRed ) {
    output |= BIT_RED;
  }
  if ( cnt < dutyCycleGreen ) {
    output |= BIT_GREEN;
  }
  if ( cnt < dutyCycleBlue ) {
    output |= BIT_BLUE;
  }

  PORTx = (PORTx & RGB_PORT_MASK) | output;
}

Este código asigna el ciclo de trabajo a una 1salida lógica en los pines; si sus LED tienen 'lógica negativa' (LED encendido cuando el pin está bajo ), puede invertir la polaridad de la señal PWM simplemente cambiando if (cnt < dutyCycle...)a if (cnt >= dutyCycle...).

Como comentó @JimmyB, la frecuencia PWM es demasiado alta.

Parece que las interrupciones tienen una latencia total de una cuarta parte del ciclo PWM.

Cuando se superpone, el ciclo de trabajo se fija dado por la latencia total, ya que la segunda interrupción se pone en cola y se ejecuta después de que se sale de la primera.

El ciclo de trabajo mínimo de PWM viene dado por el porcentaje total de latencia de interrupción en el período de PWM. La misma lógica se aplica al ciclo de trabajo máximo de PWM.

Mirando los gráficos, el ciclo de trabajo mínimo es de alrededor del 25%, y luego la latencia total debe ser ~ 1/(38000*4) = 6,7 µs.

Como consecuencia, el período mínimo de PWM es de 256*6,7 µs = 1715 µs y una frecuencia máxima de 583 Hz.

Algunas explicaciones más sobre posibles parches a alta frecuencia:

La interrupción tiene dos ventanas ciegas cuando no se puede hacer nada, entrando y saliendo de la interrupción cuando se guarda y recupera el contexto. Dado que su código es bastante simple, sospecho que esto toma una buena parte de la latencia.

Una solución para omitir los valores bajos seguirá teniendo una latencia al menos al salir de la interrupción y entrar en la siguiente interrupción, por lo que el ciclo de trabajo mínimo no será el esperado.

Siempre que no sea inferior a un paso de PWM, el ciclo de trabajo de PWM comenzará con un valor más alto. Sólo una ligera mejora de lo que tienes ahora.

Veo que ya usa el 25 % del tiempo del procesador en interrupciones, entonces, ¿por qué no usa el 50 % o más, deja la segunda interrupción y solo agrupa para el indicador de comparación? Si usa valores solo hasta 128, tendrá solo hasta un 50% de ciclo de trabajo, pero con la latencia de dos instrucciones que podrían optimizarse en ensamblador.