Le retour de l’interface USB HID !

Introduction

Quand les potes disent vouloir jouer à DCS World en multijoueurs, l’électronicien qui sommeil en moi se dit « Il me faut plus de boutons ! ». En effet, les périphériques de jeux habituels sont relativement peu pourvus en boutons, et démarrer un avion de chasse est un peu plus complexe que démarrer une Twingo. L’idée a donc germée de concevoir une électronique vue comme un joystick et proposant des entrées tout ou rien et/ou analogiques. Il est ainsi possible de réaliser son tableau de bord, avec de vrais boutons, des étiquettes… Bref, on s’y croirait.

Conception de la carte

Spécifications

Comme on ne change pas une équipe qui gagne, je suis reparti de ma première version de l’interface USB HID. Voici quelques éléments en vrac:

• Alimentation par le bus USB
• MCU : PIC18F4550 cadencé à 48MHz par un quartz 24MHz
• Carte compacte
• pas de composants additionnels à prévoir pour les entrées tout ou rien
• 16 entrées ToR
• 8 entrées analogiques 10 bits

Il me fallait écouler un vieux stock de PIC18F4550 en format DIP40, donc le CMS sera pour une prochaine réalisation. Les entrées se font sur des borniers à vis au pas de 2.54mm. Les résistances de pull-up internes au PIC permettent d’exploiter directement les ports B et D en tout ou rien. Le port A est utilisé en entrées analogiques.

Schéma et PCB

Le schéma de la carte ne constitue en rien une révolution. On retrouve presque à l’identique celui de ma première interface.

L’implantation est par contre beaucoup plus compacte.

Réalisation

Pour une fois, j’ai décidé de sous traiter la fabrication des circuits (au-delà d’un exemplaire, la gravure à la fraiseuse n’est pas franchement efficace). J’ai donc envoyé tout ça chez les chinois (NextPCB pour ne pas les citer). Le résultat est impeccable, pour un prix de revient d’1.60€/pièce, port compris :

Seul petit bémol : la durée de livraison pour l’expédition économique : compter plusieurs semaines. Place à la soudure !

Programmation

Là encore, rien de révolutionnaire : le code est écrit en C avec MikroC for PIC. Les PIC sont ensuite flashés en série grâce à un PicKit et MPLAB IPE.

Le descripteur HID déclare donc 16 entrées switch et 8 axes analogiques:

hid_rpt_desc =
  {
    0x05, 0x01,                    // USAGE_PAGE (Generic Desktop)
    0x15, 0x00,                    // LOGICAL_MINIMUM (0)
    0x09, 0x04,                    // USAGE (Joystick)
    0xa1, 0x01,                    // COLLECTION (Application)
    0x05, 0x02,                    //   USAGE_PAGE (Simulation Controls)
    0x09, 0xbb,                    //   USAGE (Throttle)
    0x09, 0xc5,                    //   USAGE (Brake)
    0x15, 0x00,                    //   LOGICAL_MINIMUM (0)
    0x26, 0xff, 0x00,              //   LOGICAL_MAXIMUM (255)
    0x75, 0x08,                    //   REPORT_SIZE (8)
    0x95, 0x02,                    //   REPORT_COUNT (2)
    0x81, 0x02,                    //   INPUT (Data,Var,Abs)
    0x05, 0x01,                    //   USAGE_PAGE (Generic Desktop)
    0x09, 0x01,                    //   USAGE (Pointer)
    0xa1, 0x00,                    //   COLLECTION (Physical)
    0x09, 0x30,                    //     USAGE (X)
    0x09, 0x31,                    //     USAGE (Y)
    0x09, 0x32,                    //     USAGE (Z)
    0x09, 0x33,                    //     USAGE (Rx)
    0x09, 0x34,                    //     USAGE (Ry)
    0x09, 0x35,                    //     USAGE (Rz)
    0x95, 0x06,                    //     REPORT_COUNT (6)
    0x81, 0x02,                    //     INPUT (Data,Var,Abs)
    0xc0,                          //   END_COLLECTION
    0x05, 0x09,                    //   USAGE_PAGE (Button)
    0x19, 0x01,                    //   USAGE_MINIMUM (Button 1)
    0x29, 0x10,                    //   USAGE_MAXIMUM (Button 16)
    0x15, 0x00,                    //   LOGICAL_MINIMUM (0)
    0x25, 0x01,                    //   LOGICAL_MAXIMUM (1)
    0x75, 0x01,                    //   REPORT_SIZE (1)
    0x95, 0x10,                    //   REPORT_COUNT (16)
    0x55, 0x00,                    //   UNIT_EXPONENT (0)
    0x65, 0x00,                    //   UNIT (None)
    0x81, 0x02,                    //   INPUT (Data,Var,Abs)
    0xc0                           // END_COLLECTION
  };

Le rapport USB associé est le suivant:

Utilisation

Le câblage des entrées analogiques peut exploiter l’alimentation de la carte (5V sur USB) pour utiliser des potentiomètres:

Le câblage des boutons se fait entre la broche d’entrée et la masse. La résistance de pull-up interne s’occupe de polariser l’entrée quand le bouton est ouvert.

Une fois le tout branché et l’USB relié au PC, Windows devrait voir un nouveau périphérique de jeu:

Conclusion

Il ne reste qu’à faire la mécanique !

Cet article Boite à boutons pour simulateurs est apparu en premier sur Electronique et Informatique.

Si vous aussi êtes fan de Mass Effect et avez investi dans l’édition collector de Mass Effect Andromeda, vous vous retrouvez sans doute avec un Nomad ND1 télécommandé par smartphone. Comme l’application Android est toute nulle perfectible et peu stable, il parait intéressant de piloter ce petit drone roulant à partir d’un PC ou, pourquoi pas, d’une radio commande conventionnelle.

Pour ce faire, je vais décortiquer la communication mise en place entre le Nomad et le smart phone.

Deux types de communication

Le Nomad est télécommandé (vitesse, direction, allumage des feux) mais dispose également d’une caméra afin de fournir un retour vidéo temps réel. Du coup, deux communications différentes sont utilisées.

Connexion WiFi

Tout d’abord, il est bon de préciser que la communication radio entre le smartphone et le Nomad est basée sur une liaison WiFi 2.4GHz. Le Nomad est un point d’accès avec serveur DHCP. Quand on connecte un périphérique réseau sur le Nomad, on obtient automatiquement une adresse IP.

Le Nomad sera toujours accessible à l’adresse 192.168.0.1.

Retour Vidéo

Je commence par exposer le fonctionnement du retour vidéo puisqu’il s’agit du moins complexe et qu’il peut être solutionné avec des logiciels comme VLC.

Le Nomad se comporte comme une caméra IP. Il héberge un serveur de streaming RTSP. Le point d’accès vidéo est vs1. Il est donc possible d’ouvrir le flux vidéo en accédant à l’adresse:

rtsp://192.168.0.1/vs1

Télécommande

L’envoie des commandes au Nomad est un peu plus artisanal. En effet, la messagerie entre le smartphone et le Nomad exploite une communication UDP sans protocole standard particulier. Les informations qui vont suivre sont issues de mes observations et d’analyses réseaux faites avec WireShark. N’ayant qu’un seul Nomad sous la main, il est possible que le comportement décrit ne soit pas identique pour tous les modèles.

Première connexion

La communication UDP bidirectionnelle s’établit sur le port 8234. Comme l’UDP n’est pas un protocole en mode connecté, il est nécessaire de pouvoir vérifier la présence d’un interlocuteur de l’autre côté de la liaison. Pour ce faire, le Nomad propose une commande de ping.

Il est possible d’envoyer la chaine MAKO_CONNECT et le Nomad répond CONNECT_OK.

On notera au passage l’amalgame entre le mako et le nomade qui laisse supposé l’existence d’un mako radiocommandé?

Récupération du statut

Il est possible de récupérer l’état général du Nomad (niveau de batterie et allumage des feux). Pour ce faire, il faut envoyer la chaine MAKO_READ_BATT. Le Nomad va alors répondre trois lignes:

BATT=%d
LED1=%b
LED2=%b

On obtient le niveau de batterie entre 0 et 100%, ainsi que l’état des deux groupes de feux avant (0=éteint, 1=allumé)

Allumage des feux

Pour gérer les feux avant du Nomad, il y a les commande MAKO_LED%d_ON et MAKO_LED%d_OFF. Il est nécessaire de préciser dans la commande le numéro des feux à allumer ou éteindre (par exemple MAKO_LED1_ON ou MAKO_LED2_OFF). Le Nomad ne répond pas à ces commandes. Le statut des LED peut être récupérer par la commande précédente MAKO_READ_BATT.

Envoie des consignes

L’envoie des consignes est un peu plus problématique. En effet, une seule commande binaire est utilisée pour envoyer les consignes de vitesse avant, de vitesse arrière et de direction. En outre, la commande semble contenir un numéro unique qui, s’il est mal renseigné, bloque l’interprétation de la commande complète.

Voici la structure de la trame binaire envoyée. Les valeurs sont données en hexadécimal:

Les consignes de vitesse  sont données en 0-255, soit en marche avant, soit en marche arrière.

La consignes de direction est également en 0-255, avec la valeur 128 pour aller tout droit. 0 tourne à gauche, 255 tourne à droite.

La réponse du Nomad à cette commande est assez impénétrable:

On y retrouve le même code qu’à la commande. Ensuite, il y a deux octets à 0, deux octets qui sembles avoir une valeur proche de 0x66, les recopies des deux consignes de vitesse et encore deux octets à 0.

Conclusion

Même s’il reste quelques octets inexpliqués dans les trames d’envoie de consigne et de réponse, il est tout à fait possible de piloter le Nomad depuis n’importe quel périphérique WiFi. Voici d’ailleurs un driver LabVIEW permettant le pilotage du Nomad:

NomadND1_LV2019.zip

En outre, j’envisage le développement d’une interface Radio <-> WiFi à base d’ESP32. L’idée est de récupérer les signaux d’écolage radio, voir les PWM de pilotage servo issues d’un récepteurs modélisme et de générer les trames UDP « qui vont bien » afin de piloter le Nomad comme il se doit!

Si une âme charitable et possédant un Nomad peut tester le pilotage par UDP afin de s’assurer que la trame C0A8 0101 0000 0421 XXXX XX fonctionne sans modifications, le retour d’expérience sera intéressant pour compléter cette petite introduction au pilotage du Nomad 🙂

Cet article Nomad ND1 – Sous le capot est apparu en premier sur Electronique et Informatique.

Les bruiteurs pour avion de modélisme disponibles dans le commerce sont relativement chers (150€ pour ce modèle de MotionRC). Aujourd’hui, avec les modules disponibles pour la bricole autour des arduinos, il doit être possible de fabriquer un bruiteur à moindre frais. C’est ce que je vais essayer de faire dans cette article.

Le matériel

Pour construire mon bruiteur, j’ai choisi de partir sur un arduino nano (ou sa copie chinoise) et un module lecteur MP3-TF-16P.

Le matériel le plus chers sera donc la carte SD pour stocker les fichiers sons.

L’arduino nano sera utilisé pour acquérir le signal PPM de pilotage moteur et envoyer les informations de lecture fichiers au module MP3 via l’UART.

Le module MP3-TF-16P est un codec audio associé à un amplificateur capable de décoder des fichiers MP3 et WAV et de les jouer sur un haut parleur de 3W.

Principe de fonctionnement

Le signal PPM issu du récepteur radio de l’avion est un pulse de 1 à 2ms émis toutes les 22ms ou 11ms (DSMX). Pour plus de détail, rendez-vous sur la page Récepteur radio-modélisme sur USB. L’arduino doit donc mesurer la durée de l’état haut du pulse. Cela tombe bien, une fonction native s’en occupe: pulseIn(). Elle renvoie la durée des pulses reçus sur une broche d’entrée en µs.

La plage de 1000µs à 2000µs est découpée en 6 plages réparties comme suis:

1000 — OFF— 1100 — RPM1 — 1280 — RPM2 — 1460 — RPM3 —1640 — RPM4 — 1820 — RPM5 — 2000

Chaque plage est associée à un fichier son sur la carte SD. Exception faite de la plage MotorOff qui donne lieu à la lecteur d’un fichier de démarrage moteur et d’une fichier d’arrêt moteur quand la consigne sort ou entre dans la plage.

Les fichiers sons sont téléchargeables sur le site Simviation par exemple.

Câblage

Le câblage du système est très simple:

1. Récupérer une prise servo 3 points
2. Alimenter l’arduino entre noir et rouge (5V issu du BEC du récepteur)
3. Alimenter le module MP3-TF-16P avec le même 5V (pin 1 : Vcc, pin 7 et pin 10 : Gnd)
4. Connecter le signal (fil orange) sur une entrée de l’arduino (j’utilise D2)
5. Connecter l’UART du module MP3-TF-16P (pin 2 : Rx, pin 3 : Tx) sur les broches Rx et Tx de l’arduino (pensez bien à croiser Rx->Tx et Tx->Rx)
6. Connecter le haut parleur sur le module MP3-TF-16P (pin 8 : Spk- et pin 6 : Spk+)

C’est tout!

[EDIT] Voici un schéma de la version amplifiée:

La spécification du module MP3-TF-16P est disponible ici.

Programmation de l’arduino

Le programme de l’arduino est assez simple. Il est basé sur une machine à états qui gère les différents régimes moteurs et les transitions de l’un à l’autre.

Le code source de l’arduino est disponible ici. La version que je propose utilise 7 fichiers son au total. Pour des raisons de simplicité d’intégration je n’ai pas utilisé la bibliothèque DFPlayer-Mini, préférant écrire ma propre implémentation. En effet, le protocole de communication mise en place sur le MP3-TF-16P est relativement simple. Il est très bien décrit dans la spécification du module:

Le même format de trame est utilisée en réception et en émission.

La carte SD

Les fichier sons doivent être rangés et nommés d’une certaine manière pour que le module puisse les lire. Voici l’arborescence que j’utilise:

• 01
  • 001.wav
  • 002.wav
  • 003.wav
  • 004.wav
  • 005.wav
  • 006.wav
  • 007.wav

Les fichier 001 et 007 sont les fichier startup et shutdown. Les fichiers 002 à 006 sont les régimes moteurs établis.

[EDIT] Ajout d’un amplificateur et utilisation d’un haut parleur vibrant (exciter)

Comme prévu, les haut parleurs de 3W ne donne pas satisfaction dans un avion RC: il faudrait percer le fuselage pour sortir le son. Un solution proposée entre autre par MotionRC est d’utiliser des excitateur vibrants. Ils fonctionnent comme un haut-parleur électroacoustique, mais sans membrane. Au lieux de la membrane, il y a juste un adhésif double faces collé sur la bobine. En montant ce type de matériel sur un avion, tout le fuselage devient haut-parleur!

Le modèle que j’ai retenu est un Dayton Audio DAEX25FHE-4 de 24W. Je l’ai couplé à un amplificateur TPA3110 sur carte de développement :

J’ai récupéré l’une des deux sorties DAC_L ou DAC_R du module MP3-TF-16P pour attaquer l’ampli. J’alimente ce dernier avec une batterie 2S auxiliaire afin de ne pas endommager le circuit électrique principal de mon avion en cas de défaillance.

Voici le résultat en images (et surtout en musique…):

Conclusion

Voici donc un petit bruiteur sans prétentions qui semble donner des résultats satisfaisants pour un budget contenu. Je n’ai pas encore pu essayer avec un haut parleur de 3W, mais une chose est sûre: avec mon petit haut parleur de 0.1W, on n’entend pas le bruiteur à cause du bruit de l’hélice de l’avion. Dans le pire des cas, j’ajouterais un amplificateur de 3W additionnel sur la sortie non amplifiée du module pour mettre deux HP en stéréo sur l’avion.

J’envisage d’équiper un su29mm de chez ParkZone.

Cet article Bruiteur pour avion de modélisme est apparu en premier sur Electronique et Informatique.

Avant de commercer cet article, je tiens à remercier Amaury qui m’a permis de publier cet article sur son site. 🙂

Je découvre actuellement l’électronique et la programmation entre  LabVIEW et Arduino et je tiens à partager certains résultats avec vous. Certaines notions abordées ne seront pas forcément poussées ou assez détaillées pour des lectures ou lectrices plus expérimenté(e)s.

Théorie de mesure de distance Lidar

Lidar est l’acronyme anglais de light detection and ranging qui est une technique qui permet de mesurer des distances allant de quelques centimètres à la distance Terre-Lune. Le lidar Garmin utilisé ici, génère un train d’onde électromagnétique cohérente (un faisceau laser InfraRouge) de longueur d’onde λ de 905 nm. Les trains d’onde sont envoyés à une fréquence comprise entre 10 à 20 kHz (à ne pas confondre avec la fréquence propre de l’onde du laser IR) d’après les datasheet. Les trains d’ondes se réfléchissent sur la cible visée par le capteur. Une partie de la lumière du laser revient sur le capteur. Une photodiode placée dans le Lidar et sensible dans la plage de longueur d’onde des IR reçoit l’onde réfléchie. L’écart de temps entre le départ d’un train d’onde et son retour est mesuré par le capteur. Cet écart de temps est proportionnel à la distance parcourue par l’onde. Cette technologie de mesure est communément appelée Time of Flight.

Le matériel utilisé pour la réalisation

Nota : un clavier et une souris seront très certainement nécessaires pour naviguer sur LattePanda.

Le Montage global

Le schéma suivant a été réalisé sur le logiciel libre Fritzing. N’ayant pas trouvé de modèle de LattePanda dans la librairie Fritzing, il a donc été représenté par sa carte Arduino qu’il intègre. Un schéma du LattePanda est donné après.

Figure 1 Schéma Global de la mesure Lidar (à l’aide du logiciel gratuit Fritzing)

L’intégration des différents éléments a été faite à l’aide d’un vieux jeu mécanos.

LattePanda

Le modèle de  LattePanda utilisé est le 4 GB/64 GB sous Windows 10. Ce modèle suffit pour faire tourner un LabVIEW 2014 (https://www.gotronic.fr/art-carte-lattepanda-4-gb-64-gb-dfr0419-24792.htm ). LattePanda sera très utile car il intègre une carte Arduino Leonardo et ses E/S associées. A l’aide des entrées et sorties numériques (0-5V), il sera possible de piloter le moteur pas à pas, le laser et d’acquérir le signal du Lidar. Le LattePanda est enfaîte un petit ordinateur d’instrumentation très compacte et assez puissant. Le projet n’utilise ici qu’une petite partie de sa capacité. Pour plus de détails sur LattePanda, le lecteur pourra se référer à l’article : LattePanda – Première mise en route

Le schéma ci-dessous reprend les principales E/S :

Figure 2 E/S LattePanda 4GB/64GB (https://www.lattepanda.com)

Le moteur Pas à Pas

Le moteur Pas à Pas bipolaire est contrôlé par un Driver Pololu (A4988). Le schéma ci-après (d’après le site Pololu qui commercialise le Driver) permet de connecter le moteur et le Driver. La puce du Driver est alimentée en 5 V par la carte Arduino du LattePanda. Ce driver a été choisi car il est facilement pilotable à partir des E/S digitales du Arduino, qui seront contrôlées par le logiciel ; lequel qui sera abordé après.

Figure 3 Schéma de fonctionnement du Drive couplé au moteur Pas à Pas (bipolaire)

Pour connecter correctement le moteur pas à pas au driver on pourra suivre le tableau suivant :

Figure 4 Schéma du moteur Pas à Pas (14HM11-0404S) d’après datasheet Go Tronic

Il est conseillé de relier la masse de l’alimentation du moteur à la masse du circuit afin d’éviter de le moteur ne grésille. Un petit régulateur LM7815 (15 V) permet de limiter la tension en entrée. Pour ma part j’ai utilisé deux piles de 9 V. En sortie du régulateur il vaut mieux ne pas oublier de limiter le courant à l’aide d’une résistance de charge. Le moteur consomme 400 mA par phase. Pour limiter le courant j’ai choisi de mettre en parallèle 4 résistances de 2 kΩ de 1/4 W qui forment une résistance 500 Ω supportant 1 W. Avec ce montage, le moteur ne chauffe et a assez de puissance pour réaliser ses pas. Un potentiomètre présent sur le driver permet de réguler la tension. Le réglage du courant limite est disponible dans la vidéo disponible en suivant de lien (https://www.youtube.com/watch?v=89BHS9hfSUk). Pololu préconise de régler le courant limite à l’aide du réglage du VREF et non en entrée comme cela a été fait ici.

• Une fois le montage du moteur réalisé, un test du moteur peut être réalise. Pour cela, la Pin STEP du driver peut être connecté au 5V délivré par l’Arduino. Le moteur est censé faire un pas. Sinon, revérifier le schéma de montage.

Les entrées MS1, MS2 et MS3 permettent de réduire le Pas, c’est-à-dire de gagner en précision angulaire. Le tableau ci-dessous affiche les niveaux à utiliser sur les pins en fonctions de la résolution du pas.

Figure 5 Tableau de résolution des pas d’après le site Pololu

Dans le cas présent, un pas complet est de 0,9°, un demi-pas en vaudra la moitié et ainsi de suite. Dans le présent projet, il n’est pas possible de descendre en dessous du demi-pas.

Nota important: il est fortement déconseillé de déconnecter le moteur du driver quand le moteur est en fonctionnement car le Driver peut-être endommagé. Il faudra couper l’alimentation du moteur pour effectuer des changements de postions (si besoin) sur les 4 fils du moteur pas à pas.

Le Lidar

Pour fonctionner le Lidar doit être alimenté en 5 V. L’alimentation 5 V de l’Arduino du LattePanda convient parfaitement. L’acquisition de la mesure de distance est lue en largeur d’impulsion (PWM) sur le fil jaune. Les datasheet préconisent l’utilisation d’une résistance de 1KΩ qui est reliée entre le fil de sortie de la mesure et la masse comme ci-dessous :

Figure 6 Schéma de câblage du lidar en acquisition de mesure en PWM (d’après datasheet Gramin)

Concernant les aspects métrologiques du capteur, la portée maximale du Lidar est de 40 mètres. Sa résolution est de 1 cm.

L’incertitude de mesure du Lidar Lite V3,  entre 0 et 5m est de ± 2.5cm et ± 10 cm au delà.

En sortie de mesure en largeur d’impulsion, la sensibilité est de 10 µs/cm. Cette valeur est à retenir pour comprendre la partie acquisition du signal du logiciel.

Le Laser de visée

Le laser est utile ici afin d’avoir un repère visuel sur l’orientation du Lidar. Le laser est du même type qu’utilisé pour les pointeurs laser de présentation (diode laser). Dans le cas présent, un laser d’alignement de 1 mW (λ = 650 nm) de couleur rouge a été utilisé. Il est alimenté en 5V par une entrée digitale de carte Arduino activable à partir du logiciel.

Attention aux yeux ! Le laser concentre l’énergie sur une surface très petite et a pour conséquence d’être nocif pour l’œil.

L’utilisateur est responsable de sa sécurité mais également celle des personnes autour !

Le logiciel/programme

Pour piloter les instruments (Lidar, moteur, laser) le logiciel LabVIEW 2014 est utilisé. Le but n’est pas de faire la présentation ni la promotion de ce logiciel mais de tenter d’expliquer comment utiliser certaines briques LINX. Si LabVIEW n’est pas utilisé, il sera quand même possible de piloter les instruments via un programme développé sur l’IDE Arduino. La suite de l’article pourra paraître obscure pour les personnes non initiées à LabVIEW; je m’en excuse par avance. Cependant, un petit effort a été fait pour que le code soit compris des personnes non initiées à LabVIEW.

Des briques (ou VI) de code LabVIEW ont été développées afin de faciliter grandement la compatibilité entre des cartes Arduino et LabVIEW. Pour utiliser les briques de codes LINX, la bibliothèque LINX côté LabVIEW doit avoir été installée préalablement dans VI Pack Manager (logiciel qui permet de charger des ToolKit ou librairies de programme).

Chargement des librairies

Avant de compiler le code, il faut charger les bibliothèques. Pour charger les bibliothèques, aller sur l’onglet Tool\MakerHub\LINX\Generate Firmware Librairies :

Et mettre en cible : C:\Program Files\Arduino\Libraries

Les librairies sont donc maintenant chargées et opérationnelles.

Configuration du type de carte

Avant de compiler le code, il faudra configurer le type de carte (Mega, Leonardo) et le type de liaison. Dans ce projet avec LattePanda, la carte Arduino Leonardo est utilisée sur le port COM 4. Dans LabVIEW cliquez dans l’onglet Tool puis \MakerHub\LINX\LINX Firmware Wizard… il faut configurer les champs à l’aide des informations mentionnées plus haut.

TEST simple avec une LED

Pour vérifier que la carte fonctionne correctement, l’exemple du pilotage d’une LED pourra être réalisé (onglet HELP/Find Example…). L’exemple est prêt à être utilisé et ne nécessite que la mise en place d’une LED en série avec une résistance de 220 Ω reliées au LattePanda.

Mettre le port COM 4 (normalement) et configurer la pin du Arduino sur laquelle est reliée l’anode de la LED (la patte la plus longue) et ne pas oublier la résistance de 220 Ω en série 😉 . Puis relier la résistance à la masse et lancer le programme (flèche blanche).

Si la LED clignote quand le bouton est pressé, c’est gagné. Passer aux étapes suivantes. Sinon, il faut trouver la raison de cette malchance.

Ne pas hésiter à reconfigurer la carte car il arrive (trop) souvent que cela saute au bout de 3 à 4 compilations. Par exemple, il vaut mieux arrêter proprement la boucle avec un bouton « stop » placé dans la boucle While plutôt que de stopper le programme avec le bouton rouge de LabVIEW.

L’IHM (côté « Face Avant » de LabVIEW)

L’IHM qui permet à l’utilisateur de contrôler les instruments pourra ressembler fortement à celle présentée ci-dessous.

Les configurations des Pins et du port sont situées à gauche.

Le bouton « Motor ON » permet d’activer le driver sur la Pin ENABLE (Driver).

Le bouton « Left » permet d’activer la Pin STEP (Driver)  et faire faire un pas au moteur.

Le bouton « Right »agit comme le bouton « Left » mais active la pin DIR (Driver) à l’état haut et permet de changer de sens de rotation.

Un bouton « Laser » permet d’activer le laser de visée.

Un bouton STOP permet d’arrêter l’exécution proprement et d’arrêter le moteur (ENABLE) et le Laser.

Trois types d’indicateurs sont présents : numérique (format chaîne de caractère), une barre de remplissage, et un graphe déroulant.

Un contrôleur barre graphe permet de passer au pilotage Pas par Pas (un clique sur LEFT ou RGTH = 0,9°) ou active la vitesse constante (comme sur la vidéo du début de l’article).

Pour le lecteur non initié à LabVIEW, la « face avant » est la partie visible finale du programme disponible pour l’utilisateur.

Le code est développé dans une seconde fenêtre appelée « Diagramme ». Et c’est la partie de développement du Diagramme que nous allons maintenant aborder.

Nota : un Crtl+E permet de permuter rapidement rentre la face avant et le diagramme.

La structure (côté diagramme)

La structure générale du programme est la suivante :

Figure 7 Structure générale du programme dans un boucle While

Le code source ne sera pas disponible dans cet article mais les principales briques seront détaillées pour arriver facilement au résultat. 🙂

Lecture de la valeur de la distance du Lidar

Le Lidar Garmin Lite V3 admet deux sorties de données pour la lecture des mesures : I2C ou PWM. La lecture en modulation de largeur d’impulsion est apparue comme le plus simple du point de vue du soft. Un VI LINX permet de réaliser cette mesure rapidement contre plusieurs VI pour la communication en I2C.

Dans la boucle While cadencée à 50 ms, la mesure du Lidar est effectuée à l’aide du VI « Lecture de la largueur d’impulsion » :

L’entrée DO Channel est connectée et la valeur de la Pin 0 de la carte Arduino est rentrée (cf Figure 8 ci-dessous).

Un tableau général de configuration des Pins d’E/S pourra être créé en amont de la boucle While comme ceci :

La valeur en sortie du VI n’est pas en cm mais en largeur d’une impulsion (µs), qui est proportionnelle à la distance mesurée en cm par le lidar. Afin de lire et d’afficher une valeur en cm, il faut diviser les valeurs en sortie du VI par une constante valant 10 pour obtenir une mesure de longueur (en cm). Cette constante est la sensibilité (en µs/cm) du capteur abordé précédemment que l’on peut retrouver dans la documentation du Lidar Lite V3 (page 4, §Mode Pin Control).

Une moyenne glissante pourra être développée afin d’obtenir une mesure plus stable et plus juste à l’aide des registres à décalage (flèches oranges sur les bords de la boucle While). L’inconvénient de cette technique est qu’il faudra attendre n fois le nombre de points moyennés, pour obtenir le résultat. Si l’on choisit de moyenner sur 10 points et que le temps du cadencement est de 500 ms, alors le résultat sera juste au bout de 5 secondes. Ne pas oublier d’initialiser les registres à décalage à zéro. Différents types d’indicateurs pourront être placés en face avant comme ci-dessous :

Figure 9 Moyenne glissante (côté diagramme/code) et exemples d’indicateurs en face avant

Comme le Lidar affiche une incertitude de ± 2.5 cm et une résolution de 1 cm, il a été choisi de n’afficher que des valeurs entières arrondies au centimètre.

VI de contrôle du Driver et du moteur

Un VI « écrire sur des E/S digitales » permet d’activer les sorties de l’Arduino du LattePanda afin de piloter le Driver.

La fonction suivante a été construite comme ci-après :

Cette fonctionnalité permet de prendre, en entrée, un tableau de booléens (ordres des boutons pressés en face avant) et d’activer les E/S correspondantes.

• La première entrée (en partant du haut) de la fonction « Construire un tableau» est reliée au bouton « MOTOR ON » et agit sur la Pin « ENABLE » du Driver. Ce bouton permet vraisemblablement d’activer l’alimentation du driver et du moteur.
• La seconde entrée permet de gérer la direction du moteur. Le fil (vert) est relié au bouton « RIGHT » de mon interface afin d’active la Pin « DIR » du driver. Le moteur tourne ainsi dans le sens horaire.
• La troisième entrée active la pin « STEP » du driver et permet d’effectuer un Pas de 0,9° (avec les entrées du driver MS1=MS2=MS3=0=GND). Le moteur effectue un pas par changement de niveau de l’état bas à l’état haut. Cette entrée est active si le bouton « LEFT » OU le bouton « RIGHT » est activé. Nous verrons ensuite comment faire tourner le moteur à vitesse constante.
• La quatrième entrée active le laser. Un laser de visée peut fonctionner qu’avec une tension de 5V et ne consomme que quelques milliampères. Il est souhaitable pour la sécurité des personnes, que le bouton « STOP » qui arrête le programme, puisse stopper l’émission du laser à la fin de la manip en même temps. Pour cela on pourra mettre une boucle conditions comme ci-dessous :

Il pourra être fait de même avec l’arrêt du moteur (« MOTOR ON ») à la fin de l’exécution du programme.

• Les cinquième, sixième et septième entrées activent les Pins MS1, MS2 et MS3 du driver et permettent de gagner en précision d’angle (jusqu’au demi pas ici).

Afin de faire fonctionner le moteur à vitesse constante, la fonctionnalité suivante a été développée :

Lorsqu’un booléen (bouton) active la structure « Cas », le VI « écrire un signal carré » est activé avec une fréquence nulle et d’une durée nulle sur la pin STEP. Cette fonctionnalité m’a permis de faire fonctionner le moteur à vitesse constante. Dans ce cas, la vitesse est fonction du temps de cadencement de la boucle (réglée à 50 ms). A l’heure où est écrit cet article, il existe surement de meilleures solutions, notamment avec le VI « PWM Set Duty Cycle »:

Mais cela n’a pas fonctionné comme il était souhaité lors du test.

A la suite de ces nombreux réglages et bidouillages, le programme doit pouvoir se lancer (flèche blanche non brisée). Si cela n’est pas le cas, résoudre les erreurs unes à unes.

Il fortement probable que rien ne fonctionne du premier coup, ou qu’à moitié, il est alors conseillé, dans un premier temps, de vérifier les branchements (alimentation) des organes dysfonctionnant.

L’utilisateur pourra jouer avec les différents types d’actions mécaniques pour contrôler le moteur (clique droit sur un bouton) :

Résultats en images :

Figure 10 Interface de la mesure de distance (Windows n’est pas à l’heure ^_^ )

J’espère que ce projet a pu continuer d’éveiller votre curiosité et a pu vous aider dans vos futurs développements !

Sources :

• Site Pololu (https://www.pololu.com/product/1182 )
• Site GO Tronic
• https://www.lattepanda.com
• Ressources LINX : http://sine.ni.com/nips/cds/view/p/lang/fr/nid/212478
• Forum LINX : https://www.labviewmakerhub.com/doku.php?id=libraries:linx:start
• Datasheet Lidar Garmin lite V3 : https://static.garmin.com/pumac/LIDAR_Lite_v3_Operation_Manual_and_Technical_Specifications.pdf
• LabVIEW – 4e édition – Programmation et applications – Introduction à LabVIEW NXG, Collection : Technique et ingénierie, Dunod, Parution : août 2018,Francis Cottet, Luc Desruelle, Michel Pinard

• The Art of electronic, Third edition, Paul Horowitz et Winfield Hill

Cet article Mesure Lidar rotatif embarqué sur LattePanda et piloté par LabVIEW (LINX) est apparu en premier sur Electronique et Informatique.

Introduction

Quoi de plus normal pour un hacker que d’essayer de hacker tout ce qui bouge?

C’est probablement l’idée qui m’a traversé l’esprit quand j’ai mis en route ma première radiocommande: comment l’utiliser pour piloter tout et n’importe quoi? Une solution serait de concevoir intégralement un récepteur radio 2.4GHz et décoder le signal de la radiocommande. Cette solution permettrait de récupérer l’intégralité des voies de la radio. Elle est par contre particulièrement complexe.

C’est pourquoi, je vais vous proposer une solution détournée: récupérer les signaux de pilotage servomoteurs derrière un récepteur radio du commerce. Il suffit alors de lire les signaux modulés en largeur d’impulsion pour avoir la valeur émise par la radio.

Le montage que je vous propose permet de numériser les signaux destinés aux servomoteurs de modélisme. Les valeurs acquises sont ensuite envoyées à un PC via une prise USB.

Grâce au protocole HID, le montage est vu par le système d’exploitation (Windows, Linux, Mac) comme un joystick sans installer de pilotes particuliers.

Il ne reste plus qu’à exploiter les valeurs pour l’usage que vous aurez imaginé :

• Piloter un simulateur de vol sans fil
• Piloter un système déporté (robot, caméra IP, …)
• …

Un peu de théorie

Un récepteur de modélisme sert à recevoir et décoder les ordres émis par la radiocommande et les envoyer aux actionneurs (servomoteurs, variateurs, …). Le pilotage des actionneurs de modélisme est standard:

• Ils reçoivent des signaux carrés d’une période de 22 millisecondes
• La largeur de l’état haut varie entre 1ms et 2ms
• 1ms correspond à 0% (ou -100%)
• 2ms correspond à 100 %
• L’amplitude du signal est déterminée par la tension d’alimentation du récepteur

Il s’agit donc de signaux modulés en largeur d’impulsion ou PWM (Pulse Width Modulation).

Pour information, la largeur d’impulsion n’est que de 10% de la période totale pour permettre au récepteur de générer jusqu’à 10 voies séquentiellement:

Le fonctionnement du récepteur en est donc simplifié: il n’a qu’une impulsion à générer à la fois.

Mise en application

Choix du matériel

Le récepteur radio que j’ai choisi pour ce montage est un Spektrum AR400. Il s’agit d’un récepteur DSM2/DSMX 4 voies dédié à l’aéromodélisme. Il est en outre capable de gérer la télémétrie (future évolution du projet?).

Pour numériser les signaux PWM, je compte utiliser un microcontrôleur doté d’une connexion USB. Mon affinité me pousse naturellement chez Microchip. J’ai donc commencé le développement sur un PIC32MX795F512H que j’avais sous la main. Malheureusement, il se trouve que l’utilisation que je vais décrire dans cet article n’est pas bien supportée par mon compilateur, spécifiquement sur cette famille de PIC32. En effet, le contrôleur d’interruption ne semble pas bien configuré. Je suis donc passé sur un PIC32MX440F256H.

La carte de développement utilisée est une Pinguino Micro de chez Olimex, reprogrammée avec le bootloader USB de Mikroelektronika.

L’idée est d’utiliser les 4 modules Input Capture disponibles dans le PIC32. Ces modules permettent de faire des mesures temporelles sur des signaux digitaux. J’utilise donc un module par voie du récepteur.

Câblage

Le câblage électrique est des plus simple. La carte Pinguino est autonome. L’alimentation électrique provient directement de la prise USB. Un régulateur 3.3V présent sur la carte permet d’alimenter l’AR400 avec une tension compatible PIC32 (ces derniers peuvent être chatouilleux sur certaines broches avec le 5V par exemple).

Sur l’AR400, on note 5 rangées de 3 pins. De gauche à droite, on trouve:

• Association/Télémétrie
• Gaz
• Ailerons
• Gouverne de profondeur
• Gouverne de direction

Ensuite, de haut en bas, on trouve:

• Signal
• +Vcc
• Gnd

Voici donc le schéma de câblage (si l’on peut appeler ça comme ça…)

Le module Input Capture

Ce module est présent dans la plupart des microcontrôleurs Microchip. Il permet de récupérer la valeur d’un Timer sur un front de signal. Comme tous les modules d’un microcontrôleur, il est possible de le configurer:

• Choix du premier front de déclenchement (montant ou descendant)
• Mode de déclenchement (armement pour un front, sur les fronts montants, sur les fronts descendants, sur tous les fronts…)
• Périodicité des interruptions (tous les fronts, tous les 2 fronts, …)
• Pour les PIC32, choix de la taille du compteur (16 ou 32 bits)

J’ai choisi d’utiliser un Timer sur 32 bits, de déclencher sur tous les fronts, de commencer par un front montant et d’avoir une interruption à chaque déclenchement. Ce qui donne la configuration suivante (cf: datasheet du module Input Capture, page 6):

IC1CONbits.ICM = 0b110; //Simple Capture Event mode – every edge, specified edge first and every edge thereafter
IC1CONbits.FEDGE = 1; //Capture rising edge first
IC1CONbits.C32 = 1; //32-bit timer resource capture
IC1CONbits.ICI = 0; //Interrupt on every capture event
IC1CONbits.ICSIDL = 0; Continue to operate in CPU Idle mode
 
//Dupplication de la configuration sur tous les modules Input Capture    
IC2CON = IC1CON;
IC3CON = IC1CON;
IC4CON = IC1CON;

Cependant, le module Input Capture ne fonctionne pas seul: il travail conjointement avec le Timer 2. Il convient donc de le configurer également:

• Source d’horloge: interne
• Pas de prescaler (avec une horloge à 80MHz, la valeur de comptage devrait être comprise entre 80000 (1ms) et 160000 (2ms), ce qui donne une résolution plus qu’acceptable)
• Timer sur 32 bits
• Pas de GATE
• Période de comptage 0xFFFFFFFF

Ce qui donne la configuration suivante (cf: datasheet du module timer, page 9):

T2CONSET.f1 = 0; //Internal peripheral clock
T2CONSETbits.T32 = 1; //TMRx and TMRy form a 32-bit timer
T2CONSETbits.TGATE = 0; //Gated time accumulation is disabled
T2CONSETbits.TCKPS0 = 0; //1:1 prescale value
T2CONSETbits.TCKPS1 = 0;
T2CONSETbits.TCKPS2 = 0;
TMR2 = 0;
PR2 = 0xFFFFFFFF;
T2CONSETbits.ON = 1; //Module is enabled

NB : tous les modules Input Capture du PIC32MX440 accèdent au Timer2.

La routine d’interruption

La majorité du code contenu dans le microcontrôleur s’exécute sur interruptions. Sur front montant, je lis et mémorise la valeur du Timer2. Sur front descendant, je calcul la durée de l’impulsion en faisant la différence des valeurs courante et précédente du Timer2.

NB : Dès qu’un évènement est capturé par un module Input Capture, il copie la valeur du registre TMR2 dans le registre ICxBUF, qui est en réalité une FIFO. Elle stocke les valeurs de comptage des derniers évènements acquis.

void IC1_ISR() iv IVT_INPUT_CAPTURE_1 ilevel 6 ics ICS_SOFT {
     unsigned long temp = 0;
     LATG.f6 = 1;
     sync = 1;
     TMR1 = 0; //reset timeout comm.
     temp = IC1BUF;
     IC1BUF = 0;
     if (toogle1 == 0) {
         ic1_start = temp;
         toogle1 = 1;
     }
     else {
         // value1 = CalculDelta(temp, ic1_start);
         
         // Calcul T2-T1, même si le timer déborde et repart à 0
         if (temp<ic1_start) {
            // théoriquement impossible sauf en cas de débordement
            value1 = 4294967295-(ic1_start-temp)+1;
         }
         else value1 = temp-ic1_start;
         toogle1 = 0;
     }
     debug_toogle++;
     if (debug_toogle >= 50) {
        debug_toogle = 0;
        LATD.f1 = !PORTD.f1;
     }
     IC1IF_bit = 0;
}

Je profite de la disposition du Timer 1 pour gérer un timeout: en cas de perte de la liaison radio, le signal PWM disparait et le Timer 1 n’est plus remis à zéro. Le débordement du timer (environ en 200ms) indique une perte du signal. A noter également la gestion du débordement du Timer 2: à 80MHz sur 32 bits, il survient assez rapidement (53 secondes).

NB : La voie de pilotage des gaz génère tout le temps un signal. En cas de perte de la radiocommande, une impulsion de 1ms est envoyée pour remettre les gaz à 0.

Cette routine est dupliquée pour tous les modules Input Capture.

ATTENTION! il ne faut pas utiliser de sous fonction commune aux 4 interruptions: elle créent un couplage nuisible au fonctionnement du programme.

NB : Il est impossible de remettre à 0 le flag ICxIF_bit tant que le registre ICxBUF n’a pas été lu intégralement.

La communication USB

Dans un premier temps, j’ai choisi de remonter les valeurs des voies sur un PC via un bus USB. Le plus simple à gérer pour Windows est un périphérique HID compatible joystick. J’ai donc récupéré et nettoyé le descripteur USB de mon simulateur de Joystick. Le nouveau descripteur gère 4 axes (X, Y, Rx et Ry) sur 16 bits.

Voici le descripteur :

{
    0x05, 0x01,                        // USAGE_PAGE (Generic Desktop)
    0x09, 0x04,                        // USAGE (Joystick)
    0xa1, 0x01,                        // COLLECTION (Application)
    0x09, 0x01,                        //   USAGE (Pointer)
    0xa1, 0x00,                        //   COLLECTION (Physical)
    0x09, 0x30,                        //     USAGE (X)
    0x09, 0x31,                        //     USAGE (Y)
    0x09, 0x34,                        //     USAGE (Ry)
    0x09, 0x33,                        //     USAGE (Rx)
    0x15, 0x00,                        //     LOGICAL_MINIMUM (0)
    0x27, 0xff, 0xff, 0x00, 0x00,    //     LOGICAL_MAXIMUM (65535)
    0x75, 0x10,                        //     REPORT_SIZE (16)
    0x95, 0x04,                        //     REPORT_COUNT (4)
    0x81, 0x02,                        //     INPUT (Data,Var,Abs)
    0xc0,                            //     END_COLLECTION
    0xc0                            // END_COLLECTION
}

Le rapport USB envoyé au PC est décrit de la manière suivante:

typedef union {
    char bytes[8];
    struct {
        unsigned int x_value;
        unsigned int y_value;
        unsigned int rx_value;
        unsigned int ry_value;
    };
} T_USB_Report;

La boucle principale de programme est donc très simple: elle récupère les 4 valeurs, leur soustrait 80000 et les divise par 1.22. On obtient ainsi une valeur comprise entre 0 et 65573. Il convient de borner les valeurs finales obtenues en cas de dépassement de la gamme (<0 ou >65535). Les valeurs sont ensuite stockées dans le rapport USB et envoyées au PC.

while (1) {
    MyReport.x_value = (value1-MIN_PERIOD)/1.22;
    MyReport.y_value = (value2-MIN_PERIOD)/1.22;
    MyReport.rx_value = (value3-MIN_PERIOD)/1.22;
    MyReport.ry_value = (value4-MIN_PERIOD)/1.22;
    HID_Write(MyReport.bytes, sizeof(MyReport));
    delay_ms(10);
}

Ainsi, il devient possible de récupérer sous Windows les 4 voies de la radiocommande, en USB et sans driver spécifique:

Le programme complet

Voici le programme complet fonctionnel:

#include "USBdsc.c"
#define MIN_PERIOD        80000.0
 
typedef union {
    char bytes[8];
    struct {
        unsigned int x_value;
        unsigned int y_value;
        unsigned int rx_value;
        unsigned int ry_value;
    };
} T_USB_Report;
 
T_USB_Report MyReport;
 
int debug_toogle = 0;
 
unsigned long int ic1_start = 0;
unsigned long int value1 = 0;
int toogle1 = 0;
 
unsigned long int ic2_start = 0;
unsigned long int value2 = 0;
int toogle2 = 0;
 
unsigned long int ic3_start = 0;
unsigned long int value3 = 0;
int toogle3 = 0;
 
unsigned long int ic4_start = 0;
unsigned long int value4 = 0;
int toogle4 = 0;
 
int sync = 0;
 
char ReadBuffer[64], WriteBuffer[64];
 
unsigned long int CalculDelta (unsigned long int T2, unsigned long int T1) {
    // Calcul T2-T1, même si le timer déborde et repart à 0
    if (T2<T1) {
       // théoriquement impossible sauf en cas de débordement
       return 4294967295-(T1-T2)+1;
    }
    else return T2-T1;
}
 
void IC1_ISR() iv IVT_INPUT_CAPTURE_1 ilevel 6 ics ICS_SOFT {
     unsigned long temp = 0;
     LATG.f6 = 1;
     sync = 1;
     TMR1 = 0; //reset timeout comm.
     temp = IC1BUF;
     IC1BUF = 0;
     if (toogle1 == 0) {
         ic1_start = temp;
         toogle1 = 1;
     }
     else {
         // value1 = CalculDelta(temp, ic1_start);
         
         // Calcul T2-T1, même si le timer déborde et repart à 0
         if (temp<ic1_start) {
            // théoriquement impossible sauf en cas de débordement
            value1 = 4294967295-(ic1_start-temp)+1;
         }
         else value1 = temp-ic1_start;
         toogle1 = 0;
     }
     debug_toogle++;
     if (debug_toogle >= 50) {
        debug_toogle = 0;
        LATD.f1 = !PORTD.f1;
     }
     IC1IF_bit = 0;
}
 
void IC2_ISR() iv IVT_INPUT_CAPTURE_2 ilevel 5 ics ICS_SOFT {
     unsigned long temp = 0;
     temp = IC2BUF;
     IC2BUF = 0;
     if (toogle2 == 0) {
         ic2_start = temp;
         toogle2 = 1;
     }
     else {
         // value2 = CalculDelta(temp, ic2_start);
         
         // Calcul T2-T1, même si le timer déborde et repart à 0
         if (temp<ic2_start) {
            // théoriquement impossible sauf en cas de débordement
            value2 = 4294967295-(ic2_start-temp)+1;
         }
         else value2 = temp-ic2_start;
         toogle2 = 0;
     }
     IC2IF_bit = 0;
}
 
void IC3_ISR() iv IVT_INPUT_CAPTURE_3 ilevel 4 ics ICS_SOFT {
     unsigned long temp = 0;
     temp = IC3BUF;
     IC3BUF = 0;
     if (toogle3 == 0) {
         ic3_start = temp;
         toogle3 = 1;
     }
     else {
         // value3 = CalculDelta(temp, ic3_start);
         
         // Calcul T2-T1, même si le timer déborde et repart à 0
         if (temp<ic3_start) {
            // théoriquement impossible sauf en cas de débordement
            value3 = 4294967295-(ic3_start-temp)+1;
         }
         else value3 = temp-ic3_start;
         toogle3 = 0;
     }
     IC3IF_bit = 0;
}
 
void IC4_ISR() iv IVT_INPUT_CAPTURE_4 ilevel 3 ics ICS_SOFT {
     unsigned long temp = 0;
     temp = IC4BUF;
     IC4BUF = 0;
     if (toogle4 == 0) {
         ic4_start = temp;
         toogle4 = 1;
     }
     else {
         // value4 = CalculDelta(temp, ic4_start);
         // Calcul T2-T1, même si le timer déborde et repart à 0
         if (temp<ic4_start) {
            // théoriquement impossible sauf en cas de débordement
            value4 = 4294967295-(ic4_start-temp)+1;
         }
         else value4 = temp-ic4_start;
         toogle4 = 0;
     }
     IC4IF_bit = 0;
}
 
void USB_ISR() iv IVT_USB_1 ilevel 7 ics ICS_SRS {
     USB_Interrupt_Proc();
     USBIF_bit = 0;
}
 
void TMR1_ISR() iv IVT_TIMER_1 ilevel 1 ics ICS_SOFT {
     LATG.f6 = 0;
     /*
     value1 = 120000;
     value2 = value1;
     value3 = value1;
     value4 = value1;
     */
     sync = 0;
     TMR1 = 0;
     T1IF_bit = 0;
}
 
void ClearBuffer (char * buffer, int buffer_len) {
     int i = 0;
     for (i=0; i<buffer_len; i++) *(buffer+i) = 0;
}
 
void main() {
 
    toogle1 = 0;
    toogle2 = 0;
    toogle3 = 0;
    toogle4 = 0;
    ic1_start = 0;
    ic2_start = 0;
    ic3_start = 0;
    ic4_start = 0;
    value1 = 0;
    value2 = 0;
    value3 = 0;
    value4 = 0;
    debug_toogle = 0;
 
    AD1PCFG = 0xFFFF;
    JTAGEN_bit = 0;
    CHECON = 0x32;
    ODCB = 0;
    TRISD = 0xffff;
    TRISD.f1 = 0;
    TRISG.f6 = 0;
    LATG.f6 = 0;
    LATD.f1 = 0;
 
    IC1CONbits.ICM = 0b110;
    IC1CONbits.FEDGE = 1;
    IC1CONbits.C32 = 1;
    IC1CONbits.ICI = 0;
    IC1CONbits.ICSIDL = 0;
    
    IC2CON = IC1CON;
    IC3CON = IC1CON;
    IC4CON = IC1CON;
 
    T2CONSET.f1 = 0;
    T2CONSETbits.T32 = 1;
    T2CONSETbits.TGATE = 0;
    T2CONSETbits.TCKPS0 = 0;
    T2CONSETbits.TCKPS1 = 0;
    T2CONSETbits.TCKPS2 = 0;
    TMR2 = 0;
    PR2 = 0xFFFFFFFF;
    T2CONSETbits.ON = 1;
    
    PR1 = 65535;
    TMR1 = 0;
    T1CONSETbits.TCKPS0 = 1;
    T1CONSETbits.TCKPS1 = 1;
    T1CONSETbits.TGATE = 0;
    T1CONSETbits.SIDL = 0;
    T1CONSETbits.TCS = 0;
    T1CONSETbits.ON = 1;
 
    IC1IP0_bit = 0;
    IC1IP1_bit = 1;
    IC1IP2_bit = 1;
 
    IC2IP0_bit = 1;
    IC2IP1_bit = 0;
    IC2IP2_bit = 1;
 
    IC3IP0_bit = 0;
    IC3IP1_bit = 0;
    IC3IP2_bit = 1;
 
    IC4IP0_bit = 1;
    IC4IP1_bit = 1;
    IC4IP2_bit = 0;
    
    USBIP0_bit = 1;
    USBIP1_bit = 1;
    USBIP2_bit = 1;
    
    T1IP0_bit = 1;
    T1IP1_bit = 0;
    T1IP2_bit = 0;
 
    
    USBIE_bit = 1;
    IC1IE_bit = 1;
    IC2IE_bit = 1;
    IC3IE_bit = 1;
    IC4IE_bit = 1;
    T1IE_bit = 1;
    
    EnableInterrupts();
 
    HID_Enable(ReadBuffer, WriteBuffer);
    
    IC1CONbits.ON = 1;
    IC2CONbits.ON = 1;
    IC3CONbits.ON = 1;
    IC4CONbits.ON = 1;
 
    T4CONSETbits.ON = 1;
    
    while (1) {
          MyReport.x_value = (value1-MIN_PERIOD)/1.22;
          MyReport.y_value = (value2-MIN_PERIOD)/1.22;
          MyReport.rx_value = (value3-MIN_PERIOD)/1.22;
          MyReport.ry_value = (value4-MIN_PERIOD)/1.22;
          HID_Write(MyReport.bytes, sizeof(MyReport));
          delay_ms(10);
    }
}

 Conclusion

Ce montage assez simple à réaliser permet de récupérer dans un microcontrôleur, puis sur un PC, les valeurs de 4 voies radiocommandées.

L’utilisation du protocole HID permet de connecter le système sur n’importe quel PC ou autre RaspberryPi/LattePanda/BeagleBoard/…

Il devient donc possible de commander à longue distance un dispositif autonome. Les idées ne vous manqueront pas, j’en suis sûr 😉

[metaslider id=771]

Cet article Récepteur radio-modélisme sur USB est apparu en premier sur Electronique et Informatique.

Acquisitions sur le terrain, télégestion, domotique… De nombreuses applications s’accommodent très bien d’une connexion à l’Internet. Qu’il s’agisse d’envoyer des mesures dans une base de données ou de piloter un système à distance: les idées ne manquent pas.

Je vous propose aujourd’hui une petite carte comprenant un microcontrôleur et l’interface réseau qui va lui permettre de dialoguer avec un modem.

Ce projet est rendu possible par Microchip qui propose un contrôleur réseau en boitier DIP28 simplement commandé par un bus SPI. Ce fameux composant se nomme ENC28J60. Il ne requiert que très peu de composants annexes: quelques condensateurs et résistances, un quartz à 25.000 MHz et, bien évidemment, une prise RJ45 et son transformateur de couplage.

Le schéma

Assez palabré, jetons un coup d’œil au schéma.

L’alimentation

J’ai choisi d’utiliser un PIC 18F qui fonctionne sous 5V, mais l’ENC fonctionne lui en 3.3V. Il y a donc deux régulateurs de tension: le premier fournit le 5V au micro et le second fournit le 3.3V à l’ENC. J’ai d’abord monté ces deux régulateurs en parallèle alimentés par le 12Vdc, mais pour limiter l’échauffement du LM317, je l’ai ensuite monté en cascade derrière le régulateur 5V (passant du même coup d’un classique 7805 à un PT78ST105 à découpage).

Il serait peut-être plus avantageux d’utiliser un PIC18LF alimenté directement en 3.3V. Mais vu la consommation de l’ENC (250 mA), il ne semble pas utilise de gratter quelques mA sur le PIC.

L’ENC28J60

L’ENC28J60 est un microcontrôleur, certes un peu particulier, mais qui a les mêmes besoins: une horloge, une alimentation découplée et un Reset.

Le quartz imposé par Microchip doit résonner à 25 MHz. C’est une fréquence courante pour les contrôleurs réseau: on peut donc récupérer de tels quartz dans de vieux routeurs, par exemple. Autrement, ils sont disponibles en neuf chez Conrad.

La connexion à la prise réseau doit obligatoirement passer par un transformateur de couplage. Là encore, il est possible d’en récupérer dans de vieux routeurs. Il existe aussi des prises réseaux intégrant le transformateur appelées « magjack ». C’est une prise de ce type que j’ai utilisé (récupérée dans une vielle Livebox Sagem).

La connexion avec le PIC passe par un bus SPI. Ce dernier transporte les informations sur deux fils (SDI et SDO) accompagnées d’un signal d’horloge (SCK). Il suffit donc de relier la broche SDO du PIC à la broche SI de l’ENC, SDI sur SO et SCK sur SCK. Il faut aussi compléter ce bus des deux lignes /RESET et /CS (chip select), qui permettent d’initialiser le composant et de le choisir (si le bus SPI est relié à d’autres périphériques).

Enfin, Une self permet d’isoler l’alimentation de la carte avec la liaison Ethernet (très bruitée).

ATTENTION: comme je l’ai déjà signalé, l’ENC fonctionne en 3.3V et le PIC en 5V. Dans le cas d’un PIC, les entrées du bus SPI sont dites à « trigger de Schmitt ». En gros, cela signifie qu’elles sont compatibles avec les signaux 3.3V. Pour d’autres microcontrôleurs, il peut être nécessaire d’ajouter un circuit d’adaptation de niveau sur les lignes SDI et /INT. Par contre les entrées de l’ENC sont compatibles TTL 5V. Il n’est donc pas nécessaire d’abaisser le niveau 5V à 3.3V avant d’entrer dans l’ENC.

Le Microcontrôleur

Je suis d’abord parti sur un PIC18F4550, bien connu, qui offre la possibilité d’utiliser le bootloader USB de l’Interface HID Universelle. Malheureusement, bien que milieu de gamme, ce contrôleur n’offre presque pas suffisamment de ressources pour utiliser une stack TCP/IP ou UDP/IP. J’ai donc migré vers un PIC18F46K80. Avec ses deux UART et son bus CAN, ce microcontrôleur est parfaitement adapté à la communication sur réseaux de terrain (je le réservais d’ailleurs à la réalisation d’un espion RS232 …). Il offre cependant 64 ko de flash et 3.6 ko de RAM (contre 32ko de flash et 2ko de RAM pour le 4550) et des convertisseurs A/N 12 bits (contre 10 bits pour le 4550).

Le PIC18F46K80 permet de programmer un mini serveur web ou d’implanter une petite stack TCP/IP pour envoyer des infos sur une base de données (par exemple).
ATTENTION: le 46K80 n’est pas entièrement compatible avec le 4550: les broches d’alimentations sont identiques, mais le bus SPI n’est pas à la même place. En outre, comme le module USB disparaît, la configuration de l’horloge diffère et il faut ajouter un connecteur ICSP (pas de bootloader pour le 46K80, sauf peut-être un en Ethernet …).

Overclocking

Pour les néophytes, l’overclocking est l’art de faire fonctionner un système informatique plus rapidement que ce que préconise le fabricant. Fort populaire sur PC, l’overclocking peut aussi s’appliquer à nos chers microcontrôleurs.

Dans le cas du 18F46K80, il s’agit surtout de conserver le quartz de 20MHz que j’avais mis pour le 4550. Le 46K80 offre une configuration d’horloge complètement différente du 4550. Il est notamment possible de configurer l’utilisation d’une horloge secondaire plus lente pour le mode basse consommation. Par contre, il ne propose qu’une seule PLL d’un coefficient de 4. On a donc le choix entre une horloge à 20MHZ ou une horloge à 80MHz. Je vous laisse imaginer quelle configuration j’utilise ;). Par contre, cette fréquence dépasse de 25% les spécifications constructeur, donc si votre micro a un comportement anormal, désactivez la PLL et contentez-vous d’une horloge à 20MHz.

NB: Il est bien connu qu’un microprocesseur de PC chauffe plus quand on l’overclocke. Un PIC n’est pas différent: si le 46K80 est froid à 20MHz, il tiédit légèrement à 80MHz (mais rien de comparable avec l’ENC28J60, qui lui tiédit franchement).

Utilisation

Une fois n’est pas coutume, j’utilise l’environnement MikroC pour programmer cette carte. En effet, MikroC offre une bibliothèque dédiée à l’utilisation de l’ENC28J60. Je vous invite à essayer leurs exemples, notamment leur serveur web.

Une version modifiée et améliorée de leur stack TCP/IP est disponible sur leur dépôt Libstock.

Voici un exemple de code :

#include "__NetEthEnc28j60.h"
#include "recources.h"
 
#define TMR0_PRE                    34286    //une IT toutes les 200ms à 80MHz
 
// mE ehternet NIC pinout
sfr sbit Net_Ethernet_28j60_Rst at LATD3_bit;  // for writing to output pin always use latch
sfr sbit Net_Ethernet_28j60_CS  at LATD2_bit;  // for writing to output pin always use latch
sfr sbit Net_Ethernet_28j60_Rst_Direction at TRISD3_bit;
sfr sbit Net_Ethernet_28j60_CS_Direction  at TRISD2_bit;
// end ethernet NIC definitions
 
const code unsigned char httpHeader[] = "HTTP/1.1 200 OK\nConnection: close";  // HTTP header
const code unsigned char httpMimeTypeHTML[] = "\nContent-type: text/html\n\n";              // HTML MIME type
const code unsigned char httpImage[] = "HTTP/1.1 200 OK\nConnection: keep-alive\nContent-type: image/jpg\n\n";           // TEXT MIME type
unsigned char httpMethod[] = "GET /";
unsigned char httpRequ[] = "GET / HTTP/1.1";
 
 
unsigned char   myMacAddr[6] = "ENC28";   // my MAC address
unsigned char   myIpAddr[4]  = {0, 0, 0, 0};                   // my IP address: 0.0.0.0 => utilise le DHCP pour obtenir une IP
unsigned char   gwIpAddr[4]  = {192, 168,   1, 254};           // gateway (router) IP address
unsigned char   ipMask[4]    = {255, 255, 255,  0 };           // network mask (for example : 255.255.255.0)
unsigned char   dnsIpAddr[4] = {192, 168,   1, 254};           // DNS server IP address
 
unsigned char   getRequest[15];                                // HTTP request buffer
unsigned char   dyna[31] ;                                     // buffer for dynamic response
char led0status = 0;
 
int nb200ms = 0;
 
////////////////////////////////////////////////////////////////////////////////
// // User must set values of global variables in _Lib_NetEthEnc24j600_Defs.c file: !!!!!
/*
NUM_OF_SOCKET_28j60 = 7;     // Max number of socket We can open.
TCP_TX_SIZE_28j60 = 256;    // Size of Tx buffer in RAM.
MY_MSS_28j60 = 30;          // Our maximum segment size.
SYN_FIN_WAIT_28j60 = 1;      // Wait-time (in second) on remote SYN/FIN segment.
RETRANSMIT_WAIT_28j60 = 1;   // Wait-time (in second) on ACK which we expect.
*/
////////////////////////////////////////////////////////////////////////////////
 
char sendHTML_mark = 0;
SOCKET_28j60_Dsc *socketHTML;
unsigned int pos[10];
// Initialization of Timer1
unsigned int cnt;
 
void Net_Ethernet_28j60_UserTCP(SOCKET_28j60_Dsc *socket) {
  unsigned int    len;
  char content_length[32];
  asm CLRWDT;
  
  // I listen only to web request on port 80 for web server
 
  if(socket->destPort != 80) return ;
  // get 10 first bytes only of the request, the rest does not matter here
  for(len = 0; len < 10; len++){
    getRequest[len] = Net_Ethernet_28j60_getByte();
    }
  getRequest[len] = 0;
 
  // only GET method is supported here
  if(memcmp(getRequest, httpMethod, 5)&&(socket->state != 3)){
    return;
    }
 
  if(memcmp(getRequest, httpRequ, 9)==0){
    sendHTML_mark = 1;
    socketHTML = socket;
  }
 
 
  //............................................................................
  // Send html page.
  if((sendHTML_mark == 1)&&(socketHTML == socket)) {
    if(pos[socket->ID]==0) {
      LATD.F1 = 1;
      // Send HTTP header.
      sprintf(content_length, "Content-Length: %d", strlen(html_code));
      Net_Ethernet_28j60_putConstStringTCP(httpHeader, socket);
      Net_Ethernet_28j60_putStringTCP(content_length, socket);
      Net_Ethernet_28j60_putConstStringTCP(httpMimeTypeHTML, socket);
      Net_Ethernet_28j60_putConstStringTCP("<script>\n", socket);
      sprintf(dyna, "var kimoTemp=%2.1f\n",getTempKimo(KIMO_TEMP));
      Net_Ethernet_28j60_putStringTCP(dyna, socket);
      sprintf(dyna, "var kimoHygro=%2.1f\n",getHygroKimo(KIMO_HYGRO));
      Net_Ethernet_28j60_putStringTCP(dyna, socket);
      Net_Ethernet_28j60_putConstStringTCP("</script>\n", socket);
    }
    while(pos[socket->ID] < strlen(html_code)) {
      asm CLRWDT;
      if(Net_Ethernet_28j60_putByteTCP(html_code[pos[socket->ID]++], socket) == 0) {
        pos[socket->ID]--;
        break;
      }
    }
    if( Net_Ethernet_28j60_bufferEmptyTCP(socket) && (pos[socket->ID] >= strlen(html_code)) ) {
      Net_Ethernet_28j60_disconnectTCP(socket);
      LATD.F1 = 0;
      sendHTML_mark = 0;
      sendDATA_mark = 0;
      pos[socket->ID] = 0;
    }
  }
}
 
////////////////////////////////////////////////////////////////////////////////
 
int ReadSampleADC (char channel)
{
      /* Fonction de lecture des voies Analogiques */
      /* Les fonctions de MikroC ne semble pas s'accomoder des entrées différentielles */
      ADCON0 = channel * 4;
      ADCON0.f0 = 1;
      ADCON0.f1 = 1;
      while(ADCON0.f1 == 1);
      ADCON0.f0 = 0;
      
      return (ADRESH*256 + ADRESL)%4096;
}
 
unsigned int    Net_Ethernet_28j60_UserUDP(UDP_28j60_Dsc *udpDsc) {
 
  unsigned int    len = 0;                           // my reply length
 
  // reply is made of the remote host IP address in human readable format
  ByteToStr(udpDsc->remoteIP[0], dyna);                // first IP address byte
  dyna[3] = '.';
  ByteToStr(udpDsc->remoteIP[1], dyna + 4);            // second
  dyna[7] = '.';
  ByteToStr(udpDsc->remoteIP[2], dyna + 8);            // third
  dyna[11] = '.';
  ByteToStr(udpDsc->remoteIP[3], dyna + 12);           // fourth
 
  dyna[15] = ':';                                // add separator
 
  // then remote host port number
  WordToStr(udpDsc->remotePort, dyna + 16);
  dyna[21] = '[';
  WordToStr(udpDsc->destPort, dyna + 22);
  dyna[27] = ']';
  dyna[28] = 0;
 
  // the total length of the request is the length of the dynamic string plus the text of the request
  len = 28 + udpDsc->dataLength;
 
  // puts the dynamic string into the transmit buffer
  Net_Ethernet_28j60_putBytes(dyna, 28);
 
  // then puts the request string converted into upper char into the transmit buffer
 
  while(udpDsc->dataLength--)
          {
          Net_Ethernet_28j60_putByte(toupper(Net_Ethernet_28j60_getByte()));
          }
  return(len);
}
 
void interrupt (void)
{
     if (INTCON.T0IF == 1)
     {
        TMR0H = TMR0_PRE / 256;
        TMR0L = TMR0_PRE % 256;
 
        nb200ms++;
 
        if (nb200ms%5 == 0)
        {
           nb200ms = 0;
           Net_Ethernet_28j60_UserTimerSec ++;
        }
 
 
        if(led0Status == 0)
        {
            LATD.f0 = 0;
        }
        else if(led0Status == 1)
        {
            LATD.f0 = 1;
        }
        else if(led0Status == 2)
        {
            LATD.f0 = !LATD.f0;
        }
 
        INTCON.T0IF = 0;
     }
 
}
 
void MCUInit() {
        ADCON1 = 0;
        ADCON2 = 0b10101010;
        ANCON0 = 0xff;
 
        CM1CON = 0;
        CM2CON = 0;
 
        CVRCON = 0;
 
        PORTA = 0 ;
        TRISA = 0xff ;          // set PORTA as input for ADC
 
        PORTB = 0 ;
        TRISB = 0xff ;          // set PORTB as input for buttons
 
        LATD  = 0 ;
        TRISD = 0 ;             // set PORTD as output
 
        INTCON.GIE = 1;
        T0CON = 0b10000110;
        TMR0H = TMR0_PRE / 256;
        TMR0L = TMR0_PRE % 256;
        INTCON.T0IE = 1;
}
 
void main() {
        char useDHCP = 0;
        int i = 0;
        
        MCUInit();
 
        for(i = 0; i < NUM_OF_SOCKET_28j60; i++)
          pos[i] = 0;
 
        Net_Ethernet_28j60_stackInitTCP();
 
        SPI1_Init();
        SPI_Rd_Ptr = SPI1_Read;
 
        Net_Ethernet_28j60_Init(myMacAddr, myIpAddr, 1); // init ethernet board
        if(Net_Ethernet_28j60_getIpAddress()[0] == 0) useDHCP = 1;
        LATD.f1 = 0;
        led0Status = 2;
        
        asm CLRWDT;
 
        if(useDHCP == 1)
        {
            while(Net_Ethernet_28j60_initDHCP(10) == 0) // try to get one from DHCP until it works
            {
              Net_Ethernet_28j60_Init(myMacAddr, myIpAddr, 1);
              asm CLRWDT;
            }
 
            memcpy(myIpAddr,  Net_Ethernet_28j60_getIpAddress(),    4) ; // get assigned IP address
            memcpy(ipMask,    Net_Ethernet_28j60_getIpMask(),       4) ; // get assigned IP mask
            memcpy(gwIpAddr,  Net_Ethernet_28j60_getGwIpAddress(),  4) ; // get assigned gateway IP address
            memcpy(dnsIpAddr, Net_Ethernet_28j60_getDnsIpAddress(), 4) ; // get assigned dns IP address
 
        }
        else
        {
            Net_Ethernet_28j60_confNetwork(ipMask, gwIpAddr, dnsIpAddr) ; // use configured IP address
        }
 
        led0Status = 1;
        
        
        while(1) {
          //  Process incoming Ethernet packets
          Net_Ethernet_28j60_doPacket();
          
          asm CLRWDT;
          
          for(i = 0; i < NUM_OF_SOCKET_28j60; i++) {
           if(socket_28j60[i].open == 0)
             pos[i] = 0;
          }
          
          if(Net_Ethernet_28j60_doDHCPLeaseTime()) Net_Ethernet_28j60_renewDHCP(5); // it's time to renew the IP address lease, with 5 secs for a reply
 
        }
}

Les actions à effectuer dans l’ordre:

1. Définir les paramètres réseau:
   • Adresse IP
   • Adresse passerelle
   • Masque de réseau
2. Initialiser le module SPI
3. Initialiser le module Ethernet
4. Configurer le réseau (ou demander une IP par DHCP)
5. Définir les deux fonctions User_UDP et User_TCP qui sont appelées pour chaque requête reçue ou envoyée
6. Appeler la fonction doPacket() dans la boucle principale

Et voilà, vous êtes prêt à créer un mini serveur web basse consommation.

Cet article Interface Ethernet PIC18F est apparu en premier sur Electronique et Informatique.

Envie d’améliorer vos expériences de jeux? Alors, concevez vos propres interfaces utilisateurs: tableaux de bord de voiture ou d’avion, manette de jeu, adaptateur pour de vieux périphériques… Avec un PIC équipé d’un module USB tout devient imaginable.

Je vais vous expliquer ici comment implanter la couche HID pour que votre PIC soit reconnu en temps que contrôleur de jeux par votre OS préféré.

Introduction

Tout d’abord, plantons le décor. J’ai mené ce projet avec comme objectif final la réalisation d’un adaptateur USB pour manette de Nintendo 64 (pour les plus jeunes, voir la page Wikipedia). N’ayant pas accès au matériel nécessaire à la réalisation finale dans l’immédiat, l’adaptateur est en stand-by, mais devrait voir le jour prochainement…

Le matériel

Voici le matériel dont vous aurez besoin:

• Un microcontrôleur avec interface USB
• Des moyens d’interagir avec ce dernier
  • boutons poussoirs
  • potentiomètres
  • joysticks
  • écran tactile
  • …
• Le logiciel HID Descriptor Tool
• De la documentation
  • Device Class Definition for Human Interface Devices
  • HID Usage Tables
• Un environnement de développement pour votre microcontrôleur
• Du temps libre

J’ai réalisé ce projet en étant en déplacement. J’ai donc utilisé ma « trousse de survie en milieu hostile »: Mikromedia for PIC32 + MikroC for PIC32 + Visual TFT. J’ai utilisé l’écran tactile pour émuler un pad analogique et des boutons poussoirs.

Un point sur le protocole HID

Bien que l’Interface USB HID porte son nom, elle n’utilise pas les fonctionnalités HID. Elle communique de manière brute (raw) avec le PC en s’appuyant uniquement sur les drivers HID. Elle est ainsi configurée par le descripteur USB généré par MikroC. Il est possible de modifier ce descripteur pour déclarer n’importe quel périphérique d’interface utilisateur.

Mais qu’est-ce qu’un descripteur? C’est très simple: il s’agit un bloc d’octets envoyés par le périphérique à chaque connexion à un PC afin de s’identifier. Ce bloc est interprété par le PC pour configurer automatiquement le driver HID. Le descripteur décrit (tiens tiens…) également le format du rapport envoyé périodiquement par le périphérique. Ce rapport contient toutes les variables acquises par le périphérique (valeur des axes, état des boutons…). Ainsi, l’utilisateur n’a pas ou peu de configuration à faire (sauf pour des cas très spéciaux): la magie du plug’n’play ! La rédaction de ce descripteur sera l’étape la plus importante et la plus critique de ce projet.

La première chose à faire est d’identifier les besoins: nombre d’entrées, de quels types … Pour ce faire, j’ai repris le matchup de la manette de N64:

• Axe X
• Axe Y
• Croix directionnelle
• Boutons C (haut, bas, gauche et droite), A, B, Z, L, R, START

J’ai donc deux types d’entrés: analogiques (x2) et tout ou rien (x14).

Voici donc la structure de données que je vais utiliser. Je décide de coder les signaux analogiques sur 8 bits signés. Les boutons se contentent eux d’un bit chacun.

Les deux derniers bits du dernier octet sont inutilisés. Ce n’est pas grave, mais il faut les faire apparaitre dans le descripteur pour obtenir un nombre entier d’octets dans le rapport.

Après avoir compulsé rapidement les deux PDF de documentation pour s’imprégner de la philosophie HID, il est temps d’ouvrir le logiciel HID Descriptor Tool.

Le panneau de gauche propose les différents champs qu’il est possible d’inclure dans le descripteur de l’interface HID. Le panneau de droite représente votre descripteur.

Vous pouvez voir sur la capture d’écran le descripteur que j’ai utilisé pour mon joystick. La règle qu’il faut toujours respecter est d’obtenir un rapport codé sur un nombre entier d’octets. Je m’explique: la plus petite unité utilisée en informatique pour coder des informations est l’octet (8 bits), le rapport HID est envoyé octet par octet au PC et se dernier doit connaitre précisément l’utilité ce chacun de ces octets.

Regardons plus en détail le descripteur:

• USAGE_PAGE (Generic Desktop): Déclare un périphérique d’usage général (joystick). Plusieurs périphériques peuvent être déclarés sur une même interface HID.
• USAGE (Joystick): Identifie le type de périphérique décrit dans la USAGE_PAGE.
• COLLECTION (Application): Déclare le descripteur.
  • USAGE (Pointer): Déclare un périphérique de pointage (ensemble d’axes analogiques)
  • COLLECTION (Physical): Déclare un descripteur physique.
    • USAGE (X): Déclare l’axe X.
    • USAGE (Y): Déclare l’axe Y.
    • LOGICAL_MAXIMUM (127): Déclare la valeur de la borne maximum des axes (8 bits signés dans mon cas).
    • LOGICAL_MINIMUM (-128): Déclare la valeur de la borne minimum des axes (8 bits signés dans mon cas).
    • REPORT_SIZE (8): Longueur en bits du champ représentant un axe.
    • REPORT_COUNT (2): Nombre de champ dans le descripteur (2 axes sur 8 bits).
    • INPUT (Data,Var,Abs): Type de données pour les axes: variable.
  • END_COLLECTION: fin du descripteur physique.
  • USAGE (Hat Switch): Déclare un PoV Hat. C’est le bouton en forme de chapeau sur le haut des joysticks. Il est fait pour changer le point de vue (PoV <=> Point of View) dans les jeux. Je vais l’utiliser pour la croix directionnelle.
  • LOGICAL_MINIMUM (0): Valeur logique minimum. C’est l’indice du premier bit représentant la première position du hat.
  • LOGICAL_MAXIMUM (3): Valeur logique maximum. C’est l’indice du dernier bit représentant la dernière position du hat.
  • PHYSICAL_MINIMUM (0): Valeur physique minimum. C’est la valeur d’angle du hat liée à la valeur logique minimum.
  • PHYSICAL_MAXIMUM (270): Valeur physique maximum. C’est la valeur d’angle du hat liée à la valeur logique maximum.
  • UNIT (Eng Rot:Angular Pos): Unité des valeurs physiques du hat: rotation en degré
  • REPORT_SIZE (4): Longueur en bits du champ représentant le hat.
  • REPORT_COUNT (1): Nombre de champ dans le descripteur (1 seul hat déclaré).
  • INPUT (Data,Var,Abs): Type de donnée pour le hat: variable.
  • USAGE_PAGE (Button): Déclare un descripteur de boutons.
  • USAGE_MINIMUM (No Buttons Pressed):Valeur représentant tous les bits au repos
  • USAGE_MAXIMUM (Button 10): Valeur représentant le dernier bit activé.
  • LOGICAL_MINIMUM (0): Valeur logique minimum. Valeur du bit représentant un bouton au repos.
  • LOGICAL_MAXIMUM (1): Valeur logique maximum. Valeur du bit représentant un bouton activé.
  • REPORT_SIZE (1): Longueur en bits du champ représentant un bouton.
  • REPORT_COUNT (10): Nombre de champ dans le descripteur (10 boutons).
  • UNIT_EXPONENT (0): Pas de facteur multiplicatif à appliquer sur les champ du descripteur.
  • UNIT (None): Pas d’unité pour un bouton.
  • INPUT (Data,Var,Abs): Type de donnée pour les boutons: variable.
• REPORT_SIZE (1): Longueur en bits du champ de padding.
• REPORT_COUNT (2): Nombre de champ dans le descripteur (2 bits vides à la fin du descripteur).
• INPUT (Cnst,Var,Abs): Type de donnée pour le hat: constant. ⚠ Il est capital de mettre ces champ en constant autrement le périphérique ne marche pas.
• END_COLLECTION: fin du descripteur.

Voici votre descripteur prêt à être implanté dans votre microcontrôleur. Il reste à l’enregistrer en fichier header (.h) pour pouvoir l’exploiter dans votre code source:

char ReportDescriptor[71] = {
    0x05, 0x01,                    // USAGE_PAGE (Generic Desktop)
    0x09, 0x04,                    // USAGE (Joystick)
    0xa1, 0x01,                    // COLLECTION (Application)
    0x09, 0x01,                    //   USAGE (Pointer)
    0xa1, 0x00,                    //   COLLECTION (Physical)
    0x09, 0x30,                    //     USAGE (X)
    0x09, 0x31,                    //     USAGE (Y)
    0x25, 0x7f,                    //     LOGICAL_MAXIMUM (127)
    0x15, 0x80,                    //     LOGICAL_MINIMUM (-128)
    0x75, 0x08,                    //     REPORT_SIZE (8)
    0x95, 0x02,                    //     REPORT_COUNT (2)
    0x81, 0x02,                    //     INPUT (Data,Var,Abs)
    0xc0,                          //   END_COLLECTION
    0x09, 0x39,                    //   USAGE (Hat switch)
    0x15, 0x00,                    //   LOGICAL_MINIMUM (0)
    0x25, 0x03,                    //   LOGICAL_MAXIMUM (3)
    0x35, 0x00,                    //   PHYSICAL_MINIMUM (0)
    0x46, 0x0e, 0x01,              //   PHYSICAL_MAXIMUM (270)
    0x65, 0x14,                    //   UNIT (Eng Rot:Angular Pos)
    0x75, 0x04,                    //   REPORT_SIZE (4)
    0x95, 0x01,                    //   REPORT_COUNT (1)
    0x81, 0x02,                    //   INPUT (Data,Var,Abs)
    0x05, 0x09,                    //   USAGE_PAGE (Button)
    0x19, 0x00,                    //   USAGE_MINIMUM (No Buttons Pressed)
    0x29, 0x0a,                    //   USAGE_MAXIMUM (Button 10)
    0x15, 0x00,                    //   LOGICAL_MINIMUM (0)
    0x25, 0x01,                    //   LOGICAL_MAXIMUM (1)
    0x75, 0x01,                    //   REPORT_SIZE (1)
    0x95, 0x0a,                    //   REPORT_COUNT (10)
    0x55, 0x00,                    //   UNIT_EXPONENT (0)
    0x65, 0x00,                    //   UNIT (None)
    0x81, 0x02,                    //   INPUT (Data,Var,Abs)
    0x75, 0x01,                    // REPORT_SIZE (1)
    0x95, 0x02,                    // REPORT_COUNT (2)
    0x81, 0x03,                    // INPUT (Cnst,Var,Abs)
    0xc0                           // END_COLLECTION
};

La variable ReportDescriptor peut être envoyée au PC sur l’USB par votre microcontrôleur.

Mise en place avec MikroC

Pour programmer ma Mikromedia, j’utilise MikroC et Visual TFT (pour l’interface graphique). Je ne vais pas détailler l’interface graphique, mais plutôt me concentrer sur la couche USB. Le départ est identique à celui utilisé pour l’Interface HID Universelle: configuration de l’horloge, déclaration des buffers USB (read et write), génération d’un descripteur avec HID Terminal et initialisation du module USB dans le programme. Voici les lignes importantes du programme qui concernent uniquement l’USB:

#include "USB_DSC.c"
#define USB_BUFFER_LEN       64
 
unsigned char readbuff[USB_BUFFER_LEN] ;
unsigned char writebuff[USB_BUFFER_LEN] ;
 
T_USB_Report USB_Report;
 
void USB_Isr() iv IVT_USB_1 ilevel 7 ics ICS_SRS {
    USB_Interrupt_Proc();        // USB servicing is done inside the interrupt
    USBIF_bit = 0;
}
 
void main() {
    EnableInterrupts();
 
    /* Interruption USB sur vecteur 7*/
    USBIP0_bit = 1;
    USBIP1_bit = 1;
    USBIP2_bit = 1;
    USBIE_bit = 1;
 
    HID_Enable(&readbuff,&writebuff);
    
    while (1) {
        HID_Write(USB_Report.bytes, sizeof(USB_Report));
    }
}

Le rapport USB est une variable de type T_USB_Report déclaré comme suit:

typedef union {
    char bytes[4];
    struct {
        char x_value;
        char y_value;
        unsigned pov_hat :4;
        unsigned button_1 :1;
        unsigned button_2 :1;
        unsigned button_3 :1;
        unsigned button_4 :1;
        unsigned button_5 :1;
        unsigned button_6 :1;
        unsigned button_7 :1;
        unsigned button_8 :1;
        unsigned button_9 :1;
        unsigned button_10:1;
    };
} T_USB_Report;

On y retrouve tous les champ déclarés dans le descripteur. L’union permet d’y accéder comme un tableau d’octets (pour l’envoi) ou champ par champ (pour y insérer les valeurs).

Ensuite, il faut modifier le fichier USBdsc.c pour y modifier le descripteur. Il faut remplacer celui généré par HID Terminal par celui que nous avons créé avec USB Descriptor Tool. Trouvez la variable hid_rpt_desc et remplacé sont contenu par celui généré par UDT:

const struct {
  char report[USB_HID_RPT_SIZE];
}hid_rpt_desc =
  {
    0x05, 0x01,                    // USAGE_PAGE (Generic Desktop)
    0x09, 0x04,                    // USAGE (Joystick)
    0xa1, 0x01,                    // COLLECTION (Application)
    0x09, 0x01,                    //   USAGE (Pointer)
    0xa1, 0x00,                    //   COLLECTION (Physical)
    0x09, 0x30,                    //     USAGE (X)
    0x09, 0x31,                    //     USAGE (Y)
    0x25, 0x7f,                    //     LOGICAL_MAXIMUM (127)
    0x15, 0x80,                    //     LOGICAL_MINIMUM (-128)
    0x75, 0x08,                    //     REPORT_SIZE (8)
    0x95, 0x02,                    //     REPORT_COUNT (2)
    0x81, 0x02,                    //     INPUT (Data,Var,Abs)
    0xc0,                          //   END_COLLECTION
    0x09, 0x39,                    //   USAGE (Hat switch)
    0x15, 0x00,                    //   LOGICAL_MINIMUM (0)
    0x25, 0x03,                    //   LOGICAL_MAXIMUM (3)
    0x35, 0x00,                    //   PHYSICAL_MINIMUM (0)
    0x46, 0x0e, 0x01,              //   PHYSICAL_MAXIMUM (270)
    0x65, 0x14,                    //   UNIT (Eng Rot:Angular Pos)
    0x75, 0x04,                    //   REPORT_SIZE (4)
    0x95, 0x01,                    //   REPORT_COUNT (1)
    0x81, 0x02,                    //   INPUT (Data,Var,Abs)
    0x05, 0x09,                    //   USAGE_PAGE (Button)
    0x19, 0x00,                    //   USAGE_MINIMUM (No Buttons Pressed)
    0x29, 0x0a,                    //   USAGE_MAXIMUM (Button 10)
    0x15, 0x00,                    //   LOGICAL_MINIMUM (0)
    0x25, 0x01,                    //   LOGICAL_MAXIMUM (1)
    0x75, 0x01,                    //   REPORT_SIZE (1)
    0x95, 0x0a,                    //   REPORT_COUNT (10)
    0x55, 0x00,                    //   UNIT_EXPONENT (0)
    0x65, 0x00,                    //   UNIT (None)
    0x81, 0x02,                    //   INPUT (Data,Var,Abs)
    0x75, 0x01,                    // REPORT_SIZE (1)
    0x95, 0x02,                    // REPORT_COUNT (2)
    0x81, 0x03,                    // INPUT (Cnst,Var,Abs)
    0xc0                           // END_COLLECTION
  };

Il faut également modifier la taille du descripteur: const char USB_HID_RPT_SIZE = 71; Cette ligne est au début du fichier USBdsc.c .

Enfin, il reste à affecter les valeurs du rapport USB avec celles acquises par le microcontrôleur, et envoyer le rapport au PC. Pour l’envoi, il est possible de choisir une période de boucle de l’ordre de 10ms. La fluidité du périphérique est bonne et la charge de calcul et de la liaison reste correcte.

Le projet pour Mikromedia est disponible sur Libstock.

Fonctionnement

Si tous s’est bien passé, une fois votre microcontrôleur programmé et branché, vous devriez le trouver en tant que contrôleur de jeux:

[metaslider id=422]

Démonstration en vidéo

Utilisation avec Zelda: Ocarina of Time

https://www.facebook.com/amaury.laurent.31/videos/147704392082253/

Cet article Joystick USB sur PIC32 est apparu en premier sur Electronique et Informatique.

Le concept

Les amateurs de photo sont rapidement tentés par la réalisation de prises de vue nocturnes, la réalisation de Timelapses ou la photo HDR. Toutes ces techniques requièrent l’utilisation d’un trépieds et le maintient parfait de l’appareil photo. Le simple appuie sur le déclencheur peut ruiner la pose! Pour me simplifier la vie, j’ai conçu une petite télécommande qui me permet, en plus de déclencher l’appareil, de lancer une suite de prises de vue avec un intervalle fixe mais long (plusieurs secondes voir plusieurs minutes).

Le protocole de communication

L’une des constante que l’on retrouve souvent dans les liaisons numériques infrarouge est la double modulation de l’onde lumineuse. Tout d’abord, la source lumineuse, une LED IR, émet de la lumière aux alentours de 940nm. Cette onde lumineuse est ensuite hachée à une quarantaine de kHz pour former un signal porteur carré (les récepteurs IR intégré du type TSOP 1133 démodulent directement ce signal carré). Ce signal est ensuite modulé pour transmettre l’information. Si le codage Manchester est souvent utilisé pour la modulation, Nikon ne semble pas l’utiliser. Le site SBProject présente la forme de la trame envoyée par la télécommande:

Ce motif vient moduler un signal carré à 38kHz avant d’être appliqué aux LED infrarouge. Le motif est répété 2 fois à 63.2ms d’intervalle. Les 2 motifs commandent une seule prise de vue.

Le fonctionnement de la télécommande

Ma télécommande vise la simplicité: un seul bouton et un double afficheur 7 segments. Avec ceci, je veux pouvoir prendre des photos à l’appuie sur le bouton, fixer une période de répétition, lancer et arrêter une séquence de prise de vue. Voici les différentes actions possibles :

• Pas de durée de répétition fixée:
  • Appuie court: Prise de vue
  • Appuie long: Incrémentation de la durée de répétition (tant que le bouton est maintenu)
• Une durée de répétition est fixée:
  • Appuie court: Arrêter/Démarrer la séquence
  • Appuie long: Remise à zéro de la durée de répétition

Un appuie court dure moins de 750ms. Un appuie long dure plus de 750ms et est maintenu tant que le bouton est enfoncé.

Le matériel

Pour réaliser cette télécommande, il vous faut: un micro-contrôleur (et tout ce qui l’accompagne), un afficheur, un bouton, une pile (et le circuit d’alimentation) et des LED infrarouge. Voici mes choix technologiques:

• Un PIC18F4550 cadencé à 48MHz (un peu gros mais c’est le seul que j’avais sous la main)
• Un double afficheur 7 segments à anodes communes
• 3 LED infrarouge et un transistor NPN pour les commander
• Une pile 9V et un 7805 pour fournit le 5V
• Un bouton poussoir
• Un boitier étanche (même s’il faut percer des trous pour les LED et les boutons…) et antichocs

Et maintenant, le schéma:

On retrouve le PIC18F4550 avec ses capacités de découplage, son horloge, son circuit de Reset et son connecteur de programmation. Autours de lui, on a l’afficheur 7 segments directement alimenté par le PIC, avec les deux digits multiplexés, et le bouton poussoir relié à la broche RB0 qui présente le double avantage de générer une interruption processeur et de proposer une résistance de Pull-Up intégrée (comme tout le port B).

Le programme

Ce programme a été écrit pour l’environnement MikroC. C’est bien sûr un exemple. Chacun est libre d’adapter le fonctionnement de la télécommande à son inspiration et son envie.

#define MAIN_CLK 48000000
#define CARRIER_CLK 38000
#define DEMI_PERIODE_US     13
#define PERIODE_AFF_MS      10
 
/* Brochage afficheur 7 segments :
**     Cathodes :
**       ___
**     | RE0 |
** RE1 |     | RA1
**     | ___ |
**     | RA5 |
** RA3 |     | RA2
**     | ___ |
**       RA4
**
**      Anodes:
**       _   _
**      |_| |_|
**      |_| |_|
**      RE2 RA0
*/
 
short displayed = 12;
short toogle = 0;
short intervalle = 0;
short running = 0;
int inc = 0;
int old_pushed_button = 0;
 
void IrCycles (int nbCycles) {
     int i = 0;
     
     for (i=0; i<nbCycles; i++) {
         latd.f1 = 1;
         Delay_us(DEMI_PERIODE_US);
         latd.f1 = 0;
         Delay_us(DEMI_PERIODE_US);
     }
}
 
void WaitCycles (int nbCycles) {
     int i = 0;
     
     latd.f1 = 0;
 
     for (i=0; i<nbCycles; i++) {
         Delay_us(DEMI_PERIODE_US);
         Delay_us(DEMI_PERIODE_US);
     }
}
 
void TakePhoto (void) {
     latd.f2 = 1;
     IrCycles(76);
     WaitCycles(1064);
     IrCycles(15);
     WaitCycles(60);
     IrCycles(15);
     WaitCycles(136);
     IrCycles(15);
     Delay_us(63200);
     IrCycles(76);
     WaitCycles(1064);
     IrCycles(15);
     WaitCycles(60);
     IrCycles(15);
     WaitCycles(136);
     IrCycles(15);
     latd.f2 = 0;
}
 
void DisplayNumber (char number) {
     number = number%16;
     
     switch (number) {
      case 0:
           lata.f1 = 0;
           lata.f2 = 0;
           lata.f3 = 0;
           lata.f4 = 0;
           lata.f5 = 1;
           late.f0 = 0;
           late.f1 = 0;
           break;
      case 1:
           lata.f1 = 0;
           lata.f2 = 0;
           lata.f3 = 1;
           lata.f4 = 1;
           lata.f5 = 1;
           late.f0 = 1;
           late.f1 = 1;
           break;
      case 2:
           lata.f1 = 0;
           lata.f2 = 1;
           lata.f3 = 0;
           lata.f4 = 0;
           lata.f5 = 0;
           late.f0 = 0;
           late.f1 = 1;
           break;
      case 3:
           lata.f1 = 0;
           lata.f2 = 0;
           lata.f3 = 1;
           lata.f4 = 0;
           lata.f5 = 0;
           late.f0 = 0;
           late.f1 = 1;
           break;
      case 4:
           lata.f1 = 0;
           lata.f2 = 0;
           lata.f3 = 1;
           lata.f4 = 1;
           lata.f5 = 0;
           late.f0 = 1;
           late.f1 = 0;
           break;
      case 5:
           lata.f1 = 1;
           lata.f2 = 0;
           lata.f3 = 1;
           lata.f4 = 0;
           lata.f5 = 0;
           late.f0 = 0;
           late.f1 = 0;
           break;
      case 6:
           lata.f1 = 1;
           lata.f2 = 0;
           lata.f3 = 0;
           lata.f4 = 0;
           lata.f5 = 0;
           late.f0 = 0;
           late.f1 = 0;
           break;
      case 7:
           lata.f1 = 0;
           lata.f2 = 0;
           lata.f3 = 1;
           lata.f4 = 1;
           lata.f5 = 1;
           late.f0 = 0;
           late.f1 = 1;
           break;
      case 8:
           lata.f1 = 0;
           lata.f2 = 0;
           lata.f3 = 0;
           lata.f4 = 0;
           lata.f5 = 0;
           late.f0 = 0;
           late.f1 = 0;
           break;
      case 9:
           lata.f1 = 0;
           lata.f2 = 0;
           lata.f3 = 1;
           lata.f4 = 0;
           lata.f5 = 0;
           late.f0 = 0;
           late.f1 = 0;
           break;
      case 0xa:
           lata.f1 = 0;
           lata.f2 = 0;
           lata.f3 = 0;
           lata.f4 = 1;
           lata.f5 = 0;
           late.f0 = 0;
           late.f1 = 0;
           break;
      case 0xb:
           lata.f1 = 1;
           lata.f2 = 0;
           lata.f3 = 0;
           lata.f4 = 0;
           lata.f5 = 0;
           late.f0 = 1;
           late.f1 = 0;
           break;
      case 0xc:
           lata.f1 = 1;
           lata.f2 = 1;
           lata.f3 = 0;
           lata.f4 = 0;
           lata.f5 = 1;
           late.f0 = 0;
           late.f1 = 0;
           break;
      case 0xd:
           lata.f1 = 0;
           lata.f2 = 0;
           lata.f3 = 0;
           lata.f4 = 0;
           lata.f5 = 0;
           late.f0 = 1;
           late.f1 = 1;
           break;
      case 0xe:
           lata.f1 = 1;
           lata.f2 = 1;
           lata.f3 = 0;
           lata.f4 = 0;
           lata.f5 = 0;
           late.f0 = 0;
           late.f1 = 0;
           break;
      case 0xf:
           lata.f1 = 1;
           lata.f2 = 1;
           lata.f3 = 0;
           lata.f4 = 1;
           lata.f5 = 0;
           late.f0 = 0;
           late.f1 = 0;
           break;
     }
}
 
void interrupt (void) {
     if (INT0IF_bit) {
        if (!PORTB.f0) {
           if (intervalle != 0) inc = 0;
           else inc = 1;
        }
        
        INT0IF_bit = 0;
     }
 
     if (TMR0IF_bit) {
        if (displayed >=0) {
           if (toogle) {
              late.f2 = 1;   //dizaine
              lata.f0 = 0;   //unite
              DisplayNumber((displayed/10)%10);
           }
           else {
              late.f2 = 0;   //dizaine
              lata.f0 = 1;   //unite
              DisplayNumber((displayed)%10);
           }
        }
        else {
             late.f2 = 0;   //dizaine
             lata.f0 = 0;   //unite
        }
        toogle = !toogle;
        TMR0IF_bit = 0;
     }
}
 
void main() {
     int i = 0;
     int j = 0;
     int cligno = 0;
 
     trisd.f2 = 0;
     trisd.f1 = 0;
     trisa = 0;
     trise = 0;
     RBPU_bit = 0;
     latd.f2 = 0;
     INTEDG0_bit = 0; //falling edge
     INT0IE_bit = 1;
     TMR0IE_bit = 1;
     GIE_bit = 1;
     PEIE_bit = 1;
     T08BIT_bit = 0;
     T0CS_bit = 0;
     PSA_bit = 1;
     TMR0H = 0;
     TMR0L = 0;
     TMR0ON_bit = 1;
     
     intervalle = 0;
     
     i = -0;
     j = 0;
     inc = 0;
     cligno = 0;
     old_pushed_button = 0;
 
     while (1) {
         if (!running) {
           if (intervalle > 0) displayed = intervalle;
           else displayed = -1;
         }
         
         if (!portb.f0) {
            j = 0;
            if (inc == 1) {
              if ((intervalle < 10) && (i%50 == 0) && (i>0)) intervalle++;
              else if ((intervalle >= 10) && (intervalle < 99) && (i%25 == 0) && (i>0)) intervalle++;
            }
            else if ((i%50 == 0) && (i>0)) intervalle = 0;
            i++;
         }
         else {
           if ((i<50)&&(i>0)&& (old_pushed_button)) {
              if (intervalle == 0) TakePhoto();
              else running = !running;
           }
           i = -0;
           
           if (running) {
               if ((j/100<intervalle)) {
                   if (j%50 == 0) cligno = !cligno;
                   if (cligno) displayed = intervalle - j/100;
                   else displayed = -1;
                   j++;
               }
               else {
                  j = 0;
                  TakePhoto();
               }
           }
         }
         old_pushed_button = !portb.f0;
         Delay_ms(10);
     }
 
}

Quelques photos

[metaslider id=399]

A vos reflex !

Cet article Télécommande IR pour Nikon est apparu en premier sur Electronique et Informatique.

!!! Avertissements !!!

Cette réalisation utilise des tensions continues supérieures à 200V. Un contact direct avec une pièce nue sous tension peut causer un choc électrique.

Historique:

Avant l’avènement des LED (1962), Afficheurs 7 segments et autres tubes VFD (1980), l’indicateur numérique par excellence était le tube Nixie. Produit en série à partir de 1954, ce sont des tubes à vides à cathode froide munis d’une dizaine d’électrodes (entre 10 et 12 généralement). Chaque électrode à la forme d’un chiffre, avec potentiellement un ou deux points décimal. L’application d’une tension sur l’une des électrode provoque une luminescence de celle-ci. En associant plusieurs tubes, il est possible de réaliser un indicateur numérique. Ces composants furent utilisés dans les premiers voltmètres à affichages digital, les calculatrices et autres appareils numériques:

Source: Wikipedia

Mise en oeuvre

Le principal problème technique posé par l’utilisation de tubes Nixie réside dans leur tension d’alimentation. La datasheet de mes tubes IN-16 (En Russe…) indique une tension d’amorçage d’au-moins 200 volts continue. La tension d’alimentation après amorçage doit être maintenue à environ 170 volts continue sous un courant de 2.5mA. La première difficulté consiste donc à obtenir 200Vdc sous 10mA (4 tubes) à partir d’une alimentation de sécurité (idéalement 9-15Vdc). La deuxième difficulté va être de trouver des composants (drivers d’affichage) capables de manipuler une telle tension.

Les tubes Nixie

Il existe plein de revendeurs de tubes Nixie sur la toile (dont pas mal sur eBay). Je me suis orienté vers kosbo.com sur les conseils d’un ami. Je n’ai vraiment pas été déçu: livraison sérieuse, tous les tubes sont arrivés entiers. Pour ces derniers, j’ai choisi un modèle de petite taille: l’IN-16. Il s’agit de tubes russes d’environ 3cm de haut. Ils ont l’avantage d’utiliser une électrode différente pour le 2 et pour le 5 (qui était souvent la même monté dans deux orientations différentes).

Pour les nostalgiques voici la datasheet d’origine en Russe: IN-16_02.pdf

Pour les non russophones, voici une traduction dans la langue de Shakespeare fournie par kosbo: IN16_layout.pdf

Le pilotage des tubes Nixie va être confié à un composant d’époque (russes également, équivalent du DM54 de MSI et du 74141…): le K555. Il s’agit d’un décodeur BCD vers décimal capable de commuter la tension d’alimentation des tubes.

L’alimentation 200Vdc

Il est possible de réaliser une alimentation à découpage 15V -> 200V à base d’un NE555, d’une capacité et d’une bobine. L’un des schéma circulant sur la toile est le suivant:

Il est tiré du site: http://www.turbokeu.com. J’ai réalisé un prototype d’une telle alimentation avec des composants tirés d’un fond de tiroir:

• Un condensateur 33µF 500 Vcc de marque CMF
• Une inductance 100µH C&D Technologies
• Un MOS IRF740 comme hacheur

Étonnement, L’alimentation s’est très bien comportée: pas de sifflement gênant, pas de surchauffe de l’IRF740, un courant convenable et une tension de sortie à partir de 170V. Cependant, lors du réglage de la tension de sortie, celle-ci à dépassée la tension de claquage de mon condensateur… Tout à refaire! J’avoue alors m’être tourné vers une solution plus simple, bien que moins élégante: acheter un module d’alimentation pour tubes Nixie. Je me suis tourné vers le revendeur de mes tubes, kosbo.com, et j’ai trouvé un petit module intégré recevant une alimentation de 12V et ressortant environ 200V ainsi que 5V régulé pour l’électronique de pilotage.

L’électronique de pilotage

L’intelligence est confiée à un PIC18F4550 (exhumé d’un fond de tiroir…), pas du tout de l’époque des tubes, animé par un quartz à 20MHz. Les valeurs envoyées aux K555 pilotant les tubes sont mémorisées dans des verrous cd4042 4 bits qui multiplexent l’un des port du PIC. L’horloge calendrier est un module MikroElektonika RTC2 Click qui a l’avantage énorme d’embarquer la pile de sauvegarde. Quatre boutons poussoirs permettent le réglage de l’heure.

Voici le schéma de principe:

Ma réalisation est faite intégralement sur platine d’essai à bandes. Je ne fournirais donc pas de typon de l’horloge.

Galerie

[metaslider id=326]

Cet article Horloge à tubes Nixie est apparu en premier sur Electronique et Informatique.

Qui n’a pas eu envie de contrôler un robot, un système embarqué ou son chauffage depuis un PC?

Traditionnellement, la liaison utilisée par les électroniciens pour communiquer entre un système embarqué et un PC est la liaison RS232. Elle est en effet très simple à mettre en place, tant sur le plan matériel que logiciel. Malheureusement, cette dernière commence à ce faire vielle (introduit sur le marché en 1962). De plus en plus de cartes mères arrivent aujourd’hui sur le marché sans port RS232, rendant ainsi impossible l’utilisation du PC pour des applications électroniques.
Heureusement pour nous, l’USB est arrivé, et avec lui tout une gamme de microcontrôleurs pourvus de contrôleurs USB intégrés.

L’interface que je vous propose s’appuie sur un micro-contrôleur PIC18F4550 utilisé en périphérique HID.
La programmation de cette interface est en outre simplifiée par l’excellent IDE C pour PIC: MikroC. Ne prenez pas peur en voyant le prix de la licence MikroC, le logiciel est disponible en version de démonstration. Sa seule limite porte sur la taille du code généré par le compilateur (2ko).

Le schéma s’articule donc autour du PIC. On y retrouve son horloge, un circuit de Reset, des connecteurs permettant d’accéder aux ports, un connecteur ICSP pour Pickit, un connecteur I2C et un connecteur USB.

Les deux capacités du résonateur quartz ne sont pas cruciales: si vous ne disposez pas de la bonne valeur, il vaut mieux ne pas mettre de condensateur du tout. De même pour la capacité C3: si votre alimentation présente un front raide à la mise sous tension, il n’est pas nécessaire de la monter (ne pas la mettre facilite la connexion du Pickit…). En revanche, les deux capacités de découplage C5 et C6 doivent être montées au plus près du PIC. La valeur du condensateur C4 (régulation de la tension USB) est assez libre. La datasheet impose 470nF à 20%, j’ai mis une capacité électrochimique de 2.2µF et l’interface marche très bien… À l’origine, cette carte à été conçue pour être interfacée avec les Légo Mindstorm NXT, les valeurs des résistances de Pull Up sur la ligne I2C répondent donc aux spécifications Légo. Si vous visez une application plus conventionnelle, des résistances de 1k ou 1k8 feront parfaitement l’affaire. La LED3 est un témoin d’alimentation et les deux LED 1 et 2 sont des LED de debug.

Le typon tiens sur un circuit simple face:

Le schéma d’implantation:

Vous trouverez tous les documents du projet ci-dessous:

• Projet Eagle 5.11
• Typon au format PDF échelle 1:1
• Un tutoriel pour la mise en place du protocole HID avec MikroC
• Un tutoriel pour la commmunication USB avec LabVIEW

Cet article Interface USB HID est apparu en premier sur Electronique et Informatique.