GMail wrote:
> En fait là ça devrait être très rapide, vu que lire la valeur d'un
> codeur prend 1 octet d'instruction et 4 octets de réponse, et que le bus
> tient 1mo/s sans problème (enfin c'est ce que je crois ;).
par exemple:
5 octets * 4 codeurs = 20 octets
Si la freq de la SPI est à 1Mhz (c'était notre cas), alors ça fait
20 * 8 microsecondes = 160us.
ou même pour un seul codeur = 40us
> En plus, vu
> que la valeur est sur 32 bits, aucun problème de tour de compteur !
Certes
> Il faut encore que j'approfondisse le sujet, mais je crois que ces chips
> ont une pin de trigger qui permet de sauvegarder la valeur du compteur
> dans un registre pour la lire plus tard. Ça devrait permettre de
> définitivement regler le problème non ?
Si c'est un registre différent de celui ou tu lis habituellement,
alors oui ça règle le problème (et en plus ça sera très précis) :)
Si ce n'est pas le cas, tu as plusieurs solutions:
1/ retourner la derniere position lue sur timer.
-> problème de précision
2/ faire la lecture des codeurs dans l'interruption.
-> que se passe-t-il si ton évènement asynchrone se
produit pendant la lecture périodique ?
3/ même chose mais en vérouillant les interruptions pour
éviter d'être préempté
-> tu perds beaucoup de temps avec les interruptions
vérouillées, c'est en général dangeureux ou non
souhaité pour le reste du prog.
4/ Même chose que 1/ mais en interpollant par rapport
au temps et aux deux dernières valeurs lues.
-> légèrement plus lent mais au moins tu n'es pas
embêté :)
Olivier
_______________________________________________
Avr-list mailing list
Avr-list@droids-corp.org
CVSWEB : http://cvsweb.droids-corp.org/cgi-bin/viewcvs.cgi/aversive
WIKI : http://wiki.droids-corp.org/index.php/Aversive
DOXYGEN : http://zer0.droids-corp.org/doxygen_aversive/html/
BUGZILLA : http://bugzilla.droids-corp.org
COMMIT LOGS : http://zer0.droids-corp.org/aversive_commitlog
