IMA4 2016/2017 ECP3 : Différence entre versions

Version du 4 juillet 2017 à 20:53

Présentation du projet

Contexte

L'élève effectue son stage sur Lille 1 et peut donc passer à l'école pour récupérer du matériel.

Objectif

L'objectif du projet est la création d'un périphérique USB ludique du type catapulte ou lance-billes. La carte de contrôle est à réaliser à l'aide d'un micro-contrôleur.

Description du projet

Le but de ce projet est de réaliser un gadget USB constitué d'une partie mécanique et d'une carte électronique de contrôle. La carte de contrôle doit permettre au gadget d'être reconnu par l'ordinateur comme un périphérique USB (USB device) sur un bus USB géré par un contrôleur USB (USB Host).

Comme carte de contrôle vous utiliserez un Arduino UNO. Reprogrammez l'ATMega16u2 de cette carte. L'objectif est de le programmer pour le faire apparaître non pas comme un convertisseur USB/Série mais comme un périphérique de type USB-gadget.

Une fois l'ATMega16u2 reconnu ainsi par l'ordinateur, des fonctions doivent être ajoutées sur l'ATMega328p pour gérer des servo-moteurs par rapport aux commandes reçues de l'hôte USB. Le périphérique doit donc présenter des points d'accès en écriture, par exemple pour commander la rotation de l'objet, mais aussi des points d'accès en lecture, par exemple pour savoir si la rotation est bloquée en fin de course. Pour la version de production, il est demandé de programmer les ATMega avec avr-gcc.

Pour finir, réalisez la structure du gadget en contre-plaqué usiné à la découpeuse laser.

Cahier des charges

L'idée générale de ce projet est de reprogrammer une carte Arduino UNO pour en faire un périphérique USB ludique de type catapulte ou lance-bille. Tout d'abord, il faut reprogrammer le micro-logiciel de communication USB (firmware) de l'ATMega16u2. L'ATMega16u2 fait le lien entre le port USB de l'ordinateur et le micro-contrôleur ATMega328p. Afin de reprogrammer l'ATMega16u2, il faut utiliser la bibliothèque LUFA. LUFA (Lightweight USB Framework for AVRs) est une librairie open-source pour les microcontrôleurs AVR conçu pour le développement de périphériques et hôtes USB. Elle est écrit spécifiquement pour le compilateur AVR-GCC. Dès que l'ATMega16u2 sera reprogrammé et reconnu par l'ordinateur comme un périphérique de type USB-gadget, on pourra passer sur la programmation de l'ATMega328p afin d'y ajouter les fonctions nécessaires pour gérer les servo-moteurs. Le code sera intégralement codé en C avec le bibliothèque avr-gcc.

Planning prévisionnel

Diagramme de Gantt

Programmation USB

Utilisez la bibliothèque LUFA pour reprogrammer l'ATMega16u2.

Semaine 1

Prise en main de la bibliothèque LUFA

J'ai tout d'abord effecteur des recherches sur la bibliothèque LUFA afin d'étudier les différentes possibilités que nous offre cette bibliothèque. Elle permet de créer des périphériques de différentes classes : Android, Audio, Generic, Joystick, Clavier, Stockage, Souris, Imprimante ...Des exemples de projet OpenSource sont même inclus dans le package.

J'ai fait des recherches également sur l'ATMega16u2. Alors que l'ATMega328p prend le soin de réaliser toutes les taches de l'Arduino, l'ATMega16u2 s'occupe de la connexion USB. Elle convertit les signaux USB provenant de l'ordinateur vers le port série SAM3X. Le protocole USB nommée DFU (Device Firmware Update) permet de mettre à jour de le firmware de l'ATMega16u2.

Ayant téléchargé la bibliothèque LUFA, j'ai implanté une USB Class Device de type Mouse dans l'Arduino afin de faire un essai :

• J'ai tout d'abord modifié le Makefile fourni afin qu'il fonctionne avec l'Arduino et l'ATMega16u2.

Makefile

• Ensuite j'ai compilé le programme afin de générer le fichier .hex pour flasher l'ATMega16u2.

make all

• Il est nécessaire de télécharger le package dfu-programmer pour flasher l'ATMega16u2.

sudo apt-get install dfu-programmer

• On réinitialise l'ATMega16u2 en reliant les broches RESET et GND du port ISCP de celui-ci

Broches à relier pour réinitialiser l'ATMega16u2

• A ce stade-là, l'Arduino n'est plus vu de la même façon avec la commande lsusb :

Avant réinitialisation

Après réinitialisation

• On efface l'ATMega16u2 :

sudo dfu-programmer atmega16u2 erase

• On le reprogramme avec le fichier .hex :

sudo dfu-programmer atmega16u2 flash Mouse.hex

• Enfin, on tape la commande :

sudo dfu-programmer atmega16u2 reset

• On déconnecte et on reconnecte l'Arduino. On observe alors le résultat avec les commandes lsusb et lsusb -v pour plus de détails :

lsusb

lsusb -v

L'Arduino est bien vu comme une souris par linux.

Semaine 2

Recherches sur le protocole USB

J'ai effectué quelques recherche afin de me familiariser avec les périphériques USB et de comprendre leur fonctionnement.

Architecture

La norme USB permet le chaînage des périphériques, en utilisant une topologie en bus ou en étoile. L'architecture USB est composée d'un hôte (USB host) et de plusieurs périphériques (USB devices). Un hôte USB peut contenir plusieurs contôleurs hôte (host controllers) et chaque contrôleur hôte peut contrôler un ou plusieurs ports USB. Un périphérique USB peut être constitué de plusieurs sous-périphériques dans le cas d'un périphérique multi-fonctions tel qu'un webcam avec micro intégré. La communication USB est basée sur des canaux logiques appelés "pipes". Un pipe est une connexion entre le contrôleur hôte et une entité logique d'un périphérique qu'on appelle "endpoint". Il y a deux types de pipes :

• Les pipes de message qui sont bi-directionnels et permettent de commander le périphérique (control transfert).
• Les pipes de stream qui sont uni-directionnels et permettent le transfert de données de façon asynchrone, par interruptions ou en mode bulk.

Communication USB host/USB device

Classes USB

Il y a différentes classes de périphériques USB permettant à l'hôte de charger le bon driver pour chaque périphérique connecté. Un code est associé à chaque classe. Il est envoyé à l'hôte. Les principales classes sont les suivantes :

• Audio pour les enceintes, microphones ...
• Communications and CDC Control pour les convertisseurs USB-série, modems ...
• Human Interface Device (HID) pour les claviers, souris, joysticks, écrans tactiles ...
• Physical Interface Device (PID)
• Mass storage pour les clés USB, lecteurs de cartes SD ...
• Vidéo pour les webcam
• Vendor-specific ou Unspecified pour des périphériques nécessitant des drivers spcéfiques

Les classes peuvent être utilisées comme interface d'un périphérique pour un périphérique multi-fonctions.

Architecture d'un périphérique USB multi-fonctions

Semaine 3

Étude de la bibliothèque LUFA

Dans la bibliothèque LUFA, il existe plusieurs types d'USB Class Driver. J'ai regardé et étudié les différents exemples proposés : Android Open Accessory, Audio 1.0, CDC-ACM (Virtual Serial), HID, MIDI, Mass Storage, Printer, RNDIS (Networking) et Still Image. Après lecture et étude, la classe CDC-ACM (Communications Device Class-Abstract Control Model) semble se rapprocher le plus de la tâche que je dois réaliser. Cette classe offre la possibilité de configurer des points d'accès en lecture et en écriture, ce qui est prévu pour le gadget que je dois réaliser. Je vais donc m'inspirer de cela pour ma programmation USB. La plupart des exemples Demo disponibles de type CDC ont une structure permettant de configurer les points d'accès : usb_classinfo_cdc_device_t.

Recherches sur "l'USB Gadget"

J'ai également fait des recherches sur la bibliothèque Linux-USB Gadget API Framework. Je pensais partir là dessus au début pour la programmation du gadget mais cela ne semble pas du tout correspondre à ce qu'il m'est demandé de faire dans le mesure où cette API permet à des périphériques embarquant GNU/Linux de se comporter comme un périphérique USB (USB device) dans le rôle d'esclave. Contrairement à une plate-forme de type Raspberry Pi, l'Arduino ne peut pas embarquer Linux. Je n'ai guère trouvé autre chose sous le nom de « USB Gadget », cela ne semble pas être un type de périphérique standard définit par l'USB Implementers Forum.

Semaine 4 & 5

Prise en main de la classe USB CDC-ACM avec LUFA

Afin de réaliser la programmation de l'Arduino en tant que périphérique USB CDC-ACM, j'ai étudié le fonctionnement des périphériques de ce type ainsi que les fonctions de la bibliothèque LUFA associées. La sous-classe ACM pour les périphériques CDC utilise deux interfaces et quatre endpoints :

• Une interface de communication comprenant deux endpoints :
  • Un endpoint bi-directionel de type "contrôle"
  • Un endpoint unidirectionnel de type "interruption"
• Une interface de données comprenant deux endpoints unidirectionnels de type bulk :
  • Un endpoint IN
  • Un endpoint OUT

Le tableau ainsi que le schéma ci-dessous décrivent l'architecture ainsi que l'utilisation des endpoints pour un périphérique CDC-ACM. Les endpoints EP2 et EP3, utilisant le transfert de données en mode bulk, constituent des point d'accès en lecture en en écriture pour l'envoi des codes de pilotage des servomoteurs du gadget.

Architecture d'un périphérique USB CDC-ACM

Programmation du driver USB pour piloter le gadget au clavier

Pour concevoir le driver de mon périphérique USB, je me suis inspiré de celui conçu pour piloter la tourelle USB lors du tutorat IMA 4 de système du semestre 7.

• On énumère tout d'abord les périphériques USB disponibles sur le bus USB de la machine hôte. Dés que le gadget USB est trouvé, on sauve la "poignée" vers ce périphérique dans une variable globale de type libusb_device_handle *.

• Un fois le périphérique trouvé, on passe à la configuration :
  • On ouvre le périphérique

int status=libusb_open(device,&handle);
if(status!=0)
   {
     perror("libusb_open"); exit(-1);
   }
* On récupère la configuration d'indice 0 du périphérique
 struct libusb_config_descriptor *config;
 status=libusb_get_active_config_descriptor(device,&config);
 if(status!=0)
   {
     perror("libusb_get_active_config_descriptor"); exit(-1);
   }
* On détache le driver utilisé par le noyau qui peut s'être approprié les interfaces du périphérique avant notre driver (pour un périphérique CDC-ACM, il est fort probable que se soit le cas)
* On utilise une configuration du périphérique
* On s'approprie ensuite les interfaces

Programmation du gadget

Semaine 1

Dès que l'Arduino est transformé en périphérique USB-Gadget après la reprogrammation de l'ATMega16u2, il est plus possible de programmer l'ATMmega328 via le port USB de l'Arduino. Il faut donc utiliser le port ISCP relier au l'ATMega328p pour programmer celui via le protocole SPI. On utilise pour cela un autre Arduino UNO. La seconde Arduino joue le rôle de programmeur AVR.

Utilisation d'un Arduino comme programmeur USB

Montage des deux Arduinos en programmation SPI

Semaine 4 & 5

Réalisation du gadget

Documents

Sources

Librairie LUFA

http://rex.plil.fr/Enseignement/Systeme/Tutorat.Systeme.IMA4/index.html