26 votos

Oscilador interno o externo

Siempre utilizo el oscilador interno que tienen las fotos, ya que nunca he encontrado la necesidad de hacer funcionar nada a una frecuencia superior a los 8 MHz (que es lo más rápido que suelen ir las fotos que utilizo). ¿Hay alguna razón, más allá de ir por encima de los 8 MHz, que signifique que debo usar un oscilador externo? A mí me parece que es una cosa más que va mal, pero me interesaría saber qué hacen los demás.

0 votos

" ¿Por qué a veces es necesario un cristal externo, aunque la MCU tenga una CPU interna? " El hecho de que la MCU tenga una CPU interna no tiene casi nada que ver con que se utilice un reloj interno o externo. ¿Estás confundiendo dos cuestiones diferentes?

0 votos

Puede ayudarle a entender completamente microcontrollerslab.com/oscillator-types-microcontrollers

38voto

RelaXNow Puntos 1164

Como han dicho otros, la precisión de la frecuencia y la estabilidad de la misma son razones para utilizar un resonador cerámico externo o un cristal. Un resonador es varias veces más preciso que el oscilador R-C interno y lo suficientemente bueno para la comunicación UART. Un cristal es mucho más preciso, y necesario si usted está haciendo algunos otros tipos de comunicación como CAN, USB, o ethernet.

Otra razón para utilizar 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 de una sola frecuencia con la posibilidad de elegir 4x PLL. Algunos PICs de núcleo de 24 bits más recientes tienen tanto un multiplicador como un divisor en la cadena de reloj, por lo que puedes obtener una amplia selección de frecuencias a partir de la única frecuencia del oscilador interno.

Por supuesto, hay varias aplicaciones que requieren intrínsecamente una frecuencia o una temporización precisas, además de las comunicaciones. El tiempo es la propiedad de la electrónica que podemos medir con mayor precisión y de forma más barata, por lo que a veces el problema se transforma en uno de medir el tiempo o producir pulsos con una temporización precisa.

Luego hay aplicaciones que requieren una sincronización a largo plazo con otros bloques. Un oscilador del 1% se desviaría más de 14 minutos al día si se utilizara como base de un reloj de tiempo real. También se puede necesitar un tiempo preciso a largo plazo sin tener que conocer el tiempo real. Por ejemplo, suponga que quiere que un grupo de dispositivos de baja potencia se despierten una vez cada hora para intercambiar datos durante unos segundos y luego vuelvan a dormir. Un cristal de 50ppm (muy fácil de conseguir) no se desviará más de 180ms en una hora. Sin embargo, un oscilador R-C del 1% podría estar apagado durante 36 segundos. Eso añadiría un tiempo de encendido significativo y, por lo tanto, requisitos de energía a los dispositivos que sólo necesitan comunicarse durante un par de segundos cada hora.

1 votos

Fuera de tema, pero pensé que CANbus estaba diseñado para ser lo suficientemente robusto como para manejar las variaciones en las frecuencias de reloj entre los nodos. ¿Estoy entendiendo mal?

1 votos

@Remiel: CAN tiene disposiciones para que los nodos permanezcan sincronizados a pesar de una cierta diferencia de frecuencia de reloj. Los nodos tienen que estar razonablemente cerca. En la mayoría de los casos se necesita al menos un resonador cerámico en cada nodo.

27voto

Passerby Puntos 28913
  1. La precisión. Los relojes internos no son precisos, pueden verse afectados por el ruido.

  2. Precisión independiente de la temperatura. Los osciladores típicos pueden variar mucho. Los osciladores especiales con compensación de temperatura pueden ser necesarios en aplicaciones de baja o alta temperatura, o si la temperatura varía mucho.

  3. La velocidad. Los osciladores internos pueden no alcanzar la máxima velocidad del CI. Para ello pueden ser necesarios los externos.

  4. Tensión. La velocidad de un temporizador interno puede depender de la tensión a la que esté funcionando.

  5. Se necesitan varios relojes. Algunas aplicaciones quieren compartir un oscilador.

  6. Aplicaciones especiales en las que no se puede utilizar fácilmente el reloj interno. Dividir el reloj interno podría ser más difícil que lanzar un cristal de reloj barato de 31 kHz, para aplicaciones de mantenimiento del tiempo.

Según mi opinión, el ATMEGA 328 que utiliza el arduino requiere un cristal externo a 5V para su velocidad máxima. La versión lily pad funciona a 8 MHz, en el oscilador interno porque está limitado a eso a 3,3v. El MSP430 Value Line launchpad está limitado a 10 MHZ a 3V, 8 a 2,5V.

10 votos

Un ejemplo de precisión: El USB necesita un reloj preciso. El PIC18F2550 de Microchips puede generar cualquier velocidad de reloj internamente, pero su precisión es demasiado mala para el USB. Cuando lo probé, había una desconexión cada 10-20s. Esto no ocurría con un oscilador externo. Mientras tanto tienen el PIC18F25k50, que puede sincronizar su reloj a la señal USB y ya no requiere un oscilador externo para USB.

1 votos

Sólo para ser pedante, el reloj interno de 8MHz es un oscilador RC, no un cristal, de ahí su escasa precisión.

0 votos

@austin comentario fijo.

14voto

jwalkerjr Puntos 828

La estabilidad de la frecuencia será mayor con uno externo. Así que si usted tiene una aplicación que realmente depende de la frecuencia de mcu, entonces usted puede necesitar para utilizar un externo.

Pero la mayoría de los mcu:s modernos tienen un osc interno bastante estable, por lo que creo que esto solía ser una cuestión mayor hace un par de años. También hay más y más maneras de recortar el interno, y compensar la deriva de la temperatura (etc etc).

Por otro lado, hay otras maneras de asegurarse de que está sincronizado, en algunos países la estabilidad de frecuencias en la red eléctrica es de 50Hz ±0,01Hz y en otros lugares como Suecia realmente tiene ±0,001Hz y he visto proyectos que utilizan esto para mantener las cosas sincronizadas. Y entonces ya no se depende tanto de la frecuencia del mcu y se puede usar la interna. Pero esto es un poco de tema :)

3 votos

Tenga en cuenta que esas cifras de frecuencia de la red son a largo plazo estabilidad. Está bien para mantener la hora con precisión durante semanas o meses, pero en un periodo corto (horas) puede experimentar graves desviaciones. Sin embargo, casi nunca tendrás que ajustar la hora en un reloj digital barato.

0 votos

@stevenvh buen punto, también hay que tener en cuenta que hay otras fuentes que podrían utilizarse para verificar la estabilidad a largo plazo también. Tanto el sistema gps como el gsm tienen muy buenos relojes pero es más complicado utilizarlos.

3 votos

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.

3voto

Jacob Griffin Puntos 126

La estabilidad de la frecuencia es la principal, sobre todo para las comunicaciones en serie a alta velocidad. Pero eso también trae a colación la necesidad ocasional de un cristal a una frecuencia aparentemente impar para obtener una tasa de baudios exacta, debido a las limitadas opciones que te dan los divisores de reloj.

2voto

Parvenu74 Puntos 257

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

Si alguno de vosotros ha oído hablar de la placa de desarrollo del microcontrolador Teensy++ v1.0, tiene una UART terriblemente sensible. Yo tenía mi host en baudios a 115200, y éste a 115200 y durante mucho tiempo no pude averiguar por qué no estaba leyendo los datos correctamente. Resulta que mi host estaba enviando más cerca de 114300 baudios. ( 115200 - 114300 ) / 115200 = ~0,9% de error. Lo probé con dos MCU's diferentes y funcionaron bien.

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

P.D. 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.

0 votos

El requisito fundamental para una UART es que el receptor muestre cada bit mientras es válido. Idealmente, el receptor notaría el momento preciso en que llega el bit de inicio, y muestrearía los datos precisamente 1,5 veces un bit después, luego 2,5, 3,5, etc. hasta 8,5 veces un bit después. En la práctica, suele haber cierta desviación en el momento en que el receptor detecta el impulso de inicio, y puede haber más desviación después. Por ejemplo, uno podría intentar recibir 2400 baudios utilizando un procesador que ejecuta 8.192 instrucciones por segundo....

0 votos

Esto se puede hacer si la sincronización de la transmisión es perfectamente limpia, pero el muestreo no se producirá a intervalos precisos de 417usec. En cambio, ocurrirá en algunos intervalos de 366us y otros de 488us. Cuando un receptor es "quisquilloso", lo que suele significar es que está muestreando datos mucho antes o después de lo que debería, pero en un momento en el que un transmisor ideal estaría emitiendo el bit de datos esperado.

0 votos

@supercat ¿Por qué iban a diseñarlo para tomar muestras antes que después? Parece que el muestreo en los 0,5 como usted describió siempre sería lo mejor. Así es como implementé mi UART por software 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.

i-Ciencias.com

I-Ciencias es una comunidad de estudiantes y amantes de la ciencia en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X