¿Por qué algunos microcontroladores tienen retrasos de sincronización tan grandes?


11

En los microcontroladores de la serie Atmel SAM-D21, muchos periféricos usan un reloj que es asíncrono al reloj de la CPU principal, y los accesos a estos periféricos deben pasar por la lógica de sincronización; en periféricos cuyo reloj es lento en relación con el tiempo de CPU, esto puede agregar algunos retrasos realmente grandes. Por ejemplo, si el RTC está configurado para usar un reloj de 1024Hz (como parece ser la intención del diseño) y la CPU está funcionando a 48Mhz, leer el registro de "hora actual" hará que la lógica del bus inserte más de 200,000 estados de espera (un mínimo de cinco ciclos del reloj de 1024Hz). Aunque es posible que la CPU emita una solicitud de lectura, ejecute algún otro código no relacionado y devuelva más de 200,000 ciclos más tarde para recuperar el tiempo, no parece haber ninguna forma de leer el tiempo más rápido.

Según tengo entendido de la sincronización, un circuito de sincronización de un solo bit retrasará una señal en 2-3 ciclos del reloj de destino; sincronizar una cantidad de varios bits es un poco más difícil, pero hay una variedad de enfoques que pueden garantizar un comportamiento confiable dentro de los cinco ciclos del reloj de destino si es más rápido que el reloj de origen, y solo unos pocos ciclos más si no lo es. ¿Qué estaría haciendo el Atmel SAM-D21 que requeriría seis ciclos en el dominio del reloj de origen para la sincronización, y qué factores favorecerían un diseño cuyos retrasos de sincronización son tan largos como para necesitar una interrupción de "sincronización realizada", frente a uno que garantice los retrasos de sincronización son lo suficientemente cortos como para que tales interrupciones sean innecesarias?


2
gracias por esta pregunta. Finalmente me hizo entender el problema en mi mano. Vine aquí porque no podía entender por qué borrar el Watchdog Timer (WDT) tomaría casi 5 milisegundos tremendos en el SAMD20 / 21. Ahora sé que es por diseño de hardware, no un error mío. (El WDT tiene una velocidad de reloj de 1024 Hz, que es la única opción sensata). Ahora al menos puedo tratarlo en consecuencia.
T-Bull

2
@ T-Bull: Lo realmente divertido del watchdog en esas partes es que está deshabilitado entre el momento en que el software emite el comando de reinicio y el momento en que el comando pasa a través del sincronizador. Si el dispositivo se va a dormir durante ese intervalo, el perro guardián no funcionará a menos que o hasta que algo más despierte la parte.
supercat

Respuestas:


2

Esa es una forma diferente de hacerme cosas, estoy acostumbrado a mis arquitecturas donde mis registros están en mi reloj de CPU o al menos la mitad de ese reloj. Entonces escribes tus registros y están listos de inmediato. ¿Quizás lo están haciendo de esta manera para ahorrar energía? Si están poniendo registros periféricos en su propio dominio de reloj realmente lento por separado, tal vez no tengan que despertarse y ejecutar el oscilador principal o el reloj de la CPU, pero pueden seguir actualizando los valores en el periférico.

Si ese es el caso, entonces podría escribir un registro en su bloque periférico súper lento, luego deshabilitar la isla de energía para toda la CPU o la puerta del reloj, y dejar que el sincronizador lento lo lea hasta que esté satisfecho y luego interrumpir la CPU para sacarlo de dormir.

Alternativamente, podría permitirle incluir la cantidad máxima de instrucciones en su tiempo de vigilia, en lugar de girar seis ciclos y esperar cada escritura.

En cuanto a por qué usan tantos ciclos de sincronización, podrían ser paranoia o podrían estar cumpliendo algún estándar de alta confiabilidad para uno de sus clientes. No puedo decirlo con certeza, pero sé que he visto clientes con demandas como cada carnero tendrá ecc y se precargará a un valor establecido, etc.

Supongo que no es una respuesta definitiva, pero esos son mis pensamientos después de revisar un poco la hoja de datos.


2
Los "seis ciclos" son seis ciclos del reloj periférico; si se configura, por ejemplo, el módulo de reloj en tiempo real para que se alimente a 1024Hz (que parece ser la recomendación de Atmel) y el reloj de la CPU está a 48MHz, seis ciclos del reloj periférico serán 281,250 ciclos del reloj de la CPU, que es un tiempo extremadamente largo es hora de girar, especialmente si hay interrupciones que necesitan reparación. El giro solo es moderadamente horrible si el reloj lento es de 8Mhz (lo que significa un giro de 36 ciclos de CPU), pero una falla dura sería mejor que un giro en un reloj de 1024Hz.
supercat
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.