le temps § - Page 1

slt, comment fait on pour determiner le temps entre 2 retours, par exemple pendant la realisation de la boucle FOR, comment faire pour k'il mette plus de temps a la réaliser?

soit tu utilises un timer, comme je le fais à un endroit ds mon tuto/
soit tu fais une boucle for dans le vent (pas joli)

Attention, une boucle for à vide est supprimé par GCC.
Je sais plus si le fait d'ajouter un continue arrange le truc.

Il faut déclarer la variable utilisée dans la boucle en volatile et il me semble que GCC ne supprimera pas la boucle vide.

met un idle(); dans ta boucle ... pis en plus, ca servira a qqch

Comment ça fonctionne, idle ?

tigccdoc/idle()

for (i=0;i<TIME;i++)
  idle();

quoi de plus simple ?
idle permet d'economiser de l'energie

for (i=TIME; i; i--) ça devrait etre un peu plus optimisé.

Attention, n'utilisez pas idle(); avec les niveaux de gris, vu que ça empêche l'interruption des niveaux de gris de fonctionner!

Moi, j'utilise ça dans Backgammon:

    pokeIO(0x600005,0b10111); /* low power mode, wake up CPU only on AI 1
                                 (grayscale), 2 (keypress), 3 (AMS clock), 5
                                 (AMS timer base, needed for APD) and 6 (ON,
                                 always wakes up the CPU) */

Peut-être qu'on peut aussi faire d'autres manipulations intéressantes, de genre éteindre la FlashROM, mais je pense plutôt que non (les auto-interruptions de AMS sont en FlashROM).

Pour plus de détails, cf. J89hw.txt (http://www.ti89hardware.tk).

oué, enfin boucle vide ennsortant l'incrémentation
for(int i=0 ; i<30000 ; ) i++;
(ça, il me semble que ct pas supprimé il y a quelques temps

Ça ne devrait pas être traîté différemment qu'avec l'incrémentation dans l'instruction for normalement...

Attention, n'utilisez pas idle(); avec les niveaux de gris, vu que ça empêche l'interruption des niveaux de gris de fonctionner!
Avec Idle si
Mais je ne sais pas si PpHd l'a implémentée dans PreOS.

Oui. Mais tout ce que le Idle de PreOs fait, c'est de lire le masque d'interruptions et de mettre en 0x600005 la valeur correspondante à toutes les interruptions non-masquées. Donc autant écrire dans 0x600005 directement, ça évite la lecture du masque d'interruptions (en général, le programmeur sait lui-même à quelles interruptions il veut permettre de réveiller la calculatrice!), d'où gain de place et de vitesse, et ça marche aussi en _nostub. Et puis Idle n'est pas dans les headers de TIGCC parce que Zeljko ne veut pas de fonctionnalités qui ne marchent qu'en mode kernel dans TIGCCLIB. (Moi non plus, d'ailleurs.)

Kevin, 11> ah ?
ben, il me semblait que, à un moment, ça faisait une différence, vu que c ce que j'utilisais dans Krypton pour faire les différences de vitesses
(heu... ça commence à dater )

Et pour avoir quelque chose de relativement précis (sans utiliser le timer 6, qui on un pas bien trop grand pour ce que je veux faire, ni les autres qui sont détournés) on fait comment ?

WaitForMillis dans les sources de TI-Chess.

Sinon, l'auto_int_1 est cadencé à 350hz.

Attention, pas sur HW2.

ah ?
Combien, sur HW2 ? c'est pas régulier ?

Ce sont 254 Hz seulement sur HW2.

Et ça dépend un peu aussi des piles, non ?

Pas sûr:
"The speeds of OSC1 and OSC2 seem to be independent of the battery strength, but OSC3 runs slower with older batteries."
"Level 1: Triggered at a fixed rate: OSC2/2^11. See $600015:7/1."

(j89hw.txt)

A priori, l'auto-int-1 ne dépend donc pas des piles...

Sur HW2, c'est 256 Hz exactement.