G
Salut gassiune,Tu veux dire que c'est simplement le fait de "gaver" le micro avec trop d'interruption qui cause l'instabilité?
Dans mon cas j'ai 4 codeurs à 480ppr et un micro 32bits à 83Mhz (vitesse maxi des moteurs 350 tr/min). J'aimerais savoir comment tu fais ton calcul de limite pour que je puisse l'appliquer à mon cas perso.
C'est un module ROVIN basé sur un processeur ARM 32 bits ARM7TDMI.Quel est la référence de ton microcontrôleur?
Je dois surement passer a coté de qqchose mais je ne vois pas ou est le problème pour faire encaisser cette vitesse de comptage à un compteur QEI interne de microcontrôleur.Il y a qq années en coupe de france, sur l'ascenseur du robot, j'avais un moto-réducteur avec encodeur placé sur le moteur (et non après le réducteur), cela me donnait qqch comme 18000 impl pour 1 tour de l'arbre après réducteur, donc, un déplacement de 2cm sur la visse à bille. Là, avoir un composant dédié était nécessaire...
J'avais une arduino... la mega 2560 ou sur une nano (328)... Pas de QEI dessus, que je sache. Donc, j'utilisais les interrupts, je perdais à vitesse lente quelques milliers d'impul, et à grande vitesse, plus de la moitié ne passait pas.Je dois surement passer a coté de qqchose mais je ne vois pas ou est le problème pour faire encaisser cette vitesse de comptage à un compteur QEI interne de microcontrôleur.
J'avais découvert sur le web une astuce qui consiste à utiliser (si tu as) deux entrées compteurs normales, et avec une simple bascule D tu transforme les signaux A et B en signaux CLK et CCLK.
Le principe en gros c'est de n'avoir plus qu'un signal qui transporte les fronts qui correspondent à un sens de rotation, et un autre signal qui transporte les fronts qui correspondent à l'autre sens de rotation.
Ça c'est le genre de raison qui explique pourquoi j'ai horreur d'utiliser des OSJ'ai refait plusieurs essais qui m'ont pointé la source du problème. C'est la gestion des événements du Rovin (pour ceux que ça intéresse, voir page 24 du PDF).
Sinon pour faire court, les interruptions sont converties en message puis placées dans une file d'attente puis les messages sont convertis en événements manipulable via une fonction réservée.
Au départ je gérais ces événements au sein de la fonction réservée via un "switch/case" (comme l'exemple page 24) afin d'incrémenter le bon compteur selon l'interruption, et quand j'ai utilisé une structure conditionnelle à base de "if" j'ai eu une amélioration avec un dépassement du compteur moins grand.
Puis j'ai creusé et n'ai laissé qu'un seul événement d'interruption (donc plus de structure conditionnelle) et là plus aucun dépassement notable!
Du coup, à moins qu'il y ai une astuce de programmation, je suis cuit car ça vient de la gestion trop lente de l'OS du module.
Ça c'est le genre de raison qui explique pourquoi j'ai horreur d'utiliser des OS(pour le meilleur et pour le pire !)
Par exemple, dans nos robots nous utilisons une carte d'évaluation de chez ST, la Nucléo-144 .
http://www.st.com/en/evaluation-tools/stm32-mcu-nucleo.html?querycriteria=productId=LN1847
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?