Oscilador interno o externo

22

Siempre uso el oscilador interno que tienen las fotos, ya que nunca he encontrado la necesidad de ejecutar nada a una frecuencia más alta que 8 MHz (que es la más rápida que las fotos que uso tienden a poder ir). ¿Hay alguna razón, más allá de ir por encima de 8 MHz, que signifique que debería usar un oscilador externo? Parece que una cosa más me va mal, pero me interesaría saber lo que hacen los demás.

SimonBarker
fuente
" ¿Por qué a veces es necesario un cristal externo, a pesar de que la MCU tiene una CPU interna? " El hecho de que la MCU tenga una CPU interna no tiene casi nada que ver con el motivo por el que se utiliza un reloj interno o externo. ¿Estás confundiendo / confundiendo dos cuestiones diferentes?
gbulmer
Puede ayudarlo a comprender completamente microcontrollerslab.com/oscillator-types-microcontrollers
Bilal Malik

Respuestas:

33

Como han dicho otros, la frecuencia precisa y la estabilidad de la frecuencia son razones para usar un resonador cerámico externo o cristal. Un resonador es varias veces más preciso que el oscilador RC interno y lo suficientemente bueno para la comunicación UART. Un cristal es mucho más preciso y necesario si está realizando otros tipos de comunicación como CAN, USB o Ethernet.

Otra razón para un cristal externo es la elección de la frecuencia. Los cristales vienen en una amplia gama de frecuencias, mientras que el oscilador interno suele ser una frecuencia con una opción de 4x PLL habilitado. Algunos nuevos PIC de núcleo de 24 bits tienen un multiplicador y un divisor en la cadena de reloj para que pueda elegir una amplia variedad de frecuencias desde la frecuencia del oscilador interno único.

Por supuesto, hay varias aplicaciones que requieren de manera inherente una frecuencia o temporización precisa que no sean las comunicaciones. El tiempo es la propiedad en electrónica que podemos medir con mayor precisión a bajo costo, por lo que a veces el problema se transforma en medir el tiempo o producir pulsos con un tiempo preciso.

Luego están las aplicaciones que requieren una sincronización a largo plazo con otros bloques. Un oscilador del 1% estaría apagado por más de 14 minutos por día si se utiliza como base para un reloj en tiempo real. También puede ser necesario un tiempo preciso a largo plazo sin tener que saber en tiempo real. Por ejemplo, suponga que desea que un grupo de dispositivos de baja potencia se despierte una vez cada hora para intercambiar datos durante unos segundos y luego volver a dormir. Un cristal de 50 ppm (muy fácil de obtener) no se apagará más de 180 ms en una hora. Sin embargo, un oscilador RC al 1% podría estar apagado por 36 segundos. Eso agregaría importantes requisitos de tiempo y, por lo tanto, de energía a los dispositivos que solo necesitaban comunicarse durante un par de segundos cada hora.

Olin Lathrop
fuente
1
Fuera de tema, pero pensé que CANbus fue diseñado para ser lo suficientemente robusto como para manejar variaciones en las frecuencias de reloj entre nodos. ¿Estoy malentendido?
Stephen Collings
1
@Remiel: CAN tiene provisiones para que los nodos permanezcan sincronizados a pesar de alguna diferencia de frecuencia de reloj. Los nodos aún necesitan estar razonablemente cerca. En la mayoría de los casos, básicamente necesita al menos un resonador de cerámica en cada nodo.
Olin Lathrop
24
  1. Precisión. Los relojes internos no son precisos, pueden verse afectados por el ruido.

  2. Temperatura de precisión independiente. Los osciladores típicos pueden variar enormemente. Se pueden necesitar osciladores especiales de compensación de temperatura en aplicaciones de baja o alta temperatura, o si la temperatura varía enormemente.

  3. Velocidad. Los osciladores internos pueden no alcanzar la velocidad más alta del CI. Los externos pueden ser necesarios para eso.

  4. Voltaje. La velocidad de un temporizador interno puede depender de la tensión a la que se está ejecutando.

  5. Se necesitan múltiples relojes. Algunas aplicaciones quieren compartir un oscilador.

  6. Aplicaciones especiales donde el reloj interno puede no ser fácil de usar. Dividir el reloj interno podría ser más difícil que arrojarle un cristal de reloj barato de 31 kHz, para aplicaciones de cronometraje.

Fuera de mi cabeza, el ATMEGA 328 que usa el arduino requiere un cristal externo a 5V para su velocidad máxima. La versión de lily pad funciona a 8 MHz, en el oscilador interno porque está limitada a eso a 3.3v. La plataforma de lanzamiento Value Line MSP430 está limitada a 10 MHZ a 3V, 8 a 2.5V.

Transeúnte
fuente
10
Un ejemplo de precisión: USB necesita un reloj preciso. Microchips PIC18F2550 puede generar prácticamente cualquier velocidad de reloj internamente, pero su precisión es demasiado mala para USB. Cuando lo intenté, hubo una desconexión cada 10-20 segundos. Esto no sucedió con un oscilador externo. Mientras tanto, tienen el PIC18F25k50, que puede sincronizar su reloj con la señal USB y ya no requiere un oscilador externo para USB.
sweber
1
Solo para ser pedante, el reloj interno de 8MHz es un oscilador RC, no un cristal, de ahí su poca precisión.
Austin
@austin reparó el comentario.
Passerby
13

La estabilidad de frecuencia será mayor con una externa. Entonces, si tiene una aplicación que realmente depende de la frecuencia de mcu, es posible que deba usar una externa.

Pero la mayoría de los mcu: s tienen una oscilación interna bastante estable, por lo tanto, creo que esta era una pregunta más importante hace un par de años. También hay más y más formas de recortar el interno y compensar la deriva de temperatura (etc., etc.).

Por otro lado, hay otras formas de asegurarse de que esté sincronizado, en algunos países la estabilidad de la frecuencia en la red de alimentación es de 50Hz ± 0.01Hz y en otros lugares como Suecia en realidad tiene ± 0.001Hz y he visto proyectos que usan esto para mantener cosas sincronizadas Y luego ya no eres tan dependiente de la frecuencia mcu y puedes usar la interna. Pero este es un poco de tema :)

Johan
fuente
3
Tenga en cuenta que esas cifras de frecuencia de red son estabilidad a largo plazo . Está bien mantener el tiempo con precisión durante semanas o meses, pero durante un corto período (horas) puede experimentar serias desviaciones. Sin embargo, casi nunca tendrá que ajustar el tiempo en un reloj digital el cheapo.
stevenvh
@stevenvh buen punto, también tenga en cuenta que hay otras fuentes que podrían utilizarse para verificar la estabilidad a largo plazo también. Los sistemas gps y gsm tienen relojes muy bonitos, pero es más complicado usarlos.
Johan
3
aunque hay muchas otras aplicaciones que lo requerirían, hay una que específicamente causa muchos problemas sin una base de tiempo precisa: las comunicaciones en serie.
JustJeff
No conozco ninguna estabilidad de frecuencia que no sea ​​mayor con un cristal de cuarzo externo. No obtendrá una precisión inferior al 0.1% con un oscilador de silicio.
Jason S
1
@Johan: DCF77 / WWVB es tan preciso como GPS o GSM, y es mucho más fácil trabajar con él (latido de
1Hz
2

La estabilidad de frecuencia es la principal, particularmente para comunicaciones en serie a alta velocidad. Pero eso también plantea la necesidad ocasional de un cristal a una frecuencia aparentemente extraña para obtener una velocidad de transmisión exacta, debido a las opciones limitadas que le brindan los divisores de reloj.

Martín
fuente
1

De hecho, me encontré con un escenario en el que el 1% no era lo suficientemente bueno para UART.

Si alguno de ustedes ha oído hablar de la placa de desarrollo de microcontroladores Teensy ++ v1.0, tiene un UART terriblemente sensible. Tenía mi baudio de host configurado en 115200, y se estableció en 115200 y durante mucho tiempo no pude entender por qué no estaba leyendo los datos correctamente. Resulta que mi anfitrión estaba enviando más cerca de 114300 baudios. (115200 - 114300) / 115200 = ~ 0.9% de error. Lo probé con dos MCU diferentes y funcionaron bien.

El punto es: independientemente de su aplicación, si una mayor precisión de la frecuencia del reloj es un beneficio, debe usar un resonador externo, cristal o incluso un oscilador si el chip no tiene los circuitos de conducción necesarios.

PD: Me pregunto si alguien tiene alguna idea sobre qué elección de diseño de bajo nivel hicieron en el hardware UART que lo hace tan sensible.

NickHalden
fuente
El requisito fundamental para un UART es que el receptor muestree cada bit mientras sea válido. Idealmente, el receptor notaría el momento preciso en que llegó el bit de inicio y muestrearía los datos con precisión 1.5 un bit más tarde, luego 2.5, 3.5, etc. hasta 8.5 bit veces más tarde. En la práctica, generalmente hay una cierta pendiente cuando el receptor detecta el pulso de inicio, y puede haber más pendiente después de eso. Por ejemplo, uno podría intentar recibir 2400 baudios usando un procesador que ejecuta 8,192 instrucciones por segundo ...
supercat
Tal cosa se puede hacer si el tiempo de transmisión está perfectamente limpio, pero el muestreo no se realizará a intervalos precisos de 417usec. En cambio, sucederá a intervalos de 366us y algunos de 488us. Cuando un receptor es "exigente", lo que a menudo significa es que está muestreando datos mucho antes o más tarde de lo que debería, pero en un momento en que un transmisor ideal emitiría el bit de datos esperado.
supercat
@supercat ¿Por qué alguna vez lo diseñarían para muestrear antes que después? Parece que el muestreo en los .5 como lo describió siempre sería lo mejor. Así es como implementé mi software UART hace un par de años ... ni siquiera se me ocurrió hacerlo de otra manera. Eso simplemente permite el mayor margen de error en el transmisor.
NickHalden
@JGord: Si el muestreo es controlado por un reloj que es mucho más rápido que la velocidad en baudios, las cosas son maravillosas, pero ese no es siempre el caso. Supongamos, por ejemplo, que uno intentara recibir 115.200 baudios usando un 6502 que funciona a 1.0MHz y sin UART. Un bucle que espera el bit de inicio tomará 7us, y las oportunidades de sondeo están programadas a intervalos de 1us. Hay una incertidumbre en cuanto a cuando 8us 6502 podría sondear un poco, pero ya bits son 8.6us larga, se podría recibir datos en caso de ...
supercat
... la velocidad de transmisión era precisa, los tiempos de subida y bajada eran uniformes y simétricos, y no había otra inquietud. No sé sobre la placa Teensy, pero no me sorprendería si estuviera usando un software UART para impulsar el controlador más allá de sus capacidades normales.
supercat
1

Los osciladores externos de cristal de cristal son más precisos que los relojes internos, y deben usarse cuando sea necesario un cronometraje preciso. A veces, para ahorrar dinero, los diseñadores usan los internos.

Mahmoud Hosseinipour
fuente
2
Esto no parece agregar nada a las respuestas existentes.
Adam Haun