Choisir la fréquence de fonctionement du MCU

Bonjour,

Je me demande comment choisir la fréquence et la configuration de l'oscillateur au début d'un projet. Cela me semble très arbitraire, mais y a t'il une bonne méthode rigoureuse ?

Si j'ai bien compris,
Lorsque j'ai besoin d'une fréquence de fonctionnement très stable et très précises -> Je sélectionne un quartz (ou TCXO) externe. (ex : modulation de fréquence pour RF)
Si j'ai pas un besoin critique -> J'utilise l'oscillateur interne de mon micro. , ce que je fait tous le temps aujourd'hui.

Mais dans ce cas la j'ai plusieurs choix arbitraires ou je ne sais quelle règle suivre :
1- Choisir de configurer l'oscillateur interne de 1MHz à 64MHz
2- Choisir le 'clock divider'. Une fois que je sais à quelle fréquence je veux configurer l'horloge du MCU, J'ai x combinaison pour le faire.

ex : la j'ai fais une carte avec un module BLE en UART, un écran OLED en I2C qui tourne bien, mais j'ai choisit les fréquences de façon assez aléatoire (à part l'I2C qu'il me faut à 100KHz)

Si vous avez une méthode merci,

Salut,
En réalité le choix et le réglage de l'oscillateur sont extrêmement importants.

Comme tu le dis, l'oscillateur externe (quartz, DCO, TCXO, OCXO, etc) est souvent conditionné par le besoin de précision, pour faire une mesure de fréquence ou de durée, faire de l'échantillonnage précis.

MAIS !

- C'est aussi pour des raisons de consommation, si tu réalises par exemple un montage ultra basse consommation parce que ton montage est très éloigné de sa source d'alimentation, tu as tout intérêt de baisser le plus possible l'horloge du micro pour gagner en consommation (ça évite la perte dans les longs câbles) et l'horloge interne à l'avantage d'avoir une grande souplesse pour faire ça. Tu peux aussi jouer avec cette souplesse et augmenter l'horloge juste avant de faire un traitement informatique particulier (un calcul) puis redescendre l'horloge pour ce qui est secondaire.

- C'est aussi une question de tension d'alimentation, un PIC18LF2455 peut tourner même avec 2V de tension mais il ne peut pas dépasser 4MHz alors qu'avec 4.2V de tension il peut tourner à 40MHz. Par exemple, si tu créais un montage électronique alimenté avec des piles, tu peux très bien lire la tension des piles et baisser la fréquence interne de ton micro en fonction de leur usure.

- C'est aussi pour des questions de bruits électroniques car plus le micro tourne vite et plus il va générer du bruit. Si tu réalises de la mesure de courant/tension très faibles (très petites variations) la rapidité de ton micro peut être très problématique même en soignant le routage + les alimentations + les découplages car le bruit que le micro va générer peut être supérieur aux variations que tu souhaites mesurer.

- C'est aussi pour une question de complexité logiciel, si tu fais des FFT ou autres calculs assez complexes et chronophages, là aussi la rapidité de l'horloge doit être adapté (sans pour autant qu'il y ait nécessité d'avoir la précision d'un quartz)

- C'est peut être aussi pour les questions des TIMER (valable pour pleins de micros, ATMEGA, MSP430) sur ton PIC tu peux être amené à utiliser le prescaler du TIMER pour rediviser la fréquence de l'oscillateur et parfois ça ne convient pas car tu n'es pas sur la valeur que tu souhaites pour ton TIMER et tu peux être obligé d'ajuster la valeur de l'oscillateur principal pour que, une fois passé dans le prescaler, le TIMER compte ou décompte à la vitesse qui te convient.

- Parfois c'est pour des raisons de compatibilité matériel, sur certain PIC une fois que tu mets en oeuvre l'USB tu es quasiment obligé d'être sur un réglage bien défini avec très peu d'alternative.

Ça fait déjà pas mal de chose à considérer. C'est pour toutes ces raisons, et il y en a surement beaucoup d'autres que j'ai oublié, que la configuration de l'horloge est si souple.

Je te rassure, lorsqu'on fait des montages électroniques pour soi on en vient pas à ce genre de considération et la configuration de l'horloge n'est que secondaire. Mais quand tu dois faire un montage électronique qui doit tenir 1 an sur deux piles AA 1.5V il faut te préoccuper de tout ça ;)

Voilà.

ok,
J'ai déjà fait plusieurs système électronique avec des durées de vie de 2 à 8 ans sur pile, et je comprend bien le rapport fréquence vs conso, mais en générale je tourne le système en veille (produits IOT) et la conso reste de l'ordre du uA (ldo inclus) c'est suffisant.

Ok, donc si je comprend bien, dans l'idéal, tu fixes ta fréquence sur le minimum requis pour tes périphériques/application et l'augmente ponctuellement si tu as besoin d'une puissance de calcul.

Le point précis qui me gène c'est F osc vs F system clock, je résume ce que je comprends, arrête moi si je me trompe :
1 - Cela sous-entend aussi que je doit éviter d'utiliser le clock divider (dans mon PIC18F26K83 "COSC" et "CDIV"). Sinon cela revient à générer (par exemple) 32Mhz (avoir plus de CEM), puis à diviser par 4 pour n'avoir que 8Mhz pour mon système. SAUF, si un périphérique à besoin d'une fréquence plus élevée que mon système.
2 - La conso est (majoritairement) relative à la fréquence du système et non de l'oscillateur.

merci pour ta réponse claire et complète.

Citation:

---

Envoyé par padrino

dans l'idéal, tu fixes ta fréquence sur le minimum requis pour tes périphériques/application et l'augmente ponctuellement si tu as besoin d'une puissance de calcul

---

En effet c'est ce que je faisais (car ce n'est plus mon métier), je m'arrangeais pour faire tourner mon micro le moins vite possible et au besoin on peut augmenter l'horloge. Bon il faut quand même avouer que mise à part pour un calcul chronophage c'est assez rare d'aller jusque là (je veux dire jouer à ce point avec l'oscillateur) sauf à avoir des contraintes très fortes de conso mais ça peut arriver.

Citation:

---

Envoyé par padrino

La conso est (majoritairement) relative à la fréquence du système et non de l'oscillateur.

---

Je vois que tu fais la distinction entre Fosc et Fclk et tu as raison, je me suis mal expliqué dans mon précédent message mais c'est bien Fclk (l'horloge système qui fait pédaler le CPU + bus data et adresse) qui fait consommer le micro.

J'ai regardé la datasheet de ton PIC et je suis surpris de ne pas avoir trouvé de courbe de conso vs vitesse ??? Mais à titre d'exemple sur un MSP430G2553 si tu alimentes le micro en +3.3V et que tu le fais tourner à 1MHz, je parle de l'horloge système, il consomme environ 500uA (en mode actif, pas en veille), si dans les mêmes conditions tu montes l'horloge à 16MHz il va consommer 4mA. Presque 10x plus :aie:

Citation:

---

Envoyé par padrino

Cela sous-entend aussi que je doit éviter d'utiliser le clock divider (dans mon PIC18F26K83 "COSC" et "CDIV"). Sinon cela revient à générer (par exemple) 32Mhz (avoir plus de CEM), puis à diviser par 4 pour n'avoir que 8Mhz pour mon système

---

Pour avoir fait beaucoup de CEM car je faisais plus de hard que de soft, ce n'est pas tant l'oscillateur qui me gênait, c'était plutôt le clock système comme je disais plus haut. Avec un CPU et des bus qui pedalent à fond la caisse les variations de tensions sont rapides et ça se voit un peu dans les alimentations. Mon problème c'est que je mesurais des courants de l'ordre de la dizaine ou centaines de nA et ces petites variations de tensions pouvaient se voir dans mes ampli op. Bref ! Je suis quasiment sur que d'un point de vu bruit, il n'y a quasiment pas de différence entre un oscillateur à 8MHz divisé par 1 pour générer un clk système de 8MHz ou un 32MHz divisé par 4 pour générer un clk système de 8MHz

Donc j'ai bien compris. Cool, ça veut dire que c'est bien expliqué, merci !!

Tiens justement, bonne coïncidence, pendant que je joue avec des PICs, je viens d'avoir un bug de l'UART et MPLABX qui m'affiche 50% d'erreur :) à cause de la fréquence de l'horloge. C'est résolue mais je vais creusé un peu pour comprendre.

Je suis Ingé Hardware & Indus depuis 7 ans, mais je me sens incomplet, faut que j'arrive à comprendre vraiment le soft embarqué. Prochaine étape, arrêter de tricher avec un MPLABX qui me chie du code ^^ et passer sur du MSP ou STM.

Merci pour l'explication, A+

Salut,
Personnellement, j'essaye d'éviter autant que possible les générateurs de codes, même si ça accélère le développement, car on perd rapidement la maîtrise du micro et on devient in fine dépendant du constructeur.

C'est très bien d'envisager : PIC18, MSP430 et STM32 car ça fait un panel plutôt large et diversifié. La migration de PIC vers des micros MSP430 ou ATMEGA n'est pas très compliqué par contre je dois avouer que migrer vers ARM m'avait demandé à l'époque bien plus d'efforts.

A+

Oui je m'en doute que c'est pas bon, j'en vois les limites, étant plutôt un hardeux , je ne peux pas tous faire. Et je fais un blocage au bas niveau, j'aurai beaucoup de mal à coder l'I2C à partir d'une datasheet, ça me parait vraiment long et laborieux, peut-être que je me trompe.