réalisation d'un fréquencemetre

[omarus]

Bonjour tous le monde,

Je souhaiterais réaliser un fréquencemètre, je cherche de la documentations pour ça, mais je suis perdu tellement y'en a !! . j'ai envie que quelqu'un m'aide a expliquer par ou commencer, et je souhaiterais faire un code en C sur pic 18f2520 (car c'est tout ce dont je dispose pour l'instant).

L'oscillateur est réalisé F(C). avec une sensibilité de 100 Hz/ pF dans une gamme de fréquence allant de 500k a 1Mhz (c'est tout ce dont j'ai besoin). le signal est sinosoidal avec une amplitude de 600mV pic-pic. et je dois pouvoir mesurer chaque pico farad.

Quelqu'un peut m'aider surtout au niveau programmation, au moins pour commencer a réalisé un cahier des charge (comment choisir ma fenêtre de comptage....etc) étant débutant en programmation, je souhaiterais avoir des indications au niveau du code en C.

Merci de votre aide
-----

[PIXEL]

hello ,

c'est un devoir à faire ?

car au prix du fréquencemètre chinois , je ne vois pas trop l'avantage du DIY.

[omarus]

j'ai juste envie d'apprendre !! et comme j'ai fini la réalisation de mon capacimètre qu'on m'a demandé et que j'ai intégré directement a un fréquencemètre existant. je souhaiterais en réaliser un pour ma propre satisfaction.

[PIXEL]

le camarade REMY traite de la question :

http://www.sonelec-musique.com/elect...metre_005.html

[A voir en vidéo sur Futura]

[omarus]

Merci PIXEL, je vais m y mettre

[omarus]

Re encore moi,

Je commence à comprendre un-peu comment établir un cahier des charge pour réalisé un fréquencemètre, j'aimerais avoir quelques indications.
la gamme de mesure s'ettant entre 100k a 1M, avec la meilleur précision possible mais pour kelk petits hertz je ne vais pas rechigné.
Je me suis dis avec un PIC 18F258, j'utiliserai le timer0 comme fenetre temporelle (50ms) et timer1 comme compteur.
d’après mes calculs une fenetre de 50ms me permet d'allé jusqu'a 1Mhz avec une bonne précision. avec un quartz de 20Mhz et en mode 16bits
Mon soucis c'est que je patine même si j'ai lu le part 1 2 et 5 de bignoff et en lisant aussi de la doc sur le net. (je débute j'arrive a faire tout ce qui allumage led, chenille..etc) mais au dela...!!!
bref je récupère des bouts de programmes pour comprendre le fonctionnement d'un fréquencemètre et les timer sur les pic

je souhaiterais commencé a comprendre comment initialisé les timers et comment bien choisir le prescal, preload, ...etc. voici un premier pas que j'ai fait dites moi ce que vous pensez

// fenetre 50ms à 20Mhz
T0CONbits.TMR0ON = 0; // Timer O off
T0CONbits.T08BIT = 0; // mode 16 bits
T0CONbits.T0CS = 0; // source Hl interne
T0CONbits.PSA = 0; // autorisation des prédivisions
T0CONbits.T0PS0 = 0; //
T0CONbits.T0PS1 = 1; // prédivision par 128
T0CONbits.T0PS2 = 1; /

[omarus]

Personne pour m'aider ?

[paulfjujo]

bonjour,


Dans ton init,il manque le chargement de TMR0H et TMR0L
soit TMR0=63583
ce qui laisse 1953 x128 cycles pour avoir le flag debordement de compteur
soit 0.2µs * 128 * (65536-63583)=> 49.996,8 µS near 50mS

La resolution ne sera pas terrible avec une fenetre de 50mS
Autant partir directement sur unefenetre de 1 sec pour avoir une mesure directe en Hz..
Attention il faudra compter le nombre de debordement du compteur
et rajouter le reste du prescaler si besoin..

[indri]

Ca ne me parait pas très cohérente de mesurer un signal d'1 Mhz avec un qqch de cadencé à 20Mhz
Quelques élucubrations:
20 Mhz: Période de 50 ns
1Mhz: T=1000ns
Bref on comptant 19 (nombre de coup clock entre chaque flanc montant du signal à mesurer): T=950ns soit 1,05.. MHz
Ou 21 T=1050ns soit 952,..khZ
Bref tu peux espérer au mieux 50khz de résolution (à ce niveau..si tu mesure un signal à quelques kHz ce sera autre chose (inversement proportionnel à la fréquence) tu auras une resolution de , au mieux, 50 ns sur la *période*)

Tout ca supposé avec un code super au point...(je peux pas aider à ce niveau..c'est un pic , c'est le mal)

Sinon faudrait pouvoir diviser ton signal à mesurer (facile avec un signal numérique, mais tu as un sinus (que tu dois pouvoir transformer en signal carré de même fréquence) pour avoir un truc qui tient un peu mieux la route

[minioim]

pour avoir fait un compte tour moto numérique, donc un fréquencemètre (le signal étant de type carré, de ratio fixe et de fréquence variant entre 33 et 400Hz) j'ai plutôt choisi l'option "calcul de la période"

car effectivement une fenêtre pose toujours le problème de la synchro.

même si tu fais démarrer la mesure sur un front montant, tu vas avoir des "pas" de mesure. en gros si la dernière impulsion arrive 5ms avant la fin de ta mesure ou juste avant voire en même temps, ça te donnera la même valeur.

la solution que j'ai utilisé c'est de d'initialiser le timer0 à 0 et de le démarrer au premier front montant. puis de sauvegarder sa valeur au front montant suivant. ça te donne la période du signal et donc sa fréquence.

le seul soucis de cette technique c'est que pour un signal un peu variant elle est "trop" précise. vu que tu mesures chaque période, qui peuvent varier.

par contre tu peux régler ce problème en faisant une mesure tous les 5 fronts montant par exemple.

pour tout ça soit tu le codes manuellement soit tu peux utiliser le mode capture du module CCP (qui peut être réglé sur une capture à chaque front ou tous les 4 ou tous les 16 fronts (ce qui permet de lisser le signal en faisant une moyenne mobile))




après il reste quand même une question: ton pic va passer l'essentiel de son temps en interruption. c'est pas un soucis si il ne fait que de la mesure de fréquence. mais c'est à prendre en compte si il doit faire d'autres choses qui nécessitent un timing précis.

enfin, si tu veux mesurer plusieurs fréquences, soit tu affectes un timer par fréquence... mais ça implique d'en avoir assez. soit tu utilises un seul timer comme "horloge" (par exemple réglé pour déborder toutes les 50µs) et une variable horloge qui s'incrémente à chaque dépassement du compteur et n'est jamais remise à 0.

au premier front montant tu sauvegardes l'état de l'horloge ainsi que celui du timer qui sert d'horloge, au suivant tu resauvegardes l'horloge et l'état du timer et la différence entre les 2 (fois les 50µs pour la variable horloge) dans cet exemple te donne le timing entre les 2.

en fait c'est comme si la variable horloge te donnait les minutes et que le timer donnait les secondes.


avec ça tu peux mesurer autant de fréquences que tu as de source d'interruption ext (au détail près que plus yen aura et plus elles seront élevées plus tu prends le risque qu'une impulsion d'une fréquence arrive en même temps qu'une autre et que seule l'une des 2 soit prise en compte vu que les interruptions seront désactivées pendant le traitement de la première impulsion)

[omarus]

Merci a vous,
minioim, merci pour toutes ces indications, j y penserai a cette astuce. Comme je débute sur ca, et que ca fait quelques jours que je m'acharne sur la méthode de fenêtre et a comprendre tout ca, je pense continuer sur cette route.
Paulfjuju, je me suis inspiré de ton code fréquencemetre sur ton site, et j'ai bien remarqué que t'as mis une fenetre de 1s ou 4s, et a proiori ça marche trés bien pour toi, mais je ne voulais pas faire du copier-coller, j'aimerais apprendre a le faire.
Mais le choix d'une fenêtre de 50ms. je l'ai choisi a partir de l'expliquation sur ce lien:
http://www.sonelec-musique.com/elect...metre_004.html

et en parlant avec un de mes proff, il m'a di que 1s c'est trop. donc c'est pour ca que je suis perdu avec les différents avis.
Pour répondre a Indri, j'ai choisi 20Mhz car sur les différentes doc que j'ai trouvé, c'est ce qui s'utilise le plus.
J'aimerais avoir votre avis sur le lien. dans le titre quelle base de temps employé

Merci

[minioim]

en résumé: plus ta base de temps est longue plus tu gagnes en précision (si tu comptes 7999 impulsions sur 8000 ou 8001, ça va pas te faire une grosse nuance....) par contre tu perds en fréquence de raffraichissement.

Si il te faut 1 seconde de mesure, ça peut ne poser aucun soucis comme ça peut en poser (pour mon projet de moto par exemple je ne peux pas donner l'info toutes les secondes... une moto accélère trop vite, il faut que la fréquence soit affichée pratiquement en temps réel)

je ne suis pas tout à fait d'accord avec son histoire de dépassement tu timer... ce n'est pas un problème que ton timer dépasse... il suffit de prévoir une variable qui s'incrémente au débordement du timer.

ainsi si tu appelles ta variable "dep_timer"

bon bah tu lances ta mesure.... le timer déborde à 256 par exemple... donc dep_timer s'incrémente de 1 etc....

donc à la fin de ta seconde de mesure, tu regardes l'état du timer (mettons 242) et l'état de la variable dep_timer (mettons 4)

et bien tu as eu 4*256 + 242 incrémentations du timer soit : 1246 incrémentations.

donc le "débordement" du timer n'est pas spécialement un soucis à mon avis. par contre le temps de mesure influe sur la vitesse de rafraîchissement.

[paulfjujo]

bonjour,

Ca ne me parait pas très cohérente de mesurer un signal d'1 Mhz avec un qqch de cadencé à 20Mhz

Cadensé par un Quartz à 20MHz ,mais FOSC=Q/4 => 5Mhz seulement ,correspondant au cycle processor 200nS
Il y aurait probleme , si on fait une mesure de frequence par pooling, test d'une entree PIC.
où la duree du cycle processor est primordiale.


Mais pour la mesure de frequence on utilise le Timerx , qui est autonome et peut compter le nombre de pulses
jusqu'à un maximum garanti,data constructeur de 30MHz ..
LE codage est effectivement assez pointu, en ASM, ou chaque instruction compte pour avoir de la precision.
Mais meme en C18 on obtient deja de bons resultat de 1Hz à 5Mhz .

J'ai deja fait des comparaisons entre les modes CCP ou comptage direct timer..
Le mode CCP est meilleur pour les faibles gammes de mesure de frequence,puisqu'on mesure la periode
et on en deduit la frequence,
Le mode comptage pendant une fenetre de temps precise,
me parait preferable , surtout pour couvrir une grande game de mesure de frequences..

L'ideal serait d'utiliser un des 2 modes (voir les 2) suivant la frequence mesuree...
afficher Periode et frequence...
Encore faut-il avoir un ou des etalons pour le verifier..

http://paulfjujo.free.fr/FREQ/frequencemeter_18F.htm

[omarus]

Merci a vous, je commence a mieux cerner les problèmes, je vais m y mettre.
paulfjujo, ton code pour le mode capture compile bien, mais pour le mode comptage, il ne reconnaissait pas le 2_LCD.h, ensuite il y a plein d'erreur qui me donne.
exemple sur la ligne valtxt=&Texte[0]; il me dit 260:Error [1131] type mismatch in assignment
Error - could not find definition of symbol 'LCD_PutRamString' in file './led test.o'.

Je compile avec MPLAB 8.7 / et la dernière mise a jour MplabCCP trouvé sur le site de microchip

[paulfjujo]

mais pour le mode comptage, il ne reconnaissait pas le 2_LCD.h,

quel source exactement ( lien ?)

[omarus]

c'est celui la, http://paulfjujo.free.fr/FREQ/datas/...z_LCD_131001.c

#include "../_common/LCD2x16.h" je l'ai transformé après avec #include LCD2x16.h toujours pareil.

[paulfjujo]

il te manquait le fichier externe

#define LCD
#ifdef LCD
#include "../_common/LCD2x16.h"   
#endif

fichier LCD2x16.h fonctions LCD rajouté dans le zip ci joint
avec la version ...131002 usage de Timer0 au lieu de Timer1 pour gerer la fenetre seconde

valtxt=&Texte[0]; il me dit 260:Error [1131] type mismatch in assignment

pas d'erreur vue sur ce point là !

mise a jour MplabCCP ?

j'utilise
MPLAB 8.92.00
et MCC18 V3.44
voir resultat de compilation en fin du fichier source

Frequencemeter_18F258_T1_Q20Mhz_LCD_131002.zip

[omarus]

Merci, ça marche bien. je vais essayé de bien décortiqué ton code, j'ai compris une partie, mais j'ai difficulté sur certaines partie non commenté, mais je vais y arrivé,
patience.
Encore merci.

[omarus]

Re encore moi.
j'aurais besoin d'aide sur le code de paulfjuju (si tu es dans le coin je te sollicite ) qu'il m'a donné plus loin,. j'ai repris tout le code ligne par ligne, j'ai bien compris la partie, gestion timer pour la fenetre timer0 et le compteur timer 1, la gestion du LCD aussi, Cependant la méthode de mesure je ne l'ai pas bien compris. si vous pouvez m'aidé a comprendre cette partie du code surtout je n'arrive pas comprendre " cumulTE "

F1=(float) CumulTE *65536.0 ;

, et toute la partie

asm bra+1

et c'est quoi exactement

count_100mS

en gros toute la partie mesure m'échape.

// start mesure
INTCONbits.GIEL=0;
INTCONbits.GIE=1; // Toutes les IT démasquées autorisées

count_100mS =0;
//Put_RS('#'); CRLF();
INTCONbits.TMR0IE=0;
INTCONbits.TMR0IF=0;
PIE1bits.TMR1IE=1; // Enable Interrupt Timer1
T0CONbits.TMR0ON=1; // comptage Timer0 On
LATAbits.LATA3=1;
T1CONbits.TMR1ON=1; // arme timer1
do
{
while(INTCONbits.TMR0IF==0);
// init timer0 avec 26474 pour presque ((65536-26474) * 128 *0.2 = 0,9999872 sec at 20Mhz
// 1 cycle = 4/FQuartz= 4/20= 1/5 de µS ou 0,2µS
// il manque 1000000-999987,2 = 12.8µS
// reglage fin duree de mesure
Delay10TCYx(15); // <- par paquet de 10 NOP
_asm
bra +1 // <- +0.4µS
bra +1
nop // <- + 0.2µS
nop
_endasm
count_100mS = count_100mS + 1;
INTCONbits.TMR0IF=0;
WriteTimer0(26474);
}while (count_100mS < TotalCount );

// stop Mesure

LATAbits.LATA3=0;
T0CONbits.TMR0ON=0;
T1CONbits.TMR1ON=0;
tWord= ReadTimer1();
INTCONbits.TMR0IF=0;
INTCONbits.TMR0IE=0; // no interrupt sur debordement timer0
INTCONbits.GIE=0;


F3=(float)tWord ;
F1=(float) CumulTE *65536.0 ;






// adaptation resolution f(temps) de mesure
//
F2=F3 + F1;

Merci de votre aide

[minioim]

Salut,

je vais t'apporter ma modeste contribution


déjà, "count_100mS"
c'est une variable. son nom est assez explicite: visiblement c'est un compteur qui s'incrément toutes les 100ms (a priori vu le but du programme: on stop la mesure et on regarde le nombre de "comptages" effectués au bout d'un certain temps qui est ici "TotalCount" par contre je vois pas sa valeur... peut être donnée ailleurs dans le programme)

ligne:
Delay10TCYx(15); // <- par paquet de 10 NOP -> c'est une macro a priori, qui permet de déclencher un délais d'attente. une instruction NOP en assembleur ne fait rien... elle perd juste du temps. par contre je ne connais pas son fonctionnement et là vu le "15" en argument, j'aurais dis que ça permettait de perdre 15*10 instructions soit 150 *0.2µs. donc 30µs mais ça ne colle pas avec les 12.8µs à rattraper...
bref ça perd juste du temps


partie:

_asm
bra +1 // <- +0.4µS
bra +1
nop // <- + 0.2µS
nop
_endasm

le _asm permet d'écrire du code directement en assembleur. l'instruction BRA permet de faire un saut depuis la position actuelle dans le programme vers une instruction éloignée de "+1" ici. en gros ça saute à la ligne suivante... une autre manière de perdre du temps car un saut implique 2 cycles d'horloge au lieu d'un (d'où le "+0.4µs" au lieu de 0.2µs.
le nop ensuite ne fait rien: on reperd 0.2µs
puis encore un... bref c'est plusieurs méthodes permettant de perdre du temps...

ligne
count_100mS = count_100mS + 1;

normalement après tout ce bazard, entre le début du while et cette ligne (en comptant le fait que le timer a été initialisé a une valeur permettant d'avoir presque une seconde avant le débordement), les 12.8µs manquante sont rattrapées j'imagine.

le timer est réinitialisé en permanence à chaque tour de boucle jusqu'à ce que la condition count_100mS > TotalCount soit remplie du coup il ne dépasse pas je dirais...

mais soit il manque une partie du code soit l'idée est trop complexe pour mes neurones fatigués après cette semaine de partiels ^^

je t'ai décrit le fonctionnement de chaque ligne mais le code est assez complexe ou incomplet... surtout pour ce qu'on veut faire au final...

il a surement un autre intérêt ou un intérêt purement pédagogique (le fait d'utiliser des "BRA" au lieu de 2 NOP puis des NOP ensuite par exemple... je comprend pas ^^

[paulfjujo]

bonsoir,


à minioim , Merci de ton support .

déjà, "count_100mS" ....c'est une variable. son nom est assez explicite

Malheureusement, NON .... voir plus loin


oui , ici, choix accumulation mesure sur 1 seconde ou 4 secondes, en fonction de l'etat de l'entree RA2

 if (PORTAbits.RA2==1)
 {
     TotalCount=1;
     strcpypgm2ram(txt,RS_Str[5]); k=PutStr_RS(txt);
 }
 else 
     {
         TotalCount=4;
   strcpypgm2ram(txt,RS_Str[6]); k=PutStr_RS(txt);
 }

ligne:
Delay10TCYx(15); // <- par paquet de 10 NOP -> c'est une macro a priori, qui permet de déclencher un délais d'attente. une instruction NOP en assembleur ne fait rien... elle perd juste du temps. par contre je ne connais pas son fonctionnement et là vu le "15" en argument, j'aurais dis que ça permettait de perdre 15*10 instructions soit 150 *0.2µs. donc 30µs mais ça ne colle pas avec les 12.8µs à rattraper...
bref ça perd juste du temps

Exact !

_asm
bra +1 // <- +0.4µS
bra +1
nop // <- + 0.2µS
nop
_endasm

le _asm permet d'écrire du code directement en assembleur. l'instruction BRA permet de faire un saut depuis la position actuelle dans le programme vers une instruction éloignée de "+1" ici. en gros ça saute à la ligne suivante... une autre manière de perdre du temps car un saut implique 2 cycles d'horloge au lieu d'un (d'où le "+0.4µs" au lieu de 0.2µs.
le nop ensuite ne fait rien: on reperd 0.2µs
puis encore un... bref c'est plusieurs méthodes permettant de perdre du temps...

Exact, c'est en fait un reglage tres fin, à 0,2µS pres de la duree totale
La seconde est elaborée à partir du timer0 qui compte (un petit peu moins de 1000mS),
il fera donc au moins 1 tours pour approcher la seconde
et je rajoute des NOP ou bra pour l'ajustage final ...afin d'arriver à 1 seconde = 1 000 000,0 µS

ligne
count_100mS = count_100mS + 1;
normalement après tout ce bazard, entre le début du while et cette ligne (en comptant le fait que le timer a été initialisé a une valeur permettant d'avoir presque une seconde avant le débordement), les 12.8µs manquante sont rattrapées j'imagine.

le timer est réinitialisé en permanence à chaque tour de boucle jusqu'à ce que la condition
count_100mS > TotalCount soit remplie du coup il ne dépasse pas je dirais..
mais soit il manque une partie du code soit l'idée est trop complexe pour mes neurones fatigués
après cette semaine de partiels ^^
.....

En fait, je suis desolé, mais j'ai oublié de modifier le nom de ma variable Count_100mS
Je concois que ca ne facilite pas la comprenette...
dans cette version , elle devrait s'appeler Count_1sec !!!
car dans une version precedente j'utilisais le timer1 qui n'a pas de prescaler 1/256 et
donc je generais des interrupt timer 100mS et en comptait 10 pour 1 sec et 40 pour 4 sec...
L'avantage du timer0 est qu'il permet d'atteindre la seconde en 1 seule passe !
.

il a surement un autre intérêt ou un intérêt purement pédagogique (le fait d'utiliser des "BRA"
au lieu de 2 NOP puis des NOP ensuite par exemple... je comprend pas ^^

Interet pedagoqique , peut etre ..
mais utiliser bra permet d'ecrire 1 seule ligne au lieu de 2 avec des NOP

normalement après tout ce bazard, entre le début du while et cette ligne (en comptant le fait que le timer
a été initialisé a une valeur permettant d'avoir presque une seconde avant le débordement),
les 12.8µs manquante sont rattrapées j'imagine.

En fait , c'est 12,8µS en theorie à rattraper..
Mais il faudrait avoir une reference de frequence Mega precise , pour
rajouter le bon nombre de NOP (0,2µS) car il faut tenir compte de sa propre horloge locale qu'est le Quartz aux bornes du PIC !!
J'ai mis 30µS pour satisfaire au mieux la correspondance de lecture avec la valeur ecrite sur mon horloge à quartz de 4,43... Mhz
qui me servait "d'etalon" .. n'ayant rien de mieux.

Rappel : une correction de 30µS sur 1000 000 de µS ... c'est 0.003% !
Il y a de la marge , mais c'etait surtout pour pouvoir utiliser un moyen de correction

[omarus]

Ok je te remercie énormément, j'ai les idées plus claire et grâce a vous je m'améliore. minioim j’espère que t'as réussi ta présentation cet aprém .
Concernant le code complet il est posté en zip unpeu avant ce poste.
j y travaillerai encore ce weekend.
Encore une fois toutes contribution m'aiderai car c'est un projet qui est de ma propre initiative juste pour apprendre.

[omarus]

paulfjujo, j viens de voir ton poste. Merci encore

[omarus]

Encore une fois,
Je ne sais pas si je confond, mais le quartz, c'est 20Mhz non ? et je ne vois pourquoi 30µS ne gênerai pas, un manque de 12.5µs est plus précis qu'un excédant sur ma fenetre en prenant 30µs?

[paulfjujo]

Oui,le quartz du pIC est de 20Mhz

Au sujet de la compensation de la seconde..
tu peux tres bien partir avec 12,5µS ... ou t'en passer

erreur de 12,5µS sur 1000 000 de µS !!!!
on est pas au pouieme pres ...

[omarus]

merci, c'est super gentil de votre part

[minioim]

salut,

@ paulfjujo: intéressant d'avoir ton commentaire merci

par contre justement je comprend pas pourquoi tu utilises d'abord des BRA +1 puis deux NOP? au lieu d'un autre BRA+1?

et merci pour le reste des explications comme le fait que c'était bien 30µs que la macro permet d'attendre ^^ je commençais à douter

mais juste pourquoi ne pas utiliser tout simplement une macro de delay sur une seconde? simple question hein

@ omarus, merci de te soucier de ma présentation oui ça s'est passé au delà de toute espérance le travail de programmation comme d'électronique a été très apprécié et devrait donner lieu à une des meilleures note de la promo selon mon responsable. ce qui est toujours très agréable à entendre^^

[paulfjujo]

par contre justement je comprend pas pourquoi tu utilises d'abord des BRA +1 puis deux NOP? au lieu d'un autre BRA+1?

Simplement parcequ'au depart j'avais aligné une multitude de NOP
que j'ai remplacé au fur et à mesure par des BRA +1..donc NOP restants..

pourquoi ne pas utiliser tout simplement une macro de delay sur une seconde?

La grosse difference est que la MACRO delay utilise tout le temps Processor
est qu'elle subirait des ruptures temporelles du au traitement IT Timer1 lorsqu'il deborde
pour incrementer le compteur CumulTE à l'interieure de l'IT...
xµS pour entrer dans l'interrupt + XµSec de traitement + xµsec de retour au main..

Ce qui n'est pas le cas avec la seconde comptée par Timer0, puisque 100% Hardware,
compte les cycles d'horloges..

C'est aussi ce qui m'a poussé ensuite à inverser les roles Timer0 et Timer1 de la version precedente (avec Count_100mS!):
utiliser Timer0 au lieu de timer1 pour elaborer la seconde
Timer1 ne pouvant pas le faire sans plusieurs debordements,donc traitement d'IT perturbantes..
vu que le prescaler est limité à 8 au lieu de 128 sur Timer0.

ce qui repond aussi à la question

cette partie du code surtout je n'arrive pas comprendre " cumulTE "

F1=(float) CumulTE *65536.0 ;

Pour les frequences hautes (> 65535 Hz !) , il y a forcement des debordements du Timer1
( celui qui compte le nb de pulses entrantes pendant la periode de 1 seconde
Des la fin de la seconde, on bloque l'arrivee des pulses entrante sur le timer1
on recupere son contenu que l'on rajoute à la somme des bordements (ici valeur de F1).