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

Rappelons rapidement le principe de fonctionnement d’un circuit imprimé.

Un circuit électronique consiste en l’interconnexion de différents composants (résistances, condensateurs, circuits intégrés, …). Ces connexions électriques doivent être réalisées avec un matériau conducteur d’électricité; habituellement le cuivre. Sur un circuit imprimé, on appelle ces connexions des pistes. Pour tenir ces pistes, on fait appel à un substrat isolant: l’époxy ou la bakélite (bien que d’autres matériaux soient également utilisés). Chaque piste relie donc différents composants via leurs broches. Les broches des composants sont reliées aux pistes par des pastilles de cuivre: c’est une zone plus large que la piste (afin de pouvoir y percer un trou) qui permet à l’étain de soudure d’adhérer et offre une meilleure résistance mécanique. Un circuit imprimé peut avoir une ou deux (voir plus) couches de cuivre afin d’augmenter la complexité du circuit. Enfin, il est possible de conserver de grandes étendues de cuivre reliées à une masse d’alimentation (ou à un autre potentiel); on parle alors de plan de masse. Ils ont plusieurs avantages, parmi lesquels une meilleure immunité du circuit au bruit électromagnétique, une meilleure dissipation thermique, …

La réalisation de circuits imprimés peut s’appuyer sur deux principes différents, mais à la finalité identique : enlever le cuivre autour des pistes afin d’isoler celles-ci les unes envers les autres. Je vais citer deux principes largement répandus:

• L’attaque chimique
• La gravure à l’anglaise (ou gravure mécanique)

L’attaque chimique

Cette méthode ancienne et fiable repose sur l’utilisation d’un composé chimique capable d’attaquer et dissoudre le cuivre.

On commence par prendre une plaque d’époxy recouverte d’une couche de cuivre et d’une couche photosensible.

Pour éviter de ronger tout le cuivre du circuit imprimé, on imprime un typon (représentation physique des pistes imprimées en noir sur une feuille transparent). Ce typon est utilisé pour insoler le vernis photosensible. Ensuite, comme pour la photographie argentique, il faut plonger la plaque dans un bain de révélateur. A ce moment, le dessin des pistes devrait apparaitre sur la plaque. On enlève les résidus de vernis photosensible et on plonge la plaque dans un bain d’attaque chimique (perchlorure de fer ou acide chlorique + peroxyde d’hydrogène).

ATTENTION : ces produits sont agressifs (voir très agressifs) et très salissant pour le perchlorure de fer.

On enlève la plaque du bain d’attaque dès que le cuivre est complètement dissout. Il ne reste alors plus qu’à percer les trous dans les pastilles et souder les composants.

Cette méthode a fait ses preuves. Elle est relativement bon marché, nécessite un peu de matériel spécifique (banc à insoler et bain de gravure) et de produits chimiques. Par contre, elle nécessiter une très bonne maitrise du temps (insolation, révélation, gravure) qui ne peut s’obtenir qu’après moult essais et échecs. En outre, elle est très salissante et s’accommode mal des espaces clos (dégagements gazeux).

La gravure à l’anglaise

Cette méthode repose elle sur l’utilisation d’une fraiseuse pour usiner la couche de cuivre. En usinant les contours des pistes, on obtient un résultat similaire à la méthode chimique: les pistes sont isolées entre-elles. C’est cette méthode que je vais détailler dans cet article.

Du logiciel de CAO au module de FAO

La Conception Assistée par Ordinateur (CAO) nous permet de concevoir un circuit électronique en toute quiétude. Le lien est fort entre le schéma et le circuit imprimé: les logiciels de CAO actuels sont capables de rendre bien des services : contrôle électriques, contrôles dimensionnels, auto-routage, …

Cependant, la concrétisation d’une conception en un circuit imprimé fonctionnel reste encore une opération assez complexe. Voici ma chaine logicielle complète pour la réalisation de circuits imprimés:

NB : PERCIVAL et LANCELOT font tous les deux partie de l’environnement de FAO GALAAD.

On distingue trois grandes phases:

1. La conception du circuit proprement dite avec un logiciel de CAO, dans mon cas, EAGLE
2. La préparation à l’usinage avec PERCIVAL
3. L’usinage avec LANCELOT

Ces phases sont toujours reliées par un fichier descriptif du circuit imprimé : PERCIVAL attend un fichier Gerber en entrée et délivre un fichier PCB ou GCODE directement interprétable par le module d’usinage (LANCELOT).

Exportation du fichier Gerber avec EAGLE

ASTUCES :

• Il convient de ne pas définir de plan de masse dans EAGLE, la suite du processus en sera simplifiée. Le plan de masse sera géré par PERCIVAL.
• L’ajout de quatre repères en croix aux quatre coins du circuit va simplifier le réglage de la fraiseuse.

EAGLE comporte un module appelé CAM (Computer Aided Machining – équivalent anglo-saxon de FAO). Il est accessible depuis la fenêtre d’édition du circuit:

Ce module permet d’exporter différents types de fichiers d’usinage. On peut symétriser le circuit imprimé, le faire tourner, … Il est également possible de choisir les couches à exporter. La configuration du module CAM est appelée un job. Il est possible d’enregistrer ses jobs au format .cam pour les rappeler plus facilement et ne pas oublier d’étape.

Voici les grandes lignes à respecter pour l’export vers PERCIVAL d’un circuit simple face:

• Device: GERBER_RS274X
• Mirror
• pos. Coord
• Optimize
• Layers 16, 17, 18:
  • Bottom
  • Pads
  • Vias

Par extension, voici les grandes lignes à respecter pour l’export vers PERCIVAL de la face supérieure d’un circuit double face:

• Device: GERBER_RS274X
• pos. Coord
• Optimize
• Layers 1, 17, 18:
  • Top
  • Pads
  • Vias

Voici les deux fichiers .cam que j’utilise:

• percival_bottom.cam
• percival_top.cam

Pour générer le fichier Gerber, cliquer simplement sur « Process Job » et le tour est joué.

Importation du fichier Gerber dans PERCIVAL

Pour importer le fichier Gerber dans PERCIVAL, il faut passer par le menu Fichier -> Ouvrir -> Nouveau Circuit (Ctrl + O). Pointer ensuite sur le fichier .grb généré par EAGLE. Une incompatibilité du format Gerber généré par EAGLE va causer l’apparition de ce message d’erreur:

Rien de grave cependant: PERCIVAL nous informe simplement que le fichier Gerber ne contient pas les définitions des pastilles. D’une certaine façon, cela nous arrange puisque nous allons reconfigurer toutes les pastilles du circuit pour optimiser l’usinage. Après validation du message, un assistant de configuration des pastilles s’ouvre:

Les pastilles concernées s’allument en rouge sur le circuit. Il est alors possible de modifier leur forme, leurs dimensions, le diamètre de perçage, …

Il faut passer en revue toutes les pastilles de la carte (en navigant avec les boutons « < » et « >« ) pour définir tous ces paramètres. Il est facile de voir quelle taille de pastille va causer un court-circuit ou bien sera trop petite par rapport au diamètre de perçage.

Une fois cette tâche effectuée, on se rend compte que certaines pastilles n’ont pas été traitées:

Le problème provient de la manière utilisée par EAGLE pour exporter les pastilles oblongues: elles sont définies comme des pistes dans le fichier. Pour convertir ces « pistes » en pastille, il faut simplement faire un clic droit sur l’une d’elle et choisir définir comme pastille. PERCIVAL propose alors gentiment de transformer toutes les autres pastilles équivalentes. A vous de voir si PERCIVAL ne fait pas un excès de zèle en convertissant en pastille des pistes bien réelles.

Une fois les torts rétablis et les fausses pistes transformées en pastilles, il convient de refaire l’étape précédente en rouvrant l’assistant de configuration de pastilles (clic droit sur la pastille a configurer -> Editer les pastilles identiques).

Gestion des plans de masse

Avec la gravure à l’anglaise, le plan de masse est quasiment intrinsèque. En effet, à moins de faire en sorte que la fraiseuse retire tout le cuivre inutile, celle-ci na va faire qu’un simple détourage. Il va donc demeurer de grandes zones cuivrées autour des pistes. Il convient alors de les relier à la masse. Cette opération s’effectue dans PERCIVAL et requiert un peu d’attention. En effet, il faut identifier sur le circuit quelles sont les broches et pistes reliées à la masse. Ensuite, il faudra passer chaque piste une par une en faisant un Clic droit -> Définir comme plan-masse. Les pistes appartenant au plan de masse sont symbolisées en marron.

Il est également possible de convertir les pastilles reliées au plan de masse en pastilles thermiques. Cela va grandement simplifier le repérage et la soudure desdites pastilles. Pour ce faire, activer l’outil Pastille thermique (en choisissant l’orientation de la pastille) et cliquer les pastilles à convertir.

Cette fois-ci quand PERCIVAL propose de convertir les pastilles identiques, il est recommandé de ne pas le faire. Une croix apparait en légère surimpression sur les pastilles thermiques.

Réglage de l’origine du circuit

Pour usiner le circuit imprimé, le module d’usinage va nécessiter la prise d’origine de la pièce. Cette origine sera d’autant plus simple à régler si elle se situe sur le bord de la carte. Dans PERCIVAL, il est possible de positionner deux croix: une rouge et une bleue.

Ces croix pourront servir d’origine pièce au module d’usinage. Pour positionner précisément ces croix, il convient au préalable d’avoir prévu des repères dans EAGLE (une petite croix dans chaque angle dessinée avec des pistes sur chacune des faces à usiner). Une fois l’outil activé en mode « Pointage manuel », il suffit de cliquer sur l’extrémité d’une piste ou une pastille pour y positionner la croix.

Le circuit est maintenant prêt pour le calcul des contours d’isolation.

Calcul des contours d’isolation

Les contours d’isolation sont les chemins que suivra la fraise afin d’isoler électriquement les pistes du circuit. Le calcul des contours dépend principalement de deux facteurs:

• La forme de l’outil
• La largeur d’isolation entre la piste et le plan de masse

Le premier facteur se règle dans le menu Paramètres -> Bibliothèque d’outils.

Ce menu permet de déclarer les différents outils en votre disposition. Ainsi, PERCIVAL adapteras les calculs d’isolation et de perçage à la forme et au diamètre des outils disponibles. En outre, le module d’usinage sera à même de vous demander d’installer le bon outil avant chaque phase de gravure ou de perçage.

J’utilise personnellement ces outils:

• Un stylet conique à 60° pour l’isolation (soie de 3.17mm)
• Un foret de 0.8mm pour les perçages (soie de 3.17mm)
• Une fraise à rainurer de 2mm pour le détourage

Il est possible de remplir le nombre de dents et la vitesse de la broche pour chaque outil. PERCIVAL calcul ainsi les vitesses avance optimales pour l’usinage.

Pour calculer les contours d’isolation, il faut utiliser le menu Usinage -> Contours d’isolation -> Calculer les contours. Il est possible de choisir le nombre de passes à réaliser autour des pistes et des pastilles. Plus ce nombre est élevé, plus large sera le contour d’isolation, mais plus long sera l’usinage. Pour ma part, je me contente de deux contours successifs et d’un contour supplémentaire autour des pastilles. Quand le calcul est terminé, PERCIVAL affiche un rendu du résultat final. Les contours affichés en rouges sont ceux qui ont été « forcés » par le logiciel, les pastilles ou pistes adjacentes étant trop proches.

Il est également possible de gérer le détourage de la carte (découpe du circuit à la fraise) en ajoutant ou non pontets de maintien.

Usinage du circuit

Positionner la carte à usiner

Pour fixer la carte à usiner sur la table de la fraiseuse, j’utilise pour ma part du Scotch double faces transparent « extra-fort »:

https://www.leroymerlin.fr/v3/p/produits/adhesif-scotch-fixation-double-face-interieur-exterieur-l1-5mxl19mm-transparent-e1400097015

Il présente l’avantage d’avoir une épaisseur suffisante pour ne pas usiner la table de la fraiseuse. Il est en outre assez simple à décoller.

Un petit carré d’adhésif dans chaque coin et un au centre de la carte suffisent à maintenir le circuit en place pendant tout l’usinage.

Lancer l’usinage

L’usinage du circuit n’est alors plus qu’une « simple » formalité. Il suffit de choisir le menu Usinage -> Fraisage, et de choisir Chainer automatiquement au module d’usinage. Le fichier GCODE est automatiquement généré et passé à LANCELOT pour la gravure.

ATTENTION : Si le circuit a été inversé à la génération du fichier GERBER (mirror activé pour la face du dessous dans EAGLE), il convient de ne pas activer l’inversion horizontale à ce moment du processus.

LANCELOT est lancé automatiquement.

La première page permet de configurer l’usinage. Le tableau en haut à gauche récapitule les différentes phases de la réalisation. Il est possible de les activer (entouré en vert) ou de les désactiver (barré de rouge) à volonté. Chaque phase est associée à un outil et repérée par le numéro de l’outil dans le magasin. Il est également possible de surcharger les paramètres d’usinage (profondeur des passes, vitesse d’avance, …). Enfin, il est possible de tourner ou symétriser le circuit, au cas où une erreur se serait glissé dans le processus précédent.

La deuxième page permet de positionner la carte sur la table d’usinage. Il faut prendre l’origine de la carte (croix rouge, croix bleue ou bien un coin du circuit) en X et Y. Pour le réglage de la hauteur d’outil, deux méthodes sont disponibles:

• La machine est équipée d’un capteur de hauteur d’outil mobile
• Le positionnement de l’outil à fleur de la carte

Pour la première méthode, il convient de se référer à la notice d’utilisation du logiciel LANCELOT. Pour la seconde, je préconise une astuce à base d’Ohmmètre. ATTENTION : toute cette manipulation devra être effectuée broche hors tension, vous allez entrer en contact avec l’outil.

• Installer l’outil dans la broche
• Amener l’outil à quelques millimètres de la surface de la carte
• Passer le pilotage en mode 1mm ou 1/10mm selon la distance entre l’outil et la carte
• Mettre l’Ohmmètre en mode continuité (bip quand les pointes de touche se touchent)
• Mettre une pointe sur la carte (partie cuivrée) l’autre sur le mandrin de la broche (ou directement l’outil si le mandrin est en plastique)
• Descendre l’outil progressivement et doucement jusqu’au bip de l’Ohmmètre
• Cliquer sur Z – ok

ATTENTION : avec un foret de 0.8mm, cette manipulation peut s’avérer destructrice pour l’outil sir la vitesse de descente est trop élevée.

Une fois l’origine réglée, il est alors possible de lancer l’Usinage Automatique (ou de faire une simulation avant d’ouvrir les hostilités).

Si tout fonctionne comme prévu, LANCELOT devrait aller au bout de la première phase avant de demander un changement d’outil. Il convient alors de refaire la prise d’origine en Z.

Voici le résultat pour un circuit simple face basé autour d’un PIC18F4550 :

[metaslider id=910]

Voici deux petites vidéos de l’outil en action (Attention, le volume sonore est un peu élevé…):

Conclusion

Avec le bon outillage, il est aisé de passer d’une conception virtuelle à un circuit bien réel. Il est tout a fait normal d’éprouver une certaine appréhension lors des premiers mouvement de la broche. J’ai cassé quelques outils et gâché un certain nombre de cartes avant de pleinement prendre en main les différents modules logiciels du processus. Il est important d’être méthodique de bout en bout. Le processus que je présente ici n’est bien sûr pas parole d’évangiles, cependant, il fonctionne à merveille chez moi.

Bonnes réalisations !

Cet article Exporter un Circuit Imprimé depuis EAGLE vers GALAAD/PERCIVAL 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.

Avertissements:

Cette réalisation a pour but de générer de hautes tensions. Il vous revient de prendre toutes les précautions nécessaires pour ne pas vous mettre en danger ou endommager vos appareils électroniques!

Historique

Comme son nom l’indique, le résonateur Tesla est l’une des inventions du savant Serbe Nikola Tesla. Né le 10 juillet 1856 à Smiljan, Nikola Tesla entre à l’école Polytechnique de Graz en 1875. Il y assimilera deux années d’études en un an seulement avant de quitter l’université faute d’argent. Il commence son travail d’ingénieur en 1881 pour l’Office du télégraphe à Budapest. À l’avènement du téléphone, il est promu chef électricien puis ingénieur-chef de la compagnie. On lui devrait le premier haut-parleur. En 1882, il vient travailler à Paris pour la société Continental Edison où il finit de mettre au point le premier moteur à induction. Il expérimente les résonateurs hautes fréquences entre 1899 et 1900 dans le but de créer une tour de télécommunications. Ce sont les fameuses bobines de Tesla.

Source: Wikipedia

Principe de fonctionnement du résonateur Tesla

L’objectif du résonateur Tesla est de produire des champs électriques intenses à haute fréquence. L’idée de Tesla repose sur deux principes fondamentaux:

• L’utilisation d’un transformateur
• L’utilisation de la résonance

Un transformateur électrique est chargé d’augmenter ou d’abaisser une tension électrique sinusoïdale en utilisant le couplage magnétique de deux bobines aux nombres de spires différents. Le rapport de transformation est alors donné par le rapport du nombre de spires de la bobine secondaire sur le nombre de spires de la bobine primaire. Le résonateur Tesla est un transformateur élévateur de tension comportant très peu de spires au primaire (une dizaine) et beaucoup plus au secondaire (plusieurs milliers).
L’idée de génie de Tesla fut d’utiliser ce transformateur à sa fréquence de résonance. Pour ce faire, il place un condensateur en série avec le primaire et un autre en série avec le secondaire. Les valeurs des condensateurs sont choisies pour que les deux circuits LC résonnent à la même fréquence.
La haute tension est alors produite par la décharge répétitive du condensateur dans la bobine primaire. Le transformateur entre en résonance (autour de 500kHz) et un très haut potentiel électrique apparait sur le condensateur secondaire.

Schéma d’un résonateur Tesla

On retrouve le condensateur primaire, les bobines primaire et secondaire, ainsi que le condensateur secondaire qui est en réalité soit un tore soit une sphère métallique. Un interrupteur est chargé de connecter périodiquement le condensateur primaire à la bobine primaire. Quand l’interrupteur conduit, le condensateur se décharge dans la bobine et le circuit primaire entre en résonance. Quand l’interrupteur est ouvert, le condensateur se charge à la tension d’alimentation du résonateur.

Particularité d’un résonateur à éclateur solide

Les bobines de Tesla conventionnelles sont alimentées en haute tension alternative (de l’ordre de 10kV). L’interrupteur du primaire doit donc être capable de commuter de très forts courants sous une tension de 10kV à la fréquence d’alimentation de la Tesla (50 Hz en France). Pour réaliser ma mini Tesla, j’ai choisi d’utiliser une alimentation 12V continue et de mettre un transistor MOS comme interrupteur primaire. Ceci présente plusieurs avantages, comme notamment la possibilité de régler la fréquence de commutation du MOS en jouant sur la fréquence du signal de grille.

Réalisation

La première chose à faire est de bobiner le secondaire. Assurez-vous au préalable d’avoir tout ce qu’il faut… Pour ma bobine secondaire, j’ai bobiné du fil de cuivre de 0.125mm de diamètre sur un tube de PVC de 32mm sur une longueur d’environ 10cm (le fil a cassé avant que j’atteigne mon objectif de 15cm…). Qu’à cela ne tienne, je poursuis ma réalisation!!!
Pensez bien à laisser suffisamment de mous au fil de cuivre de chaque côté de la bobine pour permettre les connexions électriques. Ensuite: la bobine primaire. Pour celle-là, rien de plus simple: quelques tours de fils de cuivre (celui que vous avez, pour moi du 0.75 mm²) sur un tronçon de PVC de plus grand diamètre que celui du secondaire et voilà! Ensuite, le condensateur secondaire. Le mien est une balle de ping-pong soigneusement recouverte de scotch aluminium.
Enfin: le circuit électronique de commande. Pour simplifier la réalisation, je génère la commande du MOS avec mon GBF, mais rien n’empêche de construire un petit oscillateur avec un 555 pour rendre votre réalisation parfaitement mobile. L’alimentation 12Vdc est tirée d’un vieille alimentation de PC (et alors 😉 ). Attention toutefois à ce que votre alimentation soit assez tolérante aux retours de hautes fréquences et aux courts-circuits! Le schéma n’a en sois rien de compliqué:

On retrouve le condensateur primaire connecté directement à la source, le PMOS intercalé entre le condensateur et la bobine du secondaire. Attention: le PMOS conduit quand la grille à un potentiel inférieur à Vcc – 5V et il est bloqué quand le potentiel de grille est égal à Vcc. Si vous avez un NMOS sous la main, n’hésitez surtout pas à modifier le schéma!

Les premiers essais

Après avoir relié l’alimentation, le signal de commande du MOS et relié le bas de la bobine secondaire à la masse, il ne reste plus qu’à mettre en route! Selon la fréquence du signal de commande, on peut isoler deux modes de fonctionnement:

Fréquences basses (de l’ordre du kHz): le résonateur fonctionne comme Tesla l’avait prévu: la capacité du primaire entre en résonance avec la bobine. J’ai réussi à produire des étincelles d’un petit millimètre. Assez décevant me direz-vous, mais ces fréquences sont audibles et l’on peut faire chanter la Tesla!

Fréquences élevées (environ 750 kHz): la capacité n’a plus le temps de se charger ou de se décharger et la bobine primaire entre directement en résonance avec la tension hachée fournie par le MOS. Cette fois, les étincelles atteignent facilement le centimètre.

Pour trouver la fréquence de résonances, il y a deux écoles: à l’oscilloscope (méthode « propre ») ou au tube fluo (méthode « amusante »). A l’oscilloscope, il suffit laisser la sonde posée négligemment sur le plan de travail à proximité de la Tesla pour observer les signaux HF rayonnés par la Tesla. Avec un tube fluo, c’est le même principe: il faut saisir le tube par une électrode et approcher l’autre de la Tesla. Le fluo devrait s’allumer. Ensuite, que vous utilisiez le fluo ou l’oscilloscope, il faut régler la fréquence de commande du MOS pour obtenir la plus grande amplitude de signal (à l’oscilloscope) ou la plus forte luminosité (au fluo).

NB: si vous n’avez pas de fluo, une ampoule à économie d’énergie (fluocompacte) ou même une simple LED feront l’affaire.

[metaslider id=482]

On peut remarquer la taille impressionnante du dissipateur thermique du MOS. Tous d’abord, je n’en avais pas d’autre (eh oui, ça joue…), ensuite, à basse fréquence, le courant circulant dans le MOS peut provoquer un échauffement très intense (mon premier MOS mourut ainsi dans d’atroces souffrances). Donc, ne négligez pas le refroidissement du MOS: un accident est vite arrivé!

Cet article Mini Bobine de Tesla 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.