Relojes, procesadores y temporizadores en una MCU

Así que estoy leyendo este excelente libro Patterns for Time-Triggered Embedded Systems y tengo una pregunta sobre el cálculo preciso de valores para temporizadores de hardware. Consulte el patrón "Retraso de hardware" en el libro anterior.

Según tengo entendido, una "fuente de reloj" (también conocida como "Reloj del sistema") genera una serie constante de tics (digamos f1 khz) que luego se alimenta a través de una unidad "Prescaler" que la divide (por un factor n que puede ser 1 ) dando otra frecuencia (digamos f2=f1/n khz) que luego se alimenta al procesador. Así, el "reloj del procesador" tiene una frecuencia f2 y un período de tiempo t2 = 1/f2 ms. Para calcular un intervalo de tiempo preciso (por ejemplo, un temporizador de 100 ms), solo calculamos el número de tics en 100 ms como 100/t2 = f3 "ticks del reloj del procesador". Por lo tanto, debemos configurar los registros de temporizador apropiados en valores correspondientes a f3 para generar un tic de 100 ms.

Sin embargo, no parece ser tan sencillo (al menos para el 8051) debido a la cantidad de pasos necesarios para un "ciclo de instrucción del procesador". Un procesador pasa por su ciclo de instrucción, es decir, "Buscar->Decodificar->Ejecutar->Interrumpir" (las interrupciones se verifican al final de la instrucción actual) que toma una serie de tics. Idealmente, todo el ciclo de instrucción debería tomar solo 1 tic (por ejemplo, un procesador segmentado) y, por lo tanto, puedo usar el cálculo anterior para configurar los temporizadores. Sin embargo, aparentemente en el 8051 original, el reloj del sistema funcionaba a 12 mhz y cada ciclo de instrucción tomaba 12 tics. Dado que las interrupciones se verifican solo al final del ciclo de instrucción, ahora necesitamos una división adicional por 12 para obtener el tic del reloj del "temporizador" correcto, que es "reloj del procesador"/12, es decir, f2/12.

¿Es correcto mi entendimiento anterior? Si es cierto, ¿cómo puedo calcular tiempos precisos cuando las instrucciones pueden tener ciclos diferentes (por ejemplo, instrucciones mixtas de 32 y 16 bits)? Además, ¿los temporizadores deben incrementarse a través de un ciclo de instrucción del procesador o hay alguna forma en HW de incrementar un registro de temporizador estrictamente sincronizado con la salida de la unidad "Prescaler"?

Los temporizadores funcionan independientemente del resto del uC. Son hardware dedicado que es sincronizado por la fuente seleccionada. Una vez que se reinician, generalmente activa una interrupción. Simplemente use el reloj que usa el temporizador para calcular el conteo requerido.
@ user110971 Ese fue mi entendimiento también. Pero con el ejemplo 8051 mencionado anteriormente (el libro es gratuito), parece que entra en juego el ciclo de instrucciones, lo cual era una novedad para mí. De ahí mi pregunta.
así es como está diseñado. Otros procesadores están diseñados de manera diferente. Un procesador RISC que se ejecuta internamente a 5 MHz y que tiene el canal clásico de 5 etapas puede funcionar con un reloj de 5 MHz. Sin embargo, internamente cada instrucción toma múltiples ciclos de reloj. El reloj interno, generado con PLL, puede ser mucho más rápido que 5MHz. Lo mismo es cierto para el 8051, pero el reloj rápido se proporciona externamente.

Respuestas (1)

La respuesta corta entonces es "Depende". Diferentes familias de procesadores utilizarán diferentes enfoques. No hay una idea que se ajuste a todas las micros respuesta. Además, las interrupciones síncronas (las generadas por hardware interno sincronizado con algún reloj interno) pueden reconocerse de manera más predecible y diferente que los eventos asíncronos (externos al micro). Como siempre, lea la hoja de datos y mantenga la mente abierta.

Calcular el tiempo preciso también dependerá del procesador. Incluso si ocurre un evento (coincidencia del contador del temporizador, externo, lo que sea), si su procesador está ocupado ejecutando una instrucción durante varios ciclos, generalmente no abortará la instrucción para iniciar una rutina de interrupción. (Pero algunos procesadores INTERRUMPIRÁN ALGUNAS instrucciones, aunque acabo de decir que normalmente no lo hacen. Entonces, incluso eso no es un evangelio y debe leer la hoja de datos y las guías familiares para estar seguro). Peor aún, incluso si el procesador está ejecutando una instrucción de un solo ciclo, puede haber cierta variabilidad en la respuesta a la interrupción. Por lo tanto, puede encontrar los documentos que dicen "5 a 6 ciclos más tarde", por ejemplo. Entonces, incluso entonces, no estás exactamente seguro.

Por otro lado, algunos procesadores son tan predecibles como un reloj atómico. El procesador ADSP-21xx de Analog Devices (ciclo único para CADA palabra de instrucción, algunos de los cuales pueden ejecutar tres instrucciones en paralelo), SIEMPRE tiene exactamente el mismo tiempo de respuesta de interrupción, cada vez, para un evento de temporizador. Casi puedes configurar tu reloj atómico con él. Ninguna variación, en absoluto. Solo respuestas limpias, perfectas y predecibles. Cada vez.

Pero eso es raro.

Y si su procesador tiene una tubería larga y agradable, es posible que deba esperar a que se "drene". Eso se hace para que no haya mucho estado interno que deba restaurarse, reiniciando múltiples instrucciones en varias etapas de ejecución.

Pero incluso entonces, hay excepciones. El DEC Alpha puede tomar algunos relojes solo para llegar a su rutina de interrupción. Pero cuando lo haga, probablemente tendrá varias instrucciones en varios estados en las diversas canalizaciones, todas las cuales están esperando para continuar. Su código de interrupción deberá guardar todo ese estado, hacer lo suyo, restaurar ese estado y luego reiniciar... con todas las tuberías donde estaban cuando se interrumpieron. El código de interrupción, si necesita rastrear y encontrar una instrucción defectuosa, es DOLOROSO de escribir. Pero esa cosa gritó. Ni siquiera harían cambios de carril para la selección de bytes porque agregaría un retraso combinatorio que reduciría la frecuencia del reloj.

Entonces, eso es raro. Pero sí, incluso eso puede suceder.

ENTONCES... LEA LA HOJA DE DATOS Y EL MANUAL FAMILIAR. Y prepárate para CUALQUIER COSA. Los diseñadores pueden ser MUY CREATIVOS a veces.

Ahora me has asustado :-) Estaba al tanto de los problemas relacionados con la "latencia de interrupción" (por ejemplo, retraso de propagación, identificación de la fuente de interrupción, esquemas de prioridad involucrados, etc.) pero había imaginado que las interrupciones de tictac del temporizador serían muy simples, predecibles y precisas. con la mayoría de los problemas eliminados por diseño. Parece que hay aún más factores que complican el problema.
@RamanathanR No tengas miedo. Simplemente lea los materiales suministrados. Diferentes micros (y procesadores en general) tienen diferentes enfoques. Algunos de ellos ni siquiera TIENEN interrupciones (el RS08, por ejemplo). En la mayoría de los casos, en realidad no necesita un período de precisión entre el reconocimiento de una interrupción y el inicio de la primera instrucción del código de interrupción. Sin embargo, hay veces que necesita esa función. Y esto significa que tienes que mirar mucho. En uno de mis sistemas de medición, necesitaba una respuesta exacta. El ADSP-21xx fue la solución y funcionó maravillosamente.
Relojes, procesadores y temporizadores en una MCU
RespuestasAquíPolítica de privacidad1y, 0v