L’accès à certaines fonctionnalités embarqués sur un avion de combat (navigation, systèmes d’armes, désignateur, …) passe par un écran multifonctions (MultiFunction Display). Bien que certains simulateurs proposent un cockpit cliquable, il est toujours embêtant de devoir orienter le champ de vision à chaque fois que l’on souhaite effectuer une action. Du coup, l’utilisation d’un périphérique matériel augmente l’immersion et améliore l’expérience de jeu.

Les solutions commerciales existantes (ThrustMaster Cougar Pack) ne m’ayant pas impressionné, j’ai décidé de concevoir un écran multifonction fonctionnant sur USB.

Le projet que je présente est conçu pour fonctionner avec DCS. Cependant, comme il utilise un écran HDMI et des contrôles type joystick, il n’y a pas de raisons pour que ça ne marche pas avec d’autres simulateurs.

Principes de fonctionnement

L’idée consiste à configurer DCS pour envoyer l’image des MFD gauche et droite sur deux écrans supplémentaires. Pour ce faire, il faut créer un fichier de configuration dans le dossier MonitorSetup du jeu et ajouter ces deux paramètres (il faut bien évidemment ajuster les offsets pour tomber dans les bons écrans) :

_  = function(p) return p; end;
name = _('MFD_Display');
Description = 'Config maison'
Viewports =
{
     Center =
     {
          x = 1920;
          y = 0;
          width  = 1920;
          height = 1080;
          viewDx = 0;
          viewDy = 0;
          aspect = 1.6;
     }
}

LEFT_MFCD =
{
    x = 1920*2+(1024/2-768/2);
    y = 0;
    width  = 768;
    height = 768;
}

RIGHT_MFCD =
{
    x = 1920*2+1024+(1024/2-768/2);
    y = 0;
    width  = 768;
    height = 768;
}

UIMainView = Viewports.Center
GU_MAIN_VIEWPORT = Viewports.Center

L’assignation des touches se fait simplement dans DCS, comme n’importe quel autre périphérique d’entrée.

Pour l’affichage, j’ai choisi un écran LCD 4:3 de 8 pouces. Il a une résolution de 1024×768 :

​​

Son prix et sa taille en font une solution intéressante : https://fr.aliexpress.com/item/32325920866.html?spm=a2g0s.9042311.0.0.d0dd6c37EdzyS4​

L’électronique

Conception

Pour simplifier l’intégration matérielle, j’ai choisi d’utiliser un petit microcontrôleur de chez Microchip capable de faire de l’USB et de l’I2C : le PIC18F25K50. Il communique avec 4 cartes filles qui s’occupent chacune de 7 boutons.

La séparation en plusieurs cartes répond à deux impératifs :

1. Rentrer dans une conception Autodesk EAGLE version gratuite
2. Diminuer les coûts de fabrication en réduisant la surface de circuit imprimé

La carte mère sera montée au dos du MFD :

Deux cartes en angle et deux cartes droites permettent de former un cadre autour de l’écran LCD :

​ ​

La carte mère

La carte mère du MFD se contente de faire le lien entre les différentes cartes filles (I2C) et le PC (USB). Le schéma est donc des plus simples, il reprend celui de la boite à boutons ou de l’interface HID, mais avec un composant différent :

​On retrouve une horloge, un circuit de reset, le connecteur USB, un connecteur pour l’I2C et un connecteur de programmation. Pour changer mes habitudes, j’ai réalisé mes cartes avec des composants à montage en surface (CMS) :

Les cartes filles

Bien que 2 formes différentes soient nécessaires, elles ont toutes le même schéma (à la différence de l’adresse). Il s’agit d’un multiplexeur 8 entrées tout ou rien vers I2C MCP23008. Les résistances de tirages sont intégrées dans la puce. Les cartes sont adressées par un pont à souder pour le bit de poids faible et câblé en dur à 1 pour les cartes en L (0 pour les cartes en I).

Deux connecteurs I2C permettent de former une chaine avec les 4 cartes. Un troisième permet de relier la carte mère sur l’une des cartes filles.

La configuration des boutons à bascules présents aux 4 coins du MFD oblige à avoir deux formes de cartes:

​

​

Les dimensions sont adaptées à la taille de l’écran de 8 pouces et au boitier imprimé en 3D dessiné tout spécialement.

Réalisation

J’ai sous-traité la fabrication des PCB (double couches) à NextPCB.

Les soudures des composants CMS sont réalisées au fer à souder, avec une panne fine. Pour rendre cela possible, j’ai choisi des boitiers SOIC (gros composants CMS, pas de 1.27mm) et des formats 0805 pour les résistances et condensateurs. Finalement, le composant le plus petit et le plus difficile à souder est la LED indiquant la mise sous tension.

NB : une bonne pince brucelles est nécessaire !

Intégration mécanique

J’ai fait découper au LASER des tôles d’inox pour réaliser les faces avant (https://www.metal-laser.com/). Le boitier plastique qui accueille ​les cartes filles ainsi que les différentes touches sont imprimés en 3D. La conception mécanique et l’intégration des cartes électroniques a été réalisée à l’aide Fusion 360. Cet outil permet de facilement faire converger les CAO électroniques et mécaniques.

Il est important de pouvoir vérifier la profondeur du boitier plastique, notamment pour que les boutons poussoirs tombent en dessous des touches plastiques.
​

L’écran LCD est fixé (scotché ou collé) à l’arrière du cadre. La face avant est également collée au boitier plastique.

Le logiciel

Une fois n’est pas coutume, le code du microcontrôleur a été écrit en C à l’aide de MikroC. Outre l’initialisation de la puce et le driver des multiplexeurs, la boucle principale se contente de lire les 4 ports d’entré sur l’I2C et d’envoyer le rapport USB HID.

/**
* Version IO Expander MCP23018
**/

#include "MCP23008.h"

#define USB_BUFFER_LEN       4
#define NB_MCP               4

unsigned char readbuff[USB_BUFFER_LEN] absolute 0x500;
unsigned char writebuff[USB_BUFFER_LEN] absolute 0x540;

int reset_mcp23017 = 1;

void interrupt() {
    USB_Interrupt_Proc();        // USB servicing is done inside the interrupt
    USBIF_bit = 0;
}

// define callback function
void I2C1_TimeoutCallback(char errorCode) {
   if (errorCode == _I2C_TIMEOUT_RD) {
     //LED0 = 1;
     // do something if timeout is caused during read
   }

   if (errorCode == _I2C_TIMEOUT_WR) {
     //LED1 = 1;
     // do something if timeout is caused during write
   }

   if (errorCode == _I2C_TIMEOUT_START) {
     //LED0 = 1;
     // do something if timeout is caused during start
   }

   if (errorCode == _I2C_TIMEOUT_REPEATED_START) {
     //LED1 = 1;
     // do something if timeout is caused during repeated start
   }
   
   reset_mcp23017 = 1;
}
          
void main() {
    int i = 0;
    int cpt = 0;
    
    uint16_t temp;

    ANSELA = 0;
    ANSELB = 0;
    ANSELC = 0;
    SLRCON = 0;

    ADCON1 |= 0x0F;                         // Configure all ports with analog function as digital
    CM1CON0 |= 7;                           // Disable comparators

    TRISB = 0xff;
    TRISB.f2 = 0;
    LATB.f2 = 1;

    I2C1_Init(400000);         // initialize I2C communication
    
    // set timeout period and callback function
    I2C1_SetTimeoutCallback(40000, I2C1_TimeoutCallback);

    reset_mcp23017 = 1;

    FSEN_bit = 1;
    UPUEN_bit = 1;
    HID_Enable(&readbuff,&writebuff);
    
    // Enable USB device interrupt
    IPEN_bit = 1;
    USBIP_bit = 1;
    USBIE_bit = 1;
    GIEH_bit = 1;

    while (1) {
        if (reset_mcp23017) {
           LATB.f2 = 0;       //RESET MCP23017
           Delay_ms(250);
           LATB.f2 = 1;
           Delay_ms(250);

           for (i=0; i<NB_MCP; i++) {
            MCPreset(i);
            Delay_ms(5);
           }
          reset_mcp23017 = 0;
        }

        memset(writebuff, 0x00, USB_BUFFER_LEN);
    
        for (i=0; i<NB_MCP; i++) {
          temp = MCPread(i, GPIO);
          writebuff[i] = ~temp;
          Delay_ms(5);
          if(reset_mcp23017) break;
        }
        
        HID_Write(writebuff, USB_BUFFER_LEN);
        Delay_ms(5);
    }
}

Le premier test

Un dock USB 3.1 peut servir pour gérer le HDMI et l’USB simultanément, ce qui permet d’avoir une unique prise USB occupée sur le PC. Si la configuration de DCS est correcte et que l’écran est bien détecté, voici le résultat que l’on peut obtenir :

La même chose en vidéo :

Conclusion

Il me reste encore à imprimer des touches propres et à finir l’état de surface de la face avant. Pour le reste, le rendu est vraiment sympa. Reste à tester réellement sur une session de pilotage plus longue.

Cet article Écran multifonction pour simulateur de vol (MFD) est apparu en premier sur Electronique et Informatique.

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.

Voici l’adresse du site web : http://leprototype.info/

Et la communauté Google+ : https://plus.google.com/communities/102420477003488972725

Le local est au 57 Faubourg Montmélian:

N’hésitez pas à vous renseigner !

Cet article Un FabLab à Chambéry ! 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.

Cependant, LabVIEW permet de faire bien plus. Une application embarquée va être amenée à fonctionner de manière autonome, dans un lieux potentiellement inaccessible. Il est alors indispensable que l’application soit téléchargée dans la cible et démarre automatiquement.

Déployer son application en mode autonome

Une fois le programme mis au point, il est possible de le déployer à demeure dans la cible. Un petit peu comme on flasherait une programme dans un microcontrôleur. Pour ce faire, il faut créer une spécification de construction de type Real Time Application (bien que cette dernière n’ai pas le déterminisme d’une vrai application RT, du fait des limitations du Raspberry Pi).

Un assistant de configuration s’ouvre. La première page vous permet de nommer votre application et de choisir dans quel dossier elle sera construite.

La section la plus importante est la suivante: Source Files. Elle permet entre autre de choisir le VI de démarrage. Il s’agit du premier VI lancé par le Run-Time au démarrage de l’application. Autrement dit, il s’agit du Main de l’application.

Une autre page intéressant est celle concernant les options avancées. On y trouve notamment la possibilité de compiler l’application en mode Debug, qui permet de connecter LabVIEW à l’application compilée pour la debugguer in situ.

Une fois la spécification de construction terminée, ne cliquez pas directement sur Build, mais plutôt sur OK. Enregistrez ensuite l’intégralité du projet. En effet, la configuration de la spécification de construction est sauvée dans le fichier .lvproj lui-même. La spécification apparait alors dans le projet. Il est possible de la compiler via le menu du clic droit en choisissant Build.

Une fenêtre faisant apparaitre la progression de la compilation s’ouvre:

Quand la compilation est terminée, cliquer sur Done.

A ce stade, l’application n’est pas encore dans le Raspberry Pi. LabVIEW a juste généré le fichier binaire exécutable. Pour télécharger l’application dans la cible et faire en sorte qu’elle démarre automatiquement à la mise sous tension, il fait repasser par le menu du clic droit et choisir Run as startup.

LabVIEW télécharge alors le binaire dans le Raspberry Pi et configure ce dernier pour le lancer au démarrage. Un popup apparait alors pour vous proposer de redémarrer la cible. Acceptez et votre application devrait se lancer an quelques dizaines de secondes.

Conclusion

Une application compilée sera plus économe en ressources systèmes. Elle peut démarrer automatiquement, sans le recours à LabVIEW pour lancer le code. Cependant, il n’y a plus d’interface graphique, donc certaines fonctions sont inopérantes: les popups, les message d’erreurs, … Il faut donc trouver d’autres solutions pour communiquer, mais cela sera l’objet d’un autre article.

Bon dév à tous !

Cet article LINX 3.0 – Déploiement d’une application LabVIEW sur Raspberry Pi est apparu en premier sur Electronique et Informatique.

http://wodric.com/

Bon vent 😉

Cet article Bienvenue sur la toile est apparu en premier sur Electronique et Informatique.