Je suis incapable de comprendre ton programme .... (tu ne recharges plus le timer ?)
Que tu ais des aléas sur le moment d’exécution de ton programme, c'est normal. Par contre, ces aléas ne se cumulent plus dans le temps et statistiquement, la période de ton timer est de XmS+?nS (donc regarde pour un quartz qui te permet d'utiliser 256 ou 65536 pour ton timer , ma réponse #24)
J'aime pas le Grec
Je suis d'accord avec Daudet. Des interruptions générées par un timer normalement constitué ne doivent pas dériver. Il me semble me rappeler que le fonctionnement de celui du 16F84 m'avait un peu surpris.
A+
C'était un test de ne pas recharger le timer, voir si ça avait un impact sur la génération des aléas. Et au final non ça n'a pas d'impact donc le problème ne vient pas du rechargement du timerEnvoyé par DAUDET78
Au final c'est peut-être un bug du simulateur MPLAB, faudrait pouvoir tester en vrai sur le PIC mais je n'ai pas de quoi mesurer des écarts. de nS.
Il y aura toujours un aléa.
Le problème est de savoir :
- si cet aléa se cumule à chaque interruption et que 100 interruptions te donne (100+100*aléas) millisecondes (le cas avec reload)
- si cet aléa ne se cumule pas à chaque interruption et que 100 interruptions te donne (100+aléas) millisecondes (le cas sans reload)
J'aime pas le Grec
Elle a bon dos la simul...Je relance ma simulation sous MPLAB et j'ai toujours ces écarts de 400ns qui sont complètement aléatoires.
Les écarts ne doivent pas se cumuler au delà du temps de la plus longue instruction (traversée du pipeline comprise).
3 solutions pour faire ce chrono à la milli seconde (en fait, on peut faire mieux si on veut):
solution 1: utiliser le timer 2 qui dispose d'un comparateur (quasi équivalent fonctionnellement à un reload-timer) et compter les 1ms (ou moins).
C'est fait pour, il n'attend que ça, pourquoi s'en priver (sauf si déjà utilisé...).
solution 2: utiliser un free runing timer, et compter les passage à 0
au start et stop lire le timer et la variable counter et jongler avec les passages à 0 de celui-ci.
(si passage à 0 du timer, relire les 2, sinon risque de perdre un cycle du timer
éventuellement ajuster en fonction des pertes de temps constatées.
faire la différence, gérer les passages à zéro de la variable counter, convertir en ms (ou en µs même)
attention, tester les passages à zéro, car ça n'arrive pas souvent, donc il faut un peu forcer la chance (merci le simulateur (s'il est bien foutu...)).
solution 3: mettre un quartz 32768Hz, tourner en free-running, compter les secondes ou demi ou quart de seconde.
utiliser un second timer pour les temps intermédiaires (attentions aux frontières (comme solution 2)).
cette solution permet d'avoir une fonction horlogère en plus du chrono donc faible conso quand rien à faire, mais attention aux commutations d'horloges...
Coté timer, quelle merde ces PIC...
Jusqu'ici tout va bien...
Bienvenue dans la rébellion contre ces composants d'un autre âge
Ben non, pas de traitement d'une autre IT de même priorité!!!!
Cela signifie: même nombre d'instructions pour arriver au rechargement du timer(sans test conditionnel)!!!
C'est faux Daudet!
Pas d'aléas cumulé dans l'IT qu'il nous présente.
Cette IT est parfaitement reproductible à la latence d'IT prêt!
Pour info, la latence est de maximum 400ns dans le cas le plus défavorable (IT en Tclk 0) si le quartz est bien un 10MHz
Pour s'en convaincre que la sa méthode est valable : les milliers de montages d'horloges qui fonctionnent sur ce principe ou la dérive du quartz est plus problématique que la latence d'IT...
Oui, je l'ai indiqué, son µC possède ce type ce timer
Mais bon, s'il recharge la variable "counter" dans l'IT de ce type de timer, son problème sera identique, vu qu'il parle d'erreur en mS...
ben, je pourrais te retourner le compliment, vu que dans ce fil, tu es à côté de la plaque...
Ben, moi je n'ai à ce jour, pas encore eut de problème de dérive d'IT d'un timer sans preload chez Microchip...Des interruptions générées par un timer normalement constitué ne doivent pas dériver. Il me semble me rappeler que le fonctionnement de celui du 16F84 m'avait un peu surpris.
Au fait, dans le cas présenté ICI :
Incrémentation du timer en mode Synchrone (donc pas de quartz externe), il n'est pas possible d'avoir de latence d'IT car le déclenchement de l'IT se fait TOUJOURS sur le même Tclk...
Cela signifie, que le temps est strictement identique entre chaque IT.
Conclusion, 37 posts pour rien vu que la latence d'IT n'est possible qu'en incrémentation du timer en mode asynchrone!
David.
I don't agree .....
L'overflow du timer arrive bien sur le même Tclk, mais l'interruption est exécutée quand l'instruction en cours est terminé .... donc il y a un jitter
J'aime pas le Grec
Bonjour à tous
Je rappelle à ceux qui semblent l'oublier, que toutes les discussions (pardon, crêpages de chignons) sont désormais sous haute surveillance, et peuvent être fermés (les crêpages) sans le moindre préavis.
http://forums.futura-sciences.com/el...uncements.html
Il ne faut pas généraliser. J'avais fui les pic à cause des 16F84, mais j'ai eu l'occasion de travailler plus récemment avec du pic24 et ça m'a l'air d'être un bon µC.Bienvenue dans la rébellion contre ces composants d'un autre âge
A+
