Le timer n°6 - Page 1

Pour faire des 'bench' de prog basic (non on ne rigole pas !) je pense qu'il n'y a pas d'autre possibilité que d'utiliser un timer.

Sauf que je ne sais pas très bien comment ça marche...

J'ai donc utilisé le timer n°6 qui d'après la doc de TIGCC décremente de 1 tous les 20emes de seconde. Le prog en C se lance, fixe le timer à 500. Le prog basic s'execute ensuite, puis à la fin le prog en C démarre une deuxième fois, releve la valeur du timer et la soustrait à 500 pour calculer le temps d'execution.

Je n'ai pas ma calc sur moi, donc je teste sous VTI, et les résultats sont completement absurdes. Pire que ça, je lance deux fois le bench et les 2 résultats sont totalement différents. Ce problème vient de VTI ou bien du timer 6 qui n'est pas précis ? (ou bien d'autre chose ?)

il est pas precis, en fait, c pas vraiment un 20ème de seconde mais 18 ou 19 ...

utilise directment l'AUTO_INT85, sinon (mais c pas plus précis, en fait...)
sinon, l'AU1 ou l'AU3
(sur HW2, l'AU3 est appelé exactement une fois par seconde : c'est lui qui gére l'horloge sur ROM2.07)
l'AU1... heu... moins précis...
340 sur HW1, et 350 sur HW2... quelque chose dans ce genre là...

350 fois par seconde ???
Voilà ça c'est précis
Je peux l'utiliser sans risque ? Le 6 c'est celui qui m'a semblé logique de prendre, étant donné que c'est l'USER_TIMER, et je ne voudrais pas risquer de planter qqchose...

Heu, sinon pour les GROSSES variations entre 2 tests, vous pensez que c'est dut à VTI ?

C'est possible, n'oublie pas que VTI est un programme qui tourne dans un environnement multitâches, donc il n'a pas la même quantité de ressources d'un moment à l'autre à cause des autres programmes (même quand tu fermes tout, il en reste toujours en tâche de fond).

Ok, j'essayerais sur real ti dès que je l'aurais récupérée...

Bob> 350 fois par seconde, c pas tout à fait ça...
(je connais pas la valeur exacte, mais c un ordre de grandeur comme celui-là)

Mais si tu as une HW2, utilise l'AUTO_INT_3 ! Il est TRES precis !!! (exactment une fois par seconde : c'est lui qui est le m"iatre"de l'horloge sur V200 et HW2
(sur HW1, il n'est pas aussi précis)

Ben oué mais 1 fois pas seconde c'est pas suffisant pour un bench (déjà que 20 fois par seconde c limite...)

Alors tu te bases sur les 2 chaque seconde tu remet à zéro le compteur qui est incrémenté ~350 fois par l'AI 1, et tu incrémentes de 350 unités un autre compteur

A la fin, tu additionnnes les 2 compteurs et tu obtient un temps hyper-précis

pe pas malheureusement :

- lancement du prog en C -> Free & Register timer, puis on quitte le prog
- déroulement du prog basic
- 2eme lancement du prog en C -> TimerCurVal : on releve la valeur, et on l'affiche

Impossible de toucher aux timers pendant l'execution du prog, puisqu'il est en basic

C'est possible, mais il faut passer par un peu d'asm (quoi que..... quand j'y pense, on peut tout faire en C)

Certes ça doit être faisable mais c pas ce qu'il y a de plus simple...
En fait v demander à qqun de tester sur real Ti, et si les résultats semblent cohérents on va dire que ça suffit
Après tout c'est du basic, je suis pas au 20e de seconde près

Ce n'est pas compliqué ! c'est un truc de ce genre :
 extern char Debut_FonctionAexecuterChaqueSeconde;  asm("Debut_FonctionAexecuterChaqueSeconde:");  void FonctionAexecuterChaqueSeconde(void)  {    // place ton code d'incrémentation ici    asm(" unlk a6; rte");  }  extern char Fin_FonctionAexecuterChaqueSeconde; asm("Fin_FonctionAexecuterChaqueSeconde:");     void InstallationDeLaFonction(void) {   unsigned short taille= &;Fin_FonctionAexecuterChaqueSeconde-&;Debut_FonctionAexecuterChaqueSeconde;   adresse= malloc(taille);   memcpy(adresse, &;Debut_FonctionAexecuterChaqueSeconde, taille);   // détournement de l'int, etc... }

J'ai fait ça en live, il faudrait vérifier qu'il n'y a pas d'erreur. Keviiiiiinnnn on a besoin de toi

Bah oué mais comment tu veux que je l'execute chaque seconde cette fonction ??? À moins de mettre un TSR...

Regardez les tutoriaux de la TICT, il y a un tutorial qui explique comment faire un TSR sur une interruption.

Nan mais je v pas utiliser un TSR pour faire un bench de prog basic

Le timer 6 devrait suffire (enfin j'espere...)

Bob 64 : ça c'est vraiment pas dur, mais vraiment pas du tout ! il suffit de faire SetIntVec(AUTO_INT_3, FonctionAexecuterChaqueSeconde)

Kevin : ça marche mon truc ?

oué, pas bête l'idée du TSR sur timer.

Thibaut a écrit :
Kevin : ça marche mon truc ?

Non.

Thibaut a écrit :
Bob 64 : ça c'est vraiment pas dur, mais vraiment pas du tout ! il suffit de faire SetIntVec(AUTO_INT_3, FonctionAexecuterChaqueSeconde)

Faux.

Thibaut> en faisant comme tu dis, une fois le prog ASM fini de s'éxécuter, le TIOS va le chasser de la RAM..; ou le déplacera à un moment où à un autre...
=> l'adresse du FonctionAexecuterChaqueSeconde changera...
et ça plantera

Ne vous engueulez pas pour ça

Qqun peut m'aider à faire le test sur une 'vraie' ti89 hw2 ?

squale92 : non

Kevin : tu pourrais expliquer pourquoi ?

Thibaut a écrit :
Kevin : tu pourrais expliquer pourquoi ?

Ce que tu fais là ne marchera pas parce que du code non PC-relatif (et le code généré par TIGCC ne sera en général pas PC-relatif) ne peut pas être copié ou déplacé sans être relogé.
Et en plus tu as oublié de rajouter 0x40000, donc ça plantera sur HW2.
Et enfin, il faut utiliser DEFINE_INT_HANDLER, pas ta ligne d'assembleur inline.

Sinon, si tu supprimes la copie (qui n'est pas possible à cause des relogements), le problème est celui que Squale92 vient d'expliquer.

La seule solution propre est celle du tutorial de la TICT: faire un fichier .c à part pour le TSR, le compiler, mettre le résultat dans un tableau, et le reloger avec EX_patch après la copie.

squale92 a écrit :
l'AU1... heu... moins précis... 340 sur HW1, et 350 sur HW2... quelque chose dans ce genre là...

C'est plutôt du 250Hz sur HW2 je crois.

C'est vraiment nécessaire de faire un TSR ? Pourquoi ne pas faire lancer tout simplement le programme basic par le programme C ? Un programme de bench de ce genre existe dejà, je sais plus son nom.

Et si jamais un programme détourne l'AI3, il faut le laisser executer l'ancien handler pour éviter de dérégler l'horloge sur AMS 2.07.

Pourquoi ne pas faire lancer tout simplement le programme basic par le programme C ? Un programme de bench de ce genre existe dejà, je sais plus son nom.

TimerZen. Mais je ne peux pas l'utiliser puisque plusieurs tests sont effectués successivement, et je n'ai pas très envie de découper chaque test pour le mettre dans un programme séparé...

J'ai la solution à ton problème, c'est plus simple que tout ce qu'on a pu envisager jusqu'ici !

Tu attend un peu que la 2.07 sorte pour les 89/92+, et tu n'auras plus qu'à utiliser la fonction Ti-Basic getTime() de lecture de l'horloge dans ton prog Basic

Bon la précision sera d'une seconde

C pas terrible comme précision ça une seconde... Mais sur le principe c'est pas con !

(mais je n'installerais pas cette merde d'ams 2.07 sur ma calc :p)

Thibaut, 22> si
(héhé cf explication de Kevin plus loin... ça plantera pas forcément tout de suite, mais ça plantera un jour ou l'autre... C'est aussi pour ça qu'il ne faut pas laisser les grays activés à la fin de l'exécution d'un programme, je crois...)

ExtendeD> OK.
oué, c vrai que c pas mal non plus comme solution

Bob> pour le pb de précision de 1 seconde...
tu lance ton prog 10 fois, et la précision passera à 1/10ème de second...

Il a dit qu'il voulait mesurer le temps d'exécution de différentes parties d'un même programme. Tu ne comprend rien toi

Pour l'histoire du handle déplacé, tu as tord, relit bien ce que dit Kevin. Tu ne comprend vraiment rien