¿Buenos enfoques para implementar más de una función de tiempo crítico usando un microcontrolador?

Para generar ondas cuadradas precisas, use el hardware. La mayoría de los microcontroladores tienen generadores de PWM integrados que pueden hacer esto. Usted establece el período y el tiempo en ciclos de reloj, y el hardware hace el resto. Para cambiarlo a una nueva frecuencia, escriba el nuevo período en el registro de períodos y la mitad del período en el registro de ciclos de trabajo.

En cuanto a la pérdida de tiempo del reloj en tiempo real debido a otra carga del procesador, no funciona de esa manera a menos que esté muy mal escrito. Generalmente, el hardware se usaría para crear una interrupción periódica que es un múltiplo de segundos, y el firmware se divide más allá de allí. Esto funciona independientemente de lo ocupado que esté el procesador, ya que la interrupción se ejecuta cuando es necesario. Mientras la rutina de interrupción tome una pequeña fracción de los ciclos generales, la mayoría del procesador todavía se aplica a la tarea de primer plano.

También hay formas de mantener el tiempo mediante sondeo a intervalos algo desconocidos. El hardware debe mantener un recuento y, cada vez que se actualiza el reloj, lo actualiza en función del número total de tics transcurridos. Mientras esta rutina se ejecute con la frecuencia suficiente para que el contador que se use no se ajuste entre las ejecuciones, no se pierda tiempo.

La palabra clave aquí es "soporte de hardware". Para cualquier cosa seria necesitarás soporte de hardware en el µC. El periférico integrado más común es el circuito del temporizador que se ejecuta de manera relativamente precisa y sin interferencias de otras operaciones de la CPU.

Sobre esta base, puede tener muchas funciones que se ejecutan con un tiempo de mediano plazo tan preciso como la fuente de reloj de su controlador.

Pero: como es posible que ya hayas experimentado, además de la precisión a medio o largo plazo, siempre hay un jitter involucrado en el manejo del software de eventos de hardware (incluido el desbordamiento del temporizador). Esto se debe a los diferentes estados posibles de ejecución en el momento en que ocurre un evento que resulta en retrasos variables hasta que la respuesta real al evento pueda suceder.

Por lo tanto, la conclusión es: para cualquier cosa con requisitos de jitter de alta velocidad o casi cero, el soporte de hardware es esencial. Muchos periféricos de hardware están incluidos en la mayoría de los µC, como UARTs & c, y cuanto más poderoso y costoso es el µC, más hardware de soporte suele estar integrado. Si su µC no proporciona el hardware que necesitaría, tendrá que considerar un hardware externo y dedicado para la tarea.

Haga todo lo que pueda con hardware, especialmente para funciones muy importantes en el tiempo. Todos los microcontroladores tienen temporizadores / contadores creados específicamente para contar y programar eventos.

Aparte de eso, esta es realmente una pregunta muy amplia. Así que no hay una buena respuesta.

La única respuesta verdadera es la experiencia. Pruébalo, haz un perfil, acentúalo, arréglalo. Tienes que identificar áreas de código con alto uso. El 20% del software que se ejecuta el 90% del tiempo, significa que cada instrucción eliminada mejora el rendimiento.

El buen diseño siempre ha equilibrado el hardware, el software y la memoria. Esto se aplica a todos los microprocesadores, pero especialmente a los microcontroladores. Maximice uno o use uno de manera ineficiente y tendrá un producto pobre. A medida que aumentan las densidades de silicio, cada vez se incluyen más características en el hardware de los microcontroladores. Pero más características significa más expectativas. Doble memoria interna y agregará alguna característica que la use.

Todos los ISR tienen una sobrecarga, que depende de los registros utilizados por el ISR. Si la latencia para guardar el estado de la máquina es significativa en comparación con el servicio de ISR para funciones de tiempo crítico, es posible que su diseño no sea escalable. Por lo tanto, el consenso general de las respuestas para utilizar hardware.

El uso de interrupciones de software puede disminuir la hinchazón del estado de la máquina ISR.

// Timer0 ISR
Temp = Temp + 1
if (Temp == 150)
    call Inc_Seconds()

Todos los registros de Inc_Seconds () se deben enviar, cuando solo se usan una vez cada 150 ciclos.

// Timer0 ISR
Temp = Temp + 1
if (Temp == 150)
    _Software_Interrupt
...
// Software_Interrupt ISR
    call Inc_Seconds()

Ahora, el golpe de latencia solo ocurre una vez cada 150 ciclos.

Si implementas un reloj en tiempo real en hh: mm: ss, ¿importa si está apagado a 50ms? Ninguna persona detectaría el error. Esto ciertamente no es una preocupación operativa en tiempo real.

En cuanto a los eventos que deben ocurrir al mismo tiempo. Deben ellos? Si es necesario, entonces el diseño del hardware debe hacerse cargo de ello. De lo contrario, debe haber algún compromiso de software. Si no puede establecer dos bits a la vez, establezca un bit. Siguiente instrucción establece el otro. Precisión de un ciclo de reloj en procesadores RISC. Yo diría que eso fue lo suficientemente bueno.

Para la forma de onda cuadrada, debe usar un periférico PWM que esté PLL con su XTAL usando algún tipo de contador para saber cuándo debe realizar un ciclo (para configurar las pocas frecuencias). Cada hoja de datos le dirá cómo hacer esto :)

Para mantener tiempo , sí, necesitará un RTC para hacerlo con precisión a menos que vaya a ensamblar y crear códigos de operación para que sepa a mano el tiempo exec exacto de cada instrucción en cualquier ruta de ejecución. . Probablemente también arrojará nueva luz sobre la afirmación probada de que 'goto se considera dañina'.