[PIC16F877A] Réalisation d'un chronomètre - pb de précision

[scls19fr]

Bonjour,

je suis en train de réaliser un chronomètre avec un afficheur (contrôleur HD44780 - 20x4 caractères) et un PIC16F877A en C (avec MPLAB et HI-TECH C Compiler for PIC10/12/16 MCUs).

J'utilise un quartz à 4 Mhz.

Je voudrais faire un chrono précis au millième de seconde

J'ai vu ce post :
http://forums.futura-sciences.com/el...ic-16f877.html

Il est question de l'utilisation du Timer1 (16 bits) or je rencontre un problème...

le chrono défile un peu trop lentement... (dérive de 2 secondes environ sur 1 minute !)

J'utilise les interruptions... donc je pensais que je pouvais faire quelque chose de très précis.

Déjà premier truc que je ne comprends pas :

// Timer 1 (16 bits) utilisé pour l'horloge
// Quartz 4 Mhz =>1 instruction = 1 µs
pour moi c'est 0.25 µs pas 1 ?


ensuite pour obtenir un précision de 1ms j'ai mis une interruption toutes les 0.1 ms et j'ai fait le calcul suivant :

	xx++;
	if (xx==10000) {
		xx=0;
		ss++;
		if (ss==60) {
			ss=0;
			mm++;
			if (mm==60) {
				mm=0;
				hh++;
				if (hh==24) {
					hh=0;
					//dd++;
				}
			}
		}
	}

hh désigne les heures ; mm les minutes ; ss les secondes et ; xx les 0.1ms

est-ce une bonne idée de travailler à une période inférieure à la précision souhaitée ?

Voici l'initialisation du timer1

	T1CON = 0x00 ; // Prédivision de l'horloge par 1
	TMR1H = 0xFF;
	TMR1L = 0x9B; // 100us=0x9B 10us=0xF5 // 0xC1 ; // 0xFFFF - 0xFFC1 = 62 => 62 x 1 µs = 62 µs
	TMR1ON = 1 ; // On lance le timer 1
	TMR1IE = 1 ; // On autorise les interruptions du timer 1

	// Autorisation des interruptions
	PEIE = 1 ; // Autorisation des IT peripherique
	GIE = 1 ; // Autorisation général des IT

j'effectue l'affichage dans la boucle infini (pas dans une interruption à part avec le timer0 par exemple) - est-ce une bonne idée ?

Que me suggéreriez-vous pour tester précisément la dérive dans le temps (je dispose d'un oscilloscope) ?
bref comment rendre mon chronomètre plus "crédible".

Merci d'avance
-----

[invite7a49d0d5]

Bonjour,

>est-ce une bonne idée de travailler à une période inférieure à la précision souhaitée ?

je crois pas... moi je générerais des périodes de 1ms...

après ya toujours un décalage... notamment dû à la
précision du quartz et la sauvegarde des registres...
devoir ajouter +/- 20 à la valeur théorique est courant
pour avoir un "beau" 1000Hz à l'oscillo/fréquencemètre...
...

une fois que t'as un "beau" 1000hz, t'as une horloge précise à la ms...


vede
;O]
_________________
...

[scls19fr]

Et je l'observe comment ce beau 1000 Hz ?

Il faut que dans mon interruption je change la valeur de 1 en 0 sur une patte.

en initialisant
TRISx = 0;

et à chaque interruption
PORTx = ~PORTx;

ou il y a plus "propre"

(le temps de ces opérations n'étant probablement pas négligeable)

[invite7a49d0d5]

ps : ou même 10ms... (10 000)
il me semble que cela permet une meilleure plage de réglage, d'où de résolution(1µs)...
ou même 50?

[A voir en vidéo sur Futura]

[invite7a49d0d5]

re ;O]

oui c'est ça, tu mets un port en sortie,
et tu changes son état (1/0) au début
de l'interruption...

théoriquement ça prends pas plus de 2 cycles...
à prendre en compte si re-init val Timer après...

'l"idéal" est de re-init le TIMER (TIMERH et L)
dés le début de l'interruption...
dans ce cas, suffit théoriquement de rajouter
10, pour être à 1000Hz (10µs = sauvegarde des registres)...

[ftorama]

Déjà premier truc que je ne comprends pas :

// Timer 1 (16 bits) utilisé pour l'horloge
// Quartz 4 Mhz =>1 instruction = 1 µs
pour moi c'est 0.25 µs pas 1 ?

Et non parce que les PIC ne sont pas des microcontrôleurs RISC. Il leur faut 4 temps de cycle pour éxécuter une instruction. Donc un PIC 12F,16F ou 18F est 4 fois plus lent que son quartz. Sur les 18F, Microchip cache la misère en multipliant par 4 la fréquence du quartz. Sur les 24F et les DsPic, je crois que le ratio est toujours de 2.

Sur ton 16F, rajoute le fait que tu n'aies que 35 instructions (et donc l'obligation d'en utiliser un paquet par instruction C) et tu comprendras que tu auras toutes les peines du monde à faire un truc rapide sur ces trucs.

bref comment rendre mon chronomètre plus "crédible".

En utilisant des microcontrôleurs crédibles

D'un autre côté, 1milliseconde, ça devrait être atteignable.... mais surement en boostant le quartz

[scls19fr]

En utilisant des microcontrôleurs crédibles

D'un autre côté, 1milliseconde, ça devrait être atteignable.... mais surement en boostant le quartz

Des noms ?

sinon je pensais à une solution couplée à une RTC DS1307 ?

il y a aussi des PIC avec un quartz à 32 768 Hz

vos avis m'intéressent.

car bricoler la valeur d'un registre à +/- 20 ... ça me plait pas trop comme soluce...

[invite7a49d0d5]

car bricoler la valeur d'un registre à +/- 20 ... ça me plait pas trop comme soluce...

oui, mais une fois que c'est réglé, ça ne bouge plus...
si bon quartz...

[invite7a49d0d5]

ps : comme écris ftorama, en boostant le quartz (20Mhz) tu gagneras en précision...

[scls19fr]

oui mais plus ça "pédale" vite plus ça consomme non ?

Donc je ne sais pas si c'est un bon plan de changer de quartz...

après je pense que ça peut occasionner un peu de modif dans le code de changer de quartz (notamment pour la gestion du lcd)

J'ai bricolé la valeur des registres du timer 1

de 0xFF17 théorique pour 1ms je suis tout de même à 0xFF36 !

j'ai utilisé PORTB en sortie pour ça... mais il y a peut-être moyen d'utiliser
une broche dédié à ça... (une solution plus liée directement au timer 1) ?

après je me pose quelques question sur cette "bidouille"...

je vais devoir changer cette valeur si
- le quartz n'est pas stable (avec variation de température)
- la tension d'alim fluctue un peu (derrière un RIT 7805 normalement ça doit pas trop)

mais surtout au niveau du code :
- si je rajoute d'autres interruptions
Comment gérer la "priorité" des interruptions ?

- si le code dans la boucle change... est-ce que ça va avoir une influence ?

Bref je suis modérément satisfait mais ça marche... enfin ça compte...

[invite7a49d0d5]

rere ;O]

-oui mais plus ça "pédale" vite plus ça consomme non ?
oui

je vais devoir changer cette valeur si
- le quartz n'est pas stable (avec variation de température)
- la tension d'alim fluctue un peu (derrière un RIT 7805 normalement ça doit pas trop)
ça reste minime, à moins d'avoir des mauvais composants...

mais surtout au niveau du code :
- si je rajoute d'autres interruptions
Comment gérer la "priorité" des interruptions ?
en y testant les flags... et en commençant par celui du Timer1...

- si le code dans la boucle change... est-ce que ça va avoir une influence ?
non, si tu commences toujours ton interruption par l'init. des valeurs TMR1H et L...
et finis l'interruption par l'effacement du flag TMR1IF...

[ftorama]

Des noms ?

un AVR....n'importe lequel pourvu qu'il ait assez de broches:
www.atmel.com/products

Si tu as un Pickit2, tu n'auras même pas besoin de chercher un nouveau programmateur

[scls19fr]

Je connais les AVR... j'ai un peu joué avec mais comme tout le monde fait du PIC... je m'y suis mis

[invite7a49d0d5]

re re re ;O]

tes valeurs m'étonnent...

>de 0xFF17 théorique pour 1ms ...

non, théoriquement c'est (1000µs @ 4Mhz @vec Prescaler = 1) :

65536 - 1000 = 64536
soit :
TMR1H = 64536 / 256 = 252 = FC
TMR1L = 64536 % 256 = 24 = 18

[scls19fr]

oui pardon... j'avais 0xFC17
j'avais fait 65535-1000...
mais tu as surement raison sur ce point aussi c'est 65536-...
car l'interruption a probablement lieu après le passage de 0xFFFF à 0x0000
et pas de 0xFFFE à 0xFFFF

donc je suis passé de 0xFC17 théorique à 0xFC36 pratique

[ftorama]

Je connais les AVR... j'ai un peu joué avec mais comme tout le monde fait du PIC... je m'y suis mis

rraahh mon coeur me lâche....

[scls19fr]

rraahh mon coeur me lâche....

J'ai l'impression qu'il va me manquer quelque chose de bien avec les AVR : les interruptions externes

il n'y en a qu'une sur le 16F877 ?

comment l'utilise-t'on ?

[ftorama]

comme on peut

je sors.....

aahhh un Atmega644 avec une int par port et déclenchable sur toutes les pins....

Plus sérieusement, y'a pas que les int qui vont te manquer...la rapidité, la programmation assembleur confortable, les registres de travail....tant que tu programmes en C, tu ne t'en rends pas trop compte, mais ne compare pas tes progs assembleur

[invite03481543]

Et non parce que les PIC ne sont pas des microcontrôleurs RISC. Il leur faut 4 temps de cycle pour éxécuter une instruction. Donc un PIC 12F,16F ou 18F est 4 fois plus lent que son quartz. Sur les 18F, Microchip cache la misère en multipliant par 4 la fréquence du quartz. Sur les 24F et les DsPic, je crois que le ratio est toujours de 2.

Sur ton 16F, rajoute le fait que tu n'aies que 35 instructions (et donc l'obligation d'en utiliser un paquet par instruction C) et tu comprendras que tu auras toutes les peines du monde à faire un truc rapide sur ces trucs.

Bonsoir,

vous pouvez ne pas aimer les PIC mais éviter un ton polémique svp.
sans quoi je me verrai contraint de modérer vos propos qui visiblement ne sont pas objectifs.
Microchip n'est pas le seul fabricant de microcontroleurs mais quand même le plus important pour les 8 bits, donc ce n'est pas sans raison et en tout cas pas pour les mauvaises raisons que vous voulez dénoncer.
Pour être crédible il faut éviter de donner de fausses informations et si possible parler de ce qu'on connait vraiment.

[ftorama]

Bonsoir,

vous pouvez ne pas aimer les PIC mais éviter un ton polémique svp.
sans quoi je me verrai contraint de modérer vos propos qui visiblement ne sont pas objectifs.
Microchip n'est pas le seul fabricant de microcontroleurs mais quand même le plus important pour les 8 bits, donc ce n'est pas sans raison et en tout cas pas pour les mauvaises raisons que vous voulez dénoncer.
Pour être crédible il faut éviter de donner de fausses informations et si possible parler de ce qu'on connait vraiment.

Il n'y a aucune polémique dans mes propos, seulement des faits. Un processeur RISC est défini par deux critères, un jeu d'instructions réduit et surtout une exécution généralement en 1 temps de cycle.

Avec des exécutions au minimum en 4 temps de cycle, les PIC que j'ai cité ne peuvent objectivement pas être considérés comme des processeurs RISC.

Concernant le leadership de Microchip, il est indéniable sur la communauté amateur mais est au niveau mondial, le 7 ème constructeur mondial (Atmel étant 8ème). De mémoire, NEC est leader du marché et loin devant, y compris dans les archis 8 bits. Seulement ces archis ne sont pas dispos auprès de l'amateur ou très difficilement.

A aucun moment, je n'ai donné de fausses informations. Sachant que je m'aventure en terrain glissant, et votre intervention le prouve, je vérifie systématiquement ce que j'avance.

Cordialement
ftorama

[ftorama]

Vérification faite, en 2008, les archis 8051 tenaient 19% de parts de marchés contre 12% pour les PICs

Source:
http://www.emittsolutions.com/images...lysis_2008.pdf page 9

[invite7a49d0d5]

hi ;O]

en neffet... NEC... c'est mal adapté au particulier ;O]
à moins d'avoir besoin d'une carte quadri-proc supportant les derniers Pentium 4Ghz @16 coeurs ;O]
un "mini-CRAY" quoi ;O]

vede
;O]
___________________
...

[RISC]

Salut scls19fr,

Si tu utilises un quartz 4MHz, la précision de ton chronomètre n'a rien à voir avec ton PIC16F877A mais simplement avec la précision de ton quartz.
Typiquement les quartz sont précis à quelques PPM.
Exemple : si tu utilises un quartz à 10 PPM, si ton programme est correct, tu auras une dérive de 10 sec / million de sec. Fais le calcul et tu vas voir que c'est très peu ;=).
Si tu veux quelquechose de très précis tu peux choisir un TCXO (oscillateur à quartz compensé en température).

Ce qui est important c'est de bien choisir un taux de division qui soit entier sans quoi tu auras une erreur permanente.

Si tu utilises le mode prescaler 1/1 et que tu divises par 1000 dans le TIMER1 (valeur de départ = 65536 - 1000 = 64536), tu auras une interruption toutes les Fosc/4 x 1 x 1000 = 1us x 1000 = 1ms ;=)

es-tu bien sur de fonctionner sur ton quartz externe (et pas sur l'oscillateur RC interne) ?
Peux-tu faire voir comment tu as initialisé les bits de configuration dans ton programme ?

a+

[scls19fr]

C'est bien le quartz de 4 Mhz... la preuve si je l'enlève ça s'arrête de tourner...

désolé je ne peux pas te donner les bits de configurations.... je n'ai pas le programme ici... mais je sais plus si j'ai mis l'oscillateur en XT ou en HS... bref de toute façon c'est pas RC...

[invite03481543]

Il n'y a aucune polémique dans mes propos, seulement des faits. Un processeur RISC est défini par deux critères, un jeu d'instructions réduit et surtout une exécution généralement en 1 temps de cycle.

Merci je suis un peu au courant, cela dit c'est déjà rentrer dans une polémique que de casser systématiquement les PIC sur un sujet où vous répondez à une question en remettant en cause le choix du microcontroleur sans aborder la vraie problématique de la précision d'un chronomètre.
Cela dit les PIC possèdent bien une architecture RISC de part leur jeu d'instructions limité ce qui fondamentalement le différencie des autres architectures et la plupart des instructions occupent un mot de la mémoire de programme.
Rien n'empêche de faire un chronomètre avec un PIC, de même que rien n'oblige à faire un chronomètre avec un PIC...
Il vous suffit de présenter une solution allant dans ce sens, c'est aussi simple que ça.

Avec des exécutions au minimum en 4 temps de cycle, les PIC que j'ai cité ne peuvent objectivement pas être considérés comme des processeurs RISC.

Ca c'est encore polémique, nous avons déjà eu ce genre de discussion stérile à maintes reprises.

Concernant le leadership de Microchip, il est indéniable sur la communauté amateur mais est au niveau mondial, le 7 ème constructeur mondial (Atmel étant 8ème). De mémoire, NEC est leader du marché et loin devant, y compris dans les archis 8 bits. Seulement ces archis ne sont pas dispos auprès de l'amateur ou très difficilement.

Vous devriez raffraichir votre mémoire et vos informations, il est de plus erroné de croire que le particulier ou l'amateur n'a pas accès aux produits dits professionnel, internet est passé par là depuis.

A aucun moment, je n'ai donné de fausses informations. Sachant que je m'aventure en terrain glissant, et votre intervention le prouve, je vérifie systématiquement ce que j'avance.

Vous avez raison ce serait mieux pour la séreinité et la qualité des débats futurs.

[ftorama]

Merci je suis un peu au courant, cela dit c'est déjà rentrer dans une polémique que de casser systématiquement les PIC sur un sujet où vous répondez à une question en remettant en cause le choix du microcontroleur sans aborder la vraie problématique de la précision d'un chronomètre.

Sur ce sujet en particulier, ça a été dit sur le ton de la plaisanterie, surtout que je rajoute que ensuite que sur le PIC, c'est faisable. Je l'autocite pour l'occasion:

D'un autre côté, 1milliseconde, ça devrait être atteignable.... mais surement en boostant le quartz

Cela dit les PIC possèdent bien une architecture RISC de part leur jeu d'instructions limité ce qui fondamentalement le différencie des autres architectures et la plupart des instructions occupent un mot de la mémoire de programme.

Mais pas par leur vitesse d'exécution, qui est censé être l'argument n°1 en faveur des archis RISC. C'est déja mieux qu'un 8051 avec ses 12 cycles d'horloge par temps de cycle, mais ça n'est pas encore ça....objectivement.

Rien n'empêche de faire un chronomètre avec un PIC, de même que rien n'oblige à faire un chronomètre avec un PIC...

Je n'ai jamais dit ça autrement que sur le ton de la plaisanterie encore une fois.

Il vous suffit de présenter une solution allant dans ce sens, c'est aussi simple que ça.

J'y travaille justement mais la rédaction de cours, tutos et exemples appliqués prend un temps fou

Ca c'est encore polémique, nous avons déjà eu ce genre de discussion stérile à maintes reprises.

Mon point de vue au-dessus.

Vous devriez raffraichir votre mémoire et vos informations, il est de plus erroné de croire que le particulier ou l'amateur n'a pas accès aux produits dits professionnel, internet est passé par là depuis.

Depuis au moins 2002, Microchip clame être le premier....selon la manière de tourner les chiffres, tout le monde peut être premier, et personne ne se gêne pour arranger les chiffres son avantage.
Il suffit que Microchip vende 12 millions de PIC, que NXP et TI fassent chacun 9 millions de 8051. Microchip est bien premier en termes de volumes, mais l'archi 8051 reste archi-majoritaire.

Vous avez raison ce serait mieux pour la séreinité et la qualité des débats futurs.

C'est ce que j'ai toujours fait, et pour les avoir vérifiés, je maintiens mes arguments.

[invite03481543]

Mon rôle ici n'est pas de vous convaincre de quoi que ce soit mais d'assurer un ton serein et objectif aux discussions qui ne conduise pas au pugila.
Donc désormais sur ce genre de sujet il vaut mieux prévenir que guérir.

Salutations.