Go Down

Topic: Multiplier par 1024 (Read 551 times) previous topic - next topic


Quote
Je suppose que tu voulais écrire uint32_t
Effectivement (en fait j'utilise unsigned long).

Code: [Select]
Serial.println(t1); // afficher le compteur
Je dirais plutôt
Code: [Select]
Serial.println(t1-1); // afficher le compteur
Cela donne le valeur juste.  En effet si on ne mesure rien, t1 vaut 1, et si on mesure _NOP( ), on trouve 2.

J'ai aussi une erreur de chronométrage de 1 que j'avais plus ou moins signalé. Je ne retrouve pas les 72 pour un décalage de 8 positions, j'ai dû me tromper. Pour les autres résultats, les mesures ont l'air d'être les mêmes.




J'ai refait les tests avec le timer. J'ai bien une erreur de chronométrage de 1 à partir d'un certain nombre.

Vu que ma méthode donne un résultat faux, je vais me pencher dessus. Quand je l'ai faite, je ne savais pas programmer les timers. Mais je crois que je vais m'orienter avec plusieurs chronométrages en fonction de ce que j'ai à mesurer. Je pense que passer par un timer est une meilleure solution pour les temps courts, limité à 255 cycles avec un timer 8 bits, 65535 avec un timer 16 bits. Pour des instructions plus lente (copie d'une image sur un écran par exemple) le timer ne fonctionne plus, je reprned mon ancienne version. Et une troisième méthode avec un analyseur en ayant une succession de PORTB=0; PORTB=FF; pour mesurer des choses qui ne passent pas par les deux premières méthodes, comme par exemple la durée de la remise à l'heure de l'horloge système.


D'un point de vue philosophique et pour les instructions longues, faut-il mesurer en tenant compte de l'horloge système ou pas? Ma méthode est fausse pour avoir le nombre de cycles, mais pas pour le temps moyen que va durer réellement l'instruction. Si elle dure exactement 1018µs, je suis sûr qu'elle prendre 1024µs car il y aura les 6µs perdus pendant la remise à l'heure.

Go Up