Timer irrégulier lorsque instructions dans while(1)

[quichedood]

Bonjour à tous,

Petite colle du jour :

J'utilise un timer (TMR0) sur mon PIC 18F45K20 qui à chaque débordement provoque une interruption (priorité haute).

Avec MPLAB (debugger MPLAB SIM) je calcule à quelle valeur j'initialise mon compteur pour qu'à 10Mhz je compte pile 1 msec.

Je simule avec MPLAB SIM, ça marche parfaitement, 0 décalage, même pas 1 nano sec sur plus de 100msec.

Je me suis aperçu qu'en mettant ne serait-ce qu'un "delay" dans ma boucle "while(1)", j'ai un décalage aléatoire qui apparait sur mon timer.

Exemple (valeurs en msec) :
1.000000
2.000000
3.000400
4.000400
5.000400
6.000400
7.000400
8.000400
9.000400
10.000800

Vous allez me dire c'est rien mais pour un chronomètre qui se veut précis au millième ça m'embête un peu. Surtout qu'il y a bien un raison à ce comportement ...

Quelqu'un à une idée ?

EDIT, mon interruption :

void InterruptServiceHigh(void) {
	// ISR-Timer0
	if(INTCONbits.TMR0IE && INTCONbits.TMR0IF) {
		INTCONbits.TMR0IF = 0; // Breakpoint pour debug à ce niveau là
		TMR0L = 101; // Preset timer0
		++counter;
	}
}

-----

[ElMamat]

Salut,
c'est que de la theorie tout cela, avec un quartz de 10Mhz le temps que prend une instruction pour se realiser est de 100ns si en plus tu considere le temps qu il lui faut pour partir en interruption et si en plus tu travailles en 16 bits(ta variable counter) avec une architecture 8bits c est autant de temps perdu....
Apres si tu es vraiment pointilleux au niveau du temps faut verifier le code assembleur qui est generé.

[quichedood]

Hello,

J'entends bien, mais pourquoi avec une boucle while(1) vide ça fonctionne parfaitement et que dès que je met quelque chose à l'intérieur j'ai, un coup sur X, un décalage ?

C'est censé être une interruption prioritaire, le reste du programme ne devrait pas impacter cette interruption non ?

(après je suis bien conscient que compter les nano sec en codant en C n'est pas forcément la meilleure idée ).

[ElMamat]

Ca peut etre une instruction qui met plusieurs cycles d horloge a s'effectuer et c est autant de temps de perdu.

[A voir en vidéo sur Futura]

[invitefaaca50b]

ca prouve encore que la simulation, ca ne vaut rien, et en tout cas ca ne reflete absolument pas la realité des choses....

[ftorama]

Tu travailles avec un composant qui est 4 fois plus lent que sa vitesse d'horloge, qui demande un traitement pour savoir d'ou vient l'interruption et qui n'est pas fait pour être programmé en C....de là à dire que tu l'as cherché

Plus sérieusement, la fonction delay n'utiliserait pas une désactivation des interruptions pour maintenir un semblant de précision?

Regarde si son code-source est dispo et remplace là éventuellement par une série de nop

[quichedood]

Ca peut etre une instruction qui met plusieurs cycles d horloge a s'effectuer et c est autant de temps de perdu.

Bien vu, j'y avais pas pensé mais effectivement il suffit que mon interruption tombe au milieu d'une instruction de branchement (qui consomme 2 cycles si je ne dis pas de bêtise) pour que je perde 1 cycle soit à 10Mhz : 400ns.

Et vu que je travaille en C, des instructions de branchement je dois en avoir à la pelle

Bon au moins j'ai compris d'où ça venait !

Pour pallier partiellement à cet écart j'ai comme seule solution de faire tourner mon pic plus rapidement j'imagine ?
(sans changer de µproc ni tout recoder en asm )

Bizarre quand même que ce genre de situation ne soit pas prévu car même en assembleur j'utiliserai des instructions qui me couteraient 2 cycles. Or le timer est quand même prévu pour être utilisé dans des calculs précis, non ?

[DAUDET78]

Ce n'est pas parce que ton interruption est prise en compte avec un aléa de temps que tu accumules des erreurs dans ton timer ???? Quand il arrive à 0000 , il déclenche la demande d'interruption qui est traitée quand le µC a le temps) et il se recharge automatiquement à la valeur préparée à l'avance.

Ou alors, tu recharges ton timer dans la procédure d'interruption ? Mauvaise méthode de programmation .......

[quichedood]

Ce n'est pas parce que ton interruption est prise en compte avec un aléa de temps que tu accumules des erreurs dans ton timer ???? Quand il arrive à 0000 , il déclenche la demande d'interruption qui est traitée quand le µC a le temps) et il se recharge automatiquement à la valeur préparée à l'avance.

Ou alors, tu recharges ton timer dans la procédure d'interruption ? Mauvaise méthode de programmation .......

"prise en compte avec un aléa de temps" > hmmm ... càd ?
"tu recharges ton timer dans la procédure d'interruption" > là clairement oui c'est le cas, je dois sortir le maximum de mon interruption donc ...

[DAUDET78]

là clairement oui c'est le cas, je dois sortir le maximum de mon interruption donc ...

Je n'en vois pas la raison ..... et c'est une erreur de philosophie de programmation et il ne faut pas chercher plus loin la cause de ton problème !

[simon.]

Moi j'ai toujours pas compris ce que fait ton programme, ni d'où sortent les chiffres que tu affiches. Tu nous mettrais pas le programme en entier ?

[simon.]

Ou alors, tu recharges ton timer dans la procédure d'interruption ? Mauvaise méthode de programmation .......

Dans ta grande sagesse tu vas nous donner la bonne méthode je suppose ?

[quichedood]

Pourquoi j'avais fait ça : mon timer tourne en permanence, en gros à chaque débordement ma variable "counter" est incrémentée (1 débordement = 1msec).

Si je recharge mon timer en dehors de mon interruption mon compteur ne va pas être réinitialisé immédiatement après la fin de mon interruption, je vais donc avoir un décalage (les quelques instructions entre la fin de mon interruption et le bout de code dans mon while(1) qui rechargent mon timer).

Il y a un truc qui doit m'échapper mais je ne vois pas quoi ...

[quichedood]

Moi j'ai toujours pas compris ce que fait ton programme, ni d'où sortent les chiffres que tu affiches. Tu nous mettrais pas le programme en entier ?

Le programme est très long mais si je met l'essentiel ça donne à peu près ça :

// High priority interrupt vector
#pragma interrupt InterruptServiceHigh // "interrupt" pragma also for high priority
#pragma code InterruptVectorHigh = 0x08
void InterruptVectorHigh (void) {
	_asm
		goto InterruptServiceHigh //jump to interrupt routine
	_endasm
}

short long counter = 0;

void InterruptServiceHigh(void) {
	// ISR-Timer0
	if(INTCONbits.TMR0IE && INTCONbits.TMR0IF) {
		TMR0L = 101; // Preset timer0
		++counter;
		INTCONbits.TMR0IF = 0;
	}
}

void main (void) {
	// Timer 0
	T0CONbits.TMR0ON = 1; // Enables Timer0
	T0CONbits.T08BIT = 1; // Timer0 is configured as a 8-bit timer/counter
	T0CONbits.T0CS = 0; // Internal instruction cycle clock (CLKOUT)
	T0CONbits.T0SE = 1; // Increment on high-to-low transition on T0CKI pin
	T0CONbits.PSA = 0; // Timer0 prescaler is assigned. Timer0 clock input comes from prescaler output
	T0CONbits.T0PS0 = 1; // Timer0 Prescaler Select bits (1:2) 000=204.8µs, 111=26ms (presc = 1:16, TMR0L = 101 => 1ms)
	T0CONbits.T0PS1 = 1;
	T0CONbits.T0PS2 = 0;

	while(1) {

	}
}

En gros je compte les msec (whouuu passionnant )

[DAUDET78]

Le truc qui t'échappe, c'est que le timer se recharge tout seul, à chaque débordement, à la valeur que lui as donné la première fois.

Tu sais bien que je ne veux jamais rentrer dans les logiciels, aussi il faut que tu ailles voir le fonctionnement du timer dans la spécification de ton µC et comment on lui dit de fonctionner comme ça

PS: au besoin, dans ton simulateur, ne recharge plus le timer dans ton interruption .... et regarde ce qui se passe !

[simon.]

Le truc qui t'échappe, c'est que le timer se recharge tout seul, à chaque débordement, à la valeur que lui as donné la première fois.

Et la marmotte...

[simon.]

En gros je compte les msec (whouuu passionnant )

Et les chiffres que tu affiches représentent quoi ?

[quichedood]

Les chiffres ? ceux dans le premier post ?
C'est le temps écoulé entre 2 "Breakpoints" dans MPLAB en mode debug, en gros le seul moyen que j'ai trouvé pour vérifier que ma valeur s'incrémentera bien toutes les 1 msec.

Sinon, mon timer repart bien à 0 si je ne le réinitialise pas à chaque fois.

Dans la doc j'ai que ça : "The user can work around this by adjusting the value written to the TMR0 register to compensate for the anticipated missing increments."

[simon.]

Les chiffres ? ceux dans le premier post ?
C'est le temps écoulé entre 2 "Breakpoints" dans MPLAB en mode debug, en gros le seul moyen que j'ai trouvé pour vérifier que ma valeur s'incrémentera bien toutes les 1 msec.

Donc en gros c'est juste un pb de différence d'horloge entre ton pic et ton PC...

[DAUDET78]

Tu as un lien sur la spec du PIC 18F45K20 ?

[DAUDET78]

Je viens de regarder une spec de 16F84A que j'avais ... effectivement, ça n'existe pas ! Quelle connerie ! bon, il y a peut être des PICs qui ont cette fonction, mais il faut chercher ......

Quand je pense que la structure du 8051 (que j'ai beaucoup utilisé et qui date des années 1980) a cette fonction , cela me laisse pantois !

[quichedood]

Donc en gros c'est juste un pb de différence d'horloge entre ton pic et ton PC...

C'est juste un simulateur que j'utilise, je n'ai pas de debug hardware physiquement relié au PIC.

Je viens de regarder une spec de 16F84A que j'avais ... effectivement, ça n'existe pas ! Quelle connerie ! bon, il y a peut être des PICs qui ont cette fonction, mais il faut chercher ......

Quand je pense que la structure du 8051 (que j'ai beaucoup utilisé et qui date des années 1980) a cette fonction , cela me laisse pantois !

C'est vrai que ça éviterai d'écrire à chaque fois dans le registre !

http://ww1.microchip.com/downloads/e...Doc/41303G.pdf (page 155 pour ceux que ça intéresse).

[DAUDET78]

C'est vrai que ça éviterai d'écrire à chaque fois dans le registre !

Ca, ce n'est pas grave ! Mais on a un aléa de temps à chaque interruption.... et c'est bien ce que tu constates !

Deux solutions :

1. Les spécialistes des PICs te trouvent un PIC qui a un reload automatique du timer à chaque overflow
2. Tu te trouves une valeur de quartz qui, divisé par le prescaler et 256 ou 65536, te donne 1mS pour l'interruption
3. Tu changes de fournisseur (je sais que les architectures basées sur le 8051 ont le reload)

[DAUDET78]

Valeur de quartz catalogue

• 12288000 c'est 4096*3000 donc tu peux (à vérifier) généré une interruption toutes les 0,333333333333 mS . Tu en comptes 3 et tu as ta mS
• 24576000 c'est 2*4096*3000 donc tu peux (à vérifier) généré une interruption toutes les 0,333333333333 mS . Tu en comptes 3 et tu as ta mS

[bobflux]

Et la marmotte...

N'importe quel timer de n'importe quel uC décent est capable de générer une interruption tous les N cycles et de se recharger tout seul à la valeur N, ce qui fait que la latence d'interruption n'a aucune influence sur la période du timer (seulement sur l'interruption qu'il déclenche...)

Encore heureux !

[DAUDET78]

N'importe quel timer de n'importe quel uC décent est capable de générer une interruption tous les N cycles et de se recharger tout seul à la valeur N, ce qui fait que la latence d'interruption n'a aucune influence sur la période du timer (seulement sur l'interruption qu'il déclenche...)

Sorry, mais ça ne semble pas vrai pour les PICs ! Tous ?

On va voir si RISC, l'espion de MicroChip, dément ma conclusion !

[simon.]

C'est vrai pour certains timers. De mémoire souvent le timer2, celui qui sert aussi pour les PWM. Mais dans ce cas il y a un registre spécial qui permet de regler la période.

[DavidDB]

Salut,

qui demande un traitement pour savoir d'ou vient l'interruption et qui n'est pas fait pour être programmé en C....de là à dire que tu l'as cherché

La fonction d'interruption qui est utilisée dans ce programme est parfaitement bien mise en oeuvre pour n'avoir que l'erreur de latence du déclenchement de l'IT...
Il n'y a pas de traitement pour connaitre la provenance de l'IT dans ce programme, donc, pas d'erreur cumulée...
La méthode de rechargement est bonne pour avoir une reproduction de l'interruption avec comme unique erreur le temps de latence de déclenchement d'IT.
Ce µC ne pose aucun problème pour coder en C...

L'erreur n'est pas dans l'IT du timer, il faut chercher du côté du traitement de la variable "counter"

N'importe quel timer de n'importe quel uC décent est capable de générer une interruption tous les N cycles et de se recharger tout seul à la valeur N, ce qui fait que la latence d'interruption n'a aucune influence sur la période du timer (seulement sur l'interruption qu'il déclenche...)

Oui, son µC dispose de ce type de timer, mais l'erreur est trop importante pour que cela vienne de la latence d'IT

David.

[DAUDET78]

Il n'y a pas de traitement pour connaitre la provenance de l'IT dans ce programme, donc, pas d'erreur cumulée...

ben si ....

La méthode de rechargement est bonne pour avoir une reproduction de l'interruption avec comme unique erreur le temps de latence de déclenchement d'IT.

ben non,
Suivant la place (en timing) du rechargement du timer par rapport au timing de l'overflow, on ajoute des aléas.

La question est : Y a t'il des PIC avec reload automatique du timer à l'overflow ?

Le reste, c'est du baratin !

[quichedood]

J'ai fait un test que je pense pertinent, je commente les 4 lignes suivantes :

if(INTCONbits.TMR0IE && INTCONbits.TMR0IF) {
TMR0L = 101; // Preset timer0
++counter;
}

Mon interruption devient donc :

void InterruptServiceHigh(void) {
		INTCONbits.TMR0IF = 0;
}

Il n'y a plus de preset, mon timer va de 0 à 255.

Je relance ma simulation sous MPLAB et j'ai toujours ces écarts de 400ns qui sont complètement aléatoires.

Pour rappel, en enlevant tout le contenu de ma boucle principale je n'ai plus ces écarts.