Encodeur en quadrature universel
Encodeur en quadrature universel
A /
Le nouveau montage
1 Le nouveau principe
1.1 Les rebonds
2 Le montage et son schéma
2.1 Le hardware
2.2 Le logiciel
3 Les applications logiciel
3.1 Réponse Y/N
3.2 Choix de messages
3.3 Le comptage simple
3.4 Limitations ou contrôles
3.5 La préséance + - Valid
4 Le modèle en CMS
4.1 Le Circuit Imprimé
4.2 L'encodeur avec switch et détente
4.3 Le PIC 12F675 et L'ICSP
5 Conclusions
B Le montage qui ne fonctionnait pas : La déconvenue
1 Les principes
2 Les modèles
2.1 Résistances et condensateurs
3 Le Schéma du montage
4 Les problèmes de tels appareils
5 Les modes
5.1 Mode linéaire
5.2 Mode vitesse
5.3 Les valeurs retournées
6 Les possibilités
6.1 Le nombre de bits
6.2 Les incréments
6.3 Le switch
7 Le transfert des données
7.1 Les timings
8 Le programme
9 Conclusions
10 Les essais réels
Si vous arrivez directement sur cette page par un moteur de recherche, vous pouvez avoir accès à la table des matières et à chaque article, en page d'accueil. L'accès se fait par l'un des deux liens en tête de colonne de droite ----->
ATTENTION à compter du 15/09/2019 les commentaires ne seront plus possibles à causes de quelques imbéciles qui font du spam pour le plaisir de nuire ! désolé !
Avant propos.
La lecture de cet article est un peu particulière, car vous pourriez commencer par la version qui n'a pas fonctionné correctement et que j'ai abandonnée (Chapitre B). Elle est cependant riche d'enseignements et d'explications du principe et des raisons de l'abandon.
Mais si vous êtes pressé, ou que vous souhaitez aller à l'essentiel, vous pouvez passer à la lecture en séquence de ce chapitre "A" immédiatement ci-dessous et ignorer ce chapitre B.
Toutes fois, si après lecture du chapitre A, ou si vous êtes curieux de comprendre le pourquoi de ce nouveau dispositif, alors lisez ce chapitre B, vous comprendrez mieux les raisons qui m'ont amené à cette nouvelle approche plus simple et plus fiable.
Ce sujet est un peu technique et c'est surtout un article pour les électroniciens ou bons bricoleurs, mais si le sujet est simple dans l'esprit , il devient rapidement "indigeste" dans les différentes possibilités de réalisations et des logiciels.
Information du 15/05/2016 : Ces deux articles concernent les encodeurs "libres" sans "détente" ou sans "Click". En effet j'ai voulu reprendre ce programme pour ce type particulier d'encodeur, et ça ne fonctionne pas . Un chapitre C expliquera prochainement les raisons de ce problème....(à suivre)
A /Le nouveau montage
L'impatience suite à l'acquisition d'une nouveauté a fait
comme d'habitude quelques dégâts car on prend mal en compte tous les éléments de base.
En effet, j'ai acheté pour un Euro environ quelques petits encodeurs en quadrature…, avec l'intention d'en faire un outil standard d'interface utilisateur. Ça n'a pas été immédiatement le cas, mais seulement un peu plus tard !
Ainsi je pensais faire un appareil standard et ayant beaucoup de possibilités pour s'adapter à diverses situations, et au mieux très autonome et universel.
Ça n'a pas été intégralement possible, et j'ai du revoir mes prétentions un peu à la baisse…
Mais au final c'est peut-être encore mieux que ce qui était initialement prévu… C'est réellement une chance et on peut dire que c'est ce que l'on appelle le "pot" !
Le principe de base était de transmettre un certain nombre de bits d'incréments ou de décréments (compteur) à un appareil (Montage) utilisateur situé sur un processeur hôte (Appelons le "host" pour ne pas le confondre avec le processeur du montage encodeur). Ceci aussi dans le but de décharger le host de différentes tâches, dont le paramétrage toujours fastidieux.
Ainsi l'encodeur était chargé de remplacer les switchs + et – et validation sur les montages à PIC. Donc 3 fonctions avec seulement 2 (ou 3) Ports I/O.
Les informations d'entrée et de sortie de l'encodeur étant gérées par un petit PIC chargé de deux grandes fonctions qui étaient de gérer l'encodeur en termes de signaux des phases au nombre de 2, mais aussi de transmettre au host jusqu'à 16 bits représentant la valeur d'un compteur mis à jour par les impulsions + et - de l'encodeur.
Le premier élément qui a "cafouillé" est la vitesse du PIC de l'encodeur, et on verra qu'il y a un corollaire à la vitesse…
Il faut en effet savoir qu'un encodeur mécanique de ce type peut fournir des tops à une vitesse très élevée, puisque celle-ci peut monter jusqu'à une variation par milliseconde, simplement en ROTATION MANUELLE de l'encodeur.
Les fabricants semblent garantir 3 ms, mais je n'ai pas pu retrouver cette information entr'aperçue au gré d'une doc ou d'un site.
Le travail de fond du montage encodeur consistait à "séparer le bon grain de l'ivraie" au niveau des phases (gérer les rebonds), mais aussi à gérer la vitesse de rotation pour en déduire un paramètre d'incrément supérieur à l'unité, permettant de couvrir de larges gammes de valeurs en termes de nombre de bits utiles en comptage (ou décomptage).
A cela s'ajoutait encore la gestion une fois pour toutes en début de programme d'un autre facteur de multiplication qui était la modulation (multiplication) du nombre de tops en fonction du nombre de bits choisis.
Alors pour tout ce travail il a fallu monter la vitesse à une valeur supérieure à celle de l'application associée tournant à 4 Mhz. J'étais donc passé à 16 MHz, mais cela n'a pas suffit, car de nouveaux problèmes sont apparus lors du transfert des bits de données. (Outre une consommation jugée trop élevée pour un montage sur pile ou accus)
En effet cette transmission devait être ultra rapide (Durée maxi de transmission correspondant à 1ms maximum) pour ne pas perdre de données de phases. Aussi j'avais prévu une transmission synchrone avec data et clock. Les horloges des PIC auraient dû être synchronisées, mais sur le PIC encodeur, ce n'était pas possible vu le nombre restreint d'I/O et l'absence d'USART.
Ce choix de PIC était (et est) nécessaire pour limiter la taille et au besoin réduire les consommations de fonctions inutiles)
Les éventuelles variations de fréquence de l'encodeur donnaient de nombreuses erreurs et je suis même arrivé à ne plus fonctionner du tout en essayant d'améliorer à tout prix le système. A ces erreurs, il faut ajouter une très forte sous-estimation des rebonds des contacts, car cela n'apparaît pas au premier abord au scope, vu le caractère parfaitement aléatoire de ceux-ci.
Certes on peut toujours quand on veut, mais franchement cet encodeur n'était pas mon but ultime, mais seulement un simple outil pour faire fonctionner le microampère heure mètre en étude et mise au point actuellement.
Un autre point très délicat (Au niveau individuel) était le travail tant hardware que logiciel sur deux montages à la fois, et la programmation nécessitait de "papillonner" d'un PIC à l'autre (bien que le codage soit par chance pin compatible !).
Le plus stressant était aussi de repasser d'un "sens" à l'autre, bref, une attention de tous les instants pour ne pas se tromper…Alors j'ai découvert cette nouvelle difficulté de passage d'un PIC à l'autre de façon alternative !
De plus pas moyen d'obtenir de façon simple, des sous-multiples des différentes périodes des PIC (ou de se synchroniser).
Travailler en transmission à vitesse élevée (Sans interruptions, ni USART) au niveau de l'instructions machine est une prouesse qui se termine toujours à 250ns près (Et au mieux, car je ne parle pas du pire…!)
Bref, le challenge était trop serré pour perdurer, et j'ai du revoir ma copie pour essayer de "sauver les meubles" et faire fonctionner tout de même ce tout petit "truc".
Un des souhaits de base de l'utilisation de cet encodeur "un peu intelligent" était aussi d'améliorer l'ergonomie des applications tout en réduisant les I/O nécessaires. Aussi il fallait pouvoir gérer 2 phases et un switch en entrée et sortir des données sur 2 OUT seulement.
On ne gardera pas une vitesse élevée car c'est possible de faire plus lentement du fait que bien des calculs ne seront alors plus réalisés sur l'encodeur.
Autre problème de ce manque de structure, il fallait impérativement que l'application fonctionne à une vitesse sous-multiple de la fréquence du PIC encodeur.
En effet les réglages de temps par adjonction d'instructions sont toujours délicats, et à une instruction près ça peut être "raté". Le fait de n'avoir que 16 ou 17 bits maxi à envoyer permettait d'espérer une non désynchronisation jusqu'à ce nombre d'informations élémentaires de 16 ou 17, mais…!.
Mais cela n'a pas été suffisant et j'ai aussi dû abandonner la mort dans l'âme, pour toutes ces raisons conjuguées, et surtout la principale que j'ai mal appréhendée, qui est les rebonds trop largement sous-estimés, avec pour cause principale une vision très optimiste au scope, due au caractère très aléatoire de ceux-ci.
J'ai tout de même pu sauver le hardware très simple et le reste a été seulement une modification de la programmation.
1 Le nouveau principe
Ce nouveau principe s'insère totalement dans le
hardware déjà existant et devrait permettre d'utiliser le montage au niveau encodeur, sans pour autant utiliser la sortie OC qui est abandonnée dans le contexte d'utilisation actuel. Il s'insèrera au niveau hard avec un simple croisement d'I/O au niveau "host", et un simple changement entre RC7 et RB5 qui sera la seule modification hardware.
Il faut donc revenir à un principe plus simple qui sera seulement d'envoyer des impulsions positives (de qualité) en comptage et/ou en décomptage, à une fréquence maxi de 1KHz, mais aussi de prévoir un switch de validation qui sera également codé par le montage.
En résumé il faut transmettre :
- signal +1
- signal -1
- Appui sur switch
On dispose donc de deux PORTs en sortie, et cela reste donc théoriquement possible, dans la structure même, à laquelle il faudra ajouter l'état de "repos" qui fera la 4ème possibilité du codage sur 2 bits seulement.
Cependant j'avais oublié que l'I/O GPIO3 utilisée préalablement en entrée clock devra être en sortie…
Pas de chance c'est une entrée seule ! Alors il va falloir aussi couper et strapper encore ce croisement… Le CI est déjà un peu malmené, alors un peu plus un peu moins…!
Au niveau de l'utilisation sur le host, il faudra fonctionner par changement de valeur sur ces deux bits (Interrupt On change). Il faudra donc avoir après chacune des trois actions, un retour à zéro (Repos) qui sera la quatrième valeur codée sur ces 2 bits.
Ce retour à zéro ne pourra pas avoir lieu par un signal de handshack, et sera fait sur un temps de présence de la commande initiale. On pourrait faire en sorte de n'avoir qu'une seule interrupt pour ne pas distraire "pour rien" le montage utilisateur, mais c'est un peu "short" pour s'accorder avec le host, alors il est préférable d'avoir la deuxième impulsion de retour à zéro une centaine de µ secondes plus tard, le temps nécessaire au host pour traiter sa propre séquence d'interrupt la plus longue (Horloge TIMER0 par ex.).
En sortie, les changements de sens des phases sont réalisés en code GRAY suivant le tableau ci-dessous, et principalement sur les +1 et -1 :
GP1 GP0
0 0 Repos
0 1 +1
1 0 Appui switch
1 1 -1
Ainsi c'est l'encodeur qui maintiendra la durée des ses 2 signaux codés jusqu'au retour à zéro, pour que le montage utilisateur (Sur le host) fonctionne avec sécurité sans perdre d'information.
Globalement ce sera une centaine de µs à établir que l'on mettra en paramètre initial lors de la mise sous tension à partir d'une constante EEPROM qui permettra une certaine universalité de l'encodeur qui pourra alors s'adapter à toutes les vitesses souhaitées sur les hosts, sans avoir à ré-assembler le programme source.
Pour ce faire l'interruption host due au montage encodeur devra seulement être placée en tête des interruptions.
Ce temps de présence de la sortie restera la seule véritable contrainte qui devra être traitée sur l'encodeur, mais des mémorisations locales au host sont tout à fait plausibles et même parfois nécessaires.
Le principe NRZ (Non Return to Zero) n'apporterait rien de plus sinon qu'il faudra tout de même repasser par zéro dans le cas d'une suite identique de commandes, ce qui sera souvent le cas (Lorsque l'on tourne l'axe toujours dans le même sens par exemple).
Le retour à zéro en sortie est donc traité par un temps paramétré qui assure un dialogue plus simple. C'est également plus simple dans l'énoncé et la compréhension du principe.
(Un codage NRZ reste possible mais plus complexe à mettre en place à cause des 3 possibilités de signaux potentiellement actifs)
En d'autres termes, les impulsions de codage en sortie seront à largeur fixe mais paramétrables dans l'EEPROM du PIC encodeur.
Le travail à réaliser sur le montage utilisateur, (host) sera assez réduit, puisqu'il s'agira d'une simple opération d'addition sur le nombre de bits prévus. Cette opération est tout à fait exécutable en séquence interrupt. Les limitations de comptage sont également traitées sur le host dans la séquence interrupts sans augmenter sensiblement le temps de traitement et sont un réel avantage…On verra pourquoi !
Ces additions ou soustractions pourront être adaptées en taille (nombre de bits) par le host, puisque l'encodeur lui-même ne possède pas les limites, (encore qu'il puisse faire un calcul parallèle), mais il ne pourrait de toutes façons pas le signaler au host. (Sa seule possibilité serait de bloquer tout envoi d'incrément ou de décrément).
La fréquence maxi de 1KHz sur le montage utilisateur est tout à fait supportable pour ces opérations quelque soit la vitesse.
(NOTA : Dans tous les cas une vitesse processeur de 31KHz n'est pas envisageable avec ce genre de montage, mais ce serait tout de même bon de vérifier avant de l'affirmer).
L'inconvénient principal de la solution, est de ne pas pouvoir faire la modulation d'incréments/décréments en fonction de la VITESSE de rotation et du NOMBRE DE BITS, de ne plus contrôler automatiquement les limites avant envoi, et d'obliger le host à un peu plus de calculs.
Cependant, la sensibilité angulaire est élevée (24i/tr) et cela palie beaucoup ce problème et cette réduction des possibilités locale est parallèlement un incroyable avantage…(cela représente 15° angulaires et sur un bouton de commande de diamètre moyen, c'est très vite atteint !)
Le nombre de bits n'est donc plus traité au niveau encodeur, mais seulement au niveau host.
La vitesse de rotation pourrait éventuellement être traitée si nécessaire au niveau du host si l'on a assez de temps et de place mémoire pour le programme associé à cette mesure qui prend tout de même pas mal de temps de calcul.
Au niveau host on aura directement les 2 bits reçus cadrés à la droite d'un octet et les deux précédents dans le même octet en quartet de poids fort. (Interrupt on change). On traitera le comptage sur un seul octet pour simplification.
Pour traiter rapidement ces informations, un flag bit "quadra" indique un changement de valeur de l'octet de comptage (Quadra_Val) ainsi qu'un flag bit SW qui indique l'appui sur le switch (Outre le bit quadra qui est toujours positionné sur changement, quelque soit le sens de rotation ou l'appui sur le switch).
Voilà donc la ligne conductrice des principes de ce nouvel encodeur qui ne différera pratiquement en rien du précédent au niveau hardware, (hormis les petits croisements de "pinoches" dus à GPIO3 input seule), mais seulement au niveau du programme qui sera complètement différent.
Comme on disposera d'un peu plus de temps par l'abandon du calcul de vitesse, on améliorera le contrôle de la vraisemblance des informations de l'encodeur lui-même durant un temps beaucoup plus long de 1275µs. A ce sujet, j'ai remarqué que des erreurs dues aux rebonds erratiques subsistent toujours, mais sont parfaitement compensées par la table des ordres, avec une stabilité de la commande en cas d'erreur due aux rebonds.
J'ai pu également vérifier sur un autre appareil du commerce que cela se produit aussi (Vanne électronique par exemple)
On pourra également, et c'est un point important, utiliser la fonction SLEEP sur le montage encodeur, pour réduire sa consommation. Il n'est pas possible de le couper totalement (Hors tension) car il doit pouvoir reprendre son service à tout moment par rotation de l'encodeur ou appui sur le switch.
Dans cette optique de faible consommation, les résistances pull-up des contacts encodeur sont des 100K associées à des condensateurs de 4.7nF. C'est un compromis de consommation et d'élimination des rebonds de courte largeur. J'avais essayé également 470pF, mais c'était un peu trop juste et j'ai préféré perdre quelques µs de temps de montée.
La consommation globale varie en fonction de la position des switchs de l'encodeur, et en l'absence de contact encodeur la consommation au repos est de 50 nA. Pour un contact encodeur établi, 96 µA et avec la LED allumée un court instant, on ne dépasse pas le mA.
Cela est le résultat principal de la fonction SLEEP du PIC et des résistances utilisées.
On gardera la "double nationalité" de GPIO5 à la fois entrée potentielle d'horloge ou autre (?) et sortie pour LED. On affectera l'allumage de la LED au réveil du PIC, et son extinction au SLEEP.
Un clignotement éventuel à une erreur grave au niveau encodeur (À définir, mais je n'ai pas de pistes pour l'instant)
Un éclair LED confirme l'appui sur le switch.
Le PIC démarre en 70ms après la mise sous tension.
Le réveil du PIC en sommeil se réalise environ en 25µs (l'oscillateur RC interne démarre à peu près à la moitié de la tension VCC, sur un changement d'I/O des phases de 0V à 5V).
Ce 
point d'établissement de tension me semble important à être souligné, car lorsque la tension varie très rapidement, le réveil est lui aussi très rapide…(Voir oscillogramme ci-contre avec la
variation de l'un des signaux de phase et démarrage de l'horloge du PIC -avec oscillateur externe dans ce cas précis-)
Attention je parle ici de l'établissement des niveaux issus des phases sur les entrées du PIC et provoquant son "réveil"..
(On avait vu que les temps de montée au niveau des phases dépendaient du type ouverture ou fermeture de contact, à cause de la présence nécessaire des condensateurs …(Voir oscillogrammes )
Doit-on réduire encore la valeur de ces condensateurs ? Je ne le pense pas. Le compromis me semble acceptable !
Enfin ce nouveau montage, au vu de son fonctionnement, ne causera pratiquement aucune inter-action particulière entre les deux PIC (montages), mis à part ce temps de présence des signaux. Il sera donc beaucoup plus facile de le mettre au point.
La mise au point se fera simplement sur l'entrée double trace du scope, sans nécessiter de dialogue handshake avec le host.
(Les difficultés sont largement moindres dans tous les domaines évoqués)
Je me pose la question de l'intérêt d'un tel montage relativement à une entrée analogique (avec conversion de la tension issue d'un potentiomètre) et à un switch associé ?
J'ai un peu de mal pour répondre honnêtement à cette question qui est tout de même très pertinente.
Les avantages certains, sont la non limitation à la résolution du convertisseur et à la COURSE DE ROTATION INFINIE du pseudo potentiomètre, avec peut être une rapidité plus importante (?), mais aussi plus de "temps machine" au niveau interrupts.
Enfin l'utilisation nécessaire d'un potentiomètre (organe mécanique avec ses faiblesses) pour attaquer l'entrée ANA.
Un avantage certain est la calibration parfaite des 2 signaux de sortie indépendamment des sautes d'humeur de phases...
(J'avoue que c'est d'une mauvaise foi évidente et une mauvaise raison, car ce type d'encodeur est cependant encore plus délicat au niveau mécanique (avec les rebonds) que les crachouillis d'un potentiomètre vieillissant !
Mais les avantages restent intéressants suivant les situations particulières rencontrées, et en ayant fait cette part des choses, et à l'appui de l'expérience que j'en ai maintenant, je suis même près à dire que l'ergonomie est largement améliorée et que le contrôle de valeurs proches dus à la précision d'une entrée ANA est supprimé de fait.
J'ajouterai aussi que cette expérience permet cependant, et c'est là le plus important, des rotations sur plus de 360° et que l'utilisation en capteur angulaire est cette fois incontournable et détrône sans conteste le traditionnel potentiomètre.
L'expérience ainsi acquise permettra de mieux cerner les futurs problèmes au niveau angulaire.
La fréquence maxi est de 1000 Hz environ ce qui représente des impulsions toutes les ms. Au-delà de ces valeurs, des pertes d'informations (Bien compensées cependant) peuvent se produire. En réalité, en tournant rapidement à la main l'encodeur, on arrive difficilement à cette valeur.
Il sera nécessaire au niveau host que les valeurs de sortie du montage encodeur soient maintenues durant un temps suffisant pour qu'il ait le temps de traiter aussi une interrupt de son timer0 avec mise à jour complète de l'heure (Cas de minuit au 31 Décembre…).
La rançon de cette prolongation sera la perturbation du host par le retour à zéro qui ne fera rien de particulier que de consommer un peu de temps CPU en INT pour quelques instructions.
Il est préférable pour des raisons de standardisation de fonctionner à 4 MHz sur oscillateur RC interne, ce qui facilite bien les choses, car c'est le plus simple et le temps de démarrage est quasiment instantané.
Il est évident que j'ai du réduire mes prétentions face à ce premier montage tout à fait "turbulent" et sur lequel j'ai dépensé sans compter un temps précieux pour un résultat qui se traduit seulement maintenant par un très bon fonctionnement, mais pas par un fonctionnement "parfait"
En effet, les erreurs inhérentes au procédé mécanique sont traitées proprement et n'impactent pas directement le host !
Il faut dire aussi que ces encodeurs sont de très petites mécaniques réellement très instables et à la lumière de tous les problèmes rencontrés, et outre les commandes en panel avant, je les verrais bien dans leur fonction en tant que codeur angulaire sur mon panneau solaire, là où la VITESSE DE ROTATION de la terre ne mettra pas en évidence les rebonds des contacts !!!
1.1 Les rebonds
Ces encodeurs sont constitués de simples contacts mécaniques, aussi il y a toujours des rebonds. Ces rebonds sont totalement aléatoires, ce qui explique que je les avais largement sous-estimé.
En effet le caractère aléatoire fait qu'à l'oscillo, on n'en distingue qu'une très petite partie. On se rend compte de l'étendue des problèmes que lorsque le PIC travaille en réel et que l'on comptabilise les "loupés".
(Voir un exemple particulièrement "vicieux" d'un rebond "tardif" non dangereux présentement mais d'autres peuvent être interprétés comme un changement effectif)
Je n'ai pas eu le courage d'ouvrir un de ces encodeurs pour mieux comprendre les raisons profondes de ces rebonds. Cependant je reste très surpris du mode de fonctionnement avec un couple de rotation assez résistant par un frottement "mou" de type "objectif d'appareil photo".
Ce frottement mou est cependant très bien fait car je n'ai jamais constaté d'hésitations autour d'un point de basculement, une fois l'axe lâché.
Je vais essayer un autre modèle ayant cette fois des "détentes" et un switch intégré, mais cela ne devrait pas changer le problème des rebonds. (Voir le modèle CMS ci-après)
Je pense que ces éléments sont parfaits pour contrôler des rotations manuelles ou lentes, mais sont moins bien adaptés aux fréquences élevées.
L'utilisation pour le contrôle de rotation de panneaux solaires me semble tout à fait cohérente, car le temps autorise d'attendre la stabilisation parfaite des contacts, et en ce sens la position statique est toujours parfaite.
Je n'ai pas eu non plus la possibilité de vérifier la précision angulaire de chaque position, mais j'ai quelques doutes sur la régularité des espacements.
Bien que ces systèmes mécaniques associés à des poulies soient abandonnés en contrôle de niveau en eau potable, c'est une application simple pour les bricoleurs, et qui ne devrait pas poser de problèmes, car la lenteur est de fait !
2 Le montage et son schéma
2.1 Le hardware
Ce schéma est très simple et le cœur véritable se situe dans le programme qui va compenser les instabilités mécaniques de l'encodeur et réaliser la mise à disposition des signaux vers le host. Tout repose sur un PIC 12F629 (ou 675) avec oscillateur RC interne à 4MHz. (On verra que ce schéma sera encore simplifié par la version 8)
Sur le connecteur du petit CI, il avait été prévu de fournir l'oscillateur si on le désirait. Il suffisait alors de court-circuiter X2 ou R=100 ohms et de ne pas monter C5 ni X1 ou la diode.
Il était également possible d'utiliser un oscillateur externe à une fréquence plus élevée que 4 Mhz si nécessaire. Dans ce cas c'est X1 qui devra être court-circuité. Les valeurs indiquées permettent une fréquence de l'ordre de 16 Mhz.
Enfin si vous travaillez avec l'oscillateur RC interne
, (C'est le cas ici) GPIO5 servira alors à allumer la LED qui témoignera, soit de la rotation, soit de l'appui sur le switch. C5 sera alors retiré bien évidemment.
Ce schéma Rev 7 est celui réalisé et qui fonctionne correctement, mais je pense qu'il y aura lieu de le modifier un peu plus pour réaliser en plus l'ICSP (Programmation in situ) et de figer définitivement avec le plus possible de CMS, y compris le PIC.
Autre information … Au vu de la très faible consommation du montage, je l'avais initialement alimenté en VDD par une I/O du PIC du host…Grave erreur !
Je n'avais pas fait très attention, car en général on ne se pose pas de question sur le filtrage et on est le plus souvent assez "généreux".
Si vous deviez aller dans la voie d'alimentation par une I/O (C'est tout à fait possible), il sera nécessaire de vous contenter d'un condensateur de découplage/filtrage de 1.2 nF au maximu
m pour que les temps d'accès soient respectés.
Évidemment une I/O de PIC ne peut pas charger un tel condensateur de 4.7 µF sans poser quelques problèmes et la limite est de l'ordre de 1.2 nF…! Sans découplage le PIC tourne en "patate" lorsqu'il y a quelque longueur de fils de liaison.
Le circuit imprimé présente peu d'intérêt puisqu'il n'est pas à jour, je donne le schéma seulement pour information.
Attention cependant au fait que dans ce cas précis, le codeur est soudé côté cuivre et non côté composants, pour pouvoir être dépanné facilement.
Vous noterez également un détail qui a son importance, en ce fait que le petit étrier tôle du codeur DOIT être isolé de la masse, (NON), car cela peut produire des tensions parasites dûes à des masses multiples dans le modèle prévu en fixation sur un panel métallique. J'avais hésité sur ce point et ce n'est qu'à la réalisation et la mise en boîtier métal que j'ai compris que c'était plus normal de laisser ce petit étrier sans potentiel fixé. (Exception à la règle !)
Cette particularité ne m'a pourtant pas encore posé de problèmes mais il faut tout de même ne pas refaire cette erreur .
J'ai également fait des essais à VDD de 2.5V et le fonctionnement serait très légèrement moins bon au niveau des rebonds (?), mais il faut que le host ait cette tension en compatibilité et c'est donc possible, mais je n'ai fait aucun essai réel…
Un nouveau schéma permettra de programmer le PIC directement sur le circuit et 2 pins du connecteur ont du être croisées pour s'adapter directement à mon codeur (Velleman). Le reste devrait normalement suivre et ne pas poser d'autres problèmes. La LED sera donc implantée à demeure (CMS ? verticale ou couchée, ce n'est pas encore décidé) mais peut-être avec une petite fibre optique, car il n'y aura pas beaucoup de place...
Je vous propose ce nouveau schéma en version 8 qui n'est pas encore réalisé en composants traditionnels (mais est réalisé en CMS). Voici les principales caractéristiques :
4 MHz, oscillateur interne, connecteur compatible raccordement externe et ICSP, LED, Encodeur avec "détente" et switch intégré EC12D1524403, PIC12F675 en CMS, puisque la fonction est maintenant bien stabilisée.
(Vu l'écart de prix j'ai préféré des 12F675 au lieu des 12F629. Ils pourront me resservir ultérieurement, car les achats sont maintenant par 5, 10, voire beaucoup plus !))
Les options d'oscillateur, et de possibilités diverses ont été abandonnées, car peu utiles au demeurant. Par opposition, la programmation ICSP prend toute sa dimension et le connecteur de liaison avec le host, est aussi maintenant le même connecteur qui servira à la programmation ICSP.
Ainsi que je l'avais précédemment indiqué, je n'avais pas réussi à réaliser cette programmation ICSP lors d'un épisode précédent. Le mystère reste encore entier, mais cette fois, je ne vois pas de raisons pour que cela ne fonctionne pas, vu que tout est identique à une programmation directe.
Le condensateur C5 sur le switch ne devra pas être monté pour ne pas perturber le signal Vpp. (Je pense que c'était la raison du non fonctionnement précédent).
2.2 Le logiciel
Je vais donner ici le source de la partie interrupt sur le PIC encodeur, ainsi que la partie interrupt sur le montage utilisateur (Ici le microampère heure mètre).
(La partie logiciel en liaison sur le host fera partie de l'article sur le microampère heure mètre qui sera prochainement publié)
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Sequence interrupt de base uniquement pour le codeur
;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
ORG 0x004 ; interrupt vector location
;
; Pas de Sauvegarde des regitres
;
; traitement des Phases AVANT ou OLD bits{2,3} APRES ou NEW bits{1,0}
; test si switch
;
DEB_IO
bcf GPIO,Bit5 ; LED ON (après save des autres I/O)
movfw GPIO
bcf INTCON,GPIF ; reset interrupt avec lecture préalable
movwf IO_ACTU ; save valeur actuelle I/0
movfw IO_PREC_SV ; reprise du précédent déjà maské 0x14
movwf IO_PREC ; manoeuvre et résultat de XOR
movfw IO_ACTU ; tous les bits
xorwf IO_PREC,f ; OU exclusif recherche INT dans IO_PREC total bits sauf LED
;
; IO_PREC contient maintenant le résultat du XOR OU exclusif et non plus le PREC (tous les bits)
;
btfss IO_PREC,Bit3_SW ; test CHANGEMENT SW1
goto INT1 ; Ce n'est pas le SWITCH !
btfsc IO_ACTU,Bit3_SW ; test si Switch appuyé (à zéro)
goto Ret_INT4 ; on ne fait rien car relâché du switch
bsf SW_Activ ; set switch activé en plus de Phas_Activ
goto Ret_SW ; avec Phase_activ
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; traitement des changements de PHASES
; Ce n'est pas SW, c'est donc les phases
; première analyse des phases il ne peut y avoir qu'un seul changement à la fois
; donc 01 ou 10. les autres combinaisons sont des erreurs
; XOR Prec/Actu ! 00 01 10 11 PREC
;___________________________________________________
; 00 ! 00 01 10 11
; 01 ! 01 00 11 10
; 10 ! 10 11 00 01
; 11 ! 11 10 01 00
; ACTU
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; en premier délay µs pour éviter des doubles seulement
;
INT1
movlw 255 ; delay 1275 µs à 5 cycles
call DLY_5µbase
;
; test sur les XOR retry maxi de 5
;
movlw 5 ; 3 retry maxi
movwf Cnt1 ; compteur
INT1B
movlw 10 ; petit délay 15 µs
movwf MAN1
decfsz MAN1,f ; exécution délay
goto $-1
;
; exécution des XOR
;
decfsz Cnt1,f
goto INT1C
goto erreur
INT1C movfw IO_PREC_SV ; reprise du précédent non XORé
movwf IO_PREC ; manoeuvre et résultat de XOR
movfw GPIO ; reprise pour boucle
movwf MAN1I ; save cas OK pour "codage" ci dessous
xorwf IO_PREC,W ; OU exclusif recherche INT dans IO_PREC
andlw 0x14 ; seuls 2 bits utiles
; movwf IO_PREC ; XOR masqué phases seulement
skpnz
goto INT1B ; Erreur Tout à 0 en XOR re-essai
sublw 0x14 ; cas d'un double changement de bits
skpnz ; si=14 ---> double changement theo impossible
goto INT1B ; Erreur Tout à 1 en XOR re-essai
; MAN1I contient IO_Actu complet sans erreur avec tous les bits
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; codage des valeurs (3-2, 1-0) pour new, old décalage de 2 bits systématique
codag
rrf codage,f ; codage contient à gauche les anciennes phases 2 bits
rrf codage,f ; décalage New-Old à droite
movlw 0x03 ;
andwf codage,f ; Old à droite
;
; déplacement du but 4 en bit 3
bcf MAN1I,Bit3 ; au cas où mais non utilisé pour l'instant (MCLR* non c'est MAN1I)
btfsc MAN1I,Bit4 ; cadrage Bit4 à côté du 2 (sur le 3)
bsf MAN1I,Bit3
movfw MAN1I
andlw 0x0C ; bits de phase en 3 et 2
; movwf IO_Actu ; save nouvelles valeurs phases cadrées bit 3 et 2 avec old en 1 et 0
iorwf codage,f ; on garde l'historique à gauche (sera enlevé pour indexation ?)
;
; "codage" contient maintenant gauche à droite 4 bits à 0 puis 2 bits new et 2 bit old à droite
;
Ret_SW
bsf Phas_Activ ; flag phases actives
;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; retour interrupt commun
;;;;;;;;;;;;;;;;;;;;;;;;;;;;
Ret_Int3
movfw IO_ACTU
movwf IO_PREC_SV ; Actuel dans précédent sauvegardé
Ret_Int2
bcf INTCON,GPIF ; reset INT
BK1_0
; RETFIE ; return from interrupt routine
RETURN ; Return sans valider les INT Synchro sur SLEEP
;
Ret_Int4
call DLY520ms
bsf GPIO,Bit5 ; LED OFF
bsf IO_Actu,Bit5 ; Updt IO_Actu
goto Ret_Int3
;;;;;;;;;;;;;;;;;;;;;;;;;;
; Retour erreur en interrupt
;
;;;;;;;;;;;;;;;;;;;;
erreur
movlw 150
call DLY_20µbase ; délay 3000 µs
bsf GPIO,Bit5 ; LED OFF
bsf IO_Actu,Bit5 ; Updt IO_Actu
call Pos_Init ; chargement position
goto Ret_Int2
;=====================================================================
; fin interrupt
;=====================================================================
---------------------------------------------
Le principe des phases repose sur une table à 16 valeurs regroupant anciennes et nouvelles valeurs sur un seul octet. C'est le principe le plus répandu et décrit ci-dessous. (Attention aux frontières avec PCLATH : Org 3D0)
;;;;;;;;;;;;;;;;;;
; table des phases
;;;;;;;;;;;;;;;;;;
org 0X3D0
;
; Table des phases de codeur en quadrature
;
cod_ph
addwf PCL,f ; Actuel {3,2} précédent {1,0} ordre phases AB
; C'est l'ordre Précédent/actuel qui dirige l'index
; avec 16 possibilités et la décrémentation avec le Bit7 à 1
RETLW 0X00 ; 0 0000 0000 sans changement
RETLW 0X03 ; 1 0001 0100 -1
RETLW 0x01 ; 2 0010 1000 +1
RETLW 0X00 ; 3 0011 1100 Erreur
RETLW 0x01 ; 4 0100 0001 +1
RETLW 0X00 ; 5 0101 sans changement
RETLW 0X00 ; 6 0110 1001 Erreur
RETLW 0X03 ; 7 0111 1101 -1
RETLW 0X03 ; 8 1000 0010 -1
RETLW 0X00 ; 9 1001 0110 Erreur
RETLW 0X00 ; 10 1010 sans changement
RETLW 0x01 ; 11 1011 1110 +1
RETLW 0X00 ; 12 1100 0011 Erreur
RETLW 0x01 ; 13 1101 0111 +1
RETLW 0X03 ; 14 1110 1011 -1
RETLW 0X00 ; 15 1111 sans changement
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
Des utilisations très diverses sont tout à fait possibles et font l'objet du paragraphe des applications logiciel ci dessous.
3 Les applications logiciel
(Les applications sont bien entendu associées à un montage host). Ces applications fonctionnent parfaitement sur mon microampèreheure mètre .
(Vous noterez qu'il est toujours nécessaire d'avoir l'écho de ce que l'on fait avec un afficheur, c'est évident !)
Avec afficheur LCD, j'ai pu réellement faire des choses intéressantes au niveau du dialogue opérateur. Il est ainsi possible de supprimer les traditionnels 3 switchs : Plus, Moins et Validation par un encodeur et un switch ou un encodeur directement pourvu d'un switch.
J'ai essayé 3 types de fonctionnalités sur le montage host et si c'est un peu "pénible" pour toujours renvoyer le résultat de la commande sur l'afficheur, ça ne l'est pas plus qu'avec un autre système, car on ne peut pas travailler en aveugle sans avoir le retour visuel de l'action entreprise.
3.1 Réponse Y/N
Choix d'un paramètre Y/N Yes or No ou O/N Oui ou Non.
Dans ce cas on contrôle seulement le sens de rotation et on fait reculer ou avancer le curseur clignotant de l'afficheur sur la réponse que l'on souhaite.
Ainsi en Avant vaut 1 et arrière vaut 0 (Ce sont les limites passées à la séquence interrupt du host)
On valide ensuite avec le switch la réponse souhaitée.
Cette méthode est simple et efficace, le plus délicat étant de manœuvrer le curseur de l'afficheur sans se tromper, mais là c'est le curseur de l'afficheur qui sert de guide et qui pointe la bonne réponse par des commandes cursor move right ou left en fonction du 1 ou 0 reçu du montage encodeur …
3.2 Choix de messages
Il est également possible d'afficher un choix de messages possibles, (Des paramètres par exemple), simplement en tournant l'encodeur. Ceci se réalise par indexation de la valeur du compteur de l'encodeur.
La limitation à une zone de message est impérative et se réalise ici au niveau host dans le programme principal, par la mise en place des limites de comptage/décomptage au niveau de la séquence interrupt. (Limite haute et limite basse de l'index).
Il n'y a alors plus aucun souci de dépasser les limites d'un index qui planterait immanquablement le programme.
Les limites sont établies pour chaque type de fonctionnement. On établit aussi la valeur par défaut de l'index au départ, ce qui permet une validation immédiate sans contrôle des valeurs à posteriori.
(Ce fonctionnement n'aurait pas été possible dans le cas de la version prévue au chapitre B), et c'est un véritable avantage.
Il me semble même qu'il soit possible de débugger plus facilement en affichant ainsi des contenus de variables...( Je vais y réfléchir...)
3.3 Le comptage simple
Entrer des valeurs numériques est certainement la fonction la plus évidente puisque le comptage est le mode le plus facile. Compter sur un octet ou un mot entier est laissé en libre choix.
Cependant comme on a perdu de fait la multiplication d'impulsions due à la non prise en compte de la vitesse de rotation, compter sur 2 octets devient un peu plus lourd à gérer.
Aussi dans cette optique il serait nécessaire d'implémenter une fonction liée à la vitesse pour rendre le comptage supérieur à 255 plus attrayant.
Je ne l'ai pas réalisé pour une question de temps disponible, mais cela reste théoriquement tout à fait possible au niveau host.
Pour rentrer des valeurs importantes, j'ai simplement procédé par groupe de 2 digits à concurrence du nombre choisi (À 6 digits dans le cas)
3.4 Limitations ou contrôles
Les limitations de valeurs sont préférables aux contrôles à priori, car cela gagne en rapidité et décharge le programme principal de cette tâche toujours assez pénible du respect des limites (limite inclue ou exclue....)
(en l'absence de limites ce serait le plantage garanti par dépassement de la zone des tables)
Cette limitation est donc réalisée à chaque mode particulier d'utilisation, et la vérification des limites est faite très rapidement au niveau interrupts en 4 instructions seulement.
Exemple :
Si le compteur d'impulsions (host) est à 45, qu'une limite est également fixée à 45 par exemple, et qu'une interrupt survient pour incrémenter à nouveau le compteur, alors cette demande sera simplement ignorée et aucune action de ne sera réalisée, ce qui est résolument très simple.
Seul le mouvement de rotation inverse est accepté.
(Ce système est très instinctif est ressemble à la flèche écran du PC lorsque la souris l'envoie sur un bord ! )
3.5 La préséance + - Valid
Cette préséance est imposée de fait par la rotation horaire ou anti-horaire, car on ne peut pas tourner à la fois dans les deux sens ! C'est purement mécanique.
Les rebonds étant parfaitement aléatoires, il y a cependant de tels comportements de très courte durée.
Ces impulsions sont alors filtrées par la table des ordres au niveau encodeur qui interdit ces anomalies qui contredisent le code GRAY.
Il reste cependant une possibilité de faire Validation ET de tourner dans un sens ou dans l'autre. Alors ce cas est simplement traité par priorité des deux bits de codage et c'est toujours le switch qui l'emportera sur le sens, ce qui me semble le plus normal.
D'un point de vue ergonomie pure, il parait difficile de tourner à la fois un bouton et d'appuyer sur un switch avec la même main. Pourtant, si le switch est intégré à l'encodeur, au centre de la commande de rotation comme dans certains modèles, cela devient alors tout à fait simple et possible !
Ce cas est donc résolu par la préséance de Validation sur les rotations.
Au niveau host, ce cas n'existera donc pas, et seules 3 commandes seront reçues.
4 Le modèle en CMS
4.1 Le Circuit Imprimé
Là c'est toute une histoire, car c'est vraiment le premier montage que je réalise en CMS, avec cette fois la programmation du PIC en ICSP (circuit terminé et PIC vierge). Cette fois ça marche ! et du premier coup avec pourtant pas mal de difficultés pratiques de réalisation .dues à une manque de matériel adapté, soudure fine, colle etc...
Les soudures sont loin d'être parfaites pour deux raisons : utilisation de composants récupérés et soudure trop grosse de 8/10 !
Il y aurait beaucoup à raconter sur ce sujet mais je vais seulement livrer les quelques problèmes rencontrés pour la réalisation :
J'ai récupéré quelques CMS sur divers appareils, car je n'ai aucune pièce neuve de composants passifs en CMS (Résistances, condos...)
Au niveau CI je n'ai pas eu trop de problèmes car je fais les typons sur transparent et je les insole avec un contrepoids sur la glace, de 15 Kg. Ainsi l'émulsion est parfaitement collée sur la face sensible du CI. Cette manière de faire me garantit des "run" de 1 ou 2/10 avec une très bonne régularité.
(A noter qu'il faut du circuit présensibilisé, car préalablement je faisais encore facilement le revêtement manuellement avec la résine photosensible en bombe....)
Je n'ai donc aucune facilité réelle pour les CMS, hormis deux bons fer à souder thermostatés (du copain Riri).
Pour la partie soudure, il faut mentionner la difficulté de souder avec de la soudure de 8/10 pour la plus fine, j'aurais préféré du diamètre 3/10 !
Dans la réalisation, il y a aussi la difficulté pour tenir le composant sans colle.
(J'ai essayé diverses colles que j'avais sous la main, mais j'ai pris la précaution de vérifier à l'ohmmètre et j'ai été bien inspiré car la grande majorité des colles sont conductrices (pas énormément mais suffisamment pour des CMOS...) J'ai donc utilisé le poids d'une simple pince à écarter les manchons caoutchouc pour maintenir le composant en place, et cela m'a donné satisfaction du point du vue du maintien. La première soudure est donc faite ainsi et immobilise parfaitement le composant.
Nota : Les colles type pâte élastique ne vont pas bien non plus, mais m'ont permis de constater l'extrême finesse du point de colle réalisé industriellement, car autrement cela déborde et peut aller jusqu'à cacher les empreintes à souder. (Je n'ai donc pas collé ainsi que cela a été dit).
Dans mon empressement j'ai même soudé à tort C5 que je m'étais pourtant juré de souder à la dernière seconde à cause de l'ICSP, car j'avais des doutes sur la présence d'un condensateur de 3.3 nF sur le Vpp...
Résultat ça ne marchait pas immédiatement ! Deuxième erreur j'ai croisé Clock et Data et ce n'est plus du fil à fil avec le programmateur de PIC. Tant pis pour moi, mais pour vous, pensez à votre propre programmateur et à faire du fil à fil, c'est plus simple.
Restons sérieux les composants sautent facilement et il faut prendre bien des précautions pour ne pas les perdre. (ou les retrouver)
Aie ! Mes lunettes ne suffisent plus, il faut souder à la loupe pour bien voir ce qui se passe...
Contrairement aux autres montages, cette implantation est sans erreur, (mais pas au pas).
Ce circuit est prévu aussi avec un connecteur nez de carte pour la programmation ICSP et un connecteur 2.54 pour la liaison vers le host.
(Vous pourrez le scier car il fait un peu double emploi avec les pinoches, mais c'est surtout pour le futur, car je ne veux pas installer un connecteur spécifique pour une seule fois, pour les autres montages)
J'ai trempé dans l'étain liquide le connecteur de programmation ICSP, mais si la place est comptée vous pourrez le couper, car tous les signaux existent sur l'autre connecteur.
Le circuit imprimé simple face sera fixé par 2 ou 3 vis et colonnettes, ou au contraire sera inclus dans votre schéma général d'un futur montage.
La conception est réalisée côté soudures et l'encodeur est donc vu en miroir. J'ai utilisé 3 ponts 0 ohms. Le croisement Clock et Data vous permettrait d'en économiser un tout en étant fil à fil avec le programmateur de la marque déjà citée. A vous de voir, mais c'est du détail !
La partie métallique de l'encodeur est laissée en l'air, bien que cette fois on ne puisse pas fixer l'encodeur en face avant, mais c'est à vous de voir, aussi en remontant R2, vous pourriez tirer la masse sur les deux pattes métalliques d'immobilisation.
La LED est laissée à discrétion mais montée côté encodeur, mais c'est une faible consommation et une résistance R4 de 33 ou 27 K suffit largement pour une LED rouge de 1.7V de tension directe.
Le schéma CMS est donc pratiquement identique au nouveau schéma Rev 8 à quelques repères près.
4.2 L'encodeur avec switch et détente
J'ai pu disposer juste avant publication de cet article des modèles avec switch et avec "détente". Ces modèles sont très doux de manoeuvre, contrairement à mon premier modèle. Ce sont ces modèles que j'ai utilisés dans la version CMS.
Ces modèles n'ont plus de canon fileté aussi, il est nécessaire de prévoir des trous de fixation pour le CI. J'en ai prévu seulement 3 dont seulement une diagonale devrait suffire, au vu des très faibles efforts.
4.3 Le PIC 12F675 et L'ICSP
Ainsi que je l'avais indiqué, je suis repassé sur un PIC 12F675 en remplacement du PIC12F629, simplement par le fait que j'ai du commander par 5 et que c'est plus facile de réutiliser un modèle supérieur ayant un convertisseur ANA, que le modèle inférieur. Fonctionnellement au niveau programme c'est identique à 2 instructions d'initialisation près et avec un écart de prix de 0.1€
Si vous voulez implanter directement sur un CI c'est également possible et le programme ne changera bien entendu pas d'un yota !
L'ICSP permet de souder le PIC vierge et de le programmer directement une fois le CI complètement réalisé (sauf C5).
Si vous souhaitez réaliser ce montage je mets à disposition le fichier de codage .HEX issu de MPLAB. Il est prévu comme indiqué pour un PIC 12F675.
Télécharger ce fichier pour programmer le PIC 12F675 : quadra_new
5 Conclusions
Je pense qu'au sujet des encodeurs à contacts, il n'y a jamais absence complète d'erreurs, car il est mathématiquement impossible de discriminer parfaitement le faux du vrai dans tous les cas, principalement dans des temps très courts.
Il faut donc accepter ce fonctionnement imparfait et le rendre le plus correct possible
Le tout est que ces erreurs soient réduites à leur minimum et qu'elles n'entraînent pas de conséquences graves.
Ainsi ce type d'encodeur ne devrait pas être utilisé dans les cas critiques. De toutes façons la technologie "contacts" ne représente pas par essence même une très haute fiabilité.
C'est un procédé low_cost qui a ses avantages et son revers et en plus une durée de vie limitée à 10000 ou 30000 manœuvres !
Dans les particularités, il est important de confirmer qu'une liaison à la masse et 0 Volt se réalise actuellement sur le CI initial par l'étrier métallique de l'encodeur. J'ai fixé le potentiel à la masse dans la première version, mais c'est finalement une erreur et il me semblerait plus normal de laisser ce petit étrier en potentiel flottant comme déjà suggéré. Cela a été traité dans la version CMS
Il serait nécessaire de revoir le circuit imprimé de la version en composants "standard" de l'encodeur pour palier ce détail qui n'a pas encore posé de problème, mais qui pourrait éventuellement en poser !
Pour toutes ces raisons, partez donc sur la version CMS.
A ce jour, il y a 3 versions... Celle initiale, dont le circuit a souffert un peu, une deuxième version fonctionnellement identique, mais "propre" montée sur un appreil en cours (microampère heure ) et enfin la version CMS avec switch intégré.
B Le montage qui ne fonctionnait pas : La déconvenue
1 Les principes
2 Les modèles
2.1 Résistances et condensateurs
3 Le Schéma du montage
4 Les problèmes de tels appareils
5 Les modes
5.1 Mode linéaire
5.2 Mode vitesse
5.3 Les valeurs retournées
6 Les possibilités
6.1 Le nombre de bits
6.2 Les incréments
6.3 Le switch
7 Le transfert des données
7.1 Les timings
8 Le programme
9 Conclusions
10 Les essais réels
Avant propos
C'est parfois par pur hasard que l'on découvre (ou redécouvre) des choses... C'est le cas !
Ce détecteur en quadrature dont le principe est bien connu et si présent aujourd'hui, était passé un peu aux oubliettes…Sauf qu'on l'a pratiqué tous les jours et que l'on continue de l'oublier !
En effet pas moins de 3 détecteurs de ce type "étaient" présents dans les souris d'ordinateurs d'ancienne génération (souris à boule et molette). Sur les nouvelles souris optiques, seule la molette est restée sur ce principe. Nous sommes donc "cernés" par ces encodeurs en quadrature !
C'est tellement proche de nous que l'on oublie que ce principe est aussi très simple.
Il est très intéressant car il permet de compter aussi bien en avant qu'en arrière. Il possède donc la notion de sens, car il permet de compter, mais aussi de décompter.
J'ai aussi repris conscience du même principe avec l'oscilloscope numérique TDS220 que j'ai acquis il y a peu. En effet Tektronix a remplacé tous les potentiomètres de ses oscilloscopes (Du moins le TDS220) par des encodeurs de ce type, et par rapport aux potentiomètres des anciens appareils, cela surprend !.
Extérieurement c'est très facile à reconnaître en manipulant, car contrairement à un potentiomètre, il n'y a pas de butée et on peut tourner autant de fois que l'on veut avec ou sans "clic" ! (Attention à ne pas confondre avec un potentiomètre 10 tours)
Une autre acquisition m'a aussi subjuguée qui est une vanne programmable grand public, pour radiateur (à eau, de chauffage central) qui est équipée d'un tel encodeur et c'est réellement beaucoup plus pratique que les traditionnels 3 switchs "plus, moins et validation".
Et puis j'ai également besoin pour d'autres réalisations de connaître avec précision des angles de rotation (Pour mon panneau solaire par exemple) alors le principe conviendrait fort bien, ce qui m'éviterait de compter le temps de rotation de moteurs à courant continu, dont la vitesse est trop dépendante de la température extérieure ainsi que de la durée de mise en vitesse…
Et puis pour d'autres montages à venir, quoi de mieux que ces équipements si simples (En apparence seulement, car les temps d'analyse et de transfert des informations doivent être très "serrés")
NOTA1 : J'utiliserai aussi parfois pour simplifier, le terme "codeur" en lieu et place "d'encodeur", qui n'est pas faux, mais qui est plus généraliste que le terme complet "encodeur en quadrature". Ce sera donc la même chose !
NOTA2 : Par abus de langage aussi, et sauf explicitement mentionné, incrément signifiera aussi bien incrément que décrément. (Comprendre toute évolution du comptage en + ou en -).
NOTA3 : on appellera "montage", l'ensemble électronique et son capteur,
et "host" l'ordinateur ou le micro contrôleur qui sera connecté à ce montage et utilisateur des données de comptage/décomptage
1 Les principes
Le nom du principe est bien ronflant mais indique seulement la position de deux signaux (Quadra=4-->1/4) et le fait qu'ils codent la variation d'une unité en avant OU en arrière. Ils sont aussi très souvent utilisés comme capteurs de vitesse de rotation, et si le sens n'est pas nécessaire, alors l'encodeur devient un simple capteur de vitesse qui n'utilise que l'une des phases (de la quadrature) ?
Il n'y a qu'un seul principe de base, qui est donc de générer deux signaux rectangulaires décalés de 90° angulaires, appelés aussi "phases" puisqu'ils ont un angle de déphasage (de 90°).
Il est possible d'obtenir ce résultat avec de simples switchs. On peut simplifier l'image en disant qu'un axe porte deux cames à bossages multiples et décalées de 90°, qui actionnent deux contacts.
La deuxième réalisation repose sur un principe non mécanique avec des photodiodes ou photo transistors décalés de 90° et en général avec un seul émetteur de lumière. Le plus souvent l'émission est en infra rouge. (C'est le principe des anciennes souris à boule et de certaines molettes)
Le micro contrôleur du montage (PIC), qui recevra les signaux, transmettra au host la donnée de comptage et de sens, sans que le host ait a gérer le montage lui même. (Voir les chronogrammes)
Un problème de taille est la rapidité potentielle de tels appareils, car ça peut aller très vite ! Il est tout à fait classique d'obtenir 12, 24, 40 ou plus d'impulsions par tour et même un simple demi tour manuel en une fraction de seconde peut engendrer des signaux au 1/1000 de seconde.
(L'oscillogramme ci-dessus représente une rotation manuelle avec changement de sens, et de rapidité "normale").
(Des modèles industriels peuvent aller jusqu'à plusieurs centaines ou même milliers d'impulsions par tour, mais le prix est en rapport)
Au niveau rapidité d'un modèle 24 impulsions on peut voir la période d'un des signaux de l'ordre de 2 millisecondes en tournant rapidement d'un demi-tour à la main ! Le décalage sera donc du quart soit 500 µs. Il n'y a vraiment pas de temps à perdre pour analyser la progression des impulsions décalées dans un sens ou dans l'autre.
Rappel : Cette période est obtenue manuellement !
Ceci est tellement vrai que je viens de revoir mon projet pour augmenter la vitesse de base de 4MHz à 16 MHz, non seulement pour ne pas rater de phases, mais aussi pour pouvoir transmettre très rapidement au host (Dont on ne connaît pas à priori la vitesse d'horloge)
C'est l'ordre d'apparition des signaux qui conditionne le sens de rotation et il y a donc une seule impulsion à chaque évolution de l'un des 2 signaux. À un instant donné il ne peut y avoir qu'un seul de ces 2 signaux (Phases) qui change d'état.
Il n'y a donc pas de place pour d'infimes "trous" ou recouvrements des deux signaux dans le codage. (C'est identique à un code "GRAY")
Cette rapidité sera un véritable challenge, car si l'utilisateur (host) doit effectuer son travail (prévu pour son emploi) il devrait donc aller très très vite si il devait suivre lui-même ces signaux. Il est nécessaire de le décharger de cette tâche trop rapide pour qu'il puisse se consacrer à son propre travail qui lui aussi nécessite peut-être du temps réel ?.
Au fait…comment récupérer l'information sur le host ?
Sur le fond même, on va avoir des impulsions en comptage ou en décomptage sur le montage, mais ça comptera vite, et même si ça va aussi vite, il va falloir beaucoup de capacité de comptage (comptage ou décomptage) des impulsions.
Au bas mot, un octet est un minimum et on pourrait aller largement au dessus jusqu'à 16 bits .
(Sur un potentiomètre de 270° utiles, on a bien du mal a le positionner au degré près, alors il faut au moins compter autant que 256 (8 bits) et bien entendu plus, car le procédé doit amener un progrès ou des fonctionnalités complémentaires, sinon il ne servirait qu'à se faire plaisir…
Il y aura un revers à cette hyper précision, qui sera de pouvoir envoyer le juste compte d'impulsions souhaité tout en ayant la rapidité pour accéder à la proche valeur…
C'est tout l'objet de cet article.
Le nombre d'impulsions n'est limité que par l'utilisation que l'on veut en faire et le host peut très bien prendre l'information quelques secondes plus tard, de ce qui aurait été traité localement avec cette fois un nombre élevé d'impulsions transmises ou plus exactement un mot de comptage qui aura enregistré les plus et les moins sans "importuner" le host.
Le seul problème latent est qu'il n'y a pas de "retour", et qu'en conséquence on travaille en aveugle.
Ainsi 16 bits permettent de compter jusqu'à 65535…Quelle précision par rapport à nos 270 (°) du potentiomètre !
Il y a cependant un problème d'échelle, car si c'est un moyen manuel qui doit compter, il va falloir envoyer 65535 impulsions et manuellement ce n'est plus possible !
Il faut donc des astuces dans le cas où on devrait envoyer manuellement ces impulsions. Par opposition, si ce capteur est installé sur un axe qui tourne à grande vitesse, il n'y aurait aucun problème. (Pas cependant avec ce modèle de capteur).
Pour réaliser les impulsions multiples manuellement dans le cas d'un "pseudo potentiomètre", nous n'aurons qu'un axe avec éventuellement un switch associé, mais rien d'autre !
Peut-on régler autrement ce problème en dédiant la rapidité à une petite "intelligence" intégrée au codeur qui aura l'avantage d'augmenter l'incrément suivant la vitesse de rotation et de libérer le montage (et le host) de cette tâche ou de la scrutation ?
C'est ce que je pense et qui va être l'objet principal de cette description, mais surtout au niveau fonctionnel, car si je viens tout juste de réaliser le montage, sans un host, il m'est impossible de faire de véritables essais en réel.
Alors je préfère réaliser mon article maintenant, pendant que c'est encore frais dans ma mémoire, car il y a beaucoup de détails techniques à dire sur l'ensemble du procédé retenu, sans parler de l'encodeur proprement dit, car le sujet encodeur est par ailleurs très bien détaillé au niveau Internet et particulièrement sur ces deux sites.
site1 : http://www.datelec.fr/fiches/codeur incremental.htm (recopiez ce lien dans votre navigateur, car il ne passe pas autrement à cause de l'espace à priori ?)
site2 : http://tutorial.cytron.com.my/2012/01/17/quadrature-encoder/
Au jour de la rédaction de cet article, le montage fonctionne correctement au simulateur MPLAB pour PIC, mais aussi au réel et chaque partie a été testée indépendamment, mais on n'est jamais à l'abri d'un petit bug de "derrière les fagots". (Regardez par exemple mon coffre de Twingo qui se ferme tout seul une fois sur deux ! eh oui !)
J'ai modifié quelque peu la partie programme de transmission pour vérifier sans handshake des signaux, aussi la maquette réalisée fonctionne à priori correctement, mais des modifications de dernière minute sont toujours des risques accrus (contrôle plus pointu des rebonds et entrée et sortie "host" traitées en Open collector, et la dernière est à venir…)
Une fois les données enregistrées localement dans l'encodeur intelligent (le montage), il faut pouvoir fournir ces données au host qui sera connecté et c'est un deuxième volet non négligeable qui ne devra pas utiliser plus d'I/O que les 3 switchs traditionnels (+,-,OK), qu'il est censé remplacer, soit 3 I/O. Le résultat sera acquis avec seulement 2 I/O !
Encore une petite précision, ce type d'encodeur en quadrature est un codeur dit "incrémental" par opposition à un capteur de position, car le premier ne connaît pas sa position absolue mais seulement relativement aux précédentes. Il n'a pas connaissance de l'origine des comptages.
Il est cependant possible de donner un top d'origine par un élément annexe qui définira alors l'origine des tops et permettra ainsi d'avoir une position relative à ce top par le biais du comptage…
Bref, l'utilisation de ces capteurs est vraiment très intéressante, mais nécessite beaucoup de rapidité pour ne rien perdre.
Rapidité nécessaire aussi pour transmettre les données de comptage au host, car le codeur doit pouvoir aussi réduire au strict minimum ce temps de transfert pour continuer d'enregistrer les tops. (La partie transmission est très rapide et ne devrait pas impacter l'acquisition des phases)
Au vu des temps mesurés simplement au scope en tourant à la main le codeur, le PIC12F629 à 4 MHz est un peu juste pour effectuer son travail sans perdre parfois des données très rapides, aussi c'est ma dernière modification avec un oscillateur RC à 16 MHz. (Avant dernière modif soit 4 fois plus rapide !!!)
Il est aussi possible de trouver sur certains encodeurs du commerce un switch associé à la commande principale, et il faudrait aussi transmettre cette information dans le même "train de données". (Un seul bit suffirait)
Ce "train de données" est seulement constitué de quelques bits (3 à 17 bits) plus quelques artifices de synchronisation…
Au niveau I/O du micro contrôleur principal, ("host") gagner des I/O est toujours utile, car chaque I/O a un coût supplémentaire et réduire ce coût est toujours intéressant !
Le montage permet donc de remplacer sur le host, les 3 switchs traditionnels (et 3 I/O le plus souvent) par seulement 2 I/O.
"Toujours moins cher !!!!" mais là je ne critique pas, car ce n'est pas pour sacrifier la qualité ou les performances, c'est pour simplifier et améliorer l'ergonomie, (et réduire les coûts), et pour cela je suis toujours partant !
Le PIC qui équipe le montage est maintenant un PIC 12F629, mais tout a débuté avec un PIC 12F675 ayant plus de possibilités au niveau ANA. Ces possibilités sont parfaitement inutiles dans ce cas aussi j'ai basculé sur le PIC 12F629 répondant plus simplement au sujet.
(Dans le programme, une seule ligne d'initialisation spécifique au 12F675 a été laissée en commentaires : registre ANSEL).
2 Les modèles
Il y a deux grandes familles d'encodeurs : les mécaniques et les optiques.
J'ai utilisé un modèle mécanique car il se substitue très facilement à un potentiomètre et possède un axe sur un canon fileté que je croyais de 10 mm, mais grave erreur !... c'est un diamètre 9 mm au pas de 0.75. Complètement débile, car l'écrou spécial n'est même pas livré avec, et cette dimension est très très peu répandue. Bref encore un coup du sud est asiatique ! Je rage !
Ces modèles mécaniques sont tout à fait abordables pour un coût d'à peu près 1 Euro et même 0.5 Euro à ce jour.
(Un commun et deux pins distinctes qui récupèreront les signaux en quadrature)
L'autre modèle est fait avec une LED IR à grand champ et une double photodiode en un seul boîtier à 3 pattes.
Ces diodes sont très spécifiques et ne peuvent se monter en général qu'avec le disque codeur à fente en place, pour une simple question de distance entre les trous et de distance au disque codeur.
Je pense qu'il est possible de reprendre ces éléments optiques pour en faire quelque chose de différent et d'utile, mais cela est un peu plus délicat de mise en œuvre, car il y a un peu d'adaptation mécanique de précision à réaliser. De plus ce n'est pas très facile non plus, car en infra rouge, les réglages ne peuvent être réalisés qu'au scope pour trouver la bonne position.
Je n'ai donc pas choisi cette solution, mais celle d'acheter un encodeur mécanique à bas prix, et de voir ce que l'on peut en tirer.
Des principes magnétiques en quadrature sont également tout à fait envisageables, et je pense à des réalisations telles que des girouettes qui se prêteraient fort bien à ce principe. (Avec un top de synchronisation)
Le modèle utilisé ici est donc un modèle à 24 périodes par tour, soit 48 changements d'état par tour sur chacune des phases.
2.1 Résistances et condensateurs
Ce point est spécifique aux modèles mécaniques. 
Qui dit mécanique, dit "contacts" et inévitables "rebonds", et ceux-ci peuvent être importants et de période très courte.
Outre les nécessaires résistances pull up de rappel au VDD et un commun à la masse, un condensateur devra équiper chacun des deux contacts. Le constructeur indique des résistances de 10K ce qui est relativement faible pour des appareils à utilisation longue sur piles ou accus…
Le condensateur retenu est de 4.7 nF et il donne satisfaction en éliminant avec les résistances de 10K, une très grande partie des rebonds.
Les essais avec 100K sous 5V mais également sous 2.56V donnent des résultats satisfaisants également, mais il faut aussi réduire les condensateurs anti-rebonds pour ne pas avachir les temps de montée et garder envi
ron une constante de temps de #50 µs à 100 µs environ.
(La valeur des condensateurs est alors divisée par 10 soit 470 pf).
Dans ces conditions la consommation devient pour 5V, et pour un seul élément de l'encodeur, de 50 µA, ce qui est un peu plus acceptable pour une électronique embarquée, mais…(On verra le revers de la médaille au niveau vitesse du PIC).
Il faudra tout de même vérifier tout changement d'état quelques dizaines de µ secondes plus tard, pour constater que les valeurs sont bien identiques à celles du changement initial.
Vous noterez aussi que ce circuit RC simple va affecter la forme du signal à la montée seulement (Au moment où l'interrupteur s'ouvre). A la fermeture du switch, c'est la mise en décharge brutale du condensateur (à travers les contacts), sans aucun délai (RC#0), et donc avec un temps de descente très faible, contrairement à la montée.
3 Le Schéma du montage
Il était initialement bâti pour un PIC 12F675 (C'est ce que j'avais sous la main) mais il convient exactement à un PIC 12F629 (que j'ai retrouvé) qui est identique au 675, sauf aux possibilités analogiques qu'il ne possède pas et que l'on n'utilise pas d'ailleurs. (Il est complètement Pin compatible)
Naturellement tout autre PIC est aussi capable de faire ce travail, mais les autres ont plus de pattes et de possibilités totalement inutiles et ils sont plus chers. (Le programme restera identique aux initialisations près)
(Le PIC10F202 encore plus petit ne peut pas convenir à cause du manque d'interrupts et d'absence de Timer 1).
Au niveau interrupt, la sauvegarde complète prendrait trop de temps, et sur ce point j'utilise les interruptions uniquement pour les phases, le switch et le passage du signal CLOCK à 1, et je ne fais donc plus aucune sauvegarde pour gagner du temps (Sans perdre d'informations bien entendu).
La structure programme peu habituelle permet cette "acroba
tie".
J'ai utilisé un PIC modèle DIL8 car les modèles CMS sont plus difficiles à mettre en oeuvre pour le particulier, mais une réalisation à plus grande échelle avec les ultimes corrections de logiciel devrait pouvoir aboutir à un circuit imprimé minuscule à peine plus grand que la surface de l'encodeur.
Actuellement le circuit mesure 35x31mm et peut être inséré derrière la face avant d'un appareil.
Le petit circuit est attaché à l'encodeur par des pattes latérales et seuls les contacts seront soudés côté cuivre par un bord bien accessible, et les quelques composants seront placés côté "composants", y compris le PIC sur support pour la mise au point.
Les pattes latérales sont repliées légèrement côté composants. Ces pattes peuvent ou doivent ? toucher une masse pour fixer le potentiel, ce serait mieux.
(Je ne me risque pas à les souder pour ne pas chauffer le boîtier.)
La hauteur des composants traditionnels nécessite cette disposition pour pouvoir mettre cet ensemble en face avant d'un appareil, fixé comme un traditionnel "potar" par le fameux écrou de 9x0.75 dont j'ai déjà fait l'éloge !
Vu que ce circuit sera peut-être à quelque distance de son utilisation par le host, j'ai prévu aussi bien pour DATA_OUT que CLOCK de fonctionner en open collector.
Pour DATA_OUT, c'est le transistor 2N2222 qui réalise l'opération avec sa résistance de charge déportée sur le host. (Attention cela inverse DATA_OUT qui devient au connecteur DATA_OUT*)
Pour le signal CLOCK qui est une entrée du montage, j'ai placé la résistance de charge au VDD pour que le transistor open collector du host puisse transmettre le signal qui sera correctement reçu grâce à cette résistance R6. (L'inversion est à réaliser cette fois sur le host).
(Si le host n'est pas en Open collector, vous pourrez enlever cette résistance R6 ou la laisser et consommer un peu plus ...)
Comme la sortie DATA_OUT est en open collector, j'ai prévu une résistance à monter seulement pour la mise au point, c'est R7 dont la valeur sera à discrétion (100K). Cette résistance pourra être retirée lors de l'installation du montage, car elle ne servira plus.
La consommation mesurée lors des essais est de 3.4 mA. C'est une consommation un peu trop importante pour un appareil sur accus, ainsi que je l'ai laissé entendre, mais c'est la rançon d'une vitesse de PIC à 16 MHz. Plus ça va vite plus ça consomme.
Certes, ça ne va pas mettre en surchauffe la centrale de FESSENHEIM, mais face aux 50µA de chaque branche d'encodeur….On verra que cette consommation pourra réduire jusqu'à 500 µA.
Il serait possible de tourner moins vite que 16MHz, mais les risques de pertes d'informations seraient plus importants si l'on veut conserver des vitesses de phases élevées.
Cette voie n'est pas à investiguer, car c'est seulement en mettant le montage en SLEEP que l'on obtiendra de réelles améliorations, avec de plus la résolution d'un problème délicat de retour d'interrupts du à l'absence de sauvegarde du contexte.
4 Les problèmes de tels appareils
Ces encodeurs fournissent des signaux décalés de 90° et permettent donc ainsi la détection du sens, mais l'inconvénient majeur est la rapidité nécessaire pour ne pas perdre d'informations.
Sur un appareil qui est chargé de surveiller la vitesse d'un moteur par exemple, le nombre d'impulsions n'est pas un problème, car le comptage se réalise tout seul par l'arbre qui tourne. Chaque front fait donc +1 sur le comptage et durant le temps séparant 2 ou plusieurs impulsions on en déduit la vitesse. Suivant l'ordre d'arrivée des impulsions A ou B ce sera une rotation avant ou arrière (incrément ou décrément).
Par opposition, à l'utilisation en "pseudo potentiomètre", là c'est la rotation manuelle qui va donner des impulsions, et suivant la définition de l'encodeur (Nombre d'impulsions par tour), il va falloir tourner beaucoup pour faire +1 ou -1 jusqu'au maxi ou mini.
Alors si vous avez besoin de 8000 impulsions pour la définition d'un calibre dans une application avec host, alors il faudrait "titiller" jusqu'à 8000 fois, et même à 24 "titilles" par tour, il va falloir 333 tours, sans parler de définitions plus hautes où ce serait plusieurs milliers.
Autant déclarer forfait tout de suite !
Pour ces pseudo potentiomètres, il y a donc de justes compromis à trouver entre le nombre d'impulsions et la précision recherchée. Ou alors …trouver une astuce pour faire les deux, ce sera le cas !
On notera que ce montage devrait pouvoir être utilisé dans tous les cas, et qu'il voudrait être le plus possible "universel"!
5 Les modes
Ces modes vont définir les cas d'emploi comme pour les pseudo potentiomètres ou simplement pour du comptage linéaire dans les deux sens.
Dans le premier cas on va compter les impulsions dans un mot de 16 bits au maximum (65536 comptages potentiels).
Alors que dans le mode linéaire, on peut aussi certes compter, mais on recherchera surtout à mesurer un temps entre chaque impulsion.
5.1 Mode linéaire
C'est le mode le plus simple.
Le mode linéaire permet de compter très simplement les impulsions dans les deux sens avec seulement des incréments/décréments de une unité.
Ce mode est surtout utile pour mesurer des vitesses de rotation ou de déplacement linéaire et principalement lorsque les incréments sont issus d'une machine et non d'une opération manuelle.
On remarquera que la seule mesure de vitesse revient à une mesure de temps, car une fois le sens déterminé, il n'y a plus qu'à mesurer le temps entre impulsions sur une seule phase.
(Autre procédé, inverse cette fois, celui de compter le nombre d'impulsion pour un temps donné, ce qui peut être plus précis, mais pas toujours réalisable suivant les applications).
5.2 Mode vitesse
C'est vraiment le cœur de cet article orienté vers des pseudos potentiomètres ou les mesures angulaires.
C'est le mode nécessaire pour allier un comptage rapide et pour fixer une valeur précise sans autre moyen annexe que l'utilisation de l'encodeur lui-même.
Il y a lieu d'utiliser cette fois le seul paramètre complémentaire possible qui est la vitesse à laquelle vont arriver les impulsions pour les multiplier de façon conséquente ou non, de façon à atteindre rapidement le comptage souhaité.
C'est la seule façon de pouvoir modifier le comptage originel de 1 unité sans autre artifice. Ainsi, plus la vitesse est élevée, plus on multipliera le nombre d'impulsions comptées.
La progression sera donc supérieure à 1 et pourra même atteindre quelques milliers dans certaines configurations.
Au niveau des vitesses manuelles de rotation enregistrées au réel, j'ai relevé 2 ms de période et donc 500µs entre les deux signaux ce qui reste assez rapide.
Mais il y a tout de même un obstacle à ce système, car si on n'utilise pas des mots de 16 bits, engendrer en vitesse rapide 100 ou 500 impulsions d'un coup peut être trop rapide. Faut-il une seule vitesse rapide ?
Non ! J'ai donc pris pour aller le plus vite possible, une GAMME de vitesses entre 0.52s et 2ms. (TIMER1 prescaler à 8). Le timer 1 sera remis à zéro à chaque changement des phases.
Le pas de cette gamme sera de 1/16 et on parlera du facteur de vitesse dont le calcul est simplement la division en 16 parties INégales de l'écart maximum de vitesse. Pourquoi INégales ?
Le problème majeur de ces vitesses est que le TIMER1 intervient en INVERSE DE SA VALEUR : En effet plus la valeur est faible, plus la vitesse devrait être élevée.
Cette opération n'est pas linéaire mais est resserrée du côté des fortes vitesses (ou faibles valeurs de TMR1), ce qui est favorable pour éviter tout dépassement non souhaité.
La variation est une fonction du type y=1/x.
Le facteur de vitesse pour les valeurs de TMR1H sont les suivantes et répondent au tableau ci-dessous qui relate le facteur de vitesse fonction de la valeur de TMR1H (dans le cas ancien de l'oscillateur à 4 MHz)
F_Vit 18 16 14 12 11 10 9 8 7 6 5 4 3 2
TMR1 7 8 9 10 11 12 13 15 17 19 22 26 33 43
Pour des questions de rapidité de calculs, mais aussi d'inutilité, les poids faibles (TMR1L) ont été abandonnés et la division d'une constante par TMR1 pour ramener à des valeurs acceptables a été effectuée en 8 bits.
Ceci a pour conséquence que des 16 facteurs de vitesses initiaux, on va en perdre 2.
Ainsi les facteurs de vitesse 15 et 13 ne seront jamais utilisés faute d'opérations 16 bits ramenées sur les seuls 8 bits de poids fort, mais cela ne me semble pas très important, car l'essentiel du principe est conservé.
Ce facteur de vitesse aura donc pour valeur 1 à 16 (et non zéro, car 0 fois x --> 0) avec la majorité des valeurs intermédiaires 1,2,3,4,5…11,12,14,16,18… (18 et plus si on descendait plus bas que la période de 2 ms).
On notera que le temps correspond à la distance entre deux rotations, et que ce temps peut même être infini…Alors que devient TIMER1 dans ce cas particulier, il va continuer au report et repartir par zéro ? Oui !
A chaque évolution d'une des phases, le TIMER1 est remis à zéro ainsi que le flag de passage à 0 (TMR1IF).
Dès que le Flag TMR1IF est positionné, cela signifie qu'il y AU MOINS 0.52 secondes entre 2 évolutions du capteur (valeur à 4 MHz).
Dans ce cas, quelque soit la valeur du Timer 1, TMR1H et 1L seront positionnés au maxi soit 0xFF. (TMR1L n'est même pas utile). L'incrément sera alors toujours de 1
AUTRE ASPECT AUSSI IMPORTANT, cette fois c'est celui du nombre de bits sur lesquels ont veut travailler en incrément ou décrément.
Ce nombre est primordial, relativement au facteur de vitesse, car on ne peut pas "envoyer" 200 incréments de comptage alors que le mot de comptage n'a que 4 bits (par exemple)
Lorsque le nombre de bits utiles pour le comptage est élevé, pour arriver au maximum il faudra des valeurs élevées aussi !
Par opposition pour un nombre de bits faibles, il sera en proportion et un plus petit nombre sera nécessaire.
On comprend donc la nécessité d'un DEUXIÈME FACTEUR …
Le facteur de vitesse sera donc multiplié par un autre facteur de multiplication relatif au nombre de bits choisis.
Ce deuxième facteur est fixe et est calculé une fois pour toutes à l'initialisation de l'encodeur (Mise sous tension). Il a été choisi en puissances de 2 pour accélérer les calculs.
Ainsi on aura le nombre d'impulsions qui sera représenté par le produit du facteur de vitesse (Par décalage), par le nombre correspondant au facteur de bits.
Ce nombre devient alors l'incrément.
NOTA1 :
Il est fort probable de plus dans le cas de nombre de bits utilisés inférieur ou égal à 4 ou 5 (à voir), de toujours forcer un incrément de 1 quelque soit la vitesse. Ce cas se produira lorsque l'encodeur sera utilisé en sélection de message par exemple.
NOTA2 :
Dans le même esprit de travail en sélection de messages, et pour un nombre de bits à évaluer entre 4 et 5 (16 ou 32 valeurs), j'envisage également de forcer cette fois le départ à la valeur zéro et non à la valeur médiane de la plage considérée. Ces deux fonctionnements à faible nombre de bits seront évalués lors de la mise au point finale pour leurs nécessités et leurs impacts sur les temps de traitement.
5.3 Les valeurs retournées
Le programme ne traite que des nombres positifs en comptage ou décomptage. Tout nombre avec le bit de poids fort à 1 sera compris comme la puissance de 2 correspondante et NON comme le signe.
Cela ne signifie pas qu'au début, seul un incrément sera possible. En effet après avoir vu que "traîner" des nombres négatifs posait trop de problèmes de temps de traitement, je me suis rabattu sur les seuls nombres positifs.
Pour régler ce problème initial, il est logique de placer la valeur de départ exactement à la moitié de la plage des valeurs possibles (positives) et non à zéro.
De plus en procédant ainsi il sera possible en faisant une simple soustraction au moment d'envoyer les valeurs au host, d'appliquer l'offset correspondant, générant ainsi automatiquement le bit de signe correspondant au bit de signe paramétré. (Ainsi sur 7 bits de définition (Bits 0 à 6), c'est le bit 6 qui sera le bit de signe (et non le bit 7)
Le traitement direct de nombres négatifs sur PIC est si contraignant que associé aux limites choisies, le temps deviendrait vite un problème, c'est la raison de ce choix.
Il convient aussi de voir que lorsque le compte des impulsions est réalisé uniquement en positif, il n'est pas très difficile de développer un offset pour avoir un zéro au centre de la plage de comptage.
Ce travail sera traité soit en paramètre de configuration, soit à la discrétion du host, car le montage associé à l'encodeur peut prendre ce calcul rapide en plus, d'autant qu'il ne sera pas systématiquement nécessaire (à voir suivant les applications).
Remarquez aussi que le montage n'utilise pas de quartz, et qu'il utilisait au début l'oscillateur interne à seulement 4 Mhz. (Mode INTOSCIO). Vu la rapidité nécessaire, il a fallu que je revoie ma copie !
Avec le nombre d'entrées réduites, je n'avais pas d'autres choix que d'utiliser un oscillateur externe RC, pour pouvoir garder une I/O pour un switch.
C'est donc à 16 MHz que fonctionne maintenant le montage, et la précision du temps n'est pas du tout nécessaire, ce qui arrange bien les choses au niveau des I/O.
La conséquence du signe toujours positif induit que les "dépassements à zéro" par décrémentation se traduiront par la mise à zéro du ou des octets de comptage.
Réciproquement, les dépassements en incrémentation se traduiront par la mise à la valeur maxi correspondant au nombre de bits définis (Par exemple 0xFF pour 8 bits définis + voir ci-après)
(Ces règles des minis et maxi sont valables au niveau du nombre de bits choisis (voir ci-après) et non en fonction des 16 bits qui régissent toujours toutes les opérations).
Le départ est exactement à la moitié du nombre maxi. Ainsi pour 8 bits ce sera 128 etc…32768 pour 16 bits etc….(soit respectivement 0x80 et 0x8000)
Dit autrement il faut positionner le bit de poids fort à 1 et tous les autres à zéro, ce qui semble une condition de départ plus normale que de partir de zéro.
- Vous pouvez aussi constater que la RÉDACTION d'un article conduit très souvent à des réflexions qui sont fort utiles, car elles sont d'une vision plus détachée de la perception du seul montage et de son logiciel associé.
J'aurai tout dit, en réalité, car je n'ai pas pu résister à la tentation de réaliser rapidement ce petit circuit, car j'en avais un autre également à faire pour un futur montage…Alors un peu plus, un peu moins !
J'ai été cependant obligé de faire un bout de programme d'essai pour voir un peu mieux ce que l'on peut en tirer. A priori c'est intéressant et sans autres gros problèmes de fond qu'une consommation assez élevée pour un montage embarqué. (Voir précédemment).
6 Les possibilités
6.1 Le nombre de bits
Le nombre de bits va définir avec quelle précision de comptage vous désirez travailler. Cette valeur est paramétrable, (Comme d'autres valeurs).
Le paramétrage ne peut s'effectuer que par écriture en EEPROM sur le codeur du PIC (Encore un autre codeur cette fois !).
Cela évite de fournir le code source et permet tout de même une adaptation qui régira le cas spécifique d'emploi.
Cette façon de procéder est normale sur de très petits systèmes tels que celui-ci, car il faut voir l'ensemble encodeur avec son électronique et son logiciel comme un sous-ensemble complet qui doit se suffire à lui-même, mais être capable de s'adapter une seule fois à sa seule utilisation d'installation.
En effet c'est la seule méthode qui évite un assemblage, et du fait qu'il n'y a aucun périphérique d'entrée sortie (hormis le host lui-même).
Le nombre de bits va déterminer la précision à laquelle on veut travailler. Ainsi, si c'est pour définir 16 valeurs d'une girouette par exemple, on définira le mot de comptage à 4 BITS.
Ce nombre de bits va aussi largement influer sur les incréments possibles en fonction de la vitesse.
Le host pourrait éventuellement, moyennant une routine d'initialisation, avec un protocole spécifique palier cette programmation en EEPROM, mais cela devient vite un casse tête pour les applications host, qui doivent alors gérer en plus cette partie pour laquelle on veut justement le décharger de travail.
6.2 Les incréments
Après avoir vu le facteur de vitesse, on aborde maintenant le facteur multiplicateur lié cette fois au nombre de bits paramétrés. (C'est "fact_mul")
Le facteur d'incrément "bits" pour les nombres de bits inférieurs ou égaux à 8 sera toujours de 1 (facteur de bits ou de multiplication), mais Indépendamment du facteur de vitesse qui reste actif.
Voici ci-dessous le tableau des facteurs de multiplication en fonction du nombre de bits (Nb_Bits) et du facteur de vitesse (fact_mul)
La valeur Val_max représente l'incrément du produit fact_mul par le facteur de vitesse MAXI.
Nb Bits 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Fact_mul 1 1 1 1 1 1 1 2 4 8 16 32 64 128 256
Val_max 16 16 16 16 16 16 16 32 64 128 256 512 1024 2048 4096
Pour bien comprendre les différents éléments, je préfère rappeler que ces incréments "fact_mul" sont multipliés jusqu'à 16 fois par le facteur de vitesse, ce qui donne la troisième ligne du tableau dénommée "Val_max" qui donne l'incrément maxi.
NOTA1 : Pour des vitesses encore plus élevées, il est possible de dépasser de quelques unités, le facteur de vitesse de 16.
NOTA2 : Pour un nombre de bits inférieur ou égal à 4 ou 5, (16 ou 32 possibilités), j'envisage même d'invalider le facteur de vitesse, car le nombre de possibilités est suffisamment faible. C'est le cas d'une utilisation en sélection de messages par exemple.
6.3 Le switch
Certains de ces petits encodeurs ont également un switch associé. Bien que je n'en ai pas pour l'instant, je l'ai prévu, car le nombre d'I/O le permet. Sa valeur sera transmise comme dernier bit spécial en fin de transfert vers le host. (Utilisation classique des touches + - et valid)
Au début, il restait une I/O que j'avais associée à une LED dont je ne savais pas quelle serait l'utilisation effective. Cette I/O "disponible" m'a servi pour me repérer au niveau des temps, mais aurait pu simplement s'allumer lors de transferts vers le host.
Ce point est maintenant réglé par l'utilisation de cette I/O complémentaire comme oscillateur RC à 16 MHz !
Il n'y a donc plus de LED, et c'est aussi bien, car en fonction des applications spécifiques, vous pourrez modifier la fréquence de l'oscillateur et avoir ainsi une consommation plus faible.
(Cela n'est pas nécessairement la méthode la plus efficace…Voir ci-après au niveau Programme)
Voici un tableau relevé qui confirme la vitesse comme facteur majeur de consommation.
(Ce tableau comporte la consommation TOTALE du montage, avec les valeurs de composants discrets du schéma mais avec des I/O dans un état indéterminé).
Fréquence 16MHz 8.9MHZ 4MHz 3.5MHz 1MHz 300KHz 100KHz
Conso(mA) 3.51 2.7 1.1 0.97 0.42 0.28 0.24
7 Le transfert des données
Cette partie du programme de l'encodeur va envoyer vers le host la dernière valeur connue du compteur.
Le transfert s'effectue de manière synchrone esclave au niveau bit (Présence d'une horloge).
L'horloge est envoyée par le host qui fonctionne alors en "Maître".
Le montage s'adapte au host suivant une procédure synchrone simple, certainement spécifique, dont le diagramme est donné au paragraphe suivant.
Bien que le montage soit esclave, il peut cependant indiquer au host qu'il a des informations à lui communiquer.
Cette procédure spécifique est aussi un avantage car elle évite aussi l'utilisation de PIC plus évolués (SPI par exemple) dont tous ne sont pas pourvus, et c'est le cas présent.
Les principes sont les suivants.
(Attention le signal DATA_OUT dont il est fait référence est la sortie GPIO2 sur le PIC, (et non après l'Open collector qui inverse le signal).
Cas 1 :
Le host demande le transfert de la valeur du comptage car il en a besoin immédiatement !
(Initialement les signaux Clock et Datas sont à zéro)
Le host passe à 1 le signal CLOCK (valeur sur le montage). Le montage encodeur termine ses opérations en cours et termine ses interruptions éventuelles.
Dès ses opérations terminées, il envoie durant 6 cycles son signal Data_Out à 1 pour indiquer au host qu'il est prêt à répondre à sa demande .
Le host ayant vu ce signal à 1 remet à zéro son signal CLOCK, front descendant qui permet au montage de charger le premier bit (Poids faibles en tête) sur sa sortie GPIO2 Data_Out.
Au front montant d'horloge, le bit est échantillonné par le host. Au front descendant le 2 ème bit est chargé par le montage, et au front montant d'horloge suivant etc…et ainsi de suite.
cas 2 :
C'est le montage qui indique au host une modification des phases. (Ce cas sera certainement le plus fréquent à 99%, car l'évolution d'un bit résulte d'un changement des phases)
Comme précédemment, Initialement les signaux Clock et Data_Out sont à zéro.
Il pouvait en effet être très utile que le host soit informé d'un changement, aussi j'ai ajouté cette possibilité à l'esclave, pour l'indiquer au host sans pour autant le "distraire".
Pour ce faire, le montage passe son signal Data_Out à 1.
Le host est alors libre de considérer cette information ou non. En effet il reste le Maître, mais un "Maître informé".
Ainsi, si le host veut le savoir en temps réel, il peut utiliser une interrupt sur ce signal Data_Out, et agir en conséquence.
(Au contraire il peut tout aussi bien scanner cette entrée quand bon lui semble, et complètement ignorer le changement de DATA_OUT).
La conclusion "normale" serait pour lui de monter son signal Clock qui aura pour résultat d'être vue par le montage encodeur, qui remet aussitôt un court instant son signal Data_Out* à 0.
À partir de cet instant tout se déroule alors de la même manière dans les cas 1 ou 2.
Au front descendant d'horloge, le montage encodeur charge le bit à envoyer sur la sortie DATA_OUT. Au front montant d'horloge, le host échantillonne le data présent.
Le bit data reste présent jusqu'au niveau 0 logique de l'horloge. Le cycle recommence alors et le montage présente le bit suivant sur DATA_OUT etc…
Suivant le synchronisme des 2 systèmes, environ 5 cycles doivent séparer chaque bit pour que le montage ait le temps de placer la valeur du bit en sortie datas. (1.25µs à 16 MHz)
Cas 3 :
Mais où est passé le transfert de la valeur du switch ?
Ce cas est la suite du transfert effectué suivant les cas 1 ou 2. Une fois le dernier bit du comptage transmis, il est impératif que le signal d'horloge revienne à zéro. (Il n'échantillonnera alors plus rien)
A la retombée de l'horloge du dernier bit, la valeur du switch (1 ou 0) est transmise durant 6 cycles, soit à 1 soit à 0, sans autre forme de procédure. C'est ultra simple. Le signal d'horloge restera à zéro jusqu'au prochain transfert
Pourquoi ne pas faire du SPI ? Pour plusieurs raisons !
Il faut un PIC plus évolué et passer à des PIC plus sophistiqués et peut être à la série des 16F876 877 ou les plus récents 16F685 à 16F690 qui sont des 20 pins. (Le très connu PIC 16F628 ne l'a pas).
Ensuite il faut un minimum d'interface directe pour rapatrier non pas un seul bit, mais 8 bits. Aussi des registres discrets de 8 ou 16 bits doivent être implantés sur le montage encodeur de façon à pouvoir répondre à la vitesses de Fosc/4 (800ns) qui pourrait être rapide, ou au besoin de réduire cette vitesse à Fosc/64 (12.8 µs tout de même !)
Il faudrait aussi fermer la boucle SDI/SDO sur le montage ! Il faudrait aussi un "Enable" du périphérique...!
Aïe : SPI est seulement 8 Bits ou multiples ? A priori je pense qu'il y a un compteur de bits au niveau du Maître, mais qu'il serait (peut-être) possible de transférer 2x8 bits de façon assez rapprochée. (Le maître serait bien évidemment le host)
Transférer des valeurs autres que 8 bits serait à priori impossible. (Que faire alors du bit de switch ? ou transférer 8 bits de plus pour un seul bit utile ?)
Seulement outre l'aspect faisabilité effective pour 16 bits, je préfère garder cette petite procédure spécifique qui reste intéressante et occasionne beaucoup moins de complications techniques permet des vitesses plus adaptées et réduit en conséquence les coûts.
7.1 Les timi
ngs
Les timings sont la réplique des explications ci-dessus et sont très simples.
Le signal CLOCK est toujours vu en logique positive, bien qu'il soit issu d'un open collector (La résistance est sur le montage). (Faire l'inversion au niveau host)
Le signal DATA_OUT est le signal en logique positive sur la sortie GPIO du PIC. Il est ensuite inversé par l'open collector, et sa vérification sur R7 est inversée et prend le nom en barre DATA_OUT*.
8 Le programme
Il est en assembleur PIC 12F629 qui est un des plus petits PIC a seulement 8 pattes, et le mieux adapté pour ce travail qui ne réclame que de la logique simple mais très rapide.
Le PIC12F675, pin compatible, fonctionne également très bien puisqu'il a servi au début du développement du programme.
Il comporte en plus un convertisseur A/D sur 4 I/O, mais n'est pas utile (Il a exactement le même brochage).
Le programme reflète les différentes explications données, et hormis des questions de rapidité, il n'est pas véritablement compliqué.
La détermination des phases est réalisée par une table de transcodage sur 4 bits qui groupe dans le quartet gauche dans l'ordre 3,2,1,0 des bits, l'ancienne valeur des phases (bits 3,2), suivie par les valeurs de l'instant (bits 1,0)
La phase A (GPIO0) occupe le bits de poids le plus faible et la phase B occupe le bit fort (bit 1).
C'est cette configuration qui semble la plus rapide avec l'entrée par shift left (RLF) des valeurs les plus récentes.
Il y a donc pour 4 bits utiles, 16 valeurs pour déterminer le sens de comptage d'une unité.
Comme il s'agit d'un code GRAY, certaines configurations dans lesquelles les bits de phase changent en même temps sont impossibles de par la nature même de la quadrature.
Ces impossibilités produiront un "incrément" nul. (Ces impossibilités peuvent principalement résulter de rebonds et sont donc éliminées)
Un incrément nul est également produit pour une valeur précédente identique à l'actuelle, ce qui est normal et traduit une stabilité de mouvement (Absence de mouvement de rotation).
Pour ce modèle, les rebonds restent modérés et sont pratiquement toujours compensés par les condensateurs. Cependant, par précaution j'ai ajouté une deuxième lecture décalée de 45cycles (Grâce à l'augmentation de vitesse du PIC).
En cas de différence de quelque origine qu'elle soit, l'opération est simplement annulée avec une valeur 0 qui n'affectera pas le comptage.
On constate dans la table, qu'il y a 4 valeurs d'incrément, 4 valeurs "stables", 4 valeurs "erreur" et 4 valeurs de décrément (0x80 seul bit utile dans la table)
Voici donc la table utilisée :
cod_ph
addwf PCL,f ; Precédent {2,3} Actuel {1,0} ordre phases AB
; C'est l'ordre Précédent/actuel qui dirige l'index
; avec 16 possibilités et la décrémentation avec le Bit7 à 1
RETLW 0X00 ; 0 0000 sans changement
RETLW 0X80 ; 1 0001 -1
RETLW 0x01 ; 2 0010 +1
RETLW 0X00 ; 3 0011 Erreur
RETLW 0x01 ; 4 0100 +1
RETLW 0X00 ; 5 0101 sans changement
RETLW 0X00 ; 6 0110 Erreur
RETLW 0X80 ; 7 0111 -1
RETLW 0X80 ; 8 1000 -1
RETLW 0X00 ; 9 1001 Erreur
RETLW 0X00 ; 10 1010 sans changement
RETLW 0x01 ; 11 1011 +1
RETLW 0X00 ; 12 1100 Erreur
RETLW 0x01 ; 13 1101 +1
RETLW 0X80 ; 14 1110 -1
RETLW 0X00 ; 15 1111 sans changement
;;;;;;;;;;;;;;;;;;;;;;;;;;;
Le switch :
Contrairement à ce qui a été dit sur les interrupts uniques, le switch va pouvoir interrompre la très courte boucle de surveillance. Dans ce cas il positionne un flag pour son propre compte, mais positionne aussi le flag "Phase_Activ" qui régit le changement des phases.
(Attention il serait plus exact de parler de réveiller au lieu d'interrompre, car on verra que cette dernière modification permet de parcourir seulement une fois la boucle, puis de passer en SLEEP).
En réalité les valeurs de phases sont inchangées, car ce sont les anciennes valeurs qui sont prises, mais cela génère tout de même l'information pour le host (DATA_OUT) qui est alors averti de cet évènement.
A lui de faire ce qu'il doit faire !
Le contexte lors des interruptions n'est jamais sauvegardé, car les traitements sont réalisés en moins de temps que celui d'arrivée d'une nouvelle impulsion (Environ 125 µs à 16 MHz).
De plus, hormis le calcul pour l'arrivée d'une modification des phases, le programme tournait sur une boucle extrêmement courte et la sauvegarde n'apporterait rien de significatif mais faisait perdre un temps précieux.
Là aussi la modification de SLEEP permet une synchronisation parfaite et élimine toute possibilité d'interrupt en cours d'examen des flags.
;========================================================================
;========================================================================
; boucle principale du programme 226 cycles à 12 bits pour chgt de phase
; Le test du switch ne pourra être fait que sur rapatriement des 16 bits
; interrupt d'une phase avec retour=22 cycles
;========================================================================
LOOP_P
btfsc Phas_Activ ; test si Interrupt des phases
goto calcul_Ph ; calcule incrément et décrément fonction de la vitesse
app_host
btfsc CLK_In ; test si appel du host
goto app_Xfert ; appel du transfert
SLEEP ; mise en sommeil PIC
goto LOOP_P ; retour unique d'interrupts
;========================================================================
Il y a seulement deux évènements majeurs à surveiller, les phases (avec le switch) et l'appel du host (CLOCK) pour le transfert des données, mais les interrupts pourraient tout de même perturber les retours suivant les cas.
Alors voici encore cette dernière et très IMPORTANTE MODIFICATION, qui va mettre cette fois le PIC en sommeil à la fin de la boucle de surveillance (SLEEP), ainsi le retour sera toujours synchrone en un seul point et aura l'important avantage de réduire la consommation à quasiment rien, la majeure partie du temps.
Seulement une à 2 périodes sont nécessaires au redémarrage de l'oscillateur, mais à cette vitesse élevée, ce n'est pas très grave !
Sur une interrupt de changement des phases, l'oscillateur redémarre en 50ns après le changement de phase. Il n'y aura donc aucune perte lors de changements de phases.
Lors de l'appel du host, les interruptions seront totalement bloquées durant 163 cycles, ce qui à la vitesse maxi de 2 ms devrait passer sans perdre d'informations. (Au host d'être assez rapide durant un temps très court qui pourrait nécessiter l'arrêt des interrupts. La conséquence directe d'un manque de rapidité influerait sur le montage encodeur et la non prise en compte de changements de phases !)
Je n'ai pas encore pris de décision sur la diffusion du programme source (De plus c'est prématuré, mais vous pouvez toujours poser la question si vous êtes intéressé).
(Il serait tout de même plus sage d'attendre un peu que des essais complets aient pu être réalisés,… mais au fait vous allez pouvoir peut-être aussi me retourner l'ascenseur ? ).
9 Conclusions
Je publie avant les essais réels complets, car ces articles constituent une bonne source de documentation personnelle et m'obligent à une certaine rigueur et à noter les points importants quand c'est "frais". La réalisation a été avancée, et fonctionne déjà un peu, mais les essais définitifs seront réalisés plus tard.
Les applications des ces encodeurs sont nombreuses et variées.
Ce programme peut bien sûr s'appliquer parfaitement aux encodeurs optiques sans autre forme de procédure.
Parmi les cas d'applications, on peut citer des joysticks pro, les bandes encodeuses linéaires d'imprimantes, des pseudo potentiomètres, les capteurs de vitesse de rotations, les capteurs angulaires…etc.
Ce programme est spécialement prévu pour la fonction manuelle pour réaliser un pseudo potentiomètre. Il peut aussi être utilisé pour mesurer des angles.
Il n'est par contre pas prévu pour mesurer des vitesses de rotation élevées. (Parfaitement inadapté de plus pour ce type d'encodeur mécanique : de 15 à 30 000 cycles seulement de durée de vie
Je dois dire aussi que c'est un capteur de rotation simple, même sans utiliser la différence des phases.
En ce sens, pour mesurer les angles de mon panneau solaire, il me semble bien adapté, car pour ceux qui ont lu cet article de mes débuts, vous aurez compris que les cellules photoélectriques en extérieur ne sont pas très fiables sans une protection rigoureusement adaptée…
Ce type d'encodeur est très bon marché mais pour ceux qui veulent en acheter, commandez impérativement les ÉCROUS qui vont avec (Si il y en a ?).
De plus les modèles que j'ai achetés (Un peu en aveugle Ref ALPS EC12E2430804), ont un couple trop dur, car ils ne possèdent pas de "détente". On comprend que vu le nombre d'impulsions et les très faibles dimensions, il faut un peu de rigidité et que cela parait juste un peu normal...???
Il faut donc choisir entre couple élevé ou détente !
Enfin de tels capteurs mécaniques ont une durée de vie courte de 15000 à 30 000 cycles, ce qui contingente leur utilisation aux fonctions manuelles ou très lentes et non à la vitesse non démultipliée de moteurs
La dernière modification importante a consisté à passer le montage en SLEEP en l'absence de changement des Phases ou des demandes du host. Cela résout le problème du retour synchrone d'interrupts, mais aussi le problème de la consommation trop importante pour aller sur un appareil alimenté sur batterie ou sur piles.
Ainsi cette modification en l'absence de changement de phase fait passer à 500µA au lieu de 3.4 mA précédemment (à 16 MHz). Cette modification est réellement très importante. Elle est testée partiellement seulement.
10 Les essais réels
Les essais réels se feront bien plus tard lors de l'élaboration d'un futur appareil de mesures (chut !) Ce sera la première opération à faire, pour à la fois mettre définitivement au point le montage, mais aussi la séquence host de lecture.
Si vous êtes très pressé, et désireux de prendre de l'avance, je suis preneur…
Wait and see !
C'est donc tout vu et il faut maintenant passer à la version édulcorée du chapitre A. Ça marchait pourtant bien au simulateur, mais au réel et en connexion, que de problèmes...Oubliez donc tout cela, les choses les plus simples sont souvent les meilleures et à vouloir trop bien faire, on se prend facilement les pieds dans le tapis....
____ ( retour en début d'article) ____
_____ ( retour accueil lokistagnepas ) ____
_____ ( retour accueil bricolsec ) ____
/http%3A%2F%2Fstorage.canalblog.com%2F22%2F17%2F338014%2F40419190_o.jpg)
/http%3A%2F%2Fstorage.canalblog.com%2F57%2F51%2F338014%2F57619717_o.png)
/http%3A%2F%2Fstorage.canalblog.com%2F52%2F24%2F338014%2F53520115_o.jpg)
/http%3A%2F%2Fstorage.canalblog.com%2F10%2F16%2F338014%2F89143530_o.jpg)
/https%3A%2F%2Fprofilepics.canalblog.com%2Fprofilepics%2F2%2F8%2F289215.jpg)