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 ;). En
plus, vu que la valeur est sur 32 bits, aucun problème de tour de
compteur !
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 ?
Antoine
Le 28 juin 2009 à 16:57, Olivier MATZ <z...@droids-corp.org> a écrit :
Salut Antoine,
Merci pour le patch ! j'avoue que pour le moment je l'ai juste
parcouru et pas encore regardé en détail. Je fais ça dès que
j'ai un peu de temps.
Une petite interrogation sur le principe : nous avons nous aussi
un module qui permet de récupérer la valeurs des codeurs par
spi. Je voulais juste te mettre en garde sur un inconvénient du
système (qui se contourne je te rassure):
L'an dernier on faisait du polling sur les codeurs toutes les
128us car la valeur lue était sur 8 bits, elle pouvait donc
boucler rapidement. On perdait pas mal de temps CPU à faire ça.
Cette année, la lecture des codeurs prend un certain temps
(plusieurs dizaines de microsecondes) rendant impossible de faire
un polling aussi rapide, mais comme les valeurs sont sur
16 bits, on peut se permettre de la lire que toutes les 5ms (à chaque
periode d'asservissement).
Ca ne pose aucun problème pour asservir le moteur. Par contre,
si on veut lire la position du moteur sur un évenement asynchrone,
comme dans le cas des balises par exemple, alors la précision
de la valeur lue est faible, puisqu'elle n'est mise à jour que
toutes les 5ms.
Pour pallier à ce problème, on a mis en place une interpollation
linéaire pour la balise et le scanner, ça marche très bien.
++
Olivier
Antoine albertelli wrote:
Hello,
Pour l'année prochaine, je fais (avec mon club) une carte de régul
ation
de moteurs basée sur Aversive. On a donc dû faire une solution de
lecture de codeur, vu que pas mal d'équipe ont des problèmes pour
ça, et
on pense avoir trouvé une solution intéressante : les LS7366 de LS
I/CSI.
Ce sont des compteurs de signaux en quadrature, 32 bits, interfaça
ble
par SPI, qui peuvent recevoir des signaux jusqu'à 40 MHz sur les 4
fronts des
signaux. J'ai donc fait un petit module (pas encore testé complète
ment,
uniquement avec un seul codeur au lieu de 3) qui permet de
communiquer
avec ces chips.
A+
Antoine
---
---------------------------------------------------------------------
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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
