PIC, gestion de l'heure ?

[zoocoral]

Bonjour,

je cherche un montage et des explications concernant la gestion de l"heure et éventuellement de la date pour un PIC16F877. Je programme en C sous mikroC.

C'est pour réaliser un programmateur de lumières

Merci de votre aide

[paulfjujo]

bonjour,

le plus simple est avec l'usage d'un circuit RTC genre DS 307
communiquant en I2C, voir exemple sur http://paulfjujo.free.fr/
rubrique PWM avec un 16F876
PulseWidthModulation.c
Mise à l'heure via liaison RS232 PC

[Seb.26]

+1 pour une RTC, avec une solution 100% soft, tu auras une derive dans le temps ... tout depend de la precision à long terme que tu souhaite ...

[Toufinet]

+1 pour une RTC, avec une solution 100% soft, tu auras une derive dans le temps ... tout depend de la precision à long terme que tu souhaite ...

Je vois pas du tout pourquoi tu aurais plus de précision avec une RTC qu'avec un PIC + TMR1 en interruption !
La RTC n'est là que pour incrémenter des registres et assurer un mode de communication ... elle n'est pas plus hardware qu'un PIC + TMR1 asynchrone en interruption !

[Seb.26]

Je vois pas du tout pourquoi tu aurais plus de précision avec une RTC qu'avec un PIC + TMR1 en interruption !
La RTC n'est là que pour incrémenter des registres et assurer un mode de communication ... elle n'est pas plus hardware qu'un PIC + TMR1 asynchrone en interruption !

Je ne sais pas non plus, sans doute car une RTC "ne fait que cela" alors qu'un PIC gère d'autre trucs, et si tu utilise d'autres IT, celles ci peuvent se "percuter" ...

En tout cas, c'est ce que j'ai constaté ... j'avais fait une pseudo-RTC dans mon projet, et l'heure se decalait parfois jusqu'a une s par jour ... à cause des autre IT je pense ... même en plaçant l'IT du timer en High ... donc non interuptible ...

Mais dans mon projets, il y avait d'autre IT en high, donc peut être que si ton IT rtc est la seule, le problème n'est pas le même ... ? ... toujours est t'il que j'ai ajouté une RTC I2C qui synchronisait ma rtc soft, et que le problème était réglé avec une MAJ par heure ...
( par contre la rtc I2C que j'avais ne gerait que 7 jours de comptage ... bof )

[HULK28]

Aussi parcequ'un quartz "horloger" dérive moins qu'un quartz de plusieurs MHz.
Enfin parcequ'il est plus commode de ne lire que des registres...

[Toufinet]

Je suis pas du tout d'accord avec vous.

Une RTC a besoin d'un quartz 32.768kHz en entrée, et la dérive n'est dûe EXCLUSIVEMENT qu'à la dérive du quartz. Si tu met le même quartz en entrée du TMR1 d'un PIC, tu auras EXACTEMENT la même dérive !
Je met quiconque au dédi de prouver le contraire en pratique.

Par contre, dans le cas où tu as plusieurs IT sur ton PIC, et qu'une IT intervient pendant l'IT générée par TMR1, il est claire que tu auras une dérive plus importante ... mais dans ce cas, il y a une mauvaise conception soft !

Concrètement, ce que je veux dire, c'est que physiquement parlant, il n'y a pas plus de dérive sur un PIC que sur une RTC. Le soft vient après, mais dans ce cas ce n'est plus comparable, car pour un soft correctement conçu, on retombe sur les paramètres physiques.

[RISC]

Aussi parcequ'un quartz "horloger" dérive moins qu'un quartz de plusieurs MHz.
Enfin parcequ'il est plus commode de ne lire que des registres...

Absolument d'accord.
Pour ceux qui n'ont pas compris le message de Hulk, il fait référence à la différence de dérive entre un quartz 32kHz et un quartz (par exemple) à 4.092 MHz.

Pour comprendre cela, il suffit de lire la datasheet d'un 32kHz et celle d'un quartz plusieurs MHz.
Dans le cas du 32kHz, la courbe dérive / température est en cloche (l'erreur s'ajoute autour des 25C et de plus l'erreur la + faible globale est de 50ppm)
Dans le cas d'un quartz, la courbe de dérive est en S allongé (l'erreur se compense plus ou moins autour des 25C et de plus l'erreur globale est de quelques ppm).

Conclusion, la dérive d'une horloge basée sur un 32kHz est TOUJOURS plus importante que celle basée sur un quartz à qq MHz (cela n'a rien à voir avec le fat que l'on fait l'horloge dans le micro par soft ou qu'elle vienne d'une puce externe).

Si on veut une horloge extrèmement précise, il faut alors utiliser un oscillateur externe (TCXO) qui est compensé en température intérieurement et encore plus précis qu'un quartz (attention dans ce cas on parle d'une horloge externe avec sa propre alimentation et donc pas question d'aller en standby...

a+

[invite76a]

Aussi parcequ'un quartz "horloger" dérive moins qu'un quartz de plusieurs MHz.

Absolument d'accord.
...
Conclusion, la dérive d'une horloge basée sur un 32kHz est TOUJOURS plus importante que celle basée sur un quartz à qq MHz (cela n'a rien à voir avec le fat que l'on fait l'horloge dans le micro par soft ou qu'elle vienne d'une puce externe).

a+

N'y a-t-il pas une certaine contradiction ? (ou alors, je suis trop fatigué)

th

[RISC]

N'y a-t-il pas une certaine contradiction ? (ou alors, je suis trop fatigué)

th

Tu as raison

En fait je suis en total...désaccord avec Hulk.

Merci pour la correction il est temps de

[HULK28]

Quand je parle de quartz horloger, je parle de ce modèle (voir document joint).
Si on parle du quartz "classique" à 32.768KHz en tube, nous sommes d'accord.
En fait j'aurai dû vous préciser qu'il s'agit d'un TCXO.

[DavidDB]

Salut,

Par contre, dans le cas où tu as plusieurs IT sur ton PIC, et qu'une IT intervient pendant l'IT générée par TMR1, il est claire que tu auras une dérive plus importante ... mais dans ce cas, il y a une mauvaise conception soft !

Il n'y aura dérive qu'à la condition unique que le traitement des autres interruptions soit plus long que l'intervalle entre deux interruptions du timer1.

Si le traitement de l'interruption du timer1 est retardée par d'autres interruptions, mais que l'interruption du timer1 est traitée avant le nouveau débordement du timer1, il n'y aura pas de dérive dû au soft.

Le problème de la dérive du quartz, n'étant pas un problème soft, mais il faut en tenir compte suivant la précision désirée.

David.

[Gérard]

Salut,



Il n'y aura dérive qu'à la condition unique que le traitement des autres interruptions soit plus long que l'intervalle entre deux interruptions du timer1.

Si le traitement de l'interruption du timer1 est retardée par d'autres interruptions, mais que l'interruption du timer1 est traitée avant le nouveau débordement du timer1, il n'y aura pas de dérive dû au soft.

Le problème de la dérive du quartz, n'étant pas un problème soft, mais il faut en tenir compte suivant la précision désirée.

David.

Bonjour,
Je suis d'accord avec David.
J'ai utilisé l'irq du timer1 à plusieurs reprises pour le comptage du temps et je n'ai pas rencontré de défaut.
Remarque : je n'utilise que l'irq de Timer1
Le Qz est un 3,2768MHz pour l'oscillateur principal et TMR1.

Dans un environnement type maison, la T° ne varie pas tellement que la fréquence du quartz en patisse. (suis-je dans l'erreur?)

[RISC]

Quand je parle de quartz horloger, je parle de ce modèle (voir document joint).
Si on parle du quartz "classique" à 32.768KHz en tube, nous sommes d'accord.
En fait j'aurai dû vous préciser qu'il s'agit d'un TCXO.

Excellent ce TCXO en 32kHz ;=))
Malheureusement je pourrais jamais utiliser dans mes applications un oscillateur qui consomme autant...Je suis en général condamné à qq uA...

Sur les nouveaux PIC24F, Microchip a intégré une RTCC utilisant un 32kHz qui peut être corrigé en temps-réel en fonction de la température. On peut rentrer la courbe de dérive de l'oscillateur et corriger jusqu'à +/-200 ppm. Il faut je crois utiliser un capteur de température mais j'ai pas tout bien compris...
Le chapitre est ici : http://ww1.microchip.com/downloads/e...Doc/39696a.pdf

a+

[HULK28]

Ah oui, en effet très intéressant tout ça.