Version du 4 novembre 2018 à 18:47 (voir la source) Qboens (discussion | contributions) (→‎Semaine 6 – 29/10 au 2/11) ← Modification précédente		Version du 4 novembre 2018 à 18:51 (voir la source) Qboens (discussion | contributions) (→‎Planning) Modification suivante →
Ligne 263 :		Ligne 263 :
	==Prologue==		==Prologue==
	==Planning==		==Planning==
−	[[Fichier:QBS_planning_V2.2.jpg|vignette|upright=3.5|center|Planning (V2.2) de réalisation du projet]]	+	[[Fichier:QBS_planning_V2.3.jpg|vignette|upright=3.5|center|Planning (V2.3) de réalisation du projet]]
	==Semaine 1==		==Semaine 1==

---

Version du 4 novembre 2018 à 18:51

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	Heures S1	Heures S2	Heures S3	Heures S4	Heures S5	Heures S6	Heures S7	Heures S8	Heures S9	Heures S10	Total
Analyse du projet	3h											3h
Manette 1 : 328P
1 - PCB		9h	3h									12h
2 - Programme manette				8h	14h							22h
3 - Programme PC						3h	18h					21h
Manette 2 : 16u2
1 - PCB			6h			3h						9h
2 - Programme manette
3 - Programme PC
Autres
1 - Gestion du Wiki		2h	3h	1h	1h	1h	1h					9h
TOTAL	3h	11h	12h	9h	15h	7h	19h					76h

Prologue

Planning

Semaine 1

Manette 1 - 328p

• Réalisé

Pour cette première 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 2

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 3

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 4

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.

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 5 - 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 6 – 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

Documents Rendus

Fichier:Manette1.zip