Pages: [1]   Go Down
Author Topic: [résolu][timers] ICP et CTC?  (Read 671 times)
0 Members and 1 Guest are viewing this topic.
Bretagne
Offline Offline
Edison Member
*
Karma: 10
Posts: 1296
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Salut la communauté!

Je viens vers les fous qui auraient déjà testé le savoureux mélange de l'utilisation de l'ICPn (Input Capture Pin) d'un timer n tout en faisant tourner ce timer en mode CTC (Clear on Compare Match) TOP = ICRn. sur UNO, ça donne le mode WGM1 = 12 en utilisant le timer1 et ICP1 (pin smiley-cool non, (pin 8 ).

Dans l'idée, lors d'un front (edge) qui déclenche l'interruption ICPn, la valeur TCNTn est copiée dans ICRn, or si le timer est en mode CTC, il devrait être en cas de compare match (puisque TCNTn = ICRn). il se remettrait tout seul à 0, et ainsi serait déjà nikel pour lire le temps entre le premier front ICPn et le suivant... non? On s'affranchirait alors de la lourde opération 16 bits de remettre le TCNTn à 0 à la main et le risque de perdre quelques unités timer (ou une bonne dizaine s'il tourne à 16MHz!) dans l'opération donc on gagnerait en précision, il suffirait juste de lire ICRn pour voir la dernière "capture" du timer...

Je testerai peut être demain, mais si vous avec déjà tenté... je prends vos avis!

Cinci
« Last Edit: September 24, 2012, 03:31:14 am by Super_Cinci » Logged

Ile-de-France (92 sud), France
Offline Offline
Edison Member
*
Karma: 23
Posts: 2054
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Pas utilisé de cette façon mais je ne vois pas l'intérêt.
Il est surtout dangereux de vouloir remettre le compteur à 0 par du soft dans l'interruption.

Dans une discussion a propos de la mesure du temps parcourue par une bille entre 2 capteurs je suggérais d'utiliser le code attaché.
On utilise 2 interruptions captures dans laquelle on lit la valeur du compteur.
Le temps écoulé est la différence.
Calculée sur un entier non signé de 16 bits, on s'affranchit du rebouclage pour autant que ce dernier de survienne qu'une seul fois.


* test_timer_capture.ino (2.18 KB - downloaded 2 times.)
Logged

Barbuduino: Arduino sur Breadboard & VinciDuino: Clone Leonardo // WR703: Mini-routeur hacké // LauchPad MSP430 et Stellaris // Panda II Arduino-like .NetMF sous VisualC#
RTFC: Read That F.....g Code / RTFD: Read That F.....g Doc / RTFDS: Read That F.....g DataSheet / RTFS: Read That F.....g Schematic / Wot da ya wanna D.I.Y. today ?

Bretagne
Offline Offline
Edison Member
*
Karma: 10
Posts: 1296
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Pas utilisé de cette façon mais je ne vois pas l'intérêt.
Il est surtout dangereux de vouloir remettre le compteur à 0 par du soft dans l'interruption.
Justement, si mon idée marche en WGM=12, le compteur se remet à 0 tout seul en hard, donc pas d'intervention du soft.
Dans une discussion a propos de la mesure du temps parcourue par une bille entre 2 capteurs je suggérais d'utiliser le code attaché.
On utilise 2 interruptions captures dans laquelle on lit la valeur du compteur.
Le temps écoulé est la différence.
Calculée sur un entier non signé de 16 bits, on s'affranchit du rebouclage pour autant que ce dernier de survienne qu'une seul fois
Tu as du deviner que je cherche encore et toujours à mesurer mes impulsions de PMH de ma vieille boîte à pistons... Il s'agit d'avoir un relevé de la durée de chaque impulsion (pas le droit d'en rater une, car dans le tas, il y en a une qui est cruciale car elle dure plus longtemps que les autres), donc avec l'input capture, ça fait comme nos vieux chronomètres, on a un "gel" de la valeur du compteur dès l'ICP, alors que le timer continue à tourner. S'il se remet tout seul à 0 à l'impulsion n, alors c'est tout bénéf, car il pourra donner la durée exacte pour l'impulsion n+1! D'autant plus que j'aimerais bénéficier de l'interruption OVF (sorte de time out : l'impulsion est trop en retard, débordement timer, donc on n'en tient pas compte, point barre.) Coup de bol, l'OVF se déclenche à TCNT = MAX et non pas BOTTOM...

datasheet 328, p126 :
Quote
The OCR1A or ICR1 define the top value for the counter, hence also its resolution. This mode allows greater control of the compare match output frequency. It also simplifies the operation of counting external events
Ils ne parlent cependant pas de l'utilisation de ICP1 en mode CTC... va falloir tester, pas le choix (reste encore à trouver un code simple pour récupérer les infos qui montrent que ça a marché)!

Le mode WGM=14 (fast PWM, TOP=ICR1) ne convient pas, car l'OVF est déclenchée à TCNT = TOP, donc risque d'être déclenchée en même temps que l'ICP...

Code:
ISR(TIMER1_ICP_vect){  // int "Input Capture Pin"
// blah blah
  ICR1 = 0xFFFF;  // pour laisser le timer compter jusqu'à MAX (OVF) si pas d'impulsion au prochain tour...
}
Logged

Ile-de-France (92 sud), France
Offline Offline
Edison Member
*
Karma: 23
Posts: 2054
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

L'inconvénient de ta méthode c'est qu'a moins que ce soit 100% documenté, es tu sur que le compteur se remet à 0 l'impulsion ou bien 1 coup d'horloge après ? ou 2 ?
Il peut y avoir une latence, d'où erreur de mesure.
Quand tu lis la valeur absolue du compteur, tu n'as que des différences a faire et tu es sur qu'il n'y a pas de problèmes...
Logged

Barbuduino: Arduino sur Breadboard & VinciDuino: Clone Leonardo // WR703: Mini-routeur hacké // LauchPad MSP430 et Stellaris // Panda II Arduino-like .NetMF sous VisualC#
RTFC: Read That F.....g Code / RTFD: Read That F.....g Doc / RTFDS: Read That F.....g DataSheet / RTFS: Read That F.....g Schematic / Wot da ya wanna D.I.Y. today ?

Bretagne
Offline Offline
Edison Member
*
Karma: 10
Posts: 1296
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

L'inconvénient de ta méthode c'est qu'a moins que ce soit 100% documenté, es tu sur que le compteur se remet à 0 l'impulsion ou bien 1 coup d'horloge après ? ou 2 ?
Il peut y avoir une latence, d'où erreur de mesure.
Quand tu lis la valeur absolue du compteur, tu n'as que des différences a faire et tu es sur qu'il n'y a pas de problèmes...
je n'y avais pas encore réfléchi, mais en effet, tant que la pulse ne dépasse pas 65535, c'est tout bon (j'avais oublié que par exemple sur 16 bits, 24 - 200 = 65360).

Je suppose qu'un timeout (OCR1A par exemple) égal au dernier relevé - 1 (pour éviter de déclencher l'int si TCNT1 = OCR1A) suffirait?

Pas bête... Je viens de lire une AN chez ATMEL où en effet, ils ne s'occupent pas de la remise à 0. je pars donc là-dessus.

Merci Barbudor!
Logged

Pages: [1]   Go Up
Jump to: