Compréhension d'un programme

[flyingrock]

Bonjour,
Ci joint un code écrit en C à l'aide de MikroC qui permet de mesurer un lapse de temps entre 2 fronts montants.

Je sèche un peu sur ce code surtout ici

// Calculate length of pulse from rising edge to rising edge
tword = ~tOld + tNew+1;

Pourquoi inverser les bits de tOld et pourquoi ajouter 1 à la fin ?

/*
* Project name:
Capture Sample

* Copyright:
Nicholas Sirirak

* Description:
This is a simple capture a lenght of pulse. Capture from rising edge
to rising edge and send to terimianl via RS232
* Test configuration:
MCU: PIC16F877A
Dev.Board: EasyPIC3
Oscillator: HS, 16.0000 MHz
Ext. Modules: -
SW: mikroC v8.1.0.0
* NOTES:

*/

unsigned tOld, tNew;
char th,tl;
char edge = 0;
char capture = 0;
unsigned tword;
char txt[6];

void interrupt() {
if(PIR1.CCP1IF){
if(!edge){
tOld = (256*CCPR1H)+CCPR1L; // keep starting value
edge = 1;
}else{
tNew = (256*CCPR1H)+CCPR1L; // keep ending value
capture = 1; // complete capture, set a flag
edge = 0;
}
PIR1.CCP1IF = 0; //clear CCP flag
}
}

void main() {
char i;
TRISB = 0; // PORTB is output
PORTB = 0; // Initialize PORTB
TRISA = 0;
TRISC = 0;
CCP1CON = 0x05; // Capture mode every rising edge
TRISC.F2 = 1; // RC2 must be input
T1CON = 0x21; // timer1 ON, internal clock Fosc/4, prescaler 1:4
INTCON.GIE = 1;
INTCON.PEIE =1;
PIE1.CCP1IE = 1; // enable interrupt capture
PIR1.CCP1IF = 0; //clear CCP flag

uart1_init(9600);
while(1){
if(capture){
PIE1.CCP1IE = 0; // disable interrupt while processing
capture = 0; // clear flag
// Calculate length of pulse from rising edge to rising edge
tword = ~tOld + tNew+1;
// tword contain length of pulse in micro second
WordToStr(tword, txt); // convert to string and send back to terminal
for(i=0; i<6; i++) uart1_write(txt[i]);
delay_ms(1000);
PIR1.CCP1IF = 0; //clear CCP flag
PIE1.CCP1IE = 1; // enable interrupt
}
}
}

@+
-----

[invitee23b806b]

Satut Flyingrock,

complémenter et rajouter 1 revient à calculer -tOld à partir de tOld.
Voir les cours de numérique.

Le but est de calculer la différence entre tNew et tOld.
tword = tNew- tOld = tNew + (-tOld) = tNew + (~tOld + 1)

@ +,

[micka_ch]

Bonjour,

Comme le dit Tuxtronic, une addition du complément à 2 revient a faire une soustraction.

Cela dit je ne vois pas l'utilité de faire cela car la soustraction est une instruction assembleur. Faudrait voir ce que le compilateur génère en faisant c=a-b; et c=a+(~b+1); Peut-être qu'on gagne quelques instructions quand les variable a et b sont sur 16bits.

Salutations

[Jack]

Exact.
C'est bizarre de ne pas avoir utilisé une soustraction.

@flyingrock: c'est bien pour les balises code, mais l'intérêt reste limité si tu n'indentes pas ton code.

A+

[A voir en vidéo sur Futura]

[invitee23b806b]

@ Jack,

C'est bizarre de ne pas avoir utilisé une soustraction.

J'ai peut-être une explication:
Imaginons que tOld soit échantillonné juste avant que le timer 16 bits ne replie, par ex, tOld = 65500 et que tNew soit échantillonné juste après, par ex tNew=200.

DU coup, on a tOld plus grand que tNew.

Avec un calcul sur 8 bits, le résultat de tNew-tOld est toujours correct même si le timer a replié.

Pour un calcul sur 16 bits avec un micro 8 bits, il faudrait en toute rigueur testé si tNew est plus grand que tOld.

On aurait un truc du genre:

if (tNew>=tOld)
{
    tword= tNew - tOld;
}
else
{
    tword= tOld - tNew;
}

Peut-être que le fait d'utiliser le complément à 2 plutôt que la simple soustraction permet de gèrer le repli???

@ +,

[invitee23b806b]

Bon, comme je ne peux pas ré-èditer mon précédent message, je corrige:

Il fallait évidement lire:

if (tNew>=tOld)
{
    tword= tNew - tOld;
}
else
{
    tword= (65536-tOld) + tNew; /* Temps jusqu'au repli + durée écoulée depuis le repli */
}

@ +,

[Jack]

je ne suis pas convaincu. Comme les opérations ont forcément un modulo, le résultat restera juste, même si le compteur est revenu à zéro entre les 2 temps. Pour ton exemple, 65500 = FFDCh et 200 = 00C8h
Si on effectue la soustraction directe 00C8h - FFDCh, on trouve bien ECh, soit 236.

A+

[invitee23b806b]

C'est pas impossible puisque 65536 sur 16 bits font 0.
On se retrouve donc avec la même formule qu'il y ait repli ou pas.

tword= tNew - tOld;

C'est bizarre, puisqu'avec un compilateur C (je ne sais plus lequel), il y a de cela plusieurs années, je n'avais pas le bon résultat quand le compteur 16 bits avait replié.

Il est donc prudent, de faire une petite séance de debug pour vérifier que le résultat du calcul est bon dans le cas d'un repli.

Si tNew-tOld, fonctionne, ben, même en cas de repli, tout va pour le mieux dans le meilleur des monde!

@ +,

[Jack]

C'est bizarre, puisqu'avec un compilateur C (je ne sais plus lequel), il y a de cela plusieurs années, je n'avais pas le bon résultat quand le compteur 16 bits avait replié.

Il faut choisir le bon type de donnée, en l'occurrence un "unsigned short" pour un compteur 16 bits, sinon on prend des risques.

A+

[invitee23b806b]

Oui, tout-à-fait, j'étais bien en "unsigned short".

La morale de tout ça: il ne faut pas hésiter à regarder de plus près le code généré par le compilo: on voit de tout. Et surtout, ne pas hésiter à tester son code au limites tels que replis, changements de signe, etc...

Et croire que tous les compilos sont exempt de bug, c'est croire au père noël! Déjà, faut avoir lu la doc...

@ +,

[flyingrock]

Bonjour à tous,

Merci pour m'avoir décortiqué cette ligne, il me semblait bien que cela devait être une soustraction, mais très franchement ça ne m'a pas sauté au yeux.
Je vais essayer de trouver un moyen de joindre l'auteur du programme et lui demander le pourquoi du comment.

@+

[flyingrock]

Bonjour,

J'ai reçu une réponse de l'auteur du programme, je lui ai demandé pourquoi ne pas avoir utilisé une simple soustraction.

Voici ce qu'il m'a répondu :"tNew may rollover from FFFF to 0, imagine if tOld is greater than tNew. so to be sure using adding method by subtrac the complement +1."

Vu comme ça c'est pas idiot on a pas a se soucier d'avoir tNew supérieur a tOld

@+

[Jack]

Vu comme ça c'est pas idiot on a pas a se soucier d'avoir tNew supérieur a tOld

le fait que tOld soit supérieur ou non à tOld n'a aucune espèce d'importance comme je l'ai expliqué dans le post#7.
Il me semblait que mon exemple le montrait bien pourtant ...