Oscillateur interne ou externe

22

J'utilise toujours l'oscillateur interne que les photos ont car je n'ai jamais trouvé la nécessité d'exécuter quoi que ce soit à une fréquence supérieure à 8 MHz (qui est la plus rapide que les photos que j'utilise ont tendance à pouvoir aller). Y a-t-il des raisons, au-delà de dépasser les 8 MHz, qui signifient que je devrais utiliser un oscillateur externe? Cela me semble juste une chose de plus qui ne va pas, mais je serais intéressé d'entendre ce que les autres font.

SimonBarker
la source
" Pourquoi est-il parfois nécessaire d'avoir un cristal externe, même si le MCU a un processeur interne? " Le fait que le MCU ait un processeur interne n'a presque rien à voir avec la raison pour laquelle une horloge interne ou externe est utilisée. Êtes-vous en train de confondre / confondre deux problèmes différents?
gbulmer
Cela peut vous aider à comprendre complètement microcontrollerslab.com/oscillator-types-microcontrollers
Bilal Malik

Réponses:

33

Comme d'autres l'ont dit, une fréquence et une stabilité de fréquence précises sont des raisons d'utiliser un résonateur céramique externe ou un cristal. Un résonateur est plusieurs fois plus précis que l'oscillateur RC interne et assez bon pour la communication UART. Un cristal est beaucoup plus précis et nécessaire si vous effectuez d'autres types de communication comme CAN, USB ou Ethernet.

Une autre raison pour un cristal externe est le choix de la fréquence. Les cristaux viennent dans une large gamme de fréquences tandis que l'oscillateur interne est généralement une fréquence avec peut-être un choix de 4x PLL activé. Certains PIC de base 24 bits plus récents ont à la fois un multiplicateur et un diviseur dans la chaîne d'horloge afin que vous puissiez atteindre un large choix de fréquences à partir de la seule fréquence de l'oscillateur interne.

Il existe bien entendu diverses applications qui nécessitent de manière inhérente une fréquence ou un timing précis autres que les communications. Le temps est la propriété de l'électronique que nous pouvons mesurer avec la plus grande précision et à moindre coût, de sorte que parfois le problème se transforme en mesure de temps ou en production d'impulsions avec un timing précis.

Ensuite, il existe des applications qui nécessitent une synchronisation à long terme avec d'autres blocs. Un oscillateur de 1% serait éteint de plus de 14 minutes par jour s'il était utilisé comme base pour une horloge en temps réel. Un temps précis à long terme peut également être nécessaire sans avoir à connaître le temps réel. Par exemple, supposons que vous souhaitiez qu'un groupe d'appareils à faible consommation d'énergie se réveille toutes les heures pour échanger des données pendant quelques secondes, puis se rende en veille. Un cristal de 50 ppm (très facile à obtenir) ne s'éteindra pas plus de 180 ms en une heure. Un oscillateur RC à 1% pourrait cependant être éteint de 36 secondes. Cela ajouterait des délais importants et donc des besoins en énergie aux appareils qui n'avaient besoin de communiquer que quelques secondes toutes les heures.

Olin Lathrop
la source
1
Hors sujet, mais je pensais que CANbus était conçu pour être suffisamment robuste pour gérer les variations de fréquences d'horloge entre les nœuds. Suis-je incompréhensible?
Stephen Collings
1
@Remiel: CAN a des dispositions pour que les nœuds restent synchronisés malgré une certaine différence de fréquence d'horloge. Les nœuds doivent encore être raisonnablement proches. Dans la plupart des cas, vous avez essentiellement besoin d'au moins un résonateur en céramique dans chaque nœud.
Olin Lathrop
24
  1. Précision. Les horloges internes ne sont pas précises, peuvent être affectées par le bruit.

  2. Précision indépendante de la température. Les oscillateurs typiques peuvent varier énormément. Des oscillateurs de compensation de température spéciaux peuvent être nécessaires dans les applications à basse ou haute température, ou si la température varie énormément.

  3. La vitesse. Les oscillateurs internes peuvent ne pas atteindre la vitesse la plus élevée du CI. Des externes peuvent être nécessaires pour cela.

  4. Tension. La vitesse d'une minuterie interne peut dépendre de la tension à laquelle elle fonctionne.

  5. Plusieurs horloges sont nécessaires. Certaines applications souhaitent partager un oscillateur.

  6. Applications spéciales où l'horloge interne n'est pas facile à utiliser. Il peut être plus difficile de diviser l'horloge interne que d'y jeter un cristal de montre à 31 kHz bon marché, pour les applications de conservation du temps.

Sur le dessus de ma tête, l'ATMEGA 328 que l'arduino utilise nécessite un cristal externe à 5V pour sa vitesse maximale. La version lily pad fonctionne à 8 MHz, sur l'oscillateur interne car elle est limitée à 3,3v. Le tableau de bord MSP430 Value Line est limité à 10 MHZ à 3V, 8 à 2,5V.

Passant
la source
10
Un exemple de précision: l'USB a besoin d'une horloge précise. Les micropuces PIC18F2550 peuvent générer à peu près n'importe quelle vitesse d'horloge en interne, mais sa précision est trop mauvaise pour l'USB. Quand je l'ai essayé, il y avait une déconnexion toutes les 10-20 secondes. Cela ne s'est pas produit avec un oscillateur externe. Pendant ce temps, ils ont le PIC18F25k50, qui peut synchroniser son horloge avec le signal USB et ne nécessite plus d'oscillateur externe pour USB.
sweber
1
Juste pour être pédant, l'horloge interne de 8 MHz est un oscillateur RC, pas un cristal, d'où sa mauvaise précision.
Austin
@austin a corrigé le commentaire.
Passerby
13

La stabilité de fréquence sera plus élevée avec une externe. Donc, si vous avez une application qui dépend vraiment de la fréquence mcu, vous devrez peut-être en utiliser une externe.

Mais la plupart des mcu: s modernes ont un osc interne assez stable, donc je pense que c'était une question plus importante il y a quelques années. Il y a aussi de plus en plus de façons de couper l'intérieur et de compenser la dérive de température (etc.)

D'autre part, il existe d'autres moyens de s'assurer que vous êtes synchronisé, dans certains pays, la stabilité de la fréquence dans le réseau électrique est de 50 Hz ± 0,01 Hz et d'autres endroits comme la Suède ont en réalité ± 0,001 Hz et j'ai vu des projets l'utiliser pour garder les choses en synchronisation. Et puis vous ne dépendez plus autant de la fréquence mcu et vous pouvez utiliser celle interne. Mais c'est un peu le sujet :)

Johan
la source
3
Notez que ces chiffres de fréquence du secteur sont la stabilité à long terme . C'est bien de garder le temps avec précision sur des semaines ou des mois, mais sur une courte période (heures), vous pouvez rencontrer de graves écarts. Cependant, vous n'aurez presque jamais à régler l'heure sur une horloge numérique el cheapo.
stevenvh
@stevenvh bon point, notez également qu'il existe d'autres sources qui pourraient également être utilisées pour vérifier la stabilité à long terme. Les systèmes gps et gsm ont de très belles horloges mais il est plus compliqué de les utiliser.
Johan
3
bien qu'il existe de nombreuses autres applications qui en auraient besoin, il y en a une qui cause spécifiquement beaucoup de problèmes sans base de temps précise - les communications série.
JustJeff
Je ne connais aucune stabilité de fréquence qui ne serait pas plus élevée avec un cristal de quartz externe. Vous n'obtiendrez pas une précision inférieure à 0,1% avec un oscillateur au silicium.
Jason S
1
@Johan - DCF77 / WWVB est aussi précis que le GPS ou le GSM, et beaucoup plus facile à travailler (rythme cardiaque de 1 Hz)
stevenvh
2

La stabilité de fréquence est la principale, en particulier pour les communications série à haute vitesse. Mais cela soulève également le besoin occasionnel d'un cristal à une fréquence apparemment étrange pour obtenir un débit en bauds exact, en raison des options limitées que les diviseurs d'horloge vous offrent.

Martin
la source
1

J'ai en fait rencontré un scénario où 1% n'était pas assez bon pour UART.

Si l'un d'entre vous a entendu parler de la carte de développement du microcontrôleur Teensy ++ v1.0, il possède un UART terriblement sensible. J'avais réglé mon baud hôte sur 115200, et il était réglé sur 115200 et pendant longtemps je n'ai pas pu comprendre pourquoi il ne lisait pas les données correctement. Il s'avère que mon hôte envoyait plus près de 114300 bauds. (115200 - 114300) / 115200 = erreur de ~ 0,9%. Je l'ai essayé avec deux MCU différents et ils ont bien fonctionné.

Le point est: quelle que soit votre application, si une plus grande précision de la fréquence d'horloge est un avantage, vous devez utiliser un résonateur externe, un cristal ou même un oscillateur si votre puce n'a pas les circuits de commande nécessaires.

PS Je me demande si quelqu'un a une idée de quel choix de conception de bas niveau il a fait sur le matériel UART qui le rend si sensible?

NickHalden
la source
L'exigence fondamentale pour un UART est que le récepteur échantillonne chaque bit pendant qu'il est valide. Idéalement, le récepteur remarquerait le moment précis où le bit de départ est arrivé et échantillonnerait les données avec précision 1,5 fois une fois plus tard, puis 2,5, 3,5, etc. jusqu'à 8,5 fois plus tard. En pratique, il y a généralement une pente lorsque le récepteur détecte l'impulsion de démarrage, et il peut y avoir plus de pente après cela. Par exemple, on pourrait essayer de recevoir 2400 bauds en utilisant un processeur exécutant 8 192 instructions par seconde ....
supercat
Une telle chose peut être faite si le timing de transmission est parfaitement propre, mais l'échantillonnage ne se fera pas à des intervalles précis de 417usec. Au lieu de cela, cela se produira à certains intervalles de 366us et certains de 488us. Lorsqu'un récepteur est "difficile", cela signifie souvent qu'il échantillonne les données beaucoup plus tôt ou plus tard qu'il ne le devrait, mais à un moment où un émetteur idéal émettrait le bit de données attendu.
supercat
@supercat Pourquoi le concevoiraient-ils pour échantillonner plus tôt que tard? Il semble que l'échantillonnage au 0,5 comme vous l'avez décrit serait toujours le meilleur. C'est comme ça que j'ai implémenté mon logiciel UART il y a quelques années ... je n'ai même pas pensé à le faire autrement. Cela permet simplement la plus grande marge d'erreur sur l'émetteur.
NickHalden
@JGord: Si l'échantillonnage est contrôlé par une horloge beaucoup plus rapide que le débit en bauds, les choses sont merveilleuses, mais ce n'est pas toujours le cas. Supposons, par exemple, que l'on essaye de recevoir 115 200 bauds en utilisant un 6502 fonctionnant à 1,0 MHz et sans UART. Une boucle en attente du bit de démarrage prendra 7us et les opportunités d'interrogation sont planifiées à des intervalles de 1us. Il y a une incertitude de 8us quant au moment où le 6502 interrogerait un peu, mais comme les bits sont longs de 8,6us, on pourrait recevoir des données avec succès si ...
supercat
... la vitesse de transmission était précise, les temps de montée et de descente étaient uniformes et symétriques, et il n'y avait pas d'autre gigue. Je ne connais pas la carte Teensy, mais je ne serais pas surpris si elle utilisait un logiciel UART pour pousser le contrôleur au-delà de ses capacités normales.
supercat
1

Les oscillateurs à cristal de cristal externes sont plus précis que les horloges internes, et ils doivent être utilisés lorsqu'un timing précis est nécessaire. Parfois, pour économiser de l'argent, les concepteurs en utilisent des internes.

Mahmoud Hosseinipour
la source
2
Cela ne semble rien ajouter aux réponses existantes.
Adam Haun