IMA4 2018/2019 P1 : Différence entre versions

De Wiki de Projets IMA
(→‎Présentation générale)
(→‎Documents Rendus)
 
(175 révisions intermédiaires par le même utilisateur non affichées)
Ligne 5 : Ligne 5 :
  
 
==Description==
 
==Description==
 +
L'objectif de ce projet est de concevoir et réaliser des manettes à base de micro-contrôleurs, pour des travaux pratiques GIS3 et IMA4.
 +
 +
Chaque manette devra utiliser un protocole de communication différent de l'autre.
 +
 
==Objectifs==
 
==Objectifs==
−
L'objectif de ce projet est de concevoir et réaliser des manettes à base de micro-contrôleurs, pour des travaux pratiques GIS3 et IMA4.
+
La première manette devra être conçue pour pouvoir communiquer via le protocole UDP.
 +
 
 +
La seconde, sera détectée par le PC comme un périphérique USB, plus précisément de type HID.
  
 
=Préparation du projet=
 
=Préparation du projet=
  
 
==Cahier des charges==
 
==Cahier des charges==
 +
Pour ce projet je peux me baser sur les travaux réalisés en épreuves complémentaires par d'autres étudiants.
 +
 +
Pour la première manette, M. Redon m'a informé que celle réalisée par mon prédécesseur n'était pas reconnue par le PC. Il m'a suggéré d'examiner en détail le composant responsable de la communication. J'ai donc reçu le fichier Fritzing de l'objet.
 +
 +
La seconde n'avait jamais été testé physiquement. Par conséquent il me faudra souder puis la tester afin de savoir si elle est fonctionnelle. Si nécessaire, des corrections seront apportées.
 +
 +
Chaque manette comportera 10 LEDS, qui serviront à indiquer le bon fonctionnement de l'objet. On trouvera également 5 boutons et 2 vibreurs.
 +
 +
J'ai choisi de programmer les LEDs pour que leur activité corresponde à un événement précis : pression d'un bouton, réception/envoi d'une trame de donnée...Les vibreurs seront déclenchés à chaque pression sur un bouton. Toute pression sur un bouton sera enregistrée pour être envoyée au PC, dans la prochaine trame de donnée.
 +
 +
 +
La première manette sera semblable à une Arduino Uno, avec un micro-contrôleur ATMega328p et un FTDI.
 +
Elle devra se comporter comme un périphérique IP. Grace à une communication série, en protocole UDP, il devra être possible de contrôler les LEDs situées sur la manette. Elle devra également être capable de renvoyer l'état des boutons, par sollicitation du PC.
 +
 +
Pour la seconde, une plateforme Arduino Leonardo et un micro-contrôleur ATMega16u2 seront utilisés.
 +
En utilisant la bibliothèque LUFA, il sera possible de la programmer pour qu'elle corresponde à un périphérique USB. J'ai déjà utilisé cette dernière, lors d'un tutorat durant le semestre 7.
 +
 
==Choix techniques : matériel et logiciel==
 
==Choix techniques : matériel et logiciel==
 +
Pour ce projet, il m'est possible de me baser sur les réalisations d'autres élèves, dans le cadre d'épreuves complémentaires.
 +
Je réutiliserai donc leur matériel, auquel j'ajouterai le mien, dans le cas où des modifications doivent êtres apportées.
 +
 +
Liste du matériel :
 +
{| class="wikitable"
 +
!'''Manette 16u2'''!!'''Manette 328p
 +
|-
 +
| LED rouge x12
 +
| LED rouge x12
 +
|- 
 +
|Résistance 10kOhm x6
 +
|Résistance 10kOhm x6
 +
|-
 +
| Varistances x2 
 +
|
 +
|-
 +
|  Résistance 22Ohm x2
 +
|
 +
|- 
 +
|  Résistance 220Ohm x12
 +
|  Résistance 220Ohm x12
 +
|- 
 +
|  Résistance 1kOhm x2
 +
|  Résistance 1kOhm x4
 +
|- 
 +
|  Résistance 1MOhm x1
 +
|  Résistance 1MOhm x1
 +
|- 
 +
|  Capacité 100nF x1
 +
|  Capacité 100nF x 6
 +
|- 
 +
|  Capacité 22pF x2
 +
|  Capacité 22pF x2
 +
|- 
 +
|  Capacité 1µF x1
 +
|- 
 +
|  XTAL 16MHz x1
 +
|  XTAL 16MHz x1
 +
|- 
 +
|  Transistor Bipolaire NPN x2
 +
|  Transistor Bipolaire NPN x2
 +
|- 
 +
|  Diode Melf DO-213 x4
 +
|  Diode Melf DO-213 x2
 +
|- 
 +
|  Sparkfun isp header 6 broches x1
 +
|  Sparkfun isp header 6 broches x1
 +
|- 
 +
|  Switch boitier THT x5
 +
|  Switch boitier SMD x5
 +
|- 
 +
|  Switch boitier smd x1
 +
|  Switch boitier smd x1
 +
|- 
 +
| USB-miniB-smd-ns x 1
 +
| USB-miniB-smd-ns x 1
 +
|- 
 +
| Vibreur (Sparkfun motor) x2
 +
| Vibreur (Sparkfun motor) x2
 +
|- 
 +
| Atmega 16u2 x1
 +
| Atmega 328p x1
 +
|}
 +
 
==Liste des tâches à effectuer==
 
==Liste des tâches à effectuer==
 +
Comme je l'ai expliqué plus haut, j'ai à ma disposition les projets réalisés par d'autres étudiants en épreuve complémentaire.
 +
Cependant, une phase de test sur les PCB doit être effectuée, afin de vérifier leur bon fonctionnement.
 +
 +
Après avoir discuté avec M. Redon, celui ci m'a indiqué que la manette FTDI n'était pas fonctionnelle. En effet, le FTDI n'est pas connecté correctement, ce qui fait que la manette n'arrive pas à communiquer avec le PC.
 +
J'ai donc prévu de corriger le PCB, en me basant sur la datasheet du FTDI (modèle FT232BL), afin de résoudre le problème.
 +
De plus, certaines LEDs ne sont pas correctement connectées au micro-contrôleur. Il faudra également que je corrige ce point sur le PCB.
 +
 +
La manette 16u2 n'avait pas été testée l'année précédente. Par conséquent, il me faudra vérifier son bon fonctionnement, pour ensuite apporter des modifications si nécessaire.
 +
 +
Une fois les deux manettes corrigées, je passerai à la programmation. Je commencerai par la manette FTDI, afin que celle-ci puisse communiquer en UDP avec le PC.
 +
 +
Puis je terminerai par programmer la manette 16u2, afin quelle puisse communiquer en me basant sur la bibliothèque LUFA.
 +
 
==Calendrier prévisionnel==
 
==Calendrier prévisionnel==
 +
Les trois premières semaines seront consacrés aux tests, et corrections, des PCB crées lors des épreuves complémentaires.
 +
 +
Pour les semaines qui suivront, l'attention sera portée sur la manette FTDI, afin quelle se comporte comme un périphérique IP.
 +
 +
Enfin je me consacrerai à la deuxième manette, pour qu'elle soit détectée en tant que périphérique USB par le PC.
  
 
=Réalisation du Projet=
 
=Réalisation du Projet=
Ligne 19 : Ligne 124 :
  
 
{| class="wikitable"
 
{| class="wikitable"
−
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
+
!Tâche !! Prélude S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S6 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures S11 !! Heures S12 !! Heures S13 !! Total
 +
|-
 +
|Analyse du projet
 +
|3h
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|3h
 +
|-
 +
|'''Manette 1 : 328P'''
 
|-
 
|-
−
| Analyse du projet
+
|1 - PCB
−
| 0
 
 
|  
 
|  
 +
|9h
 +
|3h
 
|
 
|
 
|
 
|
Ligne 29 : Ligne 153 :
 
|
 
|
 
|
 
|
 +
|5h30
 +
|4h
 +
|3h
 
|
 
|
 +
|3h
 +
|27h30
 +
|-
 +
|2 - Programme manette
 +
|
 
|
 
|
 
|
 
|
 +
|8h
 +
|14h
 
|
 
|
 
|
 
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|22h
 +
|-
 +
|3 - Programme PC
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|3h
 +
|18h
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|21h
 +
|-
 +
|'''Manette 2 : 16u2'''
 +
|-
 +
|1 - PCB
 +
|
 +
|
 +
|6h
 +
|
 +
|
 +
|3h
 +
|
 +
|
 +
|4h
 +
|
 +
|
 +
|
 +
|
 +
|13h
 +
|-
 +
|2 - Programme manette
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|6h
 +
|6h30
 +
|6h
 +
|8h
 +
|16h
 +
|
 +
|42h30
 +
|-
 +
|3 - Programme PC
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|3h
 +
|8h
 +
|
 +
|
 +
|11h
 +
|-
 +
|'''Autres'''
 +
|-
 +
|1 - Gestion du Wiki
 +
|
 +
|2h
 +
|3h
 +
|1h
 +
|1h
 +
|1h
 +
|1h
 +
|1h
 +
|1h
 +
|1h
 +
|1h
 +
|1h
 +
|5mins
 +
|14h05
 +
|-
 +
|'''TOTAL'''
 +
|'''3h'''
 +
|'''11h'''
 +
|'''12h'''
 +
|'''9h'''
 +
|'''15h'''
 +
|'''7h'''
 +
|'''19h'''
 +
|'''7h'''
 +
|'''17h'''
 +
|'''14h'''
 +
|'''20h'''
 +
|'''17h'''
 +
|'''3h05'''
 +
|'''154h05'''
 +
|-
 +
 
|}
 
|}
  
 +
==Prologue==
 +
==Planning==
 +
[[Fichier:QBS_planning_V2.9.jpg|vignette|upright=3.5|center|Planning (V2.9) de réalisation du projet]]
 +
 +
==Semaine 1 - 17/09 au 21/09==
 +
 +
Analyse et appropriation du sujet
 +
 +
 +
==Semaine 2 - 24/09 au 29/09 ==
 +
'''Manette 1 - 328p'''
 +
 +
*'''Réalisé'''
 +
 +
Pour cette semaine, je me suis concentré sur la correction des erreurs dans le PCB de la manette FTDI.
 +
En comparant avec la datasheet, j'ai constaté que plusieurs éléments manquaient, notamment des résistances.
 +
 +
En examinant le PCB, j'ai aussi observé que les PINs RX et TX du FTDI étaient reliés, respectivement, aux PINs RX et TX du micro-contrôleur.
 +
Cette erreur est de loin la plus importante, puisque la communication entre le FTDI et l'atmega ne peut pas s'effectuer correctement.
 +
 +
== Semaine 3 - 1/10 au 5/10==
 +
'''Manette 1 - 328p'''
 +
 +
*'''Réalisé'''
 +
 +
J’ai terminé le routage de la manette.
 +
 +
Avec l’aide de M. Redon, j’ai pu corriger les problèmes que j’ai rencontrés. Il s’agissait notamment de fils volants, dont j’ignorais l’origine et que je n’arrivais pas à supprimer, sans provoquer de nouvelles erreurs.
 +
 +
*'''Difficultés rencontrées'''
 +
 +
Fritzing : problèmes de raccordements de composants. Vu avec M. Redon (cf ci-dessus).
 +
 +
*'''Prochaines actions semaine 3'''
 +
 +
Démarrer la programmation de la manette.
 +
 +
Contacter M. Redon afin de faire imprimer la manette 328p.
 +
 +
Je vais également voir, si je peux obtenir une plaque Arduino utilisée par les GIS et IMA lors de leurs TPs. Ainsi je pourrai tester mes programmes, sans devoir attendre la fabrication de mes manettes.
 +
 +
'''Manette 2 - 16u2'''
 +
 +
*'''Réalisé'''
 +
 +
En voulant souder les composants à ma disposition sur la manette, je me suis rendu compte que la version du schéma de routage et la manette à ma disposition ne correspondent pas. Le fichier du schéma est en version 5. La manette est fabriquée selon une version au 7, elle-même modifiée.
 +
 +
Pour cette raison, il me manque certains composants, que je n’ai pas commandés auprès de M. Redon. Je l’ai donc prévenu avant qu’il ne valide les commandes de matériel.
 +
 +
J’ai soudé quelques composants, qui sont communs aux deux versions : le connecteur USB, le Quartz et les capacités nécessaires au Quartz.
 +
 +
*'''Difficultés rencontrées'''
 +
 +
Différences entre la manette et le schéma de routage, donc manque de composants.
 +
 +
*'''Prochaines actions semaine 3'''
 +
 +
Comme pour la manette 1, essayer d’obtenir une plaque Arduino utilisée par les GIS et IMA lors de leurs TPs.
 +
 +
==Semaine 4 - 8/10 au 12/10==
 +
 +
'''Manette 1 - 328p'''
 +
 +
*'''Réalisé'''
 +
J’ai principalement travaillé sur le programme de la manette et plus précisément les points suivants :
 +
* Définition des entrées/sorties des différents ports
 +
* Acquisition des états des boutons
 +
* Construction de la trame IP-UDP, dont le calcul des checksums
 +
* Envoi de la trame
 +
 +
Vendredi : M. Redon m’a contacté pour que j'apporte des modifications au PCB.
 +
 +
*'''Difficultés rencontrées'''
 +
Le planning tenait compte d’un délai de fabrication de 2 semaines à partir du lundi. Il ne pourra pas être respecté pour la manette 1.
 +
 +
*'''Prochaines actions semaine 4'''
 +
Terminer le calcul du checksum UDP
 +
 +
Programmer la lecture des trames reçues par le PC
 +
 +
'''Manette 2 - 16u2'''
 +
 +
*'''Réalisé'''
 +
Comme annoncé dans le planning, pas d’avancement cette semaine.
 +
 +
*'''Prochaines actions semaine 4'''
 +
Pas d'action prévue.
 +
 +
== Semaine 5 - 15/10 au 19/10==
 +
'''Manette 1 - 328p'''
 +
 +
*'''Réalisé'''
 +
 +
M. Redon a envoyé la commande pour mon PCB.
 +
 +
 +
'''Programmation'''
 +
 +
Lors de la semaine 3, j’avais annoncé me concentrer sur les checksums UDP et IP. J’avais également parlé de la gestion des trames reçues par le PC.
 +
 +
Dans le cas du checksum UDP, j’ai demandé de l’aide à M. Vantroy, car un des paramètres nécessaires au calcul n’était pas très clair pour moi. Une fois ce problème résolu, j’ai pu terminer le calcul sans problème.
 +
 +
Lorsqu’une trame est reçue par la manette, celle-ci va vérifier si les checksums sont cohérents avec ceux annoncés par la trame. Si c’est le cas, suivant la demande reçue, la manette renverra l’état des boutons, des LEDs et/ou des vibreurs.
 +
 +
J’ai également travaillé sur la gestion des LEDs et apporté différentes corrections sur les fonctions liées aux boutons. En effet, ma commande déterminant si un bouton est activé, ou non, renvoyait le résultat inverse. J’ai rapidement corrigé ce problème.
 +
 +
Grâce à toutes ces corrections et nouvelles fonctions, j’ai pu terminer le programme de la manette 1. Voir dans Documents Rendus "Manette1.zip".
 +
 +
 +
'''Test programme'''
 +
 +
Grâce à une Arduino, fournie par M. Redon, j’ai pu vérifier que le programme envoie des données conformes à mes attentes.
 +
 +
 +
*'''Difficultés rencontrées'''
 +
 +
Pour calculer le checksum UDP il faut prendre en compte l’adresse IP source, de destination, le protocole IP et la longueur du datagrame (en octet). C’est ce dernier paramètre qui m’a posé problème. Après avoir discuté avec M. Vantroy, j’ai compris qu’il s’agissait de la longueur de la partie UDP : en-tête + données.
 +
 +
L’erreur sur la gestion des boutons était très subtile. Voir ci-dessous.
 +
 +
  return ((PINB & entree)!=0)?1:0;  Bonne version
 +
  return ((PINB & entree)!=0)?0:1;  Mauvaise version
 +
 +
 +
*'''Prochaines actions semaine 5'''
 +
 +
Le programme de la manette 1 fini, je vais maintenant écrire le programme PC, afin de permettre l’envoi et la lecture de données provenant du port série.
 +
 +
 +
'''Manette 2 - 16u2'''
 +
 +
*'''Réalisé'''
 +
 +
Nous avons reçu les différents composants attendus pour souder la manette.
 +
 +
*'''Prochaines actions semaine 5'''
 +
 +
Réalisation du soudage de la manette.
 +
 +
Vérification de la détection de la manette par le PC.
 +
 +
== Semaine 6 - 22 au 26/10 ==
 +
'''Manette 1 - 328p'''
 +
 +
*'''Réalisé'''
 +
 +
J’ai reçu le PCB et les composants ce qui me permettra de les souder dès que possible.
 +
 +
 +
'''Programmation'''
 +
 +
J’ai commencé l’écriture du programme PC, notamment sur l’ouverture du port USB afin de lire les données envoyées par la manette.
 +
 +
    fd = open("/dev/ttyACM0",O_RDWR | O_NOCTTY);
 +
 +
Grâce à cette fonction, il m’est possible d’avoir accès au port USB correspondant à ma manette.
 +
 +
O_RDWR me permet d’avoir un accès en lecture et en écriture.
 +
 +
Les fonctions read() et write() me permettront ainsi de recevoir et d’envoyer des trames de données à la manette.
 +
 +
Le programme PC reprendra beaucoup de fonctions que j’ai utilisées dans le programme de la manette. Notamment celles calculant les checksums IP et UDP.
 +
 +
'''Test programme'''
 +
 +
Pour l’instant je n’ai pu que tester si mon programme détecte bien la manette lorsqu'elle est branchée. Le résultat est positif.
 +
 +
*'''Prochaines actions semaine 6'''
 +
 +
L’ensemble du temps sera consacré au programme PC. Il me faudra traiter la communication entre PC et manette, ainsi que l’extraction et analyse des données reçues.
 +
 +
'''Manette 2 - 16u2'''
 +
 +
*'''Réalisé'''
 +
 +
J’ai soudé cette manette, grâce aux conseils de M. Flamen. Je n’ai malheureusement pas pu la tester tout de suite. Certains composants, essentiels au bon fonctionnement, doivent être ressoudés car la première soudure n’est pas très satisfaisante.
 +
 +
*'''Difficultés rencontrées'''
 +
 +
Pour souder mon PCB je dois appliquer une pâte, puis placer mes composants et enfin passer le tout au four. Mais sur certains je pense en avoir mis trop. Je corrigerai ce problème après la semaine des vacances, M. Flamen étant absent.
 +
 +
*'''Prochaines actions semaine 6'''
 +
 +
Pas d’action n’est prévue pour cette manette en semaine 6. La priorité va à la manette 1.
 +
 +
 +
 +
'''Faits marquants'''
 +
 +
La soutenance mi-parcours a eu lieu vendredi.
 +
 +
== Semaine 7 – 29/10 au 2/11 ==
 +
'''Manette 1 - 328p'''
 +
 +
*'''Réalisé'''
 +
 +
La programmation du PC, pour la communication avec la manette, a été mon sujet de la semaine.
 +
 +
J'ai également révisé mon planning.
 +
 +
'''Programmation'''
 +
 +
Le programme du PC doit permettre plusieurs choses : échanger des données avec la manette, analyser ces données et les afficher pour l’utilisateur.
 +
 +
Pour communiquer je dispose de deux trames : mess_recu, qui permet de stocker les datas reçues par la manette, et mess_emi qui sera envoyée à la manette.
 +
 +
La communication se fait grâce à trois fonctions :
 +
 +
*open() : pour accéder au port USB et définir le type de communication. Les options sur cette fonction me permettent de limiter le risque d’erreurs. O_NONBLOCK et O_NDELAY permet d’ouvrir le fichier en mode non bloquant. O_RDWR permet de lire et d’écrire dans le fichier. Enfin O_NOCTTY détache le processus du terminal.
 +
 +
*read() : lecture des données écrites sur le port.
 +
 +
*write() : écriture des données sur le port. Un seul appel de cette fonction peut me permettre d’envoyer toute la trame de donnée. 
 +
 +
Au début mes fonctions fonctionnaient selon ce principe : si X envoie un message à Y, le message est forcément bien reçu et on peut continuer le reste du programme. Cet aspect n’étant pas très réaliste, j’ai modifié mes programmes pour qu’ils permettent l’envoi d’un accusé de réception.
 +
 +
Ce message n’est envoyé que dans le cas où la trame reçue est correcte : bonnes adresses source et destination et un calcul des checksums identique entre le PC et la manette. Ainsi le risque d’erreur dû à une mauvaise lecture des données est diminué.
 +
 +
Si un accusé de réception indiquant une mauvaise trame est reçu, l’émetteur renverra une nouvelle trame de donnée. Le PC et la manette ne peuvent pas continuer leurs programmes tant qu’ils n'ont pas reçus un accusé de validation.
 +
 +
L’objectif du programme PC est d’afficher les états des boutons, LEDs et vibreurs de la manette. Les données à afficher sont au choix de l’utilisateur.
 +
 +
Si l’utilisateur choisit d’afficher une donnée précise, ou toutes, le PC envoie une requête à la manette. Celle-ci répondra à la demande en envoyant une trame contenant la réponse associée à la requête.
 +
 +
La réponse reçue, le PC extrait les informations de la trame et les affiche, grâce aux fonctions affichage_etat_LEDs(), affichage_etat_boutons() et affichage_etat_vibreurs().
 +
 +
'''Problèmes rencontrés'''
 +
 +
En écrivant mes fonctions d’analyse des données reçues, je me suis demandé si mess_recu serait bien rempli par la fonction read().
 +
 +
La fonction send_serial() de la manette ne peut envoyer que caractère par caractère. Par conséquent, je pense que read() ne permettrait pas de charger mess_recu en un seul appel. J’ai donc modifié mon programme pour éviter ce problème.
 +
 +
'''Test programme'''
 +
 +
Pour l’instant aucun test n’a été effectué concernant le programme PC.
 +
 +
*'''Prochaines actions semaine 6'''
 +
 +
Une séance sera consacrée à la soudure de la manette, avec les composants reçus. Je contacterai M. Flamen afin d’avoir accès à la salle.
 +
 +
Cette carte sera ensuite testée. Si le PC ne la détecte pas en erreur, c’est que la manette peut être utilisée.
 +
 +
Une fois ce test effectué, je réaliserai un test sur l’ensemble des objectifs de cette manette. Je vérifierai que le PC et la manette communiquent correctement. Si l’affichage des données est conforme à l’état de la manette. Si ce test est un succès, je pourrai consacrer tout le reste de mon temps à la manette 2.
 +
 +
 +
'''Manette 2 - 16u2'''
 +
 +
*'''Réalisé'''
 +
 +
Comme annoncé dans le planning, aucune activité n’a été réalisée sur cette manette.
 +
 +
*'''Prochaines actions semaine 7'''
 +
 +
Je commencerai le programme de la manette
 +
 +
== Semaine 8 – 5/11 au 9/11 ==
 +
 +
Mise à jour du planning, version 2.4.
 +
 +
 +
'''Manette 1 - 328p'''
 +
 +
*'''Réalisé'''
 +
 +
Pas d’avancement cette semaine. Elle devait être consacrée à la soudure et aux tests des différents programmes.
 +
 +
Malheureusement l’emploi du temps de M. Flamen, et le mien, n’ont pas permis de trouver un créneau horaire possible. Je n’ai donc pas pu souder les composants.
 +
 +
 +
*'''Prochaines actions semaine 8'''
 +
 +
Les soudures de la manette n’ayant pas été faites, j’ai contacté M. Flamen afin de réserver un créneau. Elles seront faites le mercredi 14/11 ou le jeudi 15/11.
 +
 +
 +
'''Manette 2 - 16u2'''
 +
 +
*'''Réalisé'''
 +
 +
Cette semaine a été consacrée à l’étude et la compréhension des bibliothèques LUFA.
 +
 +
La manette doit se comporter comme un périphérique USB de type HID. La bibliothèque LUFA contient tous les programmes permettant d’atteindre cet objectif.
 +
 +
Je l’ai donc téléchargée et j’en ai étudié le fonctionnement. Je pense avoir déterminé toutes les fonctions qui seront nécessaires.
 +
 +
LUFA est complexe, je n’ai donc pas encore compris toutes les fonctions, mais j’en ai compris suffisamment pour savoir lesquelles seront nécessaires au bon fonctionnement du matériel.
 +
 +
Lors d’une communication le PC (hôte) envoie des rapports à la manette (device).
 +
 +
Dans les fichiers téléchargés se trouvent des démos. J’adapterai leur programme, afin qu’il corresponde à mes besoins, notamment sur la longueur des rapports.
 +
 +
*'''Prochaines actions semaine 8'''
 +
 +
Dans un premier temps, j’effectuerai les soudures de la manette. Si mon emploi du temps le permet, je commencerai la programmation de la manette.
 +
 +
== Semaine 9 – 12/11 au 16/11 ==
 +
 +
Mise à jour du planning, version 2.6
 +
 +
'''Manette 1 - 328p'''
 +
 +
*'''Réalisé et problèmes rencontrés'''
 +
 +
Les soudures ont été réalisées cette semaine, le mercredi 14/11.
 +
 +
Malheureusement, la manette n’était pas détectée par le PC. Lors de deux séances le jeudi 15/11 et le vendredi 16/11, j’ai vérifié les différents composants (valeurs, connexions …). Mais je n’ai pas trouvé la source du problème.
 +
 +
J’ai revérifié que le FT232BL est bien connecté ainsi que le microcontrôleur. Ils ne présentent aucun problème, et leurs pins sont bien reliés aux bons composants.
 +
 +
Risque fort : Il pourrait s’agir d’un problème de composants défaillants.
 +
 +
*'''Prochaines actions semaine 9'''
 +
 +
J’essaierai de résoudre le problème de détection de cette manette.
 +
 +
Quand il sera résolu, je passerai aux tests des différents programmes que j’avais réalisés avant la fin des vacances.
 +
 +
'''Manette 2 - 16u2'''
 +
 +
*'''Réalisé'''
 +
 +
'''Soudure'''
 +
 +
Les soudures ont été réalisées cette semaine, le mercredi 14/11.
 +
 +
Cependant la manette n’était pas détectée par mon PC. J’ai donc réalisé différents tests afin de déterminer où se trouvait le problème, le jeudi 15/11.
 +
 +
Après avoir vérifié tous les composants (valeur, position, connexions …), j’ai réexaminé le schéma électrique de ma manette.
 +
 +
J’ai alors constaté que trois composants étaient susceptibles de provoquer le problème. Ils ont donc été dessoudés.
 +
 +
Le PC a reconnu ma manette, comme étant un atmega16u2 DFU (voir image ci-dessous).
 +
 +
[[Fichier:Détection PC.jpg|vignette|upright=1|center|Détection de la manette par mon PC]]
 +
 +
Afin que les futures cartes ne présentent plus ce problème, j’ai modifié le schéma électrique et supprimé les composants responsables du problème. La manette fonctionnera sans ces composants.
 +
 +
[[Fichier:Version_incorrecte.jpg|vignette|upright=1|center|Ancienne version du schéma électrique]]
 +
 +
[[Fichier:Version_correcte.jpg|vignette|upright=1|center|Nouvelle version du schéma]]
 +
 +
 +
La manette fonctionnant correctement, je peux maintenant me concentrer sur sa programmation.
 +
 +
'''Programmation'''
 +
 +
Cette semaine j’ai continué mes recherches sur le fonctionnement de la bibliothèque LUFA. Principalement sur le programme de la manette.
 +
 +
Je pense pouvoir me baser sur une des démos fournies, et je dois déterminer comment adapter ce programme à mon projet.
 +
 +
*'''Prochaines actions semaine 9'''
 +
 +
Continuer les recherches sur la bibliothèque LUFA, et commencer la programmation de la manette.
 +
 +
== Semaine 10 – 19/11 au 23/11 ==
 +
 +
Mise à jour du planning, version 2.7
 +
 +
'''Manette 1 - 328p'''
 +
 +
*'''Réalisé et problèmes rencontrés'''
 +
Après plusieurs passages à l’atelier et avec l’assistance de M. Flamen, voici le compte-rendu de nos tentatives pour déterminer ce qui ne fonctionne pas.
 +
 +
Ce qui a été testé :
 +
 +
- Que les vias (traversant) étaient corrects (OK)
 +
 +
- Que le dessous du FTDI et de l’Atmega ne conduisent pas, provoquant des courts circuits (OK)
 +
 +
- Que la tension 5V arrive bien sur les pins concernés (OK)
 +
 +
- Que le quartz fonctionne correctement (NOK)
 +
 +
o Aucune tension détectée aux bornes de ce composant
 +
 +
o La valeur de la résistance à ses bornes est deux fois trop grande (2Mohm au lieu de 1Mohm)
 +
 +
o Un remplacement a été effectué, sans succès
 +
 +
o Comparaison avec le schéma de la manette 16u2 pour les connexions. Celles-ci sont identiques
 +
 +
- Que la tension envoyée par le PC via le câble est correcte (OK)
 +
 +
- Vérification du schéma électrique par M. Flamen, pas d’incohérences (OK)
 +
 +
- Contrôle de toutes les liaisons entre les différents composants (OK)
 +
 +
 +
Raisons possibles de l’échec :
 +
 +
- Un des composants a grillé dans le four
 +
 +
- L’électricité statique peut avoir grillé un composant (contact avec un objet chargé : peau, vêtement, table…)
 +
 +
- Mise en doute par M. Flamen du connecteur USB. Il pourrait ne pas fonctionner correctement
 +
 +
 +
Une seule solution est envisageable :
 +
 +
- Ressouder complétement un nouveau PCB, MAIS la méthode de soudure (via le four) présente un risque non négligeable d’endommager les composants.
 +
 +
Une autre possibilité aurait été de ressouder à la main un par un les composants et les tester au fur et à mesure. Elle est irréalisable car certains pins sont trop petits.
 +
 +
*'''Prochaines actions semaine 10'''
 +
Une nouvelle séance de soudure a été prévue. J’utiliserai une carte non soudée et des composants neufs qui m’ont été remis.
 +
 +
 +
'''Manette 2 - 16u2'''
 +
 +
*'''Réalisé'''
 +
 +
'''Programmation'''
 +
 +
Mes séances ont été consacrées à la recherche d’informations sur la bibliothèque LUFA.
 +
 +
Elle est complexe, car elle contient de nombreux fichiers et programmes.
 +
Je pense avoir trouvé quel programme modifier pour la manette. Je dois identifier celui du PC.
 +
 +
*'''Prochaines actions semaine 10'''
 +
 +
Confirmer que les informations trouvées sur le programme manette sont correctes et continuer à chercher le programme PC.
 +
 +
== Semaine 10 – 26/11 au 30/11 ==
 +
 +
Mise à jour du planning, version 2.8
 +
 +
'''Manette 1 - 328p'''
 +
 +
*'''Réalisé et problèmes rencontrés'''
 +
 +
Mercredi 28/11 : soudage d'une deuxième manette. Aucune détection par le PC.
 +
 +
En examinant le PCB, je me suis rendu compte que certains éléments n’étaient pas reliés correctement à la masse et au VCC. Le PCB correspond au plan de conception. Il n'y a pas d'erreur de fabrication. Ce plan est donc faux. Mais Fritzing n'a pas généré d'erreur.
 +
 +
Avec M. Flamen, nous avons tenté de relier les composants mal connectés en soudant quelques fils supplémentaires.
 +
 +
Cela n’a rien changé et la manette n’est toujours pas détectée par l’ordinateur.
 +
 +
*'''Prochaines actions '''
 +
 +
Reprendre l'étude de la carte dans Fritzing. Il s'agira de déterminer les erreurs et apporter les corrections.
 +
 +
Selon le temps qu'il me restera avant le 19/12, date de fin du projet, j'irai le plus loin possible dans la réalisation de cette manette.
 +
 +
Mais je traiterai en priorité la manette 16u2 car elle peut aboutir.
 +
 +
 +
'''Manette 2 - 16u2'''
 +
 +
*'''Réalisé'''
  
−
==Prologue==
+
'''Programme Manette'''
−
==Semaine 1==
+
 
−
==Semaine 2==
+
Grâce aux recherches que j’ai effectuées, j’ai réussi à comprendre quelle partie du programme fourni en exemple je dois modifier.
 +
 
 +
 
 +
Lorsque la manette doit envoyer un message, elle charge les données dans un buffer. Dans l’exemple, ce buffer est chargé avec une série de chiffres.
 +
 
 +
J’ai donc modifié le programme pour qu’il charge ce buffer avec mes données. L’état des 5 boutons et l’état des LEDs.
 +
 
 +
L'état des composants est vérifié avant chaque envoi de message.
 +
 
 +
 
 +
J’ai écrit dans le programme les différentes fonctions utiles à mon projet :
 +
 
 +
1) 'test_entree' qui permet de savoir si un pin est à l’état haut ou bas.
 +
 
 +
2) 'allume_eteindre_led' sert à allumer ou à éteindre une LED. Ce programme vérifie si toujours si la LED n’est pas déjà dans l’état souhaité.
 +
 
 +
3) 'analyse_mess' si le PC demande l’envoi d’un nouveau message cette fonction déclenche l’envoi. Si le PC demande de changer l’état d’une LED, 'allume_eteindre_led' est utilisée.
 +
 
 +
 
 +
Les messages envoyés par la manette ont le format suivant :
 +
 
 +
Message de 16bits : 5 bits de poids fort état des boutons + 11 bits état des LEDs
 +
 
 +
Ils sont envoyés toutes les 3 à 4 secondes. Mais si un message du PC le demande, un nouvel envoi aura lieu.
 +
 
 +
 
 +
'''PC'''
 +
 
 +
Comme pour mon programme manette j’ai pu, grâce à mes recherches, déterminer qu’elles sont les points à modifier. J’ai aussi ajouté mes propres fonctions pour mon projet.
 +
 
 +
 
 +
Dans le cas de l’exemple il n’y a qu’un seul échange entre la manette et le PC. Le programme se termine dès qu’un objet correspondant aux VENDOR_ID et PRODUCT_ID a répondu.
 +
 
 +
J’ai donc mis en place une boucle while, qui se termine lorsque l’utilisateur le décide.
 +
 
 +
 
 +
Dans le programme exemple fourni, les données envoyées correspondent à des états de LEDs, mais leur gestion est différente de la mienne. J’ai donc modifié ce point.
 +
 
 +
Le PC peut envoyer deux messages :
 +
 
 +
- demander l’envoi de l’état de la manette : 1er bit de poids fort à 1
 +
 
 +
- allumer/éteindre une LED : 1er bit de poids fort à 0. Les autres bits indiquent l’état souhaité sur les différentes LEDs.
 +
 
 +
 
 +
Le message envoyé dépend du choix de l’utilisateur.
 +
 
 +
J’ai également écrit une fonction affichant l’état des boutons et des LEDs.
 +
 
 +
A ce stade du projet, ces programmes sont écrits. L'étape suivante sera de les tester.
 +
 
 +
 
 +
*'''Difficultés rencontrées'''
 +
 
 +
La manette est très proche de l’arduino que nous avions utilisée lors d’un tutorat en IMA4.
 +
 
 +
Afin de télécharger mon programme manette, j’ai donc repris le tutoriel fourni par M. Redon. Mais il n’a pas fonctionné avec ma manette.
 +
 
 +
C'est pourquoi, j'en ai informé M. Redon de mon problème. Il m’a renvoyé sur un tutoriel qui m’a permis d’installer le logiciel Flip3.4.7.
 +
 
 +
Le téléchargement a pu être fait. Comme l'installation n'est pas immédiate, car la manette ne communique pas correctement avec le PC. Je décris la procédure de reconnaissance de la manette dans le fichier joint à mon Wiki : "IMA4 P1 Connexion manette PC.pdf"
 +
 
 +
 
 +
*'''Prochaines actions semaine 11'''
 +
 
 +
Tester mes différents programmes.
 +
 
 +
== Semaine 12 – 3/12 au 7/12 ==
 +
 
 +
Mise à jour du planning, version 2.9
 +
 
 +
'''Manette 1 - 328p'''
 +
 
 +
Comme annoncé l’attention a été portée sur la manette 2. Par conséquent, je n’ai pas travaillé sur la manette 1.
 +
 
 +
*'''Prochaines actions '''
 +
 
 +
Reprendre le schéma électrique de la manette et la datasheet des composants pour déterminer une éventuelle erreur.
 +
 
 +
 
 +
'''Manette 2 - 16u2'''
 +
 
 +
*'''Réalisé'''
 +
 
 +
'''Communication avec le PC en utilisant les bibliothèques LUFA'''
 +
 
 +
Comme annoncé la semaine précédente, j’ai réalisé différents tests des programmes que j’ai écrits.
 +
 
 +
Ces tests avaient pour objectif de déterminer si mes modifications dans les fonctions de la bibliothèque LUFA étaient correctes et n’entrainaient pas d’erreur. Il fallait aussi que je vérifie si mes propres fonctions, contrôlant les LEDs et détectant l’état des boutons, ne perturbaient pas celles de LUFA.
 +
 
 +
Après différents tests et corrections, je suis parvenu à faire fonctionner ma manette comme je le souhaitais.
 +
 
 +
Lorsqu’une pression sur un bouton est détectée, un message est envoyé au PC sous forme d’un code ASCII correspondant au bouton (H, G, D, B et S).
 +
 
 +
 
 +
A l’aide de la commande usbhid-dump --entity=stream, je peux observer les trames de données envoyées. Elles correspondent au bouton pressé.
 +
Pour visualiser les résultats de transmission, vous pouvez consulter le fichier joint : Manette16u2 detection donnees.pdf
 +
 
 +
EN CONCLUSION, LA COMMUNICATION AVEC LE PC FONCTIONNE.
 +
 
 +
 
 +
'''Gestion des LED et boutons'''
 +
 
 +
Les pressions sur les boutons sont bien détectées par le microcontrôleur.  Et les LEDs s’allument conformément à la programmation.
 +
 
 +
 
 +
'''Reste à faire : les vibreurs'''
 +
 
 +
Les vibreurs doivent être soudés. Une séance est déjà prévue le lundi 10/12.
 +
 
 +
Les vibreurs sont affectés aux boutons selon mon choix.
 +
 
 +
En utilisant un multimètre, j’ai constaté que le courant augmente sur la piste du vibreur concerné lorsqu’une pression sur un bouton a lieu. Cela signifie que les vibreurs seront fonctionnels dès qu’ils seront soudés.
 +
 
 +
 
 +
*'''Problèmes rencontrés'''
 +
 
 +
La LED 3 ne s’allume pas. J’ai d’abord supposé que j’avais fait une erreur et soudé la LED dans le mauvais sens. A l’aide d’un multimètre, j’ai constaté que ce n’est pas le cas : elle est soudée dans le bon sens.
 +
 
 +
L’alimentation du multimètre aurait dû suffire à l’allumer. Ça n’a pas été le cas.
 +
 
 +
Je pense donc que la LED est endommagée et qu’il faut la remplacer.
 +
 
 +
 
 +
*'''Prochaines actions semaine 11'''
 +
 
 +
Une séance de soudure est prévue pour le lundi 10/12. Une fois soudés, je pourrai tester les vibreurs.
 +
 
 +
Si tout se passe comme prévu, la manette pourra être considérée comme terminée le lundi 10/12. En effet, j’ai commencé le programme PC mais Mr Redon m’a confirmé par mail le 7/12 que le projet ne comporte pas la programmation du PC, ainsi que verbalement le vendredi 7/12.
 +
 
 +
== Semaine 13 – 10/12 au 14/12 ==
 +
 
 +
 
 +
'''Manette 1 - 328p'''
 +
 
 +
M. Redon m'a recommandé d'ajouter un composant sur la manette : un ceramic resonator.
 +
 
 +
Malheureusement, une fois installé sur la manette, ce composant n'a pas résolu les problèmes.
 +
 
 +
 
 +
'''Manette 2 - 16u2'''
 +
 
 +
Soudure d'un vibreur et test réussi sur celui-ci.
 +
 
 +
Il manque encore un vibreur, que je n'ai pas en ma possession.
  
 
=Documents Rendus=
 
=Documents Rendus=
 +
 +
'''Rapport du projet'''
 +
 +
[[Fichier:Rapport_projet_IMA4_P1-BOENS_Quentin.pdf]]
 +
 +
'''Soutenance'''
 +
 +
[[Fichier:Soutenance_IMA4_P1_BOENS_Quentin.pdf]]
 +
 +
'''Manette 328p - Programmes'''
 +
 +
Le PCB de la manette
 +
[[Fichier:Manette_328p_finale.zip]]
 +
 +
[[Fichier:Prog_manette_328p.zip]]
 +
 +
[[Fichier:Prog_PC_328p.zip]]
 +
 +
'''Manette 16u2'''
 +
 +
Le PCB de la manette
 +
[[Fichier:Manette_16u2_finale.zip]]
 +
 +
Connexion de la manette au PC
 +
[[Fichier:IMA4_P1_Connexion_manette_PC.pdf]]
 +
 +
Récupération des messages
 +
[[Fichier:Manette16u2_detection_donnees.pdf]]
 +
 +
Programme manette
 +
[[Fichier:Prog_manette_16u2.zip]]

Version actuelle datée du 19 décembre 2018 à 19:54


Présentation générale

Description

L'objectif de ce projet est de concevoir et réaliser des manettes à base de micro-contrôleurs, pour des travaux pratiques GIS3 et IMA4.

Chaque manette devra utiliser un protocole de communication différent de l'autre.

Objectifs

La première manette devra être conçue pour pouvoir communiquer via le protocole UDP.

La seconde, sera détectée par le PC comme un périphérique USB, plus précisément de type HID.

Préparation du projet

Cahier des charges

Pour ce projet je peux me baser sur les travaux réalisés en épreuves complémentaires par d'autres étudiants.

Pour la première manette, M. Redon m'a informé que celle réalisée par mon prédécesseur n'était pas reconnue par le PC. Il m'a suggéré d'examiner en détail le composant responsable de la communication. J'ai donc reçu le fichier Fritzing de l'objet.

La seconde n'avait jamais été testé physiquement. Par conséquent il me faudra souder puis la tester afin de savoir si elle est fonctionnelle. Si nécessaire, des corrections seront apportées.

Chaque manette comportera 10 LEDS, qui serviront à indiquer le bon fonctionnement de l'objet. On trouvera également 5 boutons et 2 vibreurs.

J'ai choisi de programmer les LEDs pour que leur activité corresponde à un événement précis : pression d'un bouton, réception/envoi d'une trame de donnée...Les vibreurs seront déclenchés à chaque pression sur un bouton. Toute pression sur un bouton sera enregistrée pour être envoyée au PC, dans la prochaine trame de donnée.


La première manette sera semblable à une Arduino Uno, avec un micro-contrôleur ATMega328p et un FTDI. Elle devra se comporter comme un périphérique IP. Grace à une communication série, en protocole UDP, il devra être possible de contrôler les LEDs situées sur la manette. Elle devra également être capable de renvoyer l'état des boutons, par sollicitation du PC.

Pour la seconde, une plateforme Arduino Leonardo et un micro-contrôleur ATMega16u2 seront utilisés. En utilisant la bibliothèque LUFA, il sera possible de la programmer pour qu'elle corresponde à un périphérique USB. J'ai déjà utilisé cette dernière, lors d'un tutorat durant le semestre 7.

Choix techniques : matériel et logiciel

Pour ce projet, il m'est possible de me baser sur les réalisations d'autres élèves, dans le cadre d'épreuves complémentaires. Je réutiliserai donc leur matériel, auquel j'ajouterai le mien, dans le cas où des modifications doivent êtres apportées.

Liste du matériel :

Manette 16u2 Manette 328p
LED rouge x12 LED rouge x12
Résistance 10kOhm x6 Résistance 10kOhm x6
Varistances x2
Résistance 22Ohm x2
Résistance 220Ohm x12 Résistance 220Ohm x12
Résistance 1kOhm x2 Résistance 1kOhm x4
Résistance 1MOhm x1 Résistance 1MOhm x1
Capacité 100nF x1 Capacité 100nF x 6
Capacité 22pF x2 Capacité 22pF x2
Capacité 1µF x1
XTAL 16MHz x1 XTAL 16MHz x1
Transistor Bipolaire NPN x2 Transistor Bipolaire NPN x2
Diode Melf DO-213 x4 Diode Melf DO-213 x2
Sparkfun isp header 6 broches x1 Sparkfun isp header 6 broches x1
Switch boitier THT x5 Switch boitier SMD x5
Switch boitier smd x1 Switch boitier smd x1
USB-miniB-smd-ns x 1 USB-miniB-smd-ns x 1
Vibreur (Sparkfun motor) x2 Vibreur (Sparkfun motor) x2
Atmega 16u2 x1 Atmega 328p x1

Liste des tâches à effectuer

Comme je l'ai expliqué plus haut, j'ai à ma disposition les projets réalisés par d'autres étudiants en épreuve complémentaire. Cependant, une phase de test sur les PCB doit être effectuée, afin de vérifier leur bon fonctionnement.

Après avoir discuté avec M. Redon, celui ci m'a indiqué que la manette FTDI n'était pas fonctionnelle. En effet, le FTDI n'est pas connecté correctement, ce qui fait que la manette n'arrive pas à communiquer avec le PC. J'ai donc prévu de corriger le PCB, en me basant sur la datasheet du FTDI (modèle FT232BL), afin de résoudre le problème. De plus, certaines LEDs ne sont pas correctement connectées au micro-contrôleur. Il faudra également que je corrige ce point sur le PCB.

La manette 16u2 n'avait pas été testée l'année précédente. Par conséquent, il me faudra vérifier son bon fonctionnement, pour ensuite apporter des modifications si nécessaire.

Une fois les deux manettes corrigées, je passerai à la programmation. Je commencerai par la manette FTDI, afin que celle-ci puisse communiquer en UDP avec le PC.

Puis je terminerai par programmer la manette 16u2, afin quelle puisse communiquer en me basant sur la bibliothèque LUFA.

Calendrier prévisionnel

Les trois premières semaines seront consacrés aux tests, et corrections, des PCB crées lors des épreuves complémentaires.

Pour les semaines qui suivront, l'attention sera portée sur la manette FTDI, afin quelle se comporte comme un périphérique IP.

Enfin je me consacrerai à la deuxième manette, pour qu'elle soit détectée en tant que périphérique USB par le PC.

Réalisation du Projet

Feuille d'heures

Tâche Prélude S1 Heures S2 Heures S3 Heures S4 Heures S5 Heures S6 Heures S6 Heures S8 Heures S9 Heures S10 Heures S11 Heures S12 Heures S13 Total
Analyse du projet 3h 3h
Manette 1 : 328P
1 - PCB 9h 3h 5h30 4h 3h 3h 27h30
2 - Programme manette 8h 14h 22h
3 - Programme PC 3h 18h 21h
Manette 2 : 16u2
1 - PCB 6h 3h 4h 13h
2 - Programme manette 6h 6h30 6h 8h 16h 42h30
3 - Programme PC 3h 8h 11h
Autres
1 - Gestion du Wiki 2h 3h 1h 1h 1h 1h 1h 1h 1h 1h 1h 5mins 14h05
TOTAL 3h 11h 12h 9h 15h 7h 19h 7h 17h 14h 20h 17h 3h05 154h05

Prologue

Planning

Planning (V2.9) de réalisation du projet

Semaine 1 - 17/09 au 21/09

Analyse et appropriation du sujet


Semaine 2 - 24/09 au 29/09

Manette 1 - 328p

  • Réalisé

Pour cette semaine, je me suis concentré sur la correction des erreurs dans le PCB de la manette FTDI. En comparant avec la datasheet, j'ai constaté que plusieurs éléments manquaient, notamment des résistances.

En examinant le PCB, j'ai aussi observé que les PINs RX et TX du FTDI étaient reliés, respectivement, aux PINs RX et TX du micro-contrôleur. Cette erreur est de loin la plus importante, puisque la communication entre le FTDI et l'atmega ne peut pas s'effectuer correctement.

Semaine 3 - 1/10 au 5/10

Manette 1 - 328p

  • Réalisé

J’ai terminé le routage de la manette.

Avec l’aide de M. Redon, j’ai pu corriger les problèmes que j’ai rencontrés. Il s’agissait notamment de fils volants, dont j’ignorais l’origine et que je n’arrivais pas à supprimer, sans provoquer de nouvelles erreurs.

  • Difficultés rencontrées

Fritzing : problèmes de raccordements de composants. Vu avec M. Redon (cf ci-dessus).

  • Prochaines actions semaine 3

Démarrer la programmation de la manette.

Contacter M. Redon afin de faire imprimer la manette 328p.

Je vais également voir, si je peux obtenir une plaque Arduino utilisée par les GIS et IMA lors de leurs TPs. Ainsi je pourrai tester mes programmes, sans devoir attendre la fabrication de mes manettes.

Manette 2 - 16u2

  • Réalisé

En voulant souder les composants à ma disposition sur la manette, je me suis rendu compte que la version du schéma de routage et la manette à ma disposition ne correspondent pas. Le fichier du schéma est en version 5. La manette est fabriquée selon une version au 7, elle-même modifiée.

Pour cette raison, il me manque certains composants, que je n’ai pas commandés auprès de M. Redon. Je l’ai donc prévenu avant qu’il ne valide les commandes de matériel.

J’ai soudé quelques composants, qui sont communs aux deux versions : le connecteur USB, le Quartz et les capacités nécessaires au Quartz.

  • Difficultés rencontrées

Différences entre la manette et le schéma de routage, donc manque de composants.

  • Prochaines actions semaine 3

Comme pour la manette 1, essayer d’obtenir une plaque Arduino utilisée par les GIS et IMA lors de leurs TPs.

Semaine 4 - 8/10 au 12/10

Manette 1 - 328p

  • Réalisé

J’ai principalement travaillé sur le programme de la manette et plus précisément les points suivants :

  • Définition des entrées/sorties des différents ports
  • Acquisition des états des boutons
  • Construction de la trame IP-UDP, dont le calcul des checksums
  • Envoi de la trame

Vendredi : M. Redon m’a contacté pour que j'apporte des modifications au PCB.

  • Difficultés rencontrées

Le planning tenait compte d’un délai de fabrication de 2 semaines à partir du lundi. Il ne pourra pas être respecté pour la manette 1.

  • Prochaines actions semaine 4

Terminer le calcul du checksum UDP

Programmer la lecture des trames reçues par le PC

Manette 2 - 16u2

  • Réalisé

Comme annoncé dans le planning, pas d’avancement cette semaine.

  • Prochaines actions semaine 4

Pas d'action prévue.

Semaine 5 - 15/10 au 19/10

Manette 1 - 328p

  • Réalisé

M. Redon a envoyé la commande pour mon PCB.


Programmation

Lors de la semaine 3, j’avais annoncé me concentrer sur les checksums UDP et IP. J’avais également parlé de la gestion des trames reçues par le PC.

Dans le cas du checksum UDP, j’ai demandé de l’aide à M. Vantroy, car un des paramètres nécessaires au calcul n’était pas très clair pour moi. Une fois ce problème résolu, j’ai pu terminer le calcul sans problème.

Lorsqu’une trame est reçue par la manette, celle-ci va vérifier si les checksums sont cohérents avec ceux annoncés par la trame. Si c’est le cas, suivant la demande reçue, la manette renverra l’état des boutons, des LEDs et/ou des vibreurs.

J’ai également travaillé sur la gestion des LEDs et apporté différentes corrections sur les fonctions liées aux boutons. En effet, ma commande déterminant si un bouton est activé, ou non, renvoyait le résultat inverse. J’ai rapidement corrigé ce problème.

Grâce à toutes ces corrections et nouvelles fonctions, j’ai pu terminer le programme de la manette 1. Voir dans Documents Rendus "Manette1.zip".


Test programme

Grâce à une Arduino, fournie par M. Redon, j’ai pu vérifier que le programme envoie des données conformes à mes attentes.


  • Difficultés rencontrées

Pour calculer le checksum UDP il faut prendre en compte l’adresse IP source, de destination, le protocole IP et la longueur du datagrame (en octet). C’est ce dernier paramètre qui m’a posé problème. Après avoir discuté avec M. Vantroy, j’ai compris qu’il s’agissait de la longueur de la partie UDP : en-tête + données.

L’erreur sur la gestion des boutons était très subtile. Voir ci-dessous. 

 return ((PINB & entree)!=0)?1:0;   Bonne version
 return ((PINB & entree)!=0)?0:1;   Mauvaise version


  • Prochaines actions semaine 5

Le programme de la manette 1 fini, je vais maintenant écrire le programme PC, afin de permettre l’envoi et la lecture de données provenant du port série.


Manette 2 - 16u2

  • Réalisé

Nous avons reçu les différents composants attendus pour souder la manette.

  • Prochaines actions semaine 5

Réalisation du soudage de la manette.

Vérification de la détection de la manette par le PC.

Semaine 6 - 22 au 26/10

Manette 1 - 328p

  • Réalisé

J’ai reçu le PCB et les composants ce qui me permettra de les souder dès que possible.


Programmation

J’ai commencé l’écriture du programme PC, notamment sur l’ouverture du port USB afin de lire les données envoyées par la manette. 

   fd = open("/dev/ttyACM0",O_RDWR | O_NOCTTY);

Grâce à cette fonction, il m’est possible d’avoir accès au port USB correspondant à ma manette.

O_RDWR me permet d’avoir un accès en lecture et en écriture.

Les fonctions read() et write() me permettront ainsi de recevoir et d’envoyer des trames de données à la manette.

Le programme PC reprendra beaucoup de fonctions que j’ai utilisées dans le programme de la manette. Notamment celles calculant les checksums IP et UDP.

Test programme

Pour l’instant je n’ai pu que tester si mon programme détecte bien la manette lorsqu'elle est branchée. Le résultat est positif.

  • Prochaines actions semaine 6

L’ensemble du temps sera consacré au programme PC. Il me faudra traiter la communication entre PC et manette, ainsi que l’extraction et analyse des données reçues.

Manette 2 - 16u2

  • Réalisé

J’ai soudé cette manette, grâce aux conseils de M. Flamen. Je n’ai malheureusement pas pu la tester tout de suite. Certains composants, essentiels au bon fonctionnement, doivent être ressoudés car la première soudure n’est pas très satisfaisante.

  • Difficultés rencontrées

Pour souder mon PCB je dois appliquer une pâte, puis placer mes composants et enfin passer le tout au four. Mais sur certains je pense en avoir mis trop. Je corrigerai ce problème après la semaine des vacances, M. Flamen étant absent.

  • Prochaines actions semaine 6

Pas d’action n’est prévue pour cette manette en semaine 6. La priorité va à la manette 1.


Faits marquants

La soutenance mi-parcours a eu lieu vendredi.

Semaine 7 – 29/10 au 2/11

Manette 1 - 328p

  • Réalisé

La programmation du PC, pour la communication avec la manette, a été mon sujet de la semaine.

J'ai également révisé mon planning.

Programmation

Le programme du PC doit permettre plusieurs choses : échanger des données avec la manette, analyser ces données et les afficher pour l’utilisateur.

Pour communiquer je dispose de deux trames : mess_recu, qui permet de stocker les datas reçues par la manette, et mess_emi qui sera envoyée à la manette.

La communication se fait grâce à trois fonctions :

  • open() : pour accéder au port USB et définir le type de communication. Les options sur cette fonction me permettent de limiter le risque d’erreurs. O_NONBLOCK et O_NDELAY permet d’ouvrir le fichier en mode non bloquant. O_RDWR permet de lire et d’écrire dans le fichier. Enfin O_NOCTTY détache le processus du terminal.
  • read() : lecture des données écrites sur le port.
  • write() : écriture des données sur le port. Un seul appel de cette fonction peut me permettre d’envoyer toute la trame de donnée.

Au début mes fonctions fonctionnaient selon ce principe : si X envoie un message à Y, le message est forcément bien reçu et on peut continuer le reste du programme. Cet aspect n’étant pas très réaliste, j’ai modifié mes programmes pour qu’ils permettent l’envoi d’un accusé de réception.

Ce message n’est envoyé que dans le cas où la trame reçue est correcte : bonnes adresses source et destination et un calcul des checksums identique entre le PC et la manette. Ainsi le risque d’erreur dû à une mauvaise lecture des données est diminué.

Si un accusé de réception indiquant une mauvaise trame est reçu, l’émetteur renverra une nouvelle trame de donnée. Le PC et la manette ne peuvent pas continuer leurs programmes tant qu’ils n'ont pas reçus un accusé de validation.

L’objectif du programme PC est d’afficher les états des boutons, LEDs et vibreurs de la manette. Les données à afficher sont au choix de l’utilisateur.

Si l’utilisateur choisit d’afficher une donnée précise, ou toutes, le PC envoie une requête à la manette. Celle-ci répondra à la demande en envoyant une trame contenant la réponse associée à la requête.

La réponse reçue, le PC extrait les informations de la trame et les affiche, grâce aux fonctions affichage_etat_LEDs(), affichage_etat_boutons() et affichage_etat_vibreurs().

Problèmes rencontrés

En écrivant mes fonctions d’analyse des données reçues, je me suis demandé si mess_recu serait bien rempli par la fonction read().

La fonction send_serial() de la manette ne peut envoyer que caractère par caractère. Par conséquent, je pense que read() ne permettrait pas de charger mess_recu en un seul appel. J’ai donc modifié mon programme pour éviter ce problème.

Test programme

Pour l’instant aucun test n’a été effectué concernant le programme PC.

  • Prochaines actions semaine 6

Une séance sera consacrée à la soudure de la manette, avec les composants reçus. Je contacterai M. Flamen afin d’avoir accès à la salle.

Cette carte sera ensuite testée. Si le PC ne la détecte pas en erreur, c’est que la manette peut être utilisée.

Une fois ce test effectué, je réaliserai un test sur l’ensemble des objectifs de cette manette. Je vérifierai que le PC et la manette communiquent correctement. Si l’affichage des données est conforme à l’état de la manette. Si ce test est un succès, je pourrai consacrer tout le reste de mon temps à la manette 2.


Manette 2 - 16u2

  • Réalisé

Comme annoncé dans le planning, aucune activité n’a été réalisée sur cette manette.

  • Prochaines actions semaine 7

Je commencerai le programme de la manette

Semaine 8 – 5/11 au 9/11

Mise à jour du planning, version 2.4.


Manette 1 - 328p

  • Réalisé

Pas d’avancement cette semaine. Elle devait être consacrée à la soudure et aux tests des différents programmes.

Malheureusement l’emploi du temps de M. Flamen, et le mien, n’ont pas permis de trouver un créneau horaire possible. Je n’ai donc pas pu souder les composants.


  • Prochaines actions semaine 8

Les soudures de la manette n’ayant pas été faites, j’ai contacté M. Flamen afin de réserver un créneau. Elles seront faites le mercredi 14/11 ou le jeudi 15/11.


Manette 2 - 16u2

  • Réalisé

Cette semaine a été consacrée à l’étude et la compréhension des bibliothèques LUFA.

La manette doit se comporter comme un périphérique USB de type HID. La bibliothèque LUFA contient tous les programmes permettant d’atteindre cet objectif.

Je l’ai donc téléchargée et j’en ai étudié le fonctionnement. Je pense avoir déterminé toutes les fonctions qui seront nécessaires.

LUFA est complexe, je n’ai donc pas encore compris toutes les fonctions, mais j’en ai compris suffisamment pour savoir lesquelles seront nécessaires au bon fonctionnement du matériel.

Lors d’une communication le PC (hôte) envoie des rapports à la manette (device).

Dans les fichiers téléchargés se trouvent des démos. J’adapterai leur programme, afin qu’il corresponde à mes besoins, notamment sur la longueur des rapports.

  • Prochaines actions semaine 8

Dans un premier temps, j’effectuerai les soudures de la manette. Si mon emploi du temps le permet, je commencerai la programmation de la manette.

Semaine 9 – 12/11 au 16/11

Mise à jour du planning, version 2.6

Manette 1 - 328p

  • Réalisé et problèmes rencontrés

Les soudures ont été réalisées cette semaine, le mercredi 14/11.

Malheureusement, la manette n’était pas détectée par le PC. Lors de deux séances le jeudi 15/11 et le vendredi 16/11, j’ai vérifié les différents composants (valeurs, connexions …). Mais je n’ai pas trouvé la source du problème.

J’ai revérifié que le FT232BL est bien connecté ainsi que le microcontrôleur. Ils ne présentent aucun problème, et leurs pins sont bien reliés aux bons composants.

Risque fort : Il pourrait s’agir d’un problème de composants défaillants.

  • Prochaines actions semaine 9

J’essaierai de résoudre le problème de détection de cette manette.

Quand il sera résolu, je passerai aux tests des différents programmes que j’avais réalisés avant la fin des vacances.

Manette 2 - 16u2

  • Réalisé

Soudure

Les soudures ont été réalisées cette semaine, le mercredi 14/11.

Cependant la manette n’était pas détectée par mon PC. J’ai donc réalisé différents tests afin de déterminer où se trouvait le problème, le jeudi 15/11.

Après avoir vérifié tous les composants (valeur, position, connexions …), j’ai réexaminé le schéma électrique de ma manette.

J’ai alors constaté que trois composants étaient susceptibles de provoquer le problème. Ils ont donc été dessoudés.

Le PC a reconnu ma manette, comme étant un atmega16u2 DFU (voir image ci-dessous).

Détection de la manette par mon PC

Afin que les futures cartes ne présentent plus ce problème, j’ai modifié le schéma électrique et supprimé les composants responsables du problème. La manette fonctionnera sans ces composants.

Ancienne version du schéma électrique
Nouvelle version du schéma


La manette fonctionnant correctement, je peux maintenant me concentrer sur sa programmation.

Programmation

Cette semaine j’ai continué mes recherches sur le fonctionnement de la bibliothèque LUFA. Principalement sur le programme de la manette.

Je pense pouvoir me baser sur une des démos fournies, et je dois déterminer comment adapter ce programme à mon projet.

  • Prochaines actions semaine 9

Continuer les recherches sur la bibliothèque LUFA, et commencer la programmation de la manette.

Semaine 10 – 19/11 au 23/11

Mise à jour du planning, version 2.7

Manette 1 - 328p

  • Réalisé et problèmes rencontrés

Après plusieurs passages à l’atelier et avec l’assistance de M. Flamen, voici le compte-rendu de nos tentatives pour déterminer ce qui ne fonctionne pas.

Ce qui a été testé :

- Que les vias (traversant) étaient corrects (OK)

- Que le dessous du FTDI et de l’Atmega ne conduisent pas, provoquant des courts circuits (OK)

- Que la tension 5V arrive bien sur les pins concernés (OK)

- Que le quartz fonctionne correctement (NOK)

o Aucune tension détectée aux bornes de ce composant

o La valeur de la résistance à ses bornes est deux fois trop grande (2Mohm au lieu de 1Mohm)

o Un remplacement a été effectué, sans succès

o Comparaison avec le schéma de la manette 16u2 pour les connexions. Celles-ci sont identiques

- Que la tension envoyée par le PC via le câble est correcte (OK)

- Vérification du schéma électrique par M. Flamen, pas d’incohérences (OK)

- Contrôle de toutes les liaisons entre les différents composants (OK)


Raisons possibles de l’échec :

- Un des composants a grillé dans le four

- L’électricité statique peut avoir grillé un composant (contact avec un objet chargé : peau, vêtement, table…)

- Mise en doute par M. Flamen du connecteur USB. Il pourrait ne pas fonctionner correctement


Une seule solution est envisageable :

- Ressouder complétement un nouveau PCB, MAIS la méthode de soudure (via le four) présente un risque non négligeable d’endommager les composants.

Une autre possibilité aurait été de ressouder à la main un par un les composants et les tester au fur et à mesure. Elle est irréalisable car certains pins sont trop petits.

  • Prochaines actions semaine 10

Une nouvelle séance de soudure a été prévue. J’utiliserai une carte non soudée et des composants neufs qui m’ont été remis.


Manette 2 - 16u2

  • Réalisé

Programmation

Mes séances ont été consacrées à la recherche d’informations sur la bibliothèque LUFA.

Elle est complexe, car elle contient de nombreux fichiers et programmes. Je pense avoir trouvé quel programme modifier pour la manette. Je dois identifier celui du PC.

  • Prochaines actions semaine 10

Confirmer que les informations trouvées sur le programme manette sont correctes et continuer à chercher le programme PC.

Semaine 10 – 26/11 au 30/11

Mise à jour du planning, version 2.8

Manette 1 - 328p

  • Réalisé et problèmes rencontrés

Mercredi 28/11 : soudage d'une deuxième manette. Aucune détection par le PC.

En examinant le PCB, je me suis rendu compte que certains éléments n’étaient pas reliés correctement à la masse et au VCC. Le PCB correspond au plan de conception. Il n'y a pas d'erreur de fabrication. Ce plan est donc faux. Mais Fritzing n'a pas généré d'erreur.

Avec M. Flamen, nous avons tenté de relier les composants mal connectés en soudant quelques fils supplémentaires.

Cela n’a rien changé et la manette n’est toujours pas détectée par l’ordinateur.

  • Prochaines actions

Reprendre l'étude de la carte dans Fritzing. Il s'agira de déterminer les erreurs et apporter les corrections.

Selon le temps qu'il me restera avant le 19/12, date de fin du projet, j'irai le plus loin possible dans la réalisation de cette manette.

Mais je traiterai en priorité la manette 16u2 car elle peut aboutir.


Manette 2 - 16u2

  • Réalisé

Programme Manette

Grâce aux recherches que j’ai effectuées, j’ai réussi à comprendre quelle partie du programme fourni en exemple je dois modifier.


Lorsque la manette doit envoyer un message, elle charge les données dans un buffer. Dans l’exemple, ce buffer est chargé avec une série de chiffres.

J’ai donc modifié le programme pour qu’il charge ce buffer avec mes données. L’état des 5 boutons et l’état des LEDs.

L'état des composants est vérifié avant chaque envoi de message.


J’ai écrit dans le programme les différentes fonctions utiles à mon projet :

1) 'test_entree' qui permet de savoir si un pin est à l’état haut ou bas.

2) 'allume_eteindre_led' sert à allumer ou à éteindre une LED. Ce programme vérifie si toujours si la LED n’est pas déjà dans l’état souhaité.

3) 'analyse_mess' si le PC demande l’envoi d’un nouveau message cette fonction déclenche l’envoi. Si le PC demande de changer l’état d’une LED, 'allume_eteindre_led' est utilisée.


Les messages envoyés par la manette ont le format suivant :

Message de 16bits : 5 bits de poids fort état des boutons + 11 bits état des LEDs

Ils sont envoyés toutes les 3 à 4 secondes. Mais si un message du PC le demande, un nouvel envoi aura lieu.


PC

Comme pour mon programme manette j’ai pu, grâce à mes recherches, déterminer qu’elles sont les points à modifier. J’ai aussi ajouté mes propres fonctions pour mon projet.


Dans le cas de l’exemple il n’y a qu’un seul échange entre la manette et le PC. Le programme se termine dès qu’un objet correspondant aux VENDOR_ID et PRODUCT_ID a répondu.

J’ai donc mis en place une boucle while, qui se termine lorsque l’utilisateur le décide.


Dans le programme exemple fourni, les données envoyées correspondent à des états de LEDs, mais leur gestion est différente de la mienne. J’ai donc modifié ce point.

Le PC peut envoyer deux messages :

- demander l’envoi de l’état de la manette : 1er bit de poids fort à 1

- allumer/éteindre une LED : 1er bit de poids fort à 0. Les autres bits indiquent l’état souhaité sur les différentes LEDs.


Le message envoyé dépend du choix de l’utilisateur.

J’ai également écrit une fonction affichant l’état des boutons et des LEDs.

A ce stade du projet, ces programmes sont écrits. L'étape suivante sera de les tester.


  • Difficultés rencontrées

La manette est très proche de l’arduino que nous avions utilisée lors d’un tutorat en IMA4.

Afin de télécharger mon programme manette, j’ai donc repris le tutoriel fourni par M. Redon. Mais il n’a pas fonctionné avec ma manette.

C'est pourquoi, j'en ai informé M. Redon de mon problème. Il m’a renvoyé sur un tutoriel qui m’a permis d’installer le logiciel Flip3.4.7.

Le téléchargement a pu être fait. Comme l'installation n'est pas immédiate, car la manette ne communique pas correctement avec le PC. Je décris la procédure de reconnaissance de la manette dans le fichier joint à mon Wiki : "IMA4 P1 Connexion manette PC.pdf"


  • Prochaines actions semaine 11

Tester mes différents programmes.

Semaine 12 – 3/12 au 7/12

Mise à jour du planning, version 2.9

Manette 1 - 328p

Comme annoncé l’attention a été portée sur la manette 2. Par conséquent, je n’ai pas travaillé sur la manette 1.

  • Prochaines actions

Reprendre le schéma électrique de la manette et la datasheet des composants pour déterminer une éventuelle erreur.


Manette 2 - 16u2

  • Réalisé

Communication avec le PC en utilisant les bibliothèques LUFA

Comme annoncé la semaine précédente, j’ai réalisé différents tests des programmes que j’ai écrits.

Ces tests avaient pour objectif de déterminer si mes modifications dans les fonctions de la bibliothèque LUFA étaient correctes et n’entrainaient pas d’erreur. Il fallait aussi que je vérifie si mes propres fonctions, contrôlant les LEDs et détectant l’état des boutons, ne perturbaient pas celles de LUFA.

Après différents tests et corrections, je suis parvenu à faire fonctionner ma manette comme je le souhaitais.

Lorsqu’une pression sur un bouton est détectée, un message est envoyé au PC sous forme d’un code ASCII correspondant au bouton (H, G, D, B et S).


A l’aide de la commande usbhid-dump --entity=stream, je peux observer les trames de données envoyées. Elles correspondent au bouton pressé. Pour visualiser les résultats de transmission, vous pouvez consulter le fichier joint : Manette16u2 detection donnees.pdf

EN CONCLUSION, LA COMMUNICATION AVEC LE PC FONCTIONNE.


Gestion des LED et boutons

Les pressions sur les boutons sont bien détectées par le microcontrôleur. Et les LEDs s’allument conformément à la programmation.


Reste à faire : les vibreurs

Les vibreurs doivent être soudés. Une séance est déjà prévue le lundi 10/12.

Les vibreurs sont affectés aux boutons selon mon choix.

En utilisant un multimètre, j’ai constaté que le courant augmente sur la piste du vibreur concerné lorsqu’une pression sur un bouton a lieu. Cela signifie que les vibreurs seront fonctionnels dès qu’ils seront soudés.


  • Problèmes rencontrés

La LED 3 ne s’allume pas. J’ai d’abord supposé que j’avais fait une erreur et soudé la LED dans le mauvais sens. A l’aide d’un multimètre, j’ai constaté que ce n’est pas le cas : elle est soudée dans le bon sens.

L’alimentation du multimètre aurait dû suffire à l’allumer. Ça n’a pas été le cas.

Je pense donc que la LED est endommagée et qu’il faut la remplacer.


  • Prochaines actions semaine 11

Une séance de soudure est prévue pour le lundi 10/12. Une fois soudés, je pourrai tester les vibreurs.

Si tout se passe comme prévu, la manette pourra être considérée comme terminée le lundi 10/12. En effet, j’ai commencé le programme PC mais Mr Redon m’a confirmé par mail le 7/12 que le projet ne comporte pas la programmation du PC, ainsi que verbalement le vendredi 7/12.

Semaine 13 – 10/12 au 14/12

Manette 1 - 328p

M. Redon m'a recommandé d'ajouter un composant sur la manette : un ceramic resonator.

Malheureusement, une fois installé sur la manette, ce composant n'a pas résolu les problèmes.


Manette 2 - 16u2

Soudure d'un vibreur et test réussi sur celui-ci.

Il manque encore un vibreur, que je n'ai pas en ma possession.

Documents Rendus

Rapport du projet

Fichier:Rapport projet IMA4 P1-BOENS Quentin.pdf

Soutenance

Fichier:Soutenance IMA4 P1 BOENS Quentin.pdf

Manette 328p - Programmes

Le PCB de la manette Fichier:Manette 328p finale.zip

Fichier:Prog manette 328p.zip

Fichier:Prog PC 328p.zip

Manette 16u2

Le PCB de la manette Fichier:Manette 16u2 finale.zip

Connexion de la manette au PC Fichier:IMA4 P1 Connexion manette PC.pdf

Récupération des messages Fichier:Manette16u2 detection donnees.pdf

Programme manette Fichier:Prog manette 16u2.zip

Récupérée de « https://projets-ima.plil.fr/mediawiki/index.php?title=IMA4_2018/2019_P1&oldid=64758 »