Dérive PIC18

[invitee4b44406]

Bonjour,
Je suis un étudiant en informatique pas spécialement calé en électronique et je développe dans le cadre de mon travail un prototype basé sur un PIC18 qui doit avoir les deux caractéristiques suivantes.

- Très faible consommation
- RTC

Dans cette optique, j'utilise une horloge externe à 32768hz (quartz sur Timer1) avec des interruptions asynchrones. Je charge le registre TMR1H à 0xF0 afin d'obtenir 8 interruptions par seconde (le proto se doit d'être réactif à des entrées brèves).
Le timer1 est également la source de mon horloge système pour minimiser la consommation d'énergie et je tourne bien entendu en sleep mode.

Mon problème est que j'observe une dérive très importante (de l'ordre d'une minute par jour). Je pense que le problème vient du fait que mon processeur est trop lent pour traiter l'interruption en 15,25us et que l'erreur cumulée induit une dérive comme décrit dans http://ww1.microchip.com/downloads/e...Doc/80329a.pdf
Je ne comprends cependant pas bien comment implémenter la solution proposée dans l'errata (je programme en C avec la librairie HITECH) et de plus je m'interroge sur la faisabilité d'une RTC sans dérive si le processeur travaille à la même vitesse que la clock... Ne vas-t-on pas nécessairement laisser filer des coups de clock durant le traitement de l'interruption?
Est-ce que quelqu'un pourrait m'éclairer quand à la démarche adéquate à adopter pour résoudre ce problème?
Merci d'avance!
-----

[invitee05a3fcc]

Mon problème est que j'observe une dérive très importante (de l'ordre d'une minute par jour).

une erreur (pas une dérive !) de 60 secondes par jour, c'est une erreur de 60/86400 =700 ppm

C'est un peu élevé pour un quartz, mais à la limite du normal pour un quartz horloger monté sur un microprocesseur. Regarde les valeurs des capacités mises en parallèle sur les entrées quartz. Une erreur de 10 secondes/jour serait plus logique

[invitee4b44406]

Bonjour et merci pour cette réponse.
Je vais me renseigner sur les capa car ce n'est pas moi qui ai réalisé le montage du chip.
Cependant pour mon application il me faut une erreur maximale de 0,5s par jour, comment pourrais-je atteindre un tel chiffre?
En ajustant à tâtons la valeur préchargée dans les registres TMR1H et TMR1L, j'ai pu approcher une erreur d'environ 3s/jour mais cela reste beaucoup trop pour les besoins de mon prototype.
Merci de votre aide!

[invitee05a3fcc]

une lecture interessante : http://forums.futura-sciences.com/thread65801.html
tu veux une stabilité de 0,5/86400= 6 ppm avec une faible consommation
C'est mission impossible ....
Il faut utiliser un module oscillateur séparé du PIC ou un quartz thermostaté

Tu as aussi la solution de recaller réguliérement ton temps avec un module DCF77 : http://fr.wikipedia.org/wiki/DCF77 et la, tu as une dérive d'une seconde en 1000000 d'année (sauf erreur de ma part sur le nombre de "0")

[A voir en vidéo sur Futura]

[invitee05a3fcc]

Attention : le DCF77 ne marche que dans un rayon "approximatif" de 1500 Km autour de Francfort-sur-le-Main (Allemagne). La réception peut être pertubée facilement (et alors, pas de re-synchronisation !)

[invitee4b44406]

Merci pour cette réponse!
Concernant les quartz thermostatés, en dépit de leur coût additionnel, ont-ils également une consommation de courant supérieure?
Pour le DCF77 je suis dans le rayon (Genève) et j'ai à la maison un réveil qui se synchronise avec l'émetteur. Je me demande en revanche ce qu'il en est de la consommation du module récepteur et de son prix?

[invitee05a3fcc]

Quartz thermostaté = chauffage à 60° = consommation
Pour le DCF77, la consommation importe peu, tu mets en marche deux fois par jour le récepteur pour faire une synchronisation.

[invitee4b44406]

Bien vu!
Une idée du prix de récepteurs DCF77?

[invitee05a3fcc]

Ici, c'est un forum! Pas une boutique, ni SVP1111.
Tu te prends ton clavier par la main et tu cherches sur le WEB

[invite2562e666]

une lecture interessante : http://forums.futura-sciences.com/thread65801.html
tu veux une stabilité de 0,5/86400= 6 ppm avec une faible consommation
C'est mission impossible ....
Il faut utiliser un module oscillateur séparé du PIC ou un quartz thermostaté

ça existe et s'apelle DS3232 (déviation nominale = 2ppm)
C'est une RTC, avec sortie 32,768Khz donc parfaitement utilisable.
C'est pas un quartz thermostaté, mais il y a une correction (capacités commutées) en fonction de la température.
Il y a également une correction pour le vieillissement.


Et, ce qui ne gâte rien, c'est disponible en sample gratuit.

thierry

[invitee0bbe70d]

Bonjour,

Mon problème est que j'observe une dérive très importante (de l'ordre d'une minute par jour). Je pense que le problème vient du fait que mon processeur est trop lent pour traiter l'interruption en 15,25us et que l'erreur cumulée induit une dérive comme décrit dans http://ww1.microchip.com/downloads/e...Doc/80329a.pdf
Je ne comprends cependant pas bien comment implémenter la solution proposée dans l'errata (je programme en C avec la librairie HITECH)

L'implémentation du workaround qui corrige l'erreur que tu mentionnes doit impérativement être fait en assembleur. N'utilises pas les librairies tu ne pourras pas y arriver...Le code est fourni dans l'exemple 2 du document errata. Tu peux certainement adapter cela facilement dans le compilateur HiTech.

Même si tu fonctionnes avec une fréquence faible la correction est possible.
Quelle fréquence utilises-tu pour l'oscillateur principal ?

Les quartz 32kHz ont une erreur au mieu de 50ppm sur toute la gamme de température...donc la solution du TCXO 32kHz proposée dans les posts précédents est nécessaire si tu veux une erreur très faible.

Une autre alternative est d'utiliser un PIC24 plutôt qu'un PIC18 car les PIC24 intègrent en standard une RTCC avec un système de correction en température qui nécessite simplement un capteur de température externe. Cette correction programmable peut corriger jusqu'à +/-250ppm. Avec une bonne implémentation on peut arriver à +/- 10ppm.

[invitee4b44406]

Merci à tous pour vos pistes très intéressantes!
Le DS3232 semble être un super produit, je vais me renseigner sur ce dernier mais j'imagine que le prix et la consommation vont s'en faire ressentir.

Je te remercie microchip, je n'avais pas pensé à simplement lancer les instructions en assembleur!
Ma source d'horloge pour le système est dérivée du timer1 donc je tourne à 32768Hz.

J'avais effectivement entrevu le pic24 comme une solution avec son RTCC très séduisante mais je me demande si la migration du code (assez conséquent) vers un pic24 était chose aisée ou alors un véritable casse tête?

[invitee0bbe70d]

Bonsoir,

Quelles sont tes priorités ?
1/ Prix du système ?
2/ Quelle erreur max est acceptable pour ton horloge par jour/mois/an ?
3/ A quelle température fonctionne ton système (min/max) ?
4/ A quelle fréquence dois-tu réveiller ton micro ?

Concernant le portage PIC18 --> PIC24, les périphériques sont identiques mais l'architecture est très différente. Si ton soft est écrit en C ca facilite fortement le portage.
Si tu as utilisé les librairies du C18, le portage est même très simplifié.
Ce document explique la migration PIC18 --> PIC24

[invite2562e666]

Bonsoir,

Ce document explique la migration PIC18 --> PIC24

Document de 54 pages dont la conclusion est la suivante :
"Ultimately, the user will need to review their application’s design and implementation, and make the decisions as to how their code and hardware design must be changed to work on the new platform."

C'est plus une migration mais une émigration de masse...

th.

[invite2562e666]

PS: Je trouve personnellement très malsain et de très mauvais gout qu'un représentant officiel d'une marque commerciale intervienne directement sur un forum en principe destiné aux amateurs, d'autant plus que les interventions de ce représentant consistent principalement en des renvois vers le site microchip.

Merci aux modérateurs de réfléchir à cette situation.

thm

[invitee4b44406]

Mes priorités sont les suivantes par ordre décroissant d'importance:

Précision RTC 6ppm max (critique)
Faible consommation
Prix réduit

Le dispositif est conçu pour fonctionner dans un milieu ou la température varie très peu (intérieur) et je réveille le chip assez rarement (8 fois par seconde pour les interruptions du timer1 et lors de rares événements externes enregistrés par un capteur).
J'ai utilisé la librairie HITECH pour le PIC18 et je pense effectivement que la migration vers pic24 est possible sans trop de complications mais que cela n'est pas l'affaire d'une journée non-plus.

Pour répondre à thm, je ne suis personnellement pas dérangé par le fait que microchip me renseigne sur ses produits dans la mesure où je les utilise déjà (pic18) et où son pseudo est suffisamment explicite pour que l'on ne puisse l'accuser de faire de la pub discrètement.

[invitee0bbe70d]

Bonjour,

Ton cahier des charges est clair.
Je pense qu'il vaut mieux rester en PIC18 si l'aspect cout n'est pas ta priorité.

Si tu cherches +/- 6 ppm il faut passer
* soit par un TCXO 32kHz

* soir par un chip d'horloge temps-réel externe avec correction
NXP vient de sortir une horloge externe sur bus SPI (PCF2123) avec une conso incroyable de 100nA sous 2V. impressionant !! par contre elle utilise un 32khz standard donc il faut la corriger (meme méthode utilisée apparemment que les PIC24F).

Point très important, le réveil du micro...
Si tu utilises un quartz externe ou résonnateur externe, il faut attendre à chaque réveil que l'oscillateur soit stable ET si tu l'utilises, que la PLL soit lockée ce qui entraine une "surconsommation".
Mon conseil est d'utiliser un réveil sur l'oscillateur RC interne (très rapide) et si nécessaire, de basculer sur l'oscillateur externe.

Quel type d'oscillateur principal utilises-tu (quartz, résonnateur, RC interne) ?
A quelle fréquence ?
Avec ou sans la PLL ?

[invitee4b44406]

Ok, merci je vais regarder ces deux références!
Concernant le réveil du micro je ne suis pas sur de bien comprendre ta remarque (comme je le disais je ne suis pas expert en electro). Ma primary clock source est le Timer1(32768Hz) donc lorsque le micro se réveille je ne devrais pas avoir besoin d'attendre que ce dernier se stabilise non?
Concernant la PLL je ne l'utilise pas.

[invitee0bbe70d]

Bonjour,

1/ Quelle référence précise de PIC18F....utilises-tu ?

Oscillateur principal : si j'ai bien compris, tu as donc connecté ton 32kHz sur les broches OSC1 et OSC2 (primary oscillator) et tu as choisi le mode LP pour les bits de configuration de l'oscillateur ?

2/ Cela veut-il dire que tu exécutes tes instructions à 32kHz/4 ?
cela veut dire tcycle = 12,2ms (très lent)
3/ ou Bascules-tu en mode oscillateur interne (8MHz) pour exécuter les instructions ?

4/ Sous quelle tension travailles-tu ? (il existe quelques nouveaux PIC18 très faible consomation (1uA / 32kHz) mais ils fonctionnent uniquement de 1.8V à 3.6V. Cela te permettrait de réduire ta consommation en mode 32kHz ;=)
On peut les reconnaitre à leur référence PIC18FxxKxx (un K au milieu de la référence comme le PIC1825K20 ou PIC18F45K20).