Discussion:Binome2021-2

2022-05-05T17:58:28Z

Aboe : Page créée avec « Carte USB fonctionnelle et personnelle. Code LUFA personnel Carte Annexe fonctionnelle mais problème communication SPI entre les deux cartes Boîtier 3D conçu et réal... »

Discussion:Binome2021-1

2022-05-05T17:56:32Z

Aboe : Page créée avec « Carte USB fonctionnelle et personnelle Carte Annexe non fonctionnelle mais pour cause de problème communication SPI avec DAC. wiki moyen pour l'instant, alimenté à ch... »

Carte USB fonctionnelle et personnelle

Carte Annexe non fonctionnelle mais pour cause de problème communication SPI avec DAC.

wiki moyen pour l'instant, alimenté à chaque séance mais sans plus

note provisoire : 17/20

BE 2021-2022

2022-04-07T18:12:00Z

Aboe : /* Bibliothèque LUFA */

= Présentation du bureau d'étude =

Nous vous proposons de découvrir ce qu'est réellement cet objet devenu banal appelé clé USB (Universal Serial Bus).

[[File:Firefly-serenity-usb-flash-drive.jpg|thumb|center|200px]]

Le bureau d'étude consiste à construire de A à Z une clé USB :
* en créant un circuit électronique ou PCB (Printed Circuit Board) à l’aide d’un logiciel ;
* en soudant des composants électroniques (micro-contrôleur, mémoire FLASH, ...) ;
* en programmant le micro-contrôleur pour gérer la communication USB en utilisant la bibliothèque LUFA (Lightweight USB Framework for AVRs) ;
* en programmant le micro-contrôleur pour accéder à la mémoire ;
* en fabriquant un beau boitier pour votre clef.

Pour personnaliser votre clé n'hésitez pas à ajouter des fonctionnalités :
* LED qui clignotent lors des accès en lecture ou écriture ;
* vumètre qui indique le remplissage de la clé ;
* micro-interrupteurs pour verrouiller la clé ;
* vibreur parce que c'est possible, vous trouverez bien une justification ;
* microphone permettant d’espionner les conversations ;
* toute autre fonction plus ou moins utile mais qui vous inspire ...

Vous allez d'abord réaliser une carte gérant uniquement une des fonctionnalités annexes de votre carte. Cette carte comportera un micro-contrôleur facile à souder : un ATTiny84. Ainsi cette première carte sera un minimum autonome. Par la suite, vous vous attacherez à concevoir la carte complète avec un micro-contrôleur plus puissant possédant des capacités USB matérielle comme l'ATMega16u2. Pour la première carte n'hésitez pas à consulter les pages Wiki de vos prédécesseurs, ils se sont servis d'un ATTiny84 pour réaliser un dé électronique.

Les supports de la présentation de ce bureau d'études : [[Media:BE_clef_USB.pdf]].

= Survol d'USB =

== Evolution des connexions USB ==

L'acronyme USB signifie "Universal Serial Bus" et effectivement l'USB peut être défini comme un bus USB très verbeux. L'USB est géré par un consortium autonome "USB Implementers Forum".

[[File:USB-2.png|thumb|left|300px]] Jusqu'à la version 2, l'acronyme est fidèle à la réalité. Pour ces périphériques, 3 vitesses de transfert sont possibles sur la paire différentielle :
* basse vitesse : 1,5 Mb/s ;
* pleine vitesse : 12 Mb/s ;
* haute vitesse : 480 Mb/s.
<br style="clear: both;"/>
[[File:USB-3.jpg|thumb|right|300px]] A partir de l'USB 3.0, la notion de bus série est un peu oubliée. La vitesse augmente en utilisant les deux nouvelles paires blindées : 5Gb/s (super vitesse).
<br style="clear: both;"/>
[[File:USB-4.png|thumb|left|500px]] Et maintenant USB (USB 3.1, USB 3.2, USB 4) se prend pour de l'Ethernet. En effet, le connecteur USB-C ajoute, à la paire historique, quatre paires blindées. USB 3.2 promet des vitesses jusqu'à 20G/s.
<br style="clear: both;"/>

== Un protocole verbeux ==

[[File:USB-communication.gif|thumb|left|600px]]
L'initialisation d'un périphérique USB se fait comme suit :
* détection électrique de la connexion du périphérique ;
* alimentation électrique du périphérique ;
* utilisation de l'adresse temporaire 0 sur le bus ;
* récupération de la taille des messages pour le point d'accès 0 ;
* envoi de l'adresse au périphérique sur le point d'accès 0 ;
* envoi des descripteurs du périphérique au contrôleur USB via le point d'accès 0.
Pour un périphérique simple :
* souris : environ 100 octets pour le descripteur de configuration ;
* clavier : environ 150 octets pour le descripteur de configuration.
<br style="clear: both;"/>

[[File:USB-descripteurs.gif|thumb|right|700px]]
Les points d'accès (terminaison sur le schéma) :
* des identifiants sur 8 bits (numéro sur 4 bits) ;
* un point d'accès de contrôle de numéro 0 bidirectionnel ;
* les communications se font de ou vers les points d'accès ;
* un sens de communication (bit de poid fort) :
** IN => du périphérique vers le contrôleur ;
** OUT => du contrôleur vers le périphérique.
* la direction est IN ou OUT vis à vis de l’hôte.
Plusieurs types de points d'accès :
* isodromique (isochronous) : débit réservé (e.g. vidéo en temps réel) ;
* par interruption (interrupt) : latence garantie (e.g. souris) ;
* de volume (bulk) : débit maximal sans garantie (e.g. clef mémoire).
<br style="clear: both;"/>

= Logiciels =

Pour la conception de circuits imprimés nous vous recommandons le logiciel [http://fritzing.org/home/ fritzing].

Pour la découpe laser de nombreux utilisateurs utilisent [https://inkscape.org/fr/ inkscape].

Pour la conception 3D vous pouvez tenter [http://www.freecadweb.org/?lang=fr_FR freeCAD]. Une solution en ligne existe : [https://www.onshape.com/ onshape].

Pour la programmation du micro-contrôleur vous utiliserez le compilateur C <tt>avr-gcc</tt> et le logiciel de téléversement <tt>dfu-programmer</tt>.

= Cartes intermédiaires =

Pour les élèves n'ayant jamais conçu de carte électronique il est conseillé de concevoir une première carte ne comportant que la partie spécifique de leur clef USB.

Composant Fritzing SOIC-10 : [[File:SOIC-10.zip]] (à renommer en <code>SOIC-10.fzpz</code>).

= Les composants électroniques =

[[File:atmega16u2.png|thumb|left|200px|ATMega16u2]]
Le coeur de votre clé va être un micro-contrôleur AVR plus exactement l'ATMega16u2. Ce micro-contrôleur possède l'électronique nécessaire pour la gestion d'un bus USB 2.0. Un document très important pour comprendre le fonctionnement de ce micro-contrôleur est le document technique (datasheet en patoi) : [http://ww1.microchip.com/downloads/en/DeviceDoc/doc7799.pdf].
<br style="clear: both;"/>

[[File:adesto64Mb.jpg|thumb|left|200px|AT45DB641E-SHN2B-T]]
[[File:MT29F128G08.jpg|thumb|right|200px|MT29F128G8]]
Sans mémoire une clé n'est pas une clé.

Vous pouvez utiliser des mémoires AT45DB641E faciles à gérer avec un ATMega16u2. Ces mémoires sont accessibles par un bus série SPI et facile à souder. Par contre elles sont de faible capacité (64Mb). Le document technique [https://www.adestotech.com/wp-content/uploads/DS-45DB641E-027.pdf] de ces mémoires permet de connaître les commandes pour les configurer et y accéder en lecture et en écriture.

Si vous êtes téméraire, vous pouvez utiliser une mémoire MT29F128G8 accessible par un bus de 8 bits, plus difficile à souder, plus difficile à programmer mais d'une capacité intéressante (128Gb). La documentation technique est plus difficile à trouver, il faut aller sur le site du fabricant (micron) et montrer patte blanche. Vous trouverez le document dans le répertoire éponyme des machines de projet.
<br style="clear: both;"/>

Il vous faudra aussi quelques autres composants comme un quartz, des résistances, des condensateurs, des diodes, des régulateurs de tension et bien sur des LED pour ajouter un peu de lumière. La carte de base peut être décrite comme suit.
* Le micro-contrôleur peut être accompagné d'un quartz à 8Mhz et de ses condensateurs et résistance.
* Le micro-contrôleur peut être alimenté par le connecteur USB en 5v (broche UVCC) mais avec ses lignes VCC et AVCC bouclées sur la sortie UCAP du régulateur 3.3v interne.
* Un convertisseur 5v vers 3.3v est nécessaire pour l'alimentation des mémoires.
* Le micro-contrôleur dialogue avec les mémoires par le bus SPI, une ligne de sélection est nécessaire par mémoire.

Pour la conception de votre clé vous pouvez vous appuyer sur un prototype de clef réalisé pour ce bureau d'études. Pour vous faciliter la vie il est cependant recommandé :
* de prévoir un vrai connecteur ISP (connecteur 2x3 broches) pour la programmation initiale du micro-contrôleur ;
* de prévoir un connecteur FTDI (comportant principalement la liaison série) pour la facilité de déverminage.

== Cartes version beta ==
[[File:cle_usbv2_schema.png|thumb|left|400px|Schéma électronique]]
[[File:clef_usbv2_pcb.png|thumb|right|400px|Carte électronique]]
Une piste parasite entre masse et 3,3v a été supprimée, le <tt>reset</tt> est en 3,3v et un mini-connecteur ICSP a été ajouté.
Le fichier source Fritzing est disponible : [[Media:cle_usbv2.zip]] (renommer en <tt>.fzz</tt>).
<br style="clear: both;"/>

[[File:cle_usb_bisv2_schema.png|thumb|left|400px|Schéma électronique]]
[[File:clef_usb_bisv2_pcb.png|thumb|right|400px|Carte électronique]]
Le <tt>reset</tt> est en 3,3v et un mini-connecteur ICSP a été ajouté.
Le fichier source Fritzing est disponible : [[Media:cle_usb_bisv2.zip]] (renommer en <tt>.fzz</tt>).
<br style="clear: both;"/>

Il peut y avoir des problèmes lors du chargement des fichiers, des composants peuvent être déclarés absents. Essayez d'importer les composants suivants :
* mémoire MT29F128G8 : [[file:MT29F128G08.zip]]
* mémoire AT45DB641E : [[file:SO08-EIAJ.zip]]
* quartz FA238 : [[file:FA238.zip]]

Renommez les fichiers de <tt>.zip</tt> en <tt>.fzpz</tt> avant de les importer dans Fritzing.

= Test des cartes =

== Premier test, faire clignoter une LED par programmation DFU ==

[[File:cle_usb_recto.jpg|thumb|left|400px|Recto des deux cartes]]
[[File:cle_usb_verso.jpg|thumb|right|400px|Verso des deux cartes]]
Vision recto et verso des deux circuits décrit dans la section précédente (ancienne version à gauche). A noter que dans l'ancienne version seule les deux puces mémoire se trouvent au recto. Pour la nouvelle version la carte a du être agrandie et le micro-contrôleur rejoint la mémoire au verso.
<br style="clear: both;"/>

La première étape de test consiste à insérer les PCB dans un port USB. Remarquez la sur-épaisseur réalisée à l'aide d'un papier un peu épais pour assurer le contact. Si l'ATMega16u2 est fonctionne correctement, en lançant l'utilitaire <tt>lsusb</tt> vous devez voir apparaître un périphérique labellé <tt>Atmel DFU device</tt>.

Pour tester plus en avant, il est proposé d'envoyer sur le micro-contrôleur un programme permettant de faire clignoter la LED connectée au micro-contrôleur (la LED est contrôlée par PB6 sur l'ancienne version et sur PB0 sur la nouvelle).

Vous pouvez trouver les programmes de test dans cette archive : [[Media:ClefUSB.zip]]. Pour compiler les programmes, il suffit de se placer dans le répertoire correspondant à la version de la clef et lancer le <tt>makefile</tt> avec la commande <tt>make</tt>. Pour télécharger le programme un simple <tt>make upload</tt> suffit. Pour remettre les micro-contrôleur en mode DFU pour les reprogrammer, il faut court-circuiter les broches <tt>reset</tt> et de la masse (connecteur à deux broches sur les deux cartes).

== Premier problème, correction par programmation SPI ==

Voila le résultat de l'exécution du programme de test du micro-contrôleur sur la nouvelle version : [[Media:ClefUSBTestLed.mp4]].

Force est de constater un problème, la LED clignote bien trop lentement. Quelques recherches apprennent que les <tt>ATMega16u2</tt> sont vendus configurés avec un diviseur d'horloge par 8 activé. Le micro-contrôleur fonctionne donc à 1MHz et pas à 8Mhz comme souhaité. Ce type de configuration passe par une reconfiguration des <tt>fuses</tt> du micro-contrôleur. Manque de chance ces <tt>fuses</tt> ne peuvent être changées que par programmation SPI : impossible de les modifier en mode DFU. Voir le paragraphe ci-après pour comprendre comment se fait une programmation par SPI.

[[File:cle_mini_isp.jpg|thumb|left|300px|Ancienne clef, fils soudés au vol et programmateur SPI]]
[[File:cle_mini_icsp.jpg|thumb|right|300px|Nouvelle clef, fils soudés sur le micro-ICSP et programmateur SPI]]
Les premières version de PCB n'étaient pas prévues pour ce type de programmation. Le mode DFU semblait suffisant. Pour faciliter cette programmation, des via ont été placées de façon à implanter un mini connecteur ICSP. Une erreur a été corrigée en passant : la ligne <tt>reset</tt> du micro-contrôleur était alimentée en 5v, elle a été passée à 3,3v. En attendant les nouvelles cartes, des fils ont été soudés sur les cartes pour avoir un accès au bus SPI et au <tt>reset</tt>. D'ailleurs, une malheureuse tentative de programmation en 5v ayant grillé les micro-contrôleur, d'autres cartes version alpha ont du être soudées.

Une fois le dispositif de programmation SPI adéquat mis au point, une configuration est tentée pour désactiver la division de l'horloge (modification de la valeur de l'octet de configuration appelé <tt>lfuse</tt>) :

avrdude -c arduino -p atmega16u2 -P /dev/ttyACM0 -b 19200 -U lfuse:w:0xFF:m
<br style="clear: both;"/>

Cette configuration échoue : le micro-contrôleur est passé, en usine, en état verrouillé. Vous pouvez vérifier cela avec la commande ci-dessous et en utilisant l'outil de calcul des <tt>fuses</tt> en ligne [http://eleccelerator.com/fusecalc/fusecalc.php?chip=atmega16u2].

avrdude -c arduino -p atmega16u2 -P /dev/ttyACM0 -b 19200 -U lock:r:-:h

Il faut donc totalement réinitialiser le micro-contrôleur :

avrdude -c arduino -p atmega16u2 -P /dev/ttyACM0 -b 19200 -t
avrdude> erase
avrdude> quit

Il est alors possible de modifier l'octet de configuration <tt>lfuse</tt> comme indiqué ci-dessus. Sauf que maintenant le micro-contrôleur ne contient même plus l'amorçeur. Il n'est plus possible de le programmer en mode DFU. Il ne semble pas possible de mettre la main sur l'amorceur du fondeur pour <tt>ATMega16u2</tt>. Heureusement l'amorceur pour une précédente version de la puce est disponible : [[media:at90usb162-bl-usb-1_0_5.zip]]. Il est assez simple d'installer l'amorceur par programmation SPI :

avrdude -c arduino -p atmega16u2 -P /dev/ttyACM0 -b 19200 -U flash:w:at90usb162-bl-usb-1_0_5.hex

Après la modification de l'octet de configuration <tt>lfuse</tt>, la LED clignote normalement : [[media:ClefUSBTestLedBis.mp4]]. A noter qu'il faut maintenant télécharger le programme en utilisant <tt>at90usb162</tt> comme cible au lieu de <tt>atmega16u2</tt> à cause de la différence d'amorceur.

== Second test, accès aux mémoires ==

Il faut maintenant souder le régulateur 3,3v pour alimenter les mémoires et aussi souder les-dites mémoires.

Ensuite il faut tester si l'accès aux mémoires fonctionne. Les programmes sont différents suivant les types de mémoire.

=== Test des mémoires AT45DB641E ===

[[File:cle_usb_verso_AT45DB641E.jpg|thumb|left|300px|Mémoires AT45DB641E]]
Pour tester une des deux mémoires, il faut déjà sélectionner la mémoire sur le bus SPI. La première mémoire se sélectionne en passant la ligne <tt>PD0</tt> à l'état bas. Pour la seconde mémoire, il faut utiliser la ligne <tt>PB4</tt>. La broche <tt>reset</tt> des deux mémoires est reliée à la ligne <tt>PB5</tt> du micro-contrôleur. Il faut donc passer <tt>PB5</tt> en sortie et la mettre à l'état haut.

Pour tester une mémoire, il est possible de demander ses identifiants. Pour cela, il faut envoyer sur le bus SPI, une fois la mémoire sélectionnée, l'octet <tt>0x9F</tt>. Ensuite, il faut lire les cinq octets des identifiants (ID fabricant, ID de la mémoire, ...) puis il faut remonter la ligne de sélection à l'état haut.

Un programme de détection est disponible [[Media:ClefUSBTestMem.zip]]. Le test commence par 10 flashes rapides sur la LED de test. Pour simplifier la lecture du résultat, un test validé donne lieu à 5 flashes et un test en échec à un seul flash. Les deux mémoires sont testées tour à tour. Le prototype de clef USB avec des mémoires AT45DB641E passe avec succès ce test.

Pour aller plus loin, il faut écrire dans les mémoires et vérifier, par une lecture, que les écritures ont été bien effectuées.

Un premier programme de test des mémoires est disponible [[Media:ClefUSBTestMemRW.zip]]. Ce programme écrit cinq octets dans le premier bloc de la première mémoire, les lit, les multiplie par 2 et écrit les résultats dans le premier bloc de la seconde mémoire. Le test commence encore par 10 flashes rapides. Un test effectué avec succès donne lieu à 5 flashes, en cas d'échec un seul flash. Le prototype de clef USB avec des mémoires AT45DB641E passe avec succès ce test.

Un second programme de test de la première mémoire est disponible [[Media:ClefUSBTestMemRW2.zip]]. Ce programme écrit des valeurs séquentielles dans tous les blocs puis vérifie par des lectures que les écritures étaient bien effectuées. Le test commence encore par 10 flashes rapides. Ensuite un flash de contrôle est effectué tous les 256 blocs en écriture comme en lecture. C'est l'occasion de voir que les écritures sont plus lentes que les lectures. Après test des 8M de la première mémoire le résultat est donné en boucle. Toujours 5 flashes pour un succès et 1 pour un échec. Le résultat est répété toutes les 5 minutes histoire de pouvoir laisser le test se dérouler tout seul (test assez long).

<br style="clear: both;"/>

=== Test de la mémoire MT29F128G8 ===

[[File:cle_usb_verso_MT29F128G8.jpg|thumb|left|150px|Mémoires MT29F128G8]]
L'accès à cette mémoire se fait par un bus de 8 bits. Le bus est utilisé à la fois pour envoyer des commandes et des données vers la mémoire mais aussi pour récupérer les données stockées
en mémoire.

Les mémoires MT29F peut comporter plusieurs puces adressables séparémement, chaque puce pouvant comporter plusieurs unités logiques (LUN). La programmation commence par une réinitialisation des puces. Pour cela il suffit d'envoyer la commande <code>0xff</code> à chaque puce et d'attendre que la ligne d'activité repasse au niveau "libre".

Ensuite pour tester la mémoire, il est possible de lui demander divers identifiants. Pour cela, il faut envoyer la commande <code>0x90</code> suivie des adresses <code>0x00</code>, <code>0x20</code> ou <code>0x40</code> suivant l'identifiant souhaité. Les octets d'identification peuvent alors être récupérés, un par un, sur le bus 8 bits.

Le programme de récupération de l'identification est disponible [[Media:ClefUSBGoIDBasique.zip]]. Le test commence par 10 flashes rapides sur la LED de test. Les octets de l'identification sont ensuite "affichés" sur la LED de test. Cet affichage se fait bit par bit : un flashe pour un 0 et deux flashes pour un 1. Le programme se termine par 5 flashes rapides. Vérifiez avec la documentation de la mémoire que les octets donnés par le programme de test sont ceux attendus.

<br style="clear: both;"/>

= Programmation de micro-contrôleur par SPI =

Nativement les micro-contrôleurs AVR peuvent être programmés via le bus SPI. Généralement un amorceur (bootloader) est installé sur ces micro-contrôleurs pour qu'ils puissent être programmés plus facilement par une connexion série pure (cas de l'ATMega328p par exemple) ou par une connexion USB (cas de l'ATMega16u2). Malheureusement les amorceurs peuvent être effacés par une mauvaise manoeuvre ou ne permettent pas de configurer tous les aspects du micro-contrôleur.

[[File:uno_as_isp.jpg|thumb|left|400px|Arduino Uno comme programmateur]]
Généralement pour une programmation de micro-contrôleur par bus SPI, un connecteur ICSP est utilisé. Ce connecteur regroupe les lignes du bus SPI, la masse, l'alimentation et le <tt>reset</tt>. Un simple Arduino UNO peut-être utilisé comme programmateur par bus SPI. Les lignes MISO, MOSI, SCK, GND, VCC du programmateur sont connectées sur les mêmes lignes de la cible. La ligne 10 du programmateur est connectée sur le <tt>reset</tt> de la cible. Le programme ArduinoISP doit être téléversé sur le UNO jouant le rôle de programmateur. Ce programme fait partie des exemples fournis avec l'IDE Arduino.
<br style="clear: both;"/>

Un exemple d'utilisation d'un programmateur par bus SPI pour obtenir les <tt>fuses</tt> d'un <tt>ATMega16u2</tt> (les <tt>fuses</tt> sont des octets de configuration bas niveau du micro-contrôleur) :

avrdude -c arduino -p atmega16u2 -P /dev/ttyACM0 -b 19200 -v

Un exemple pour télécharger un programme par SPI sur un <tt>ATMega16u2</tt> :

avrdude -c arduino -p atmega16u2 -P /dev/ttyACM0 -b 19200 -U flash:w:programme.hex

Dans ces exemples, il est supposé que le port série associé à l'UNO est <tt>/dev/ttyACMO</tt>.

[[File:minipro_as_isp.jpg|thumb|left|400px|Arduino mini-pro comme programmateur]]
Si le micro-contrôleur est alimenté en 3,3v utiliser un Arduino Uno comme programmateur est une mauvaise idée : un UNO fonctionne à 5v et la communication SPI entre une plateforme à 5v et une autre à 3,3v ne fonctionne pas. Il existe assez peu de plateformes Arduino en 3,3v. Vous pouvez utiliser un Arduino Mini Pro 3,3v en conjonction avec un FTDI (convertisseur USB/série) lui aussi en 3,3v. Le Mini Pro ne dispose pas d'un connecteur ICSP. Il faut utiliser la ligne 11 pour connecter la ligne MOSI de la cible, la ligne 12 pour MISO et la ligne 13 pour SCK.
<br style="clear: both;" />

L'utilitaire <tt>avrdude</tt> peut être utilisé pour programmer la cible comme avec le programmateur à base d'UNO. Attention le port série sera probablement <tt>/dev/ttyUSBO</tt> cette fois.

= Bibliothèque LUFA =

Pour la gestion du bus USB par le micro-contrôleur nous allons nous appuyer au maximum sur la bibliothèque USB LUFA. Cette bibliothèque permet d'exploiter plus facilement les aspects USB des micro-contrôleurs AVR comme l'ATMega16u2.

Vous pouvez télécharger la dernière version de la bibliothèque [http://www.fourwalledcubicle.com/LUFA.php]. Il est ensuite conseillé d'effectuer quelques manipulations pour pouvoir développer dans de bonnes conditions.
* Créez un répertoire <tt>PolytechLille</tt> au même niveau que les répertoires <tt>Demos</tt> et <tt>Projects</tt>.
* Dans ce répertoire copiez la démonstration de périphérique USB bas niveau <tt>MassStorage</tt>. Au niveau du <tt>makefile</tt> indiquez <tt>atmega16u2</tt> comme micro-contrôleur, <tt>NONE</tt> comme platine et restez à 8Mhz.
* Il faut ensuite modifier la configuration de la mémoire et les fonctions d'accès à cette mémoire dans le sous-répertoire <tt>Lib</tt> du répertoire <tt>PolytechLille/MassStorage</tt>. Pour vous aider une version modifiée de la démonstration <tt>MassStorage</tt> est disponible [[media:MassStoragePeiP.zip]]. Dans cette version, vous n'avez à modifier que les fichiers <tt>Lib/DataflashManager.h</tt> et <tt>Lib/DataflashManager.c</tt> en vous appuyant sur les programmes de test des mémoires.

Une tendance naturelle est de créer un tableau pour stocker une page mémoire mais avec un ATMega16u2 il vaut mieux éviter : ce micro-contrôleur ne possède que 512 octets de mémoire vive. Même allouer un tableau pour une page de 256 octets n'est pas une évidence sachant que la bibliothèque LUFA consomme déjà de la mémoire. Vous écrirez donc les octets un à un dans le tampon d'écriture des mémoires et vous lirez les octets d'une page mémoire un à un.

Pour téléverser votre programme sur l’<tt>ATMega16u2</tt>, le paquetage Debian <tt>dfu-programmer</tt> est nécessaire. Installez-le au besoin. La procédure à suivre pour charger votre programme sur l’<tt>ATMega16u2</tt> est la suivante :

* court-circuitez momentanément les lignes reset et masse de l’<tt>ATMega16u2</tt>, l'utilitaire <tt>lsusb</tt> doit lister la carte comme étant en mode DFU, vous pouvez alors exécuter les commandes suivantes :
** <tt>dfu-programmer at90usb162 erase</tt>
** <tt>dfu-programmer at90usb162 flash MassStorage.hex</tt>
** <tt>dfu-programmer at90usb162 reset</tt>
* débranchez et rebranchez votre carte, votre programme doit être actif sur le micro-contrôleur.

= Test du programme avec la bibliothèque LUFA =

Un premier test très simple à réaliser consiste à compiler le programme <tt>MassStoragePeiP</tt> sans ajouter les accès à la mémoire puis à le télécharger sur le micro-contrôleur. Vous devriez déjà vous apercevoir que votre carte est reconnue comme une clef USB. Sur un système Linux, les deux utilitaires <tt>dmesg</tt> et <tt>lsblk</tt> vous en convaincront.

# dmesg | tail
[21942.134207] usb 1-1: new full-speed USB device number 4 using xhci_hcd
[21942.333156] usb 1-1: New USB device found, idVendor=03eb, idProduct=2045, bcdDevice= 0.01
[21942.333161] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=220
[21942.333163] usb 1-1: Product: LUFA Mass Storage Demo
[21942.333166] usb 1-1: Manufacturer: Dean Camera
[21942.333168] usb 1-1: SerialNumber: 758303337383514140C1
[21942.339211] usb-storage 1-1:1.0: USB Mass Storage device detected
[21942.339407] scsi host6: usb-storage 1-1:1.0
[21943.358141] scsi 6:0:0:0: Direct-Access LUFA Dataflash Disk 0.00 PQ: 0 ANSI: 0
[21943.358778] sd 6:0:0:0: Attached scsi generic sg2 type 0
[21943.359523] sd 6:0:0:0: [sdb] 2048 512-byte logical blocks: (1.05 MB/1.00 MiB)
[21943.359910] sd 6:0:0:0: [sdb] Write Protect is off
[21943.359915] sd 6:0:0:0: [sdb] Mode Sense: 00 00 00 00
[21943.360221] sd 6:0:0:0: [sdb] Asking for cache data failed
[21943.360241] sd 6:0:0:0: [sdb] Assuming drive cache: write through
[21943.404925] sd 6:0:0:0: [sdb] Attached SCSI removable disk

# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 119,2G 0 disk
├─sda1 8:1 0 114,4G 0 part /
├─sda2 8:2 0 1K 0 part
└─sda5 8:5 0 4,9G 0 part [SWAP]
sdb 8:16 1 1M 0 disk
sr0 11:0 1 1024M 0 rom

Pour vous familiariser avec le code, vous pouvez tenter de changer les noms du produit, du fabricant, le numéro de série et même la taille de la clef.

Avant de faire un test de votre clef avec un système de fichier, vous pouvez tester si elle gère correctement ses blocs mémoires. Le programme [[media:TestBlock.zip]] permet d'effectuer une écriture dans les blocs et, dans un second temps, de vérifier que ces blocs contiennent bien les bonnes valeurs. Pour l'utiliser, insérez votre clef, trouvez le nom du périphérique avec la commande <tt>lsblk</tt> et lancez la commande ci-dessous (ici il est supposé que le nom du périphérique est <tt>/dev/sdb</tt>) :

./testblock /dev/sdb W

Une fois le programme terminé, enlevez la clef pour s'assurer que la lecture ne se fera pas dans les tampons, remettez la et envoyez la commande :

./testblock /dev/sdb R

Si le programme ne vous affiche pas de différence d'octet, c'est que votre clef fonctionne correctement.

Vous pouvez alors formater votre clef :

mkfs -t vfat /dev/sdb

La monter :

mount /dev/sdb /mnt

Mettre quelques fichiers dessus, la démonter (avec la commande <tt>umount</tt>) et vérifier que vos fichiers sont encore là quand vous reconnectez la clef.

= Calcul de l'espace occupée sur une clef USB =

Certains binômes cherchent à afficher le pourcentage d'espace libre sur leur clef USB. C'est possible à réaliser avec quelques hypothèses. Dans un premier temps nous allons supposer que la clef n'est pas partionnée et que le système de fichiers est de type FAT.

== Cas du système de fichiers FAT32 ==

Le système de fichier FAT32 peut être utilisé à partir d'environ 260Mo disponible.

Pour ce type de système de fichiers il est possible d'avoir une évalution de l'espace libre en utilisant deux champs de la structure "informations". Cette structure se trouve généralement dans le second bloc du système de fichier et comporte deux champs pour donner le nombre de groupes alloués et de groupes libres. Ces champs ne sont qu'approximatifs et malheureusement pas toujours mis à jour par les systèmes d'exploitation. Cela dit Linux fait correctement le travail. Un fichier C de démonstration est disponible : [[File:fat32disp.zip]].

== Cas du système de fichiers FAT12 ==

Pour les très petites clef (en dessous de 260Mo), seul le système de fichiers FAT12 peut fonctionner dans la famille des systèmes de fichiers FAT.

Pour ce système de fichiers la seule solution pour connaître la taille libre de la clef est de parcourir la table d'allocation des groupes de secteurs et de compter les groupes alloués.

D'un coté c'est assez simple car les groupes sont listés exhaustivement dans la table d'allocation et d'un autre coté en FAT12 un groupe est géré sur 12 bits, il faut donc regarder les groupes par deux (3 octets utilisés pour deux groupes).

Un programme C de démonstration est fourni : [[File:fatdisp.zip]].

Le principe du programme est assez simple :
* le premier bloc est lu et quelques champs sont récupérés :
** taille, en nombre de blocs, des groupes ;
** nombre de blocs réservés ;
** taille, en nombre de blocs, des tables d'allocation ;
** nombre total de blocs.
* ensuite les blocs reservés sont passés ;
* enfin les chaînages des groupes sont lus deux par deux (en lisant 3 octets).

La partie de lecture des chaînages est un peu complexe en deux points :
* un calcul doit être effectué pour séparer les trois octets en deux chaînages ;
* l'énumération se fait sur les octets et pas sur les blocs.

Le dernier point fait que le programme de démonstration peut être assez facile à adapter sur la clef : au lieu de lire des blocs de 512 octets avec la primitive <code>read</code> il faut juste la fonction de lecture des pages avec la fonction <code>AT45DB641E_read_page</code> présentée plus haut.

== Implantation dans la clef ==

Il ne faut surtout pas lancer le calcul de l'espace libre à chaque accès à la clef par le bus USB. Une façon efficace de faire est la suivante :
* lire les informations sur le premier bloc à l'initialisation et stocker les informations pertinentes en mémoire ;
* noter quand un bloc de la table d'allocation est modifié ;
* quand un bloc de données est accédé et que la table d'allocation a été modifiée lancer la fonction d'analyse de la table d'allocation.

= Réalisations des binômes =

{| class="wikitable"
! Numéro !! Elèves !! Fonctionnalité supplémentaire !! Page !! Carte finale
|-
| Binôme 1
| CRUCHET SIMON - JOLY MAXIME
| Clé USB plaisir
| [[Binome2021-1|Binôme 1 2021/2022]]
|
|-
| Binôme 2
| CHEVALIER Juliette - MENUGE Clément
| Clé USB avec manette + LED
| [[Binome2021-2|Binôme 2 2021/2022]]
|
|-
| Binôme 3
| ISMAIL Amine & ZAIDI Alissia
| Clé USB SanGoku qui diffuse de la fumée odorante + LED
| [[Binome2021-3|Binôme 3 2021/2022]]
|
|-
| Binôme 4
| NOM Prénom
| Description rapide de votre spécificité
| [[Binome2021-4|Binôme 4 2021/2022]]
|
|-
| Binôme 5
| Louis BONNINGRE & Alexis NOEL
| Boutton écriture rapide + led multicolore
| [[Binome2021-5|Binôme 5 2021/2022]]
|
|-
| Binôme 6
| DELAUNOY Tanguy & DERYCKERE Louis
| Clé USB lampe torche
| [[Binome2021-6|Binôme 6 2021/2022]]
|
|-
| Binôme 7
| Alexis JENBACK & DAHMANI Jibril
| Description rapide de votre spécificité
| [[Binome2021-7|Binôme 7 2021/2022]]
|
|-
| Binôme 8
| Louis GAMBART & Martin CHAUVELIERE
| Bluetooth pour controle de souris via Application mobile
| [[Binome2021-8|Binôme 8 2021/2022]]
|
|-
| Binôme 9
| Titouan CHACHIGNOT & Romain DUHR
| Possibilité de changer de profil sur la clé (mémoire divisée)
| [[Binome2021-9|Binôme 9 2021/2022]]
|
|-
| Binôme 10
| Anaël POULET & Théophile CASTELAIN
| Clé USB avec code de déverrouillage
| [[Binome2021-10|Binôme 10 2021/2022]]
|
|-
|}

Fichier:Carteg1.zip

2022-03-24T18:43:01Z

Aboe : Aboe a téléversé une nouvelle version de Fichier:Carteg1.zip

Fichier:Carteg1.zip

2022-03-24T18:42:28Z

Aboe :

Binome2021-1

2022-03-24T18:42:06Z

Aboe : /* COMPOSANTS */

=<div class="mcwiki-header" style="border-radius: 15px; border-color: #080004; padding: 15px; font-weight: bold;color: #FFFFFF; text-align: center; font-size: 80%; background:#FF00C8; vertical-align: top; width: 98%;"> INTRODUCTION </div>=

Durant ce BE, nous avons décidé de réaliser une clé qui possédé un haut parleur ainsi qu'un vibreur permettant de se satisfaire

Description : Ce projet est une clé USB ayant une spécialité qui ferra fureur. Elle permet de stocker des données comme des photos ou bien des vidéos mais peut tout aussi bien vibrer mais aussi compter une belle histoire d'amour. Le but de se projet est de remonter le moral des personnes faisant du télétravail avec un objet passe partout et tout à fait anodin qui permet de passer une bien meilleure journée. La clé de forme cylindrique est fourni avec un long câble USB pour plus de maniabilité et d'aisance lors de l'utilisation.

https://azduino.com/bin/micronucleus/

[[Fichier:cle.zip]]

=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #FF00C8; vertical-align: top; width: 98%;"> Séance 1 </div>=
Création du binôme; choix de l'option ajouté à la clé

=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #FF00C8; vertical-align: top; width: 98%;"> Séance 2 </div>=
Début des recherches des différents composants requis pour la construction de notre clé + début du projet sur Fritzing (première esquisse produite)

[[Fichier:fritzing1.jpg|thumb|600px|center]]

=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #FF00C8; vertical-align: top; width: 98%;"> Séance 3 </div>=
Vérification de la part des professeurs du bon fonctionnement électronique du projet: Modification au niveau du HP (mise en place d'un convertisseur num/anal pour mettre des fichiers audio pré-enregistré)

=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #FF00C8; vertical-align: top; width: 98%;"> Séance 4 </div>=
Mise en place du convertisseur sur Fritzing et vérification par les professeurs. Possibilité d'avoir une clé Stéréo. Intégration d'un deuxieme HP sur le Fritzing mais possibilité d'en mettre qu'un seul

[[Fichier:fritzing2.jpg|thumb|600px|center]]

=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background:#FF00C8; vertical-align: top; width: 98%;"> Séance 5 </div>=
Routage de la carte externe

[[Fichier:routagecarteexterne.jpg|thumb|600px|center]]

=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #FF00C8; vertical-align: top; width: 98%;"> Séance 6 </div>=
Modifications du routage pour la carte

[[Fichier:routagecarteexternev2.jpg|thumb|600px|center]]

=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #FF00C8; vertical-align: top; width: 98%;"> Séance 7</div>=
Soudures effectuées vérification du fonctionnement de la carte

[[Fichier:photocarte1.jpg|thumb|600px|center]]

[[Fichier:photocarte2.jpg|thumb|600px|center]]

=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #FF00C8; vertical-align: top; width: 98%;"> Séance 8 </div>=
CC enlevé et test de programmation sur l'attiny 84 avec l'arduino

[[Fichier:photocarte3.jpg|thumb|600px|center]]

=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #FF00C8; vertical-align: top; width: 98%;"> Séance 9 </div>=
Programmation réussi test de vibration avec un vibreur piézo (vibration trop faible ==> On va partir sur un vibreur de telephone)
et test spi transfer

[[Fichier:photopiezo.jpg|thumb|600px|center]]

[[Fichier:Exemple45.png|thumb|600px|center]]

=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #FF00C8; vertical-align: top; width: 98%;"> Séance 10 </div>=
programmation vibreur pwm et test encodage haut parleur

=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #FF00C8; vertical-align: top; width: 98%;"> Séance 11 </div>=
Routage de la clé USB (ajout RX, TX et GND + ISP + Alimentation (+ , GND) de la carte fille directement sur la clé USB), carte fille refaite par le corps professoral.

=<div class="mcwiki-header" style="border-radius: 40px; padding: 15px; font-weight: bold; color: #FFFFFF; text-align: center; font-size: 80%; background: #FF00C8; vertical-align: top; width: 98%;"> Séance 12 </div>=
Début de la modélisation 3D du projet, début de la programmation en C de la clé USB

https://www.youtube.com/watch?v=bj57xuQS7L8

=<div class="mcwiki-header" style="border-radius: 15px; border-color: #080004; padding: 15px; font-weight: bold;color: #FFFFFF; text-align: center; font-size: 80%; background:#FF00C8; vertical-align: top; width: 98%;"> COMPOSANTS </div>=

Haut parleur :

Convertiseur Numérique/analogique : MCP48FVBXX
Cablage:
[[Fichier:MCP48FVBXX.jpg|thumb|600px|center]]

Micro-controleur : Attiny84
Pinout:
[[Fichier:Att84.jpg|thumb|600px|center]]

Carte essai par Alexandre :
[[Fichier:carteg1.zip]]

Binome2021-1

2022-03-24T18:41:11Z

Aboe : /* COMPOSANTS */

Discussion:Binome2020-1

2021-03-09T11:52:36Z

Aboe : /* Travail */

= Commentaires sur le BE =

== Wiki ==

Un bel effort avec les schéma des circuits. Vous pouvez ajouter une photo du circuit. Merci de corriger les coquilles, j'ai modifié ce qui me faisait le plus mal aux yeux mais relisez par vous-même. Très bonne idée d'inclure des simulations mais expliquez ce qu'il faut en conclure.

== Travail ==

Rien à redire au moment de la rédaction de ce commentaire. Carte intermédiaire conçue et réalisée. C'est dommage qu'elle soit non fonctionnelle (expliquez le problème dans le Wiki). Attendez le PCB industriel pour un second essai.

Vous pouvez vous inspirer de ce lien ... avec des capacités beaucoup plus petites, cela va sans dire : https://maker.pro/custom/projects/make-coil-gun-without-camera ou ici :http://pafgadget.free.fr/bidouillages/flash.htm ou ça : http://bxtronics.free.fr/how/appjetab/appjetab.htm

Discussion:Binome2020-1

2021-03-09T11:47:26Z

Aboe : /* Travail */

Discussion:Binome2020-1

2021-03-09T11:42:07Z

Aboe : /* Travail */

BE 2020-2021

2021-01-18T10:12:47Z

Aboe : /* Réalisations des binômes */

= Présentation du bureau d'étude =

Nous vous proposons de découvrir ce qu'est réellement cet objet devenu banal appelé clé USB (Universal Serial Bus).

[[File:Firefly-serenity-usb-flash-drive.jpg|thumb|center|200px]]

Le bureau d'étude consiste à construire de A à Z une clé USB :
* en créant un circuit électronique ou PCB (Printed Circuit Board) à l’aide d’un logiciel ;
* en soudant des composants électroniques (micro-contrôleur, mémoire FLASH, ...) ;
* en programmant le micro-contrôleur pour gérer la communication USB en utilisant la bibliothèque LUFA (Lightweight USB Framework for AVRs) ;
* en programmant le micro-contrôleur pour accéder à la mémoire ;
* en fabriquant un beau boitier pour votre clef.

Pour personnaliser votre clé n'hésitez pas à ajouter des fonctionnalités :
* LED qui clignotent lors des accès en lecture ou écriture ;
* vumètre qui indique le remplissage de la clé ;
* micro-interrupteurs pour verrouiller la clé ;
* vibreur parce que c'est possible, vous trouverez bien une justification ;
* microphone permettant d’espionner les conversations ;
* toute autre fonction plus ou moins utile mais qui vous inspire ...

Vous allez d'abord réaliser une carte gérant uniquement une des fonctionnalités annexes de votre carte. Cette carte comportera un micro-contrôleur facile à souder : un ATTiny84. Ainsi cette première carte sera un minimum autonome. Par la suite, vous vous attacherez à concevoir la carte complète avec un micro-contrôleur plus puissant possédant des capacités USB matérielle comme l'ATMega16u2. Pour la première carte n'hésitez pas à consulter les pages Wiki de vos prédécesseurs, ils se sont servis d'un ATTiny84 pour réaliser un dé électronique.

Les supports de la présentation de ce bureau d'études : [[Media:BE_clef_USB.pdf]].

= Survol d'USB =

== Evolution des connexions USB ==

L'acronyme USB signifie "Universal Serial Bus" et effectivement l'USB peut être défini comme un bus USB très verbeux. L'USB est géré par un consortium autonome "USB Implementers Forum".

[[File:USB-2.png|thumb|left|300px]] Jusqu'à la version 2, l'acronyme est fidèle à la réalité. Pour ces périphériques, 3 vitesses de transfert sont possibles sur la paire différentielle :
* basse vitesse : 1,5 Mb/s ;
* pleine vitesse : 12 Mb/s ;
* haute vitesse : 480 Mb/s.
<br style="clear: both;"/>
[[File:USB-3.jpg|thumb|right|300px]] A partir de l'USB 3.0, la notion de bus série est un peu oubliée. La vitesse augmente en utilisant les deux nouvelles paires blindées : 5Gb/s (super vitesse).
<br style="clear: both;"/>
[[File:USB-4.png|thumb|left|500px]] Et maintenant USB (USB 3.1, USB 3.2, USB 4) se prend pour de l'Ethernet. En effet, le connecteur USB-C ajoute, à la paire historique, quatre paires blindées. USB 3.2 promet des vitesses jusqu'à 20G/s.
<br style="clear: both;"/>

== Un protocole verbeux ==

[[File:USB-communication.gif|thumb|left|600px]]
L'initialisation d'un périphérique USB se fait comme suit :
* détection électrique de la connexion du périphérique ;
* alimentation électrique du périphérique ;
* utilisation de l'adresse temporaire 0 sur le bus ;
* récupération de la taille des messages pour le point d'accès 0 ;
* envoi de l'adresse au périphérique sur le point d'accès 0 ;
* envoi des descripteurs du périphérique au contrôleur USB via le point d'accès 0.
Pour un périphérique simple :
* souris : environ 100 octets pour le descripteur de configuration ;
* clavier : environ 150 octets pour le descripteur de configuration.
<br style="clear: both;"/>

[[File:USB-descripteurs.gif|thumb|right|700px]]
Les points d'accès (terminaison sur le schéma) :
* des identifiants sur 8 bits (numéro sur 4 bits) ;
* un point d'accès de contrôle de numéro 0 bidirectionnel ;
* les communications se font de ou vers les points d'accès ;
* un sens de communication (bit de poid fort) :
** IN => du périphérique vers le contrôleur ;
** OUT => du contrôleur vers le périphérique.
* la direction est IN ou OUT vis à vis de l’hôte.
Plusieurs types de points d'accès :
* isodromique (isochronous) : débit réservé (e.g. vidéo en temps réel) ;
* par interruption (interrupt) : latence garantie (e.g. souris) ;
* de volume (bulk) : débit maximal sans garantie (e.g. clef mémoire).
<br style="clear: both;"/>

= Logiciels =

Pour la conception de circuits imprimés nous vous recommandons le logiciel [http://fritzing.org/home/ fritzing].

Pour la découpe laser de nombreux utilisateurs utilisent [https://inkscape.org/fr/ inkscape].

Pour la conception 3D vous pouvez tenter [http://www.freecadweb.org/?lang=fr_FR freeCAD]. Une solution en ligne existe : [https://www.onshape.com/ onshape].

Pour la programmation du micro-contrôleur vous utiliserez le compilateur C <tt>avr-gcc</tt> et le logiciel de téléversement <tt>dfu-programmer</tt>.

= Les composants électroniques =

[[File:atmega16u2.png|thumb|left|200px|ATMega16u2]]
Le coeur de votre clé va être un micro-contrôleur AVR plus exactement l'ATMega16u2. Ce micro-contrôleur possède l'électronique nécessaire pour la gestion d'un bus USB 2.0. Un document très important pour comprendre le fonctionnement de ce micro-contrôleur est le document technique (datasheet en patoi) : [http://ww1.microchip.com/downloads/en/DeviceDoc/doc7799.pdf].
<br style="clear: both;"/>

[[File:adesto64Mb.jpg|thumb|left|200px|AT45DB641E-SHN2B-T]]
[[File:MT29F128G08.jpg|thumb|right|200px|MT29F128G8]]
Sans mémoire une clé n'est pas une clé.

Vous pouvez utiliser des mémoires AT45DB641E faciles à gérer avec un ATMega16u2. Ces mémoires sont accessibles par un bus série SPI et facile à souder. Par contre elles sont de faible capacité (64Mb). Le document technique [https://www.adestotech.com/wp-content/uploads/DS-45DB641E-027.pdf] de ces mémoires permet de connaître les commandes pour les configurer et y accéder en lecture et en écriture.

Si vous êtes téméraire, vous pouvez utiliser une mémoire MT29F128G8 accessible par un bus de 8 bits, plus difficile à souder, plus difficile à programmer mais d'une capacité intéressante (128Gb). La documentation technique est plus difficile à trouver, il faut aller sur le site du fabricant (micron) et montrer patte blanche. Vous trouverez le document dans le répertoire éponyme des machines de projet.
<br style="clear: both;"/>

Il vous faudra aussi quelques autres composants comme un quartz, des résistances, des condensateurs, des diodes, des régulateurs de tension et bien sur des LED pour ajouter un peu de lumière. La carte de base peut être décrite comme suit.
* Le micro-contrôleur peut être accompagné d'un quartz à 8Mhz et de ses condensateurs et résistance.
* Le micro-contrôleur peut être alimenté par le connecteur USB en 5v (broche UVCC) mais avec ses lignes VCC et AVCC bouclées sur la sortie UCAP du régulateur 3.3v interne.
* Un convertisseur 5v vers 3.3v est nécessaire pour l'alimentation des mémoires.
* Le micro-contrôleur dialogue avec les mémoires par le bus SPI, une ligne de sélection est nécessaire par mémoire.

Pour la conception de votre clé vous pouvez vous appuyer sur un prototype de clef réalisé pour ce bureau d'études.

== Cartes version alpha ==
[[File:cle_usb_schema.png|thumb|left|400px|Schéma électronique]]
[[File:clef_usb_pcb.png|thumb|right|400px|Carte électronique]]
<br style="clear: both;"/>
Le schéma décrit le circuit électronique partie par partie.
A partir du circuit, il faut créer une carte sans croisement de pistes pour éviter les court-circuits.
Le fichier source Fritzing est disponible : [[Media:cle_usb.zip]] (renommer en <tt>.fzz</tt>).

Une autre carte est disponible pour une mémoire parallèle de plus grande capacité. Attention cette carte n'a pas été testée.

[[File:cle_usb_bis_schema.png|thumb|left|400px|Schéma électronique]]
[[File:clef_usb_bis_pcb.png|thumb|right|400px|Carte électronique]]
<br style="clear: both;"/>
Le fichier source Fritzing est disponible : [[Media:cle_usb_bis.zip]] (renommer en <tt>.fzz</tt>).

== Cartes version beta ==
[[File:cle_usbv2_schema.png|thumb|left|400px|Schéma électronique]]
[[File:clef_usbv2_pcb.png|thumb|right|400px|Carte électronique]]
Une piste parasite entre masse et 3,3v a été supprimée, le <tt>reset</tt> est en 3,3v et un mini-connecteur ICSP a été ajouté.
Le fichier source Fritzing est disponible : [[Media:cle_usbv2.zip]] (renommer en <tt>.fzz</tt>).
<br style="clear: both;"/>

[[File:cle_usb_bisv2_schema.png|thumb|left|400px|Schéma électronique]]
[[File:clef_usb_bisv2_pcb.png|thumb|right|400px|Carte électronique]]
Le <tt>reset</tt> est en 3,3v et un mini-connecteur ICSP a été ajouté.
Le fichier source Fritzing est disponible : [[Media:cle_usb_bisv2.zip]] (renommer en <tt>.fzz</tt>).
<br style="clear: both;"/>

Il peut y avoir des problèmes lors du chargement des fichiers, des composants peuvent être déclarés absents. Essayez d'importer les composants suivants :
* mémoire MT29F128G8 : [[file:MT29F128G08.zip]]
* mémoire AT45DB641E : [[file:SO08-EIAJ.zip]]
* quartz FA238 : [[file:FA238.zip]]

Renommez les fichiers de <tt>.zip</tt> en <tt>.fzpz</tt> avant de les importer dans Fritzing.

= Test des cartes =

== Premier test, faire clignoter une LED par programmation DFU ==

[[File:cle_usb_recto.jpg|thumb|left|400px|Recto des deux cartes]]
[[File:cle_usb_verso.jpg|thumb|right|400px|Verso des deux cartes]]
Vision recto et verso des deux circuits décrit dans la section précédente (ancienne version à gauche). A noter que dans l'ancienne version seule les deux puces mémoire se trouvent au recto. Pour la nouvelle version la carte a du être agrandie et le micro-contrôleur rejoint la mémoire au verso.
<br style="clear: both;"/>

La première étape de test consiste à insérer les PCB dans un port USB. Remarquez la sur-épaisseur réalisée à l'aide d'un papier un peu épais pour assurer le contact. Si l'ATMega16u2 est fonctionne correctement, en lançant l'utilitaire <tt>lsusb</tt> vous devez voir apparaître un périphérique labellé <tt>Atmel DFU device</tt>.

Pour tester plus en avant, il est proposé d'envoyer sur le micro-contrôleur un programme permettant de faire clignoter la LED connectée au micro-contrôleur (la LED est contrôlée par PB6 sur l'ancienne version et sur PB0 sur la nouvelle).

Vous pouvez trouver les programmes de test dans cette archive : [[Media:ClefUSB.zip]]. Pour compiler les programmes, il suffit de se placer dans le répertoire correspondant à la version de la clef et lancer le <tt>makefile</tt> avec la commande <tt>make</tt>. Pour télécharger le programme un simple <tt>make upload</tt> suffit. Pour remettre les micro-contrôleur en mode DFU pour les reprogrammer, il faut court-circuiter les broches <tt>reset</tt> et de la masse (connecteur à deux broches sur les deux cartes).

== Premier problème, correction par programmation SPI ==

Voila le résultat de l'exécution du programme de test du micro-contrôleur sur la nouvelle version : [[Media:ClefUSBTestLed.mp4]].

Force est de constater un problème, la LED clignote bien trop lentement. Quelques recherches apprennent que les <tt>ATMega16u2</tt> sont vendus configurés avec un diviseur d'horloge par 8 activé. Le micro-contrôleur fonctionne donc à 1MHz et pas à 8Mhz comme souhaité. Ce type de configuration passe par une reconfiguration des <tt>fuses</tt> du micro-contrôleur. Manque de chance ces <tt>fuses</tt> ne peuvent être changées que par programmation SPI : impossible de les modifier en mode DFU. Voir le paragraphe ci-après pour comprendre comment se fait une programmation par SPI.

[[File:cle_mini_isp.jpg|thumb|left|300px|Ancienne clef, fils soudés au vol et programmateur SPI]]
[[File:cle_mini_icsp.jpg|thumb|right|300px|Nouvelle clef, fils soudés sur le micro-ICSP et programmateur SPI]]
Les premières version de PCB n'étaient pas prévues pour ce type de programmation. Le mode DFU semblait suffisant. Pour faciliter cette programmation, des via ont été placées de façon à implanter un mini connecteur ICSP. Une erreur a été corrigée en passant : la ligne <tt>reset</tt> du micro-contrôleur était alimentée en 5v, elle a été passée à 3,3v. En attendant les nouvelles cartes, des fils ont été soudés sur les cartes pour avoir un accès au bus SPI et au <tt>reset</tt>. D'ailleurs, une malheureuse tentative de programmation en 5v ayant grillé les micro-contrôleur, d'autres cartes version alpha ont du être soudées.

Une fois le dispositif de programmation SPI adéquat mis au point, une configuration est tentée pour désactiver la division de l'horloge (modification de la valeur de l'octet de configuration appelé <tt>lfuse</tt>) :

avrdude -c arduino -p atmega16u2 -P /dev/ttyACM0 -b 19200 -U lfuse:w:0xFF:m
<br style="clear: both;"/>

Cette configuration échoue : le micro-contrôleur est passé, en usine, en état verrouillé. Vous pouvez vérifier cela avec la commande ci-dessous et en utilisant l'outil de calcul des <tt>fuses</tt> en ligne [http://eleccelerator.com/fusecalc/fusecalc.php?chip=atmega16u2].

avrdude -c arduino -p atmega16u2 -P /dev/ttyACM0 -b 19200 -U lock:r:-:h

Il faut donc totalement réinitialiser le micro-contrôleur :

avrdude -c arduino -p atmega16u2 -P /dev/ttyACM0 -b 19200 -t
avrdude> erase
avrdude> quit

Il est alors possible de modifier l'octet de configuration <tt>lfuse</tt> comme indiqué ci-dessus. Sauf que maintenant le micro-contrôleur ne contient même plus l'amorçeur. Il n'est plus possible de le programmer en mode DFU. Il ne semble pas possible de mettre la main sur l'amorceur du fondeur pour <tt>ATMega16u2</tt>. Heureusement l'amorceur pour une précédente version de la puce est disponible : [[media:at90usb162-bl-usb-1_0_5.zip]]. Il est assez simple d'installer l'amorceur par programmation SPI :

avrdude -c arduino -p atmega16u2 -P /dev/ttyACM0 -b 19200 -U flash:w:at90usb162-bl-usb-1_0_5.hex

Après la modification de l'octet de configuration <tt>lfuse</tt>, la LED clignote normalement : [[media:ClefUSBTestLedBis.mp4]]. A noter qu'il faut maintenant télécharger le programme en utilisant <tt>at90usb162</tt> comme cible au lieu de <tt>atmega16u2</tt> à cause de la différence d'amorceur.

== Second test, accès aux mémoires ==

Il faut maintenant souder le régulateur 3,3v pour alimenter les mémoires et aussi souder les-dites mémoires.

Ensuite il faut tester si l'accès aux mémoires fonctionne. Les programmes sont différents suivant les types de mémoire.

=== Test des mémoires AT45DB641E ===

[[File:cle_usb_verso_AT45DB641E.jpg|thumb|left|300px|Mémoires AT45DB641E]]
Pour tester une des deux mémoires, il faut déjà sélectionner la mémoire sur le bus SPI. La première mémoire se sélectionne en passant la ligne <tt>PD0</tt> à l'état bas. Pour la seconde mémoire, il faut utiliser la ligne <tt>PB4</tt>. La broche <tt>reset</tt> des deux mémoires est reliée à la ligne <tt>PB5</tt> du micro-contrôleur. Il faut donc passer <tt>PB5</tt> en sortie et la mettre à l'état haut.

Pour tester une mémoire, il est possible de demander ses identifiants. Pour cela, il faut envoyer sur le bus SPI, une fois la mémoire sélectionnée, l'octet <tt>0x9F</tt>. Ensuite, il faut lire les cinq octets des identifiants (ID fabricant, ID de la mémoire, ...) puis il faut remonter la ligne de sélection à l'état haut.

Un programme de test est disponible [[Media:ClefUSBTestMem.zip]]. Pour communiquer la valeur des cinq octets d'identification, un système de clignotement de LED est implanté. Pour chaque bit un clignotement représente un 0 et deux clignotement représentent un 1. Le prototype de clef USB avec des mémoires AT45DB641E passe avec succès ce test.

Pour aller plus loin, il faut écrire dans les mémoires et vérifier, par une lecture, que les écritures ont été bien effectuées. Un programme de test est disponible [[Media:ClefUSBTestMemRW.zip]]. Ce programme écrit cinq octets dans la première mémoire, les lit, les multiplie par 2 et écrit les résultats dans la seconde mémoire. Les cinq octets de la seconde mémoire sont lus et communiqués avec le système de clignotement de LED décrit ci-dessus.
<br style="clear: both;"/>

=== Test de la mémoire MT29F128G8 ===

Cette mémoire est sélectionnée par défaut. Il faut juste arriver à lui envoyer un ordre en utilisant les 8 lignes de contrôle.

= Programmation de micro-contrôleur par SPI =

Nativement les micro-contrôleurs AVR peuvent être programmés via le bus SPI. Généralement un amorceur (bootloader) est installé sur ces micro-contrôleurs pour qu'ils puissent être programmés plus facilement par une connexion série pure (cas de l'ATMega328p par exemple) ou par une connexion USB (cas de l'ATMega16u2). Malheureusement les amorceurs peuvent être effacés par une mauvaise manoeuvre ou ne permettent pas de configurer tous les aspects du micro-contrôleur.

[[File:uno_as_isp.jpg|thumb|left|400px|Arduino Uno comme programmateur]]
Généralement pour une programmation de micro-contrôleur par bus SPI, un connecteur ICSP est utilisé. Ce connecteur regroupe les lignes du bus SPI, la masse, l'alimentation et le <tt>reset</tt>. Un simple Arduino UNO peut-être utilisé comme programmateur par bus SPI. Les lignes MISO, MOSI, SCK, GND, VCC du programmateur sont connectées sur les mêmes lignes de la cible. La ligne 10 du programmateur est connectée sur le <tt>reset</tt> de la cible. Le programme ArduinoISP doit être téléversé sur le UNO jouant le rôle de programmateur. Ce programme fait partie des exemples fournis avec l'IDE Arduino.
<br style="clear: both;"/>

Un exemple d'utilisation d'un programmateur par bus SPI pour obtenir les <tt>fuses</tt> d'un <tt>ATMega16u2</tt> (les <tt>fuses</tt> sont des octets de configuration bas niveau du micro-contrôleur) :

avrdude -c arduino -p atmega16u2 -P /dev/ttyACM0 -b 19200 -v

Un exemple pour télécharger un programme par SPI sur un <tt>ATMega16u2</tt> :

avrdude -c arduino -p atmega16u2 -P /dev/ttyACM0 -b 19200 -U flash:w:programme.hex

Dans ces exemples, il est supposé que le port série associé à l'UNO est <tt>/dev/ttyACMO</tt>.

[[File:minipro_as_isp.jpg|thumb|left|400px|Arduino mini-pro comme programmateur]]
Si le micro-contrôleur est alimenté en 3,3v utiliser un Arduino Uno comme programmateur est une mauvaise idée : un UNO fonctionne à 5v et la communication SPI entre une plateforme à 5v et une autre à 3,3v ne fonctionne pas. Il existe assez peu de plateformes Arduino en 3,3v. Vous pouvez utiliser un Arduino Mini Pro 3,3v en conjonction avec un FTDI (convertisseur USB/série) lui aussi en 3,3v. Le Mini Pro ne dispose pas d'un connecteur ICSP. Il faut utiliser la ligne 11 pour connecter la ligne MOSI de la cible, la ligne 12 pour MISO et la ligne 13 pour SCK.
<br style="clear: both;" />

L'utilitaire <tt>avrdude</tt> peut être utilisé pour programmer la cible comme avec le programmateur à base d'UNO. Attention le port série sera probablement <tt>/dev/ttyUSBO</tt> cette fois.

= Bibliothèque LUFA =

Pour la gestion du bus USB par le micro-contrôleur nous allons nous appuyer au maximum sur la bibliothèque USB LUFA. Cette bibliothèque permet d'exploiter plus facilement les aspects USB des micro-contrôleurs AVR comme l'ATMega16u2.

Vous pouvez télécharger la dernière version de la bibliothèque [http://www.fourwalledcubicle.com/LUFA.php]. Il est ensuite conseillé d'effectuer quelques manipulations pour pouvoir développer dans de bonnes conditions.
* Créez un répertoire <tt>PolytechLille</tt> au même niveau que les répertoires <tt>Demos</tt> et <tt>Projects</tt>.
* Dans ce répertoire copiez la démonstration de périphérique USB bas niveau <tt>MassStorage</tt>. Au niveau du <tt>makefile</tt> indiquez <tt>atmega16u2</tt> comme micro-contrôleur, <tt>NONE</tt> comme platine et restez à 8Mhz.
* Il faut ensuite modifier la configuration de la mémoire et les fonctions d'accès à cette mémoire dans le sous-répertoire <tt>Lib</tt> du répertoire <tt>PolytechLille/MassStorage</tt>. Pour vous aider une version modifiée de la démonstration <tt>MassStorage</tt> est disponible [[media:MassStoragePeiP.zip]]. Dans cette version, vous n'avez à modifier que les fichiers <tt>Lib/DataflashManager.h</tt> et <tt>Lib/DataflashManager.c</tt> en vous appuyant sur les programmes de test des mémoires.

Pour téléverser votre programme sur l’<tt>ATMega16u2</tt>, le paquetage Debian <tt>dfu-programmer</tt> est nécessaire. Installez-le au besoin. La procédure à suivre pour charger votre programme sur l’<tt>ATMega16u2</tt> est la suivante :

* court-circuitez momentanément les lignes reset et masse de l’<tt>ATMega16u2</tt>, l'utilitaire <tt>lsusb</tt> doit lister la carte comme étant en mode DFU, vous pouvez alors exécuter les commandes suivantes :
** <tt>dfu-programmer atmega16u2 erase</tt>
** <tt>dfu-programmer atmega16u2 flash MassStorage.hex</tt>
** <tt>dfu-programmer atmega16u2 reset</tt>
* débranchez et rebranchez votre carte, votre programme doit être actif sur le micro-contrôleur.

= Test du programme avec la bibliothèque LUFA =

Un premier test très simple à réaliser consiste à compiler le programme <tt>MassStoragePeiP</tt> sans ajouter les accès à la mémoire puis à le télécharger sur le micro-contrôleur. Vous devriez déjà vous apercevoir que votre carte est reconnue comme une clef USB. Sur un système Linux, les deux utilitaires <tt>dmesg</tt> et <tt>lsblk</tt> vous en convaincront.

# dmesg | tail
[21942.134207] usb 1-1: new full-speed USB device number 4 using xhci_hcd
[21942.333156] usb 1-1: New USB device found, idVendor=03eb, idProduct=2045, bcdDevice= 0.01
[21942.333161] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=220
[21942.333163] usb 1-1: Product: LUFA Mass Storage Demo
[21942.333166] usb 1-1: Manufacturer: Dean Camera
[21942.333168] usb 1-1: SerialNumber: 758303337383514140C1
[21942.339211] usb-storage 1-1:1.0: USB Mass Storage device detected
[21942.339407] scsi host6: usb-storage 1-1:1.0
[21943.358141] scsi 6:0:0:0: Direct-Access LUFA Dataflash Disk 0.00 PQ: 0 ANSI: 0
[21943.358778] sd 6:0:0:0: Attached scsi generic sg2 type 0
[21943.359523] sd 6:0:0:0: [sdb] 2048 512-byte logical blocks: (1.05 MB/1.00 MiB)
[21943.359910] sd 6:0:0:0: [sdb] Write Protect is off
[21943.359915] sd 6:0:0:0: [sdb] Mode Sense: 00 00 00 00
[21943.360221] sd 6:0:0:0: [sdb] Asking for cache data failed
[21943.360241] sd 6:0:0:0: [sdb] Assuming drive cache: write through
[21943.404925] sd 6:0:0:0: [sdb] Attached SCSI removable disk

# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 119,2G 0 disk
├─sda1 8:1 0 114,4G 0 part /
├─sda2 8:2 0 1K 0 part
└─sda5 8:5 0 4,9G 0 part [SWAP]
sdb 8:16 1 1M 0 disk
sr0 11:0 1 1024M 0 rom

Pour vous familiariser avec le code, vous pouvez tenter de changer les noms du produit, du fabricant, le numéro de série et même la taille de la clef.

Avant de faire un test de votre clef avec un système de fichier, vous pouvez tester si elle gère correctement ses blocs mémoires. Le programme [[media:TestBlock.zip]] permet d'effectuer une écriture dans les blocs et, dans un second temps, de vérifier que ces blocs contiennent bien les bonnes valeurs. Pour l'utiliser, insérez votre clef, trouvez le nom du périphérique avec la commande <tt>lsblk</tt> et lancez la commande ci-dessous (ici il est supposé que le nom du périphérique est <tt>/dev/sdb</tt>) :

./testblock /dev/sdb W

Une fois le programme terminé, enlevez la clef pour s'assurer que la lecture ne se fera pas dans les tampons, remettez la et envoyez la commande :

./testblock /dev/sdb R

Si le programme ne vous affiche pas de différence d'octet, c'est que votre clef fonctionne correctement.

Vous pouvez alors formater votre clef :

mkfs -t vfat /dev/sdb

La monter :

mount /dev/sdb /mnt

Mettre quelques fichiers dessus, la démonter (avec la commande <tt>umount</tt>) et vérifier que vos fichiers sont encore là quand vous reconnectez la clef.

= Réalisations des binômes =

{| class="wikitable"
! Numéro !! Elèves !! Fonctionnalité supplémentaire !! Page
|-
| Binôme 1
| Prénom NOM & Prénom NOM
|
| [[Binome2020-1|Binôme 1 2020/2021]]
|-
| Binôme 2
| Prénom NOM & Prénom NOM
|
| [[Binome2020-2|Binôme 2 2020/2021]]
|-
| Binôme 3
| Prénom NOM & Prénom NOM
|
| [[Binome2020-3|Binôme 3 2020/2021]]
|-
| Binôme 4
| Prénom NOM & Prénom NOM
|
| [[Binome2020-4|Binôme 4 2020/2021]]
|-
| Binôme 5
| Prénom NOM & Prénom NOM
|
| [[Binome2020-5|Binôme 5 2020/2021]]
|-
| Binôme 6
| Prénom NOM & Prénom NOM
|
| [[Binome2020-6|Binôme 6 2020/2021]]
|-
| Binôme 7
| Prénom NOM & Prénom NOM
|
| [[Binome2020-7|Binôme 7 2020/2021]]
|-
| Binôme 8
| Prénom NOM & Prénom NOM
|
| [[Binome2020-8|Binôme 8 2020/2021]]
|-
| Binôme 9
| Prénom NOM & Prénom NOM
|
| [[Binome2020-9|Binôme 9 2020/2021]]
|-
| Binôme 10
| Prénom NOM & Prénom NOM
|
| [[Binome2020-10|Binôme 10 2020/2021]]
|-
| Binôme 11
| Prénom NOM & Prénom NOM
|
| [[Binome2020-11|Binôme 11 2020/2021]]
|-
| Binôme 12
| Prénom NOM & Prénom NOM
|
| [[Binome2020-12|Binôme 12 2020/2021]]
|-
|}

BE 2020-2021

2021-01-17T20:01:16Z

Aboe : /* Présentation du bureau d'étude */

= Présentation du bureau d'étude =

Nous vous proposons de découvrir ce qu'est réellement cet objet devenu banal appelé clé USB (Universal Serial Bus).

[[File:Firefly-serenity-usb-flash-drive.jpg|thumb|center|200px]]

Le bureau d'étude consiste à construire de A à Z une clé USB :
* en créant un circuit électronique ou PCB (Printed Circuit Board) à l’aide d’un logiciel ;
* en soudant des composants électroniques (micro-contrôleur, mémoire FLASH, ...) ;
* en programmant le micro-contrôleur pour gérer la communication USB en utilisant la bibliothèque LUFA (Lightweight USB Framework for AVRs) ;
* en programmant le micro-contrôleur pour accéder à la mémoire ;
* en fabriquant un beau boitier pour votre clef.

Pour personnaliser votre clé n'hésitez pas à ajouter des fonctionnalités :
* LED qui clignotent lors des accès en lecture ou écriture ;
* vumètre qui indique le remplissage de la clé ;
* micro-interrupteurs pour verrouiller la clé ;
* vibreur parce que c'est possible, vous trouverez bien une justification ;
* microphone permettant d’espionner les conversations ;
* toute autre fonction plus ou moins utile mais qui vous inspire ...

Vous allez d'abord réaliser une carte gérant uniquement une des fonctionnalités annexes de votre carte. Cette carte comportera un micro-contrôleur facile à souder : un ATTiny84. Ainsi cette première carte sera un minimum autonome. Par la suite, vous vous attacherez à concevoir la carte complète avec un micro-contrôleur plus puissant possédant des capacités USB matérielle comme l'ATMega16u2. Pour la première carte n'hésitez pas à consulter les pages Wiki de vos prédécesseurs, ils se sont servis d'un ATTiny84 pour réaliser un dé électronique.

Les supports de la présentation de ce bureau d'études : [[Media:BE_clef_USB.pdf]].

= Survol d'USB =

== Evolution des connexions USB ==

L'acronyme USB signifie "Universal Serial Bus" et effectivement l'USB peut être défini comme un bus USB très verbeux. L'USB est géré par un consortium autonome "USB Implementers Forum".

[[File:USB-2.png|thumb|left|300px]] Jusqu'à la version 2, l'acronyme est fidèle à la réalité. Pour ces périphériques, 3 vitesses de transfert sont possibles sur la paire différentielle :
* basse vitesse : 1,5 Mb/s ;
* pleine vitesse : 12 Mb/s ;
* haute vitesse : 480 Mb/s.
<br style="clear: both;"/>
[[File:USB-3.jpg|thumb|right|300px]] A partir de l'USB 3.0, la notion de bus série est un peu oubliée. La vitesse augmente en utilisant les deux nouvelles paires blindées : 5Gb/s (super vitesse).
<br style="clear: both;"/>
[[File:USB-4.png|thumb|left|500px]] Et maintenant USB (USB 3.1, USB 3.2, USB 4) se prend pour de l'Ethernet. En effet, le connecteur USB-C ajoute, à la paire historique, quatre paires blindées. USB 3.2 promet des vitesses jusqu'à 20G/s.
<br style="clear: both;"/>

== Un protocole verbeux ==

[[File:USB-communication.gif|thumb|left|600px]]
L'initialisation d'un périphérique USB se fait comme suit :
* détection électrique de la connexion du périphérique ;
* alimentation électrique du périphérique ;
* utilisation de l'adresse temporaire 0 sur le bus ;
* récupération de la taille des messages pour le point d'accès 0 ;
* envoi de l'adresse au périphérique sur le point d'accès 0 ;
* envoi des descripteurs du périphérique au contrôleur USB via le point d'accès 0.
Pour un périphérique simple :
* souris : environ 100 octets pour le descripteur de configuration ;
* clavier : environ 150 octets pour le descripteur de configuration.
<br style="clear: both;"/>

[[File:USB-descripteurs.gif|thumb|right|700px]]
Les points d'accès (terminaison sur le schéma) :
* des identifiants sur 8 bits (numéro sur 4 bits) ;
* un point d'accès de contrôle de numéro 0 bidirectionnel ;
* les communications se font de ou vers les points d'accès ;
* un sens de communication (bit de poid fort) :
** IN => du périphérique vers le contrôleur ;
** OUT => du contrôleur vers le périphérique.
* la direction est IN ou OUT vis à vis de l’hôte.
Plusieurs types de points d'accès :
* isodromique (isochronous) : débit réservé (e.g. vidéo en temps réel) ;
* par interruption (interrupt) : latence garantie (e.g. souris) ;
* de volume (bulk) : débit maximal sans garantie (e.g. clef mémoire).
<br style="clear: both;"/>

= Logiciels =

Pour la conception de circuits imprimés nous vous recommandons le logiciel [http://fritzing.org/home/ fritzing].

Pour la découpe laser de nombreux utilisateurs utilisent [https://inkscape.org/fr/ inkscape].

Pour la conception 3D vous pouvez tenter [http://www.freecadweb.org/?lang=fr_FR freeCAD]. Une solution en ligne existe : [https://www.onshape.com/ onshape].

Pour la programmation du micro-contrôleur vous utiliserez le compilateur C <tt>avr-gcc</tt> et le logiciel de téléversement <tt>dfu-programmer</tt>.

= Les composants électroniques =

[[File:atmega16u2.png|thumb|left|200px|ATMega16u2]]
Le coeur de votre clé va être un micro-contrôleur AVR plus exactement l'ATMega16u2. Ce micro-contrôleur possède l'électronique nécessaire pour la gestion d'un bus USB 2.0. Un document très important pour comprendre le fonctionnement de ce micro-contrôleur est le document technique (datasheet en patoi) : [http://ww1.microchip.com/downloads/en/DeviceDoc/doc7799.pdf].
<br style="clear: both;"/>

[[File:adesto64Mb.jpg|thumb|left|200px|AT45DB641E-SHN2B-T]]
[[File:MT29F128G08.jpg|thumb|right|200px|MT29F128G8]]
Sans mémoire une clé n'est pas une clé.

Vous pouvez utiliser des mémoires AT45DB641E faciles à gérer avec un ATMega16u2. Ces mémoires sont accessibles par un bus série SPI et facile à souder. Par contre elles sont de faible capacité (64Mb). Le document technique [https://www.adestotech.com/wp-content/uploads/DS-45DB641E-027.pdf] de ces mémoires permet de connaître les commandes pour les configurer et y accéder en lecture et en écriture.

Si vous êtes téméraire, vous pouvez utiliser une mémoire MT29F128G8 accessible par un bus de 8 bits, plus difficile à souder, plus difficile à programmer mais d'une capacité intéressante (128Gb). La documentation technique est plus difficile à trouver, il faut aller sur le site du fabricant (micron) et montrer patte blanche. Vous trouverez le document dans le répertoire éponyme des machines de projet.
<br style="clear: both;"/>

Il vous faudra aussi quelques autres composants comme un quartz, des résistances, des condensateurs, des diodes, des régulateurs de tension et bien sur des LED pour ajouter un peu de lumière. La carte de base peut être décrite comme suit.
* Le micro-contrôleur peut être accompagné d'un quartz à 8Mhz et de ses condensateurs et résistance.
* Le micro-contrôleur peut être alimenté par le connecteur USB en 5v (broche UVCC) mais avec ses lignes VCC et AVCC bouclées sur la sortie UCAP du régulateur 3.3v interne.
* Un convertisseur 5v vers 3.3v est nécessaire pour l'alimentation des mémoires.
* Le micro-contrôleur dialogue avec les mémoires par le bus SPI, une ligne de sélection est nécessaire par mémoire.

Pour la conception de votre clé vous pouvez vous appuyer sur un prototype de clef réalisé pour ce bureau d'études.

== Cartes version alpha ==
[[File:cle_usb_schema.png|thumb|left|400px|Schéma électronique]]
[[File:clef_usb_pcb.png|thumb|right|400px|Carte électronique]]
<br style="clear: both;"/>
Le schéma décrit le circuit électronique partie par partie.
A partir du circuit, il faut créer une carte sans croisement de pistes pour éviter les court-circuits.
Le fichier source Fritzing est disponible : [[Media:cle_usb.zip]] (renommer en <tt>.fzz</tt>).

Une autre carte est disponible pour une mémoire parallèle de plus grande capacité. Attention cette carte n'a pas été testée.

[[File:cle_usb_bis_schema.png|thumb|left|400px|Schéma électronique]]
[[File:clef_usb_bis_pcb.png|thumb|right|400px|Carte électronique]]
<br style="clear: both;"/>
Le fichier source Fritzing est disponible : [[Media:cle_usb_bis.zip]] (renommer en <tt>.fzz</tt>).

== Cartes version beta ==
[[File:cle_usbv2_schema.png|thumb|left|400px|Schéma électronique]]
[[File:clef_usbv2_pcb.png|thumb|right|400px|Carte électronique]]
Une piste parasite entre masse et 3,3v a été supprimée, le <tt>reset</tt> est en 3,3v et un mini-connecteur ICSP a été ajouté.
Le fichier source Fritzing est disponible : [[Media:cle_usbv2.zip]] (renommer en <tt>.fzz</tt>).
<br style="clear: both;"/>

[[File:cle_usb_bisv2_schema.png|thumb|left|400px|Schéma électronique]]
[[File:clef_usb_bisv2_pcb.png|thumb|right|400px|Carte électronique]]
Le <tt>reset</tt> est en 3,3v et un mini-connecteur ICSP a été ajouté.
Le fichier source Fritzing est disponible : [[Media:cle_usb_bisv2.zip]] (renommer en <tt>.fzz</tt>).
<br style="clear: both;"/>

Il peut y avoir des problèmes lors du chargement des fichiers, des composants peuvent être déclarés absents. Essayez d'importer les composants suivants :
* mémoire MT29F128G8 : [[file:MT29F128G08.zip]]
* mémoire AT45DB641E : [[file:SO08-EIAJ.zip]]
* quartz FA238 : [[file:FA238.zip]]

Renommez les fichiers de <tt>.zip</tt> en <tt>.fzpz</tt> avant de les importer dans Fritzing.

= Test des cartes =

== Premier test, faire clignoter une LED par programmation DFU ==

[[File:cle_usb_recto.jpg|thumb|left|400px|Recto des deux cartes]]
[[File:cle_usb_verso.jpg|thumb|right|400px|Verso des deux cartes]]
Vision recto et verso des deux circuits décrit dans la section précédente (ancienne version à gauche). A noter que dans l'ancienne version seule les deux puces mémoire se trouvent au recto. Pour la nouvelle version la carte a du être agrandie et le micro-contrôleur rejoint la mémoire au verso.
<br style="clear: both;"/>

La première étape de test consiste à insérer les PCB dans un port USB. Remarquez la sur-épaisseur réalisée à l'aide d'un papier un peu épais pour assurer le contact. Si l'ATMega16u2 est fonctionne correctement, en lançant l'utilitaire <tt>lsusb</tt> vous devez voir apparaître un périphérique labellé <tt>Atmel DFU device</tt>.

Pour tester plus en avant, il est proposé d'envoyer sur le micro-contrôleur un programme permettant de faire clignoter la LED connectée au micro-contrôleur (la LED est contrôlée par PB6 sur l'ancienne version et sur PB0 sur la nouvelle).

Vous pouvez trouver les programmes de test dans cette archive : [[Media:ClefUSB.zip]]. Pour compiler les programmes, il suffit de se placer dans le répertoire correspondant à la version de la clef et lancer le <tt>makefile</tt> avec la commande <tt>make</tt>. Pour télécharger le programme un simple <tt>make upload</tt> suffit. Pour remettre les micro-contrôleur en mode DFU pour les reprogrammer, il faut court-circuiter les broches <tt>reset</tt> et de la masse (connecteur à deux broches sur les deux cartes).

== Premier problème, correction par programmation SPI ==

Voila le résultat de l'exécution du programme de test du micro-contrôleur sur la nouvelle version : [[Media:ClefUSBTestLed.mp4]].

Force est de constater un problème, la LED clignote bien trop lentement. Quelques recherches apprennent que les <tt>ATMega16u2</tt> sont vendus configurés avec un diviseur d'horloge par 8 activé. Le micro-contrôleur fonctionne donc à 1MHz et pas à 8Mhz comme souhaité. Ce type de configuration passe par une reconfiguration des <tt>fuses</tt> du micro-contrôleur. Manque de chance ces <tt>fuses</tt> ne peuvent être changées que par programmation SPI : impossible de les modifier en mode DFU. Voir le paragraphe ci-après pour comprendre comment se fait une programmation par SPI.

[[File:cle_mini_isp.jpg|thumb|left|300px|Ancienne clef, fils soudés au vol et programmateur SPI]]
[[File:cle_mini_icsp.jpg|thumb|right|300px|Nouvelle clef, fils soudés sur le micro-ICSP et programmateur SPI]]
Les premières version de PCB n'étaient pas prévues pour ce type de programmation. Le mode DFU semblait suffisant. Pour faciliter cette programmation, des via ont été placées de façon à implanter un mini connecteur ICSP. Une erreur a été corrigée en passant : la ligne <tt>reset</tt> du micro-contrôleur était alimentée en 5v, elle a été passée à 3,3v. En attendant les nouvelles cartes, des fils ont été soudés sur les cartes pour avoir un accès au bus SPI et au <tt>reset</tt>. D'ailleurs, une malheureuse tentative de programmation en 5v ayant grillé les micro-contrôleur, d'autres cartes version alpha ont du être soudées.

Une fois le dispositif de programmation SPI adéquat mis au point, une configuration est tentée pour désactiver la division de l'horloge (modification de la valeur de l'octet de configuration appelé <tt>lfuse</tt>) :

avrdude -c arduino -p atmega16u2 -P /dev/ttyACM0 -b 19200 -U lfuse:w:0xFF:m
<br style="clear: both;"/>

Cette configuration échoue : le micro-contrôleur est passé, en usine, en état verrouillé. Vous pouvez vérifier cela avec la commande ci-dessous et en utilisant l'outil de calcul des <tt>fuses</tt> en ligne [http://eleccelerator.com/fusecalc/fusecalc.php?chip=atmega16u2].

avrdude -c arduino -p atmega16u2 -P /dev/ttyACM0 -b 19200 -U lock:r:-:h

Il faut donc totalement réinitialiser le micro-contrôleur :

avrdude -c arduino -p atmega16u2 -P /dev/ttyACM0 -b 19200 -t
avrdude> erase
avrdude> quit

Il est alors possible de modifier l'octet de configuration <tt>lfuse</tt> comme indiqué ci-dessus. Sauf que maintenant le micro-contrôleur ne contient même plus l'amorçeur. Il n'est plus possible de le programmer en mode DFU. Il ne semble pas possible de mettre la main sur l'amorceur du fondeur pour <tt>ATMega16u2</tt>. Heureusement l'amorceur pour une précédente version de la puce est disponible : [[media:at90usb162-bl-usb-1_0_5.zip]]. Il est assez simple d'installer l'amorceur par programmation SPI :

avrdude -c arduino -p atmega16u2 -P /dev/ttyACM0 -b 19200 -U flash:w:at90usb162-bl-usb-1_0_5.hex

Après la modification de l'octet de configuration <tt>lfuse</tt>, la LED clignote normalement : [[media:ClefUSBTestLedBis.mp4]]. A noter qu'il faut maintenant télécharger le programme en utilisant <tt>at90usb162</tt> comme cible au lieu de <tt>atmega16u2</tt> à cause de la différence d'amorceur.

== Second test, accès aux mémoires ==

Il faut maintenant souder le régulateur 3,3v pour alimenter les mémoires et aussi souder les-dites mémoires.

Ensuite il faut tester si l'accès aux mémoires fonctionne. Les programmes sont différents suivant les types de mémoire.

=== Test des mémoires AT45DB641E ===

[[File:cle_usb_verso_AT45DB641E.jpg|thumb|left|300px|Mémoires AT45DB641E]]
Pour tester une des deux mémoires, il faut déjà sélectionner la mémoire sur le bus SPI. La première mémoire se sélectionne en passant la ligne <tt>PD0</tt> à l'état bas. Pour la seconde mémoire, il faut utiliser la ligne <tt>PB4</tt>. La broche <tt>reset</tt> des deux mémoires est reliée à la ligne <tt>PB5</tt> du micro-contrôleur. Il faut donc passer <tt>PB5</tt> en sortie et la mettre à l'état haut.

Pour tester une mémoire, il est possible de demander ses identifiants. Pour cela, il faut envoyer sur le bus SPI, une fois la mémoire sélectionnée, l'octet <tt>0x9F</tt>. Ensuite, il faut lire les cinq octets des identifiants (ID fabricant, ID de la mémoire, ...) puis il faut remonter la ligne de sélection à l'état haut.

Un programme de test est disponible [[Media:ClefUSBTestMem.zip]]. Pour communiquer la valeur des cinq octets d'identification, un système de clignotement de LED est implanté. Pour chaque bit un clignotement représente un 0 et deux clignotement représentent un 1. Le prototype de clef USB avec des mémoires AT45DB641E passe avec succès ce test.

Pour aller plus loin, il faut écrire dans les mémoires et vérifier, par une lecture, que les écritures ont été bien effectuées. Un programme de test est disponible [[Media:ClefUSBTestMemRW.zip]]. Ce programme écrit cinq octets dans la première mémoire, les lit, les multiplie par 2 et écrit les résultats dans la seconde mémoire. Les cinq octets de la seconde mémoire sont lus et communiqués avec le système de clignotement de LED décrit ci-dessus.
<br style="clear: both;"/>

=== Test de la mémoire MT29F128G8 ===

Cette mémoire est sélectionnée par défaut. Il faut juste arriver à lui envoyer un ordre en utilisant les 8 lignes de contrôle.

= Programmation de micro-contrôleur par SPI =

Nativement les micro-contrôleurs AVR peuvent être programmés via le bus SPI. Généralement un amorceur (bootloader) est installé sur ces micro-contrôleurs pour qu'ils puissent être programmés plus facilement par une connexion série pure (cas de l'ATMega328p par exemple) ou par une connexion USB (cas de l'ATMega16u2). Malheureusement les amorceurs peuvent être effacés par une mauvaise manoeuvre ou ne permettent pas de configurer tous les aspects du micro-contrôleur.

[[File:uno_as_isp.jpg|thumb|left|400px|Arduino Uno comme programmateur]]
Généralement pour une programmation de micro-contrôleur par bus SPI, un connecteur ICSP est utilisé. Ce connecteur regroupe les lignes du bus SPI, la masse, l'alimentation et le <tt>reset</tt>. Un simple Arduino UNO peut-être utilisé comme programmateur par bus SPI. Les lignes MISO, MOSI, SCK, GND, VCC du programmateur sont connectées sur les mêmes lignes de la cible. La ligne 10 du programmateur est connectée sur le <tt>reset</tt> de la cible. Le programme ArduinoISP doit être téléversé sur le UNO jouant le rôle de programmateur. Ce programme fait partie des exemples fournis avec l'IDE Arduino.
<br style="clear: both;"/>

Un exemple d'utilisation d'un programmateur par bus SPI pour obtenir les <tt>fuses</tt> d'un <tt>ATMega16u2</tt> (les <tt>fuses</tt> sont des octets de configuration bas niveau du micro-contrôleur) :

avrdude -c arduino -p atmega16u2 -P /dev/ttyACM0 -b 19200 -v

Un exemple pour télécharger un programme par SPI sur un <tt>ATMega16u2</tt> :

avrdude -c arduino -p atmega16u2 -P /dev/ttyACM0 -b 19200 -U flash:w:programme.hex

Dans ces exemples, il est supposé que le port série associé à l'UNO est <tt>/dev/ttyACMO</tt>.

[[File:minipro_as_isp.jpg|thumb|left|400px|Arduino mini-pro comme programmateur]]
Si le micro-contrôleur est alimenté en 3,3v utiliser un Arduino Uno comme programmateur est une mauvaise idée : un UNO fonctionne à 5v et la communication SPI entre une plateforme à 5v et une autre à 3,3v ne fonctionne pas. Il existe assez peu de plateformes Arduino en 3,3v. Vous pouvez utiliser un Arduino Mini Pro 3,3v en conjonction avec un FTDI (convertisseur USB/série) lui aussi en 3,3v. Le Mini Pro ne dispose pas d'un connecteur ICSP. Il faut utiliser la ligne 11 pour connecter la ligne MOSI de la cible, la ligne 12 pour MISO et la ligne 13 pour SCK.
<br style="clear: both;" />

L'utilitaire <tt>avrdude</tt> peut être utilisé pour programmer la cible comme avec le programmateur à base d'UNO. Attention le port série sera probablement <tt>/dev/ttyUSBO</tt> cette fois.

= Bibliothèque LUFA =

Pour la gestion du bus USB par le micro-contrôleur nous allons nous appuyer au maximum sur la bibliothèque USB LUFA. Cette bibliothèque permet d'exploiter plus facilement les aspects USB des micro-contrôleurs AVR comme l'ATMega16u2.

Vous pouvez télécharger la dernière version de la bibliothèque [http://www.fourwalledcubicle.com/LUFA.php]. Il est ensuite conseillé d'effectuer quelques manipulations pour pouvoir développer dans de bonnes conditions.
* Créez un répertoire <tt>PolytechLille</tt> au même niveau que les répertoires <tt>Demos</tt> et <tt>Projects</tt>.
* Dans ce répertoire copiez la démonstration de périphérique USB bas niveau <tt>MassStorage</tt>. Au niveau du <tt>makefile</tt> indiquez <tt>atmega16u2</tt> comme micro-contrôleur, <tt>NONE</tt> comme platine et restez à 8Mhz.
* Il faut ensuite modifier la configuration de la mémoire et les fonctions d'accès à cette mémoire dans le sous-répertoire <tt>Lib</tt> du répertoire <tt>PolytechLille/MassStorage</tt>. Pour vous aider une version modifiée de la démonstration <tt>MassStorage</tt> est disponible [[media:MassStoragePeiP.zip]]. Dans cette version, vous n'avez à modifier que les fichiers <tt>Lib/DataflashManager.h</tt> et <tt>Lib/DataflashManager.c</tt> en vous appuyant sur les programmes de test des mémoires.

Pour téléverser votre programme sur l’<tt>ATMega16u2</tt>, le paquetage Debian <tt>dfu-programmer</tt> est nécessaire. Installez-le au besoin. La procédure à suivre pour charger votre programme sur l’<tt>ATMega16u2</tt> est la suivante :

* court-circuitez momentanément les lignes reset et masse de l’<tt>ATMega16u2</tt>, l'utilitaire <tt>lsusb</tt> doit lister la carte comme étant en mode DFU, vous pouvez alors exécuter les commandes suivantes :
** <tt>dfu-programmer atmega16u2 erase</tt>
** <tt>dfu-programmer atmega16u2 flash MassStorage.hex</tt>
** <tt>dfu-programmer atmega16u2 reset</tt>
* débranchez et rebranchez votre carte, votre programme doit être actif sur le micro-contrôleur.

= Test du programme avec la bibliothèque LUFA =

Un premier test très simple à réaliser consiste à compiler le programme <tt>MassStoragePeiP</tt> sans ajouter les accès à la mémoire puis à le télécharger sur le micro-contrôleur. Vous devriez déjà vous apercevoir que votre carte est reconnue comme une clef USB. Sur un système Linux, les deux utilitaires <tt>dmesg</tt> et <tt>lsblk</tt> vous en convaincront.

# dmesg | tail
[21942.134207] usb 1-1: new full-speed USB device number 4 using xhci_hcd
[21942.333156] usb 1-1: New USB device found, idVendor=03eb, idProduct=2045, bcdDevice= 0.01
[21942.333161] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=220
[21942.333163] usb 1-1: Product: LUFA Mass Storage Demo
[21942.333166] usb 1-1: Manufacturer: Dean Camera
[21942.333168] usb 1-1: SerialNumber: 758303337383514140C1
[21942.339211] usb-storage 1-1:1.0: USB Mass Storage device detected
[21942.339407] scsi host6: usb-storage 1-1:1.0
[21943.358141] scsi 6:0:0:0: Direct-Access LUFA Dataflash Disk 0.00 PQ: 0 ANSI: 0
[21943.358778] sd 6:0:0:0: Attached scsi generic sg2 type 0
[21943.359523] sd 6:0:0:0: [sdb] 2048 512-byte logical blocks: (1.05 MB/1.00 MiB)
[21943.359910] sd 6:0:0:0: [sdb] Write Protect is off
[21943.359915] sd 6:0:0:0: [sdb] Mode Sense: 00 00 00 00
[21943.360221] sd 6:0:0:0: [sdb] Asking for cache data failed
[21943.360241] sd 6:0:0:0: [sdb] Assuming drive cache: write through
[21943.404925] sd 6:0:0:0: [sdb] Attached SCSI removable disk

# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 119,2G 0 disk
├─sda1 8:1 0 114,4G 0 part /
├─sda2 8:2 0 1K 0 part
└─sda5 8:5 0 4,9G 0 part [SWAP]
sdb 8:16 1 1M 0 disk
sr0 11:0 1 1024M 0 rom

Pour vous familiariser avec le code, vous pouvez tenter de changer les noms du produit, du fabricant, le numéro de série et même la taille de la clef.

Avant de faire un test de votre clef avec un système de fichier, vous pouvez tester si elle gère correctement ses blocs mémoires. Le programme [[media:TestBlock.zip]] permet d'effectuer une écriture dans les blocs et, dans un second temps, de vérifier que ces blocs contiennent bien les bonnes valeurs. Pour l'utiliser, insérez votre clef, trouvez le nom du périphérique avec la commande <tt>lsblk</tt> et lancez la commande ci-dessous (ici il est supposé que le nom du périphérique est <tt>/dev/sdb</tt>) :

./testblock /dev/sdb W

Une fois le programme terminé, enlevez la clef pour s'assurer que la lecture ne se fera pas dans les tampons, remettez la et envoyez la commande :

./testblock /dev/sdb R

Si le programme ne vous affiche pas de différence d'octet, c'est que votre clef fonctionne correctement.

Vous pouvez alors formater votre clef :

mkfs -t vfat /dev/sdb

La monter :

mount /dev/sdb /mnt

Mettre quelques fichiers dessus, la démonter (avec la commande <tt>umount</tt>) et vérifier que vos fichiers sont encore là quand vous reconnectez la clef.

= Réalisations des binômes =

{| class="wikitable"
! Numéro !! Elèves !! Fonctionnalité supplémentaire !! Page
|-
| Binôme 1
| Prénom NOM & Prénom NOM
|
| [[Binome2020-1|Binôme 1 2020/2021]]
|-
| Binôme 2
| Prénom NOM & Prénom NOM
|
| [[Binome2020-2|Binôme 2 2020/2021]]
|-
| Binôme 3
| Prénom NOM & Prénom NOM
|
| [[Binome2020-3|Binôme 3 2020/2021]]
|-
| Binôme 4
| Prénom NOM & Prénom NOM
|
| [[Binome2020-4|Binôme 4 2020/2021]]
|-
| Binôme 5
| Prénom NOM & Prénom NOM
|
| [[Binome2020-5|Binôme 5 2020/2021]]
|-
| Binôme 6
| Prénom NOM & Prénom NOM
|
| [[Binome2020-6|Binôme 6 2020/2021]]
|-
| Binôme 7
| Prénom NOM & Prénom NOM
|
| [[Binome2020-7|Binôme 7 2020/2021]]
|-
| Binôme 8
| Prénom NOM & Prénom NOM
|
| [[Binome2020-8|Binôme 8 2020/2021]]
|-
| Binôme 9
| Prénom NOM & Prénom NOM
|
| [[Binome2020-9|Binôme 9 2020/2021]]
|-
| Binôme 10
| Prénom NOM & Prénom NOM
|
| [[Binome2020-10|Binôme 10 2020/2021]]
|-
| Binôme 11
| Prénom NOM & Prénom NOM
|
| [[Binome2020-11|Binôme 11 2020/2021]]
|-
|}

Discussion:Binome2019-3

2020-04-27T07:07:50Z

Aboe :

OK pour la description du dé.

Un très bon Wiki. Bon passage concernant la conception de la clef.

Commentaires sur la carte supplémentaire à la clé USB :
#Schématique
** au niveau de J1 une connexion erronée entre masse et reset
** au niveau ATMega :
*** connexion erronée entre reset et AVCC
*** manque connexion de AGND vers GND
# PCB
** Placement des composants à revoir :
*** Le quartz (FA) doit être en CMS, à placer beaucoup plus proche du µP, sans changement de face (uniquement supérieure)
*** J1 est généralement un connecteur 3*2 broches (deux rangées)
*** il faut mettre les capacités de découplage proche de la broche à découpler
*** mettre les résistances des afficheurs proche de l'afficheur vaguement alignées ?
*** idem pour les transistors
** il faudra mettre un plan de masse
# Peut-être faire le placement et renvoyer pour vérification avant le routage. Si zones problématiques, il est possible d'échanger sur le schématique des connexions (par exemple, mettre A sur PD2 et C sur PD0,au hasard, juste pour expliquer) afin de rendre l'ensemble plus simplement routable

Discussion:Binome2019-3

2020-04-27T07:03:59Z

Aboe :

Discussion:Binome2019-2

2020-03-26T14:31:02Z

Aboe : Page créée avec « Montage micro : il manque une liaison vers VCC ; le schéma peut être améliorer pour une meilleure lisibilité (liaisons directes à des symboles de masse) »

Montage micro : il manque une liaison vers VCC ; le schéma peut être améliorer pour une meilleure lisibilité (liaisons directes à des symboles de masse)

Discussion:Binome2017-8

2018-05-25T17:14:06Z

Aboe :

Commentaires sur le Wiki :
* Quelques coquilles.
* Une partie chronologique avec des descriptions très rapides du travail.
* Une partie plus synthètique sur le circuit électronique, le chassis et la programmation. Un peu court.
* Wiki illustré.

Une démarche de conception intéressante mais un Wiki un peu rapide : 13/20.

Vidéo :
* Très bonne description du robot.
* Une excellente démonstration du fonctionnment du robot y compris l'évitement d'autres robots grâce à l'infra-rouge (démonstration avec un autre robot).

Vidéo très réussie : 19/20.

Robot :
* chassis plexiglas et 3D.
* Carte électronique.
* Sonar, TSOP, effet Hall.

Un robot très achevé ! Un très bon bureau d'études : 18/20 (effet monöme).

Discussion:Binome2017-7

2018-05-25T17:09:55Z

Aboe :

Commentaires sur le Wiki :
* Rédaction un peu en style télégraphique du moins pour les premières séances.
* Des coquilles.
* Bien illustré.
* Un code pas vraiment expliqué.
* Il manque un bilan des fonctionnalités du robot.

Un Wiki correct mais qui aurait pu être plus soigné : 13/20.

Vidéo :
* Description très correcte du robot BOB.
* Une démonstration réussie du mode télécommande de BOB. L'image de la caméra est visible.

Une vidéo très correcte : 16/20.

Robot :
* Raspberry Pi.
* Shield Arduino.
* Sonar.
* Caméra.
* Pièce 3D pour le sonar et la caméra.

De la persévérence, un robot télécommandable en fin de bureau d'étude : 15/20 (effet monôme).

2017-01-04T12:30:50Z

Aboe : /* Objectif à atteindre */

= Objectif à atteindre =

Comme pour les saisons précédentes vous devez concevoir des robots pour concourir dans un jeu de balle.

Le terrain peut être marqué comme sur le schéma ci-dessous. Durant une manche les joueurs ne peuvent pas sortir du cadre principal. Les bords du terrain sont inclinés pour que la balle revienne vers la zone de jeu. Les lignes permettent de marquer le centre du terrain et les zones de garage des robots. Les robots devront pouvoir distinguer deux types de lignes, peu importe les couleurs.

[[Fichier:terrain2.png|500px|thumb|center|Schéma du terrain]]

Une manche est décomposée en plusieurs étapes :
* Le robot ramasseur est invité à sortir de son garage pour aller positionner la balle au centre du terrain. Cette invitation peut se faire après un but ou manuellement en début de partie. Quand la balle est correctement placée le robot ramasseur se gare et prévient les robots joueurs que le jeu peut démarrer.
* Les deux robots joueurs sortent de leur garage et vont chercher la balle en la repérant par leurs capteurs infrarouges. Si un robot capture la balle il demande au but adverse d'allumer sa balise infrarouge. Il essaye alors d'envoyer la balle dans le but. Au moment du tir, il permet au but d'éteindre sa balise.
* Soit le tir est raté et les robots continuent à tenter d'attraper la balle.
* Soit le tir est réussi et le but concerné le confirme, les robots joueurs vont se garer et le robot ramasseur entre en action. Les buts sont chargés d'afficher le score. Pour qu'un but soit marqué, il suffit que la balle rentre dans le but. Le sol du but est en pente pour que la balle ressorte automatiquement.

Une partie est constituée de plusieurs manches.

= Matériel à votre disposition pour les robots =

Votre robot doit pouvoir réaliser les actions suivantes :
* avancer et reculer le tout en tournant éventuellement ;
* repérer une ligne au sol ;
* détecter des signaux infra-rouges pulsés ;
* détecter des obstacles sur son chemin ;
* communiquer avec les autres acteurs (robots et buts) ;
* capturer et déplacer une balle.

Nous vous imposons de construire ce robot à base de micro-contrôleur ATMega. Par contre nous vous laissons le choix de la variante. Les possibilités sont classées de la plus simple à la plus complexe.
* Vous pouvez partir d'un des robots construits lors de la saison précédente. Ces robots ne sont pas forcément totalement fonctionnels mais les parties déjà réalisées peuvent vous faire gagner du temps que vous pourrez consacrer à la programmation du robot.
* Vous pouvez construire un robot à partir d'un des deux chassis proposés, utiliser un Arduino Mega et concevoir un bouclier pour cet Arduino comportant des emplacements pour les divers composants nécessaires (contrôleur moteur, détecteur ultrason, détecteur de lignes, etc).
* Vous pouvez aussi fabriquer votre propre chassis avec deux plaques de plexiglass et y intégrer deux moto-réducteurs et leurs roues ainsi qu'une roue folle. Pour le micro-contrôleur vous pouvez aussi vous passer de l'Arduino Mega et concevoir votre propre circuit intégré à base de micro-contrôleur ATMega328p et de contrôleur moteurs TB6612FNG. Même les détecteurs de lignes peuvent être construits à partir de composants électroniques de base. Seul le sonar ultrason est trop complexe pour être conçu à partir des composants de base.
* Si vous aimez les défis vous pouvez aussi construire un robot avec un moto-réducteur de meilleure qualité et avec une carte électronique réalisée uniquement avec des composants électroniques de surface.

Les montages photographiques ci-dessous présente les éléments permettant de construire un robot sans trop souffrir et les composants de base pour construire un robot plus optimisé et personnalisé.

[[Fichier:robot-kit.jpg|300px|thumb|left|Chassis, Arduino Mega, détecteur couleur, sonar, contrôleur moteurs, phototransistor, modem ZigBee, détecteur de ligne]]
[[Fichier:robot-composant.jpg|300px|thumb|right|Moto-réducteurs et roues, micro-contrôleurs ATMega328p et quartz, contrôleur de moteurs TB6612FNG, interrupteur optique QRE1113]]
<br style="clear: both;"/>

Des dispositifs mécaniques, comme une pince, peuvent être réalisés en utilisant des servo-moteurs et des pièces en plexiglas ou en MDF découpés à l'aide de la découpeuse laser du [http://www.fabricarium.fr/mediawiki-1.23.5/index.php?title=Accueil Fabricarium].
Pour les fixations vous avez de la visserie (vis, écrous, entretoises).

<gallery style="margin: 0 auto;">
Fichier:servo.jpg|Servo-moteur
Fichier:pince-robot.jpg|Exemple de pince
Fichier:entretoises.jpg|Visserie
</gallery>

= Matériel à votre disposition pour les buts =

Les buts sont constitués :
* d'une cage de but à réaliser, par exemple, en plexiglas avec la découpeuse laser ;
* d'une balise infrarouge pouvant être activée à la demande ;
* d'un détecteur de passage de la balle (par phototransistor par exemple) ;
* d'un afficheur 7 segments pour le score.

Consultez les bureau d'études de 2014/2015 pour comprendre comment réaliser une balise infrarouge avec un micro-contrôleur. Cette année la fonctionnalité de clignotement de la balise à basse fréquence n'est pas nécessaire. Par contre il vous est demandé de gérer un afficheur 7 segments et un bouclier de communication par radio. Le micro-contrôleur de l'an passé, l'ATtiny85, ne sera pas suffisant pour gérer toutes les fonctionnalités du but de cette année. Vous utiliserez donc un Arduino Uno.

<gallery style="margin: 0 auto;">
Fichier:LEDIR.jpg|LED infrarouge (940 nm)
Fichier:2n3904.png|Transistor pour LED
Fichier:Arduino Uno R3.jpg|Arduino Uno
Fichier:Serie7segments.png|Afficheur 7 segments
</gallery>

= Logiciels à utiliser =

Pour concevoir un schéma propre du câblage de votre robot vous pouvez utiliser [http://fritzing.org/home/ fritzing]. Tous les composants de votre robot ne sont pas modélisés dans fritzing. Voici une liste de composants supplémentaires mis au points par des élèves IMA de la promotion 2017 (Julie Debock, Hugo Vandenbunder et Sylvain Verdonck) et revus par les encadrants du bureau d'études :
* détecteur ultrason : [[Fichier:UltrasonicSensor_HCSR04.zip]]
* détecteur de ligne : [[Fichier:LineSensor_Sparkfun.zip]]
* capteur de couleurs : [[Fichier:ColorSensor_Adafruit_TCS34725.zip]]
* contrôleur de moteurs : [[Fichier:MotorDriver_Pololu_md08a.zip]]

Pour la conception de circuits imprimés nous vous recommandons le logiciel [http://www.cadsoftusa.com/download-eagle/freeware/ eagle] ou le précédent.

Pour la découpe laser de nombreux utilisateurs utilisent [https://inkscape.org/fr/ inkscape].

Pour la conception 3D solidwork est très utilisé. Vous pouvez tenter [http://www.freecadweb.org/?lang=fr_FR freeCAD] si vous cherchez un logiciel plus libre.

Pour le développement avec les plateformes Arduino, utilisez l'environnement du même nom. Si la programmation C++ vous fait peur, n'hésitez pas à ajouter l'outil [http://sourceforge.net/projects/ardublock/ ardublock] à cet environnement.

Pour vous aider dans la conception des circuits imprimés nous vous proposons des circuits modélisés avec fritzing que vous pourrez adapter à vos robots. Ces circuits ont été ébauchés par les élèves IMA sus-cités et lourdement modifiés par les encadrants du bureau d'études.

Un premier circuit vous donne un exemple de circuit pour les capteurs de l'avant du robot : [[Fichier:robot_capteur.zip]].
<gallery style="margin: 0 auto;">
Fichier:robot_capteur_bb.png|Capteurs : plaque d'essai
Fichier:robot_capteur_schem.png|Capteurs : schéma
Fichier:robot_capteur_pcb.png|Capteurs : circuit imprimé
</gallery>

Un second circuit de type bouclier Arduino permet d'éviter tous les câbles entre l'Arduino et les contrôleurs de moteurs : [[Fichier:robot_bouclier.zip]]. Ce circuit est prévu pour 4 moteurs, les binômes avec des chassis bi-moteurs devront le simplifier.
<gallery style="margin: 0 auto;">
Fichier:robot_bouclier_bb.png|Bouclier : plaque d'essai
Fichier:robot_bouclier_schem.png|Bouclier : schéma
Fichier:robot_bouclier_pcb.png|Bouclier : circuit imprimé
</gallery>

= Répartition des tâches =

Nous n'imposons pas de répartition rigide des tâches. Pour qu'une démonstration puisse se faire en fin de bureau d'étude il faut au moins deux robots joueurs, deux cages de buts et un robot ramasseur. Bien entendu plusieurs parties peuvent avoir lieu en même temps.

== Fonctionnement de la cage de but ==

Deux événements peuvent faire agir la cage de but :
* une balle pénètre dans la cage ;
* un message est envoyé à la cage par un robot.

Pour détecter une balle entrant dans la cage, le plus simple est d'y fixer un phototransistor infrarouge avec un cache adapté pour ne détecter la balle que lorsqu'elle se trouve dans la cage.

Lorsque que la balle est détectée il faut incrémenter le score (ce score est initialisé à zéro lors de la réinitialisation de l'Arduino). Il faut ensuite envoyer un message aux robots pour que les robots joueurs aillent se garer et que le robot ramasseur se mette en action. Le format des messages est a déterminer globalement, doit y figurer un champ destination qui permet de cibler un acteur précis et aussi un champ données pour préciser le message.

Quand un message est envoyé spécifiquement à la cage, c'est à dire qu'elle reconnait son identifiant dans le champs destination, elle doit activer ou arrêter sa balise infrarouge. Mettons que la balise est activée si la donnée est 1 et arrêtée si la donnée est 0.

Le câblage peut se faire en utilisant des plaques à essai ou en concevant un circuit imprimé avec le logiciel <tt>eagle</tt>.

== Robot ramasseur de balle ==

Un robot ramasseur de balle est constitué comme suit :
* un châssis roulant, un contrôleur pour chaque paire de moteurs, un Arduino Mega2560 ou un circuit électronique maison à base de micro-contrôleur ATMega328p ;
* un détecteur ultrason pour éviter les collisions ;
* trois détecteurs de ligne pour suivre efficacement les lignes au sol ;
* des phototransistors infrarouges pour repérer la balle infrarouge ;
* un système de pince basé sur un servo-moteur pour capturer la balle ;
* un bouclier XBee pour communiquer avec les autres acteurs.

Le robot ramasseur de balle peut être activé soit manuellement par un bouton, soit sur réception d'un message lui étant destiné.

Une fois activé le robot se promène en changeant de direction jusqu'à ce qu'il détecte la balle infrarouge. Il se dirige alors vers la balle et la capture avec sa pince.

Le robot se remet à se promener comme précédemment et s'arrête lorsqu'il détecte une ligne de la croix centrale. Il remonte cette ligne dans un sens et il analyse la prochaine intersection avec ses trois capteurs. S'il ne se trouve pas au centre du terrain il se retourne pour remonter la ligne dans l'autre sens. Une fois au centre du terrain, il lâche la balle et va se garer.

Il ne lui reste alors plus qu'à envoyer un message aux robots joueurs pour qu'ils jouent une manche.

Pour détecter les lignes les capteurs doivent être séparés de l'épaisseur des lignes au sol. Ainsi quand le capteur du milieu perdra la ligne, un des deux autres capteurs devrait l'apercevoir. De cette façon le robot saura par quel coté il perd la ligne et pourra tourner en sens inverse pour la retrouver sur le capteur central. Vous pouvez utiliser le temps entre deux pertes de ligne pour avoir une idée de la courbure de la ligne et lancer le robot dans une trajectoire courbe plutôt que rectiligne.

Pour détecter la balle infrarouge plusieurs phototransistors installés dans des caches réduisant leur angle de détection sont nécessaires. A vous de trouver la meilleure répartition sur le châssis pour les détecteurs. Vous pouvez aussi utiliser un plateau rotatif réalisé avec un servo-moteur pour augmenter le champ de vision.

Les éléments de la pince sont à réaliser par impression 3D ou découpe laser de plexiglas.

== Robot compétiteur ==

Un robot compétiteur est constitué comme suit :
* un châssis roulant, un contrôleur pour chaque paire de moteurs, un Arduino Mega2560 ou un circuit électronique maison à base de micro-contrôleur ATMega328p ;
* un détecteur ultrason pour ne pas rentrer dans les obstacles ;
* trois détecteurs de ligne pour suivre efficacement les lignes au sol ;
* des phototransistors infrarouges pour repérer la balle infrarouge et les buts ;
* un système de pince basé sur un servo-moteur pour capturer la balle ;
* un système d'éjection de la balle pour tirer ;
* un bouclier XBee pour communiquer avec les autres acteurs.

Un robot compétiteur est activé par un message du robot ramasseur de balle. Il sort alors de son garage pour rentrer sur le terrain.

Une fois sur le terrain le robot s'y promène en changeant de direction lorsqu'il arrive en limite du terrain jusqu'à ce qu'il détecte la balle infrarouge. Il se dirige alors vers la balle et tente de la capturer avec sa pince. Il demande alors au but adverse d'activer sa balise IR.

Le robot tourne jusqu'à trouver le but adverse et tire pour envoyer la balle dans le but. Après avoir tiré, il demande au but adverse d'arrêter sa balise IR.

Si le robot reçoit un message signalant qu'un but a été marqué, il va se garer. Pour cela il parcourt le terrain jusqu'à trouver une ligne de l'aire de jeu. Il suit cette ligne jusqu'à trouver l'intersection qui correspond à son garage.

Pour détecter la balle infrarouge plusieurs phototransistors installés dans des caches réduisant leur angle de détection sont nécessaires. A vous de trouver la meilleure répartition sur le châssis pour les détecteurs. Vous pouvez aussi utiliser un plateau rotatif réalisé avec un servo-moteur pour augmenter le champ de vision.

Les éléments de la pince sont à réaliser par impression 3D ou découpe laser de plexiglas ou bois. Quand la pince se referme elle doit occulter la balle pour que le robot puisse détecter la balise du but.

== Robot télécommandé ==

Un robot télécommandé est un robot compétiteur dirigé par un humain. Il est donc constitué des composants d'un robot compétiteur moins les phototransistors. En effet la balle est repérée par l'opérateur humain au travers d'une caméra. Le contrôle du robot se fait via une Raspberry Pi dotée d'une interface WiFi transformée en point d'accès et hébergeant un site Web. L'opérateur contrôle le robot en utilisant un smartphone connecté sur le point d'accès.

Un robot télécommandé ne peut avancer que sur réception du message du robot ramasseur de balle.

L'opérateur peut diriger le robot à sa guise dans le terrain mais le robot interdit toute sortie de ce terrain. L'opérateur peut capturer la balle avec la pince et la lancer dans le but adverse. La procédure d'activation de la balise du but adverse n'est donc jamais déclenchée contrairement à ce qui se passe avec un robot compétiteur.

La pince doit être réalisée comme pour un robot compétiteur. La contrainte d'occulter les signaux IR de la balle n'est pas utile ici.

== Réalisations des binômes ==

{| class="wikitable"
! Numéro !! Elèves !! Tâches !! Page
|-
| Binôme 1
| Prénom1 Nom1 / Prénom2 Nom2
| Type de robot
| [[Binome2016-1|Binôme 1 2016/2017]]
|-
| Binôme 2
| Prénom1 Nom1 / Prénom2 Nom2
| Type de robot
| [[Binome2016-2|Binôme 2 2016/2017]]
|-
| Binôme 3
| Prénom1 Nom1 / Prénom2 Nom2
| Type de robot
| [[Binome2016-3|Binôme 3 2016/2017]]
|-
| Binôme 4
| Prénom1 Nom1 / Prénom2 Nom2
| Type de robot
| [[Binome2016-4|Binôme 4 2016/2017]]
|-
| Binôme 5
| Prénom1 Nom1 / Prénom2 Nom2
| Type de robot
| [[Binome2016-5|Binôme 5 2016/2017]]
|-
| Binôme 6
| Prénom1 Nom1 / Prénom2 Nom2
| Type de robot
| [[Binome2016-6|Binôme 6 2016/2017]]
|-
| Binôme 7
| Prénom1 Nom1 / Prénom2 Nom2
| Type de robot
| [[Binome2016-7|Binôme 7 2016/2017]]
|-
| Binôme 8
| Prénom1 Nom1 / Prénom2 Nom2
| Type de robot
| [[Binome2016-8|Binôme 8 2016/2017]]
|-
| Binôme 9
| Prénom1 Nom1 / Prénom2 Nom2
| Type de robot
| [[Binome2016-9|Binôme 9 2016/2017]]
|-
| Binôme 10
| Prénom1 Nom1 / Prénom2 Nom2
| Type de robot
| [[Binome2016-10|Binôme 10 2016/2017]]
|-
| Binôme 11
| Prénom1 Nom1 / Prénom2 Nom2
| Type de robot
| [[Binome2016-11|Binôme 11 2016/2017]]
|-
|}

Discussion:Binome2015-1

2016-05-21T08:16:14Z

Aboe :

* Travail
Sans conteste du travail avec de nombreuses heures passées hors séances.
Création d'un composant sous Fritzing.
Des efforts importants pour résoudre les problèmes lors de la fabrication du robot.
Un résultat décevant mais les efforts mis en œuvre sont irréprochables.

* Wiki
Wiki de type chronologique très complet.
Mise à jour assez régulière. Assez bien illustré.
Rédaction assez télégraphique mais dans un français correct. Pas mal de coquilles dans les dernière entrées.

* Vidéo
Pas de démonstration dans la vidéo car les élèves espéraient pouvoir modifier leurs robot pour avoir un résultat plus probant.

* Conclusion
Très bon travail. Le Wiki donne bien la mesure de ce travail. Dommage que le robot n'ait pas été fonctionnel. Dommage aussi qu'il n'y ait pas de démonstration vidéo.

Note : 17/20.