Version actuelle datée du 4 mai 2020 à 11:23

Sommaire

1 I. Présentation générale
- 1.1 Description
- 1.2 Objectifs
2 II. Analyse du projet
3 III. Préparation du projet
4 IV. Réalisation du Projet
5 Bibliographie

I. Présentation générale

Description

Trois périphériques sont envisagés :

un clavier
une souris
et une clef USB

Chacun des périphériques sera construit autour d'un ATMEGA16u2 gérant le protocole USB.

Le clavier aura pour fonction de gérer les entrées et quelques LED.
La fonctionnalité supplémentaire consiste à enregistrer des touches tapées par l'utilisateur. Le contenu de cet historique sera stocké dans la mémoire interne du clavier, et pourra être vidé ou supprimé via une combinaison de touches.

La souris contrôlera le déplacement du curseur et possédera des boutons.
Elle contiendra également un mode "Berserk" qui cliquera aléatoirement sur l'écran. Ce mode sera déclenchable à distance.

Enfin, la clef USB sera utilisée comme lecteur de carte SD.
En cas d'inactivité prolongée, elle émulera un clavier qui injectera une séquence d’actions préalablement enregistrée afin de télécharger un logiciel de surveillance sur le PC auquel elle est connectée.

Objectifs

Notre objectif est de réaliser ces périphériques USB artisanaux avec les fonctionnalités supplémentaires décrites.

II. Analyse du projet

Analyse du premier concurrent

KeyGrabber USB 16Mo

Le premier concurrent, celui du clavier, est représenté par les produits de type Keylogger.

Voici un des principaux concurrents de ce marché :
Nom du produit : KeyGrabber USB
Société : Keelog

Description générale:

Ce périphérique USB se connecte entre le port USB de l’ordinateur et celui du clavier. Il enregistre l’activité du clavier dans une mémoire interne. Les données peuvent être récupérées ou effacées avec la bonne combinaison de touches.

Caractéristiques :

Sa longueur est de 38mm. Elle a une capacité de stockage de 16Mo ou 8Go.
Les données présentes sont encryptées par un cryptage 128 bits, unique à chaque produit.
Son prix est 43.99$ pour la version 16Mo ou 83,99$ pour la version 8Go.

Analyse du second concurrent

USB Rubber Ducky

Le second concurrent est celui de la clé USB.

Nom : USB RUBBER DUCKY
Société :hak5

Description général:
Il s'agit d'un périphérique USB reconnu en tant que clavier. Il injecte des instructions présentes sur la carte micro SD.

Il est facile d'utilisation car il suffit d'écrire les instructions dans un fichier texte, dans un langage spécifique.
Son prix est de 44,99$.

Positionnement par rapport à l'existant

En ce qui concerne le clavier, il aura à peu près les mêmes caractéristiques techniques que le KeyGrabber. La différence majeure réside dans la discrétion de celui-ci. En effet, le keygrabber est une clef USB et il est facilement repérable. Cela implique de le cacher à l'arrière de la tour.

Or, notre dispositif Keylogger sera directement implémentée dans le clavier. Ainsi il restera inaperçu depuis l'extérieur, sur n'importe quelle machine.

Ensuite, notre clé USB diffère de l'USB RUBBER DUCKY car elle sera en premier lieu utilisée comme lecteur de carte SD. On pourra donc s'en servir de stockage alors que chez le concurrent la carte micro SD sert de stockage pour les instructions à envoyer au PC.
Ce stockage rend donc moins suspect notre clé, qui pourra lancer le téléchargement du logiciel de surveillance en cas d'inactivité.

Scénario d'usage du produit ou du concept envisagé

Prenons des parents qui laissent leurs enfants utilisés l'ordinateur familial pour leur devoir maison. Mais il aimeraient vérifier qu'ils ne fassent pas n'importe quoi et qu'ils ne jouent pas sans rester en permanence derrière eux. Dans ce cadre, ils pourraient utilisés nos périphériques. Le clavier, leur permettrait de récupérer les données tapées et de vérifier que celles-ci correspondent bien au travail qu'ils avaient à réaliser. Afin de récupéré les données même si ils ne sont pas chez eux, ils peuvent utilisés la clé pour qu'elle télécharge un logiciel, qui tous les certains temps enregistre ce qu'il a été fait et l'envoie sur leur adresse mail. Quand à la souris, elle pourrait si en passant dans le bureau ils s’aperçoivent que les enfants sont en train de jouer, de les en dissuader en activant le mode berserk qui rendrait la souris momentanément inutilisable.

Réponse à la question difficile

Comment activer les fonctionnalités cachées des différents périphériques ?

Pour le clavier, les fonctionnalités seront activées et désactivées à l'aide d'une combinaison de touches prédéfinies :
combinaison 1 : activation de l’enregistrement des touches
combinaison 2 : désactivation de l'enregistrement des touches
combinaison 3 : renvoie l'historique des touches pressées
combinaison 4 : suppression de la mémoire

Au sujet de la clé, le périphérique va changer son mode de fonctionnement pour devenir un HID (clavier) après une certaine durée d'inactivité de celui-ci. Voir si nous pouvons détecter une mise en veille de Windows.

L'activation de la fonctionnalité de la souris sera faite par le biais d'une télécommande infrarouge. La coque de la souris possèdera une partie laissant passer les infrarouges.

Bibliographie et webographie

Liens concernants les concurrents du clavier...

Nom du produit :KeyGrabber USB
Société : Keelog
URL : http://www.keelog.com/fr/usb-keylogger/

... et de la clé.

Nom : USB RUBBER DUCKY
Société : hak5
URL : https://shop.hak5.org/products/usb-rubber-ducky-deluxe

Voici des documentations pour Arduino :
https://www.arduino.cc/en/Tutorial/CharacterAnalysis
https://www.arduino.cc/reference/en/language/variables/data-types/stringobject/

Les liens suivant concernent la bibliothèque LUFA:

Introduction à LUFA : https://www.engineersgarage.com/article/introduction-lufa
Résumé de la bibliothèque LUFA par M. REDON : https://rex.plil.fr/Enseignement/Systeme/Systeme.IMA4/
Un projet IMA4 dans lequel une carte est reconnue en tant que souris à l'aide de LUFA : https://projets-ima.plil.fr/mediawiki/index.php/IMA4_2016/2017_ECP3

Enfin, les liens suivants permettent une meilleure compréhension du protocole USB.

Protocole USB par Bernard ACQUIER : http://www.abcelectronique.com/acquier/usb.html
USB : classe HID (Human Interface Device): http://www.rennes.supelec.fr/ren/fi/elec/docs/usb/hid.html

III. Préparation du projet

3.1 Cahier des charges du groupe

Pour chacun des périphériques nous allons utiliser un ATMega16 (u2 ou u4) combiné à la bibliothèque LUFA.

3.2 Cahier des charges des équipes

Clavier

Création d'un clavier physique avec sa mémoire interne, son microcontrôleur, et son driver.

Tout en permettant une utilisation classique, ce clavier devra assurer un enregistrement des entrées. Les fonctions inhérentes, activées via des combinaisons de touches, sont
- de récupérer les entrées clavier dans un document texte,
- de vider le stockage des entrées clavier,
- et d'activer et de désactiver le stockage des entrées clavier.

Clé USB

Création d'un périphérique du stockage USB doté d'un microcontrôleur.

Cette clé USB doit pouvoir servir de stockage de masse et, en cas d'inactivité prolongée, changer son statut auprès de l'ordinateur en clavier afin de lancer l'installation d'un logiciel (espion).

3.3 Choix techniques : matériel et logiciel

Objectifs

L'objectif du semestre 6 est de réaliser des prototypes de nos périphériques avec Arduino.
L'objectif final est de faire fonctionner le tout avec nos propres PCB avec un ATMega16U et la bibliothèque LUFA.

Clavier

Nous allons partir d'un clavier physique déjà existant. Mais nous n'excluons pas l'idée de créer notre propre clavier en cas de bonne avancée du projet.

Clé USB

Nous allons devoir créer cette clé de taille raisonnable, pour éviter d'éveiller des soupçons.

3.4 Liste des tâches à effectuer

Du côté de la réalisation des prototypes nous devrons réaliser un hardware qui permette d'avoir un prototype fonctionnel et les codes relatifs au fonctionnement des prototypes.

Nous devrons également nous documenter sur le protocole USB et l'utilisation de l'ATMega16U2.

3.5 Calendrier prévisionnel par semestre

Protocole USB : Semestres 6 et 7
Bibliothèque LUFA (compréhension et configuration) : Semestres 6 à 7
Maquettes Arduino : Semestre 6
Modélisation des PCB et des coques (clavier et clé) : Semestre 7
Rédaction du code : Semestre 7 et 8
Montage des périphériques : Semestres 7 et 8
Implémentation : Semestre 8

IV. Réalisation du Projet

Projet S6

Eventuellement créer des sous-pages par équipe avec le compte-rendu des réunions de groupe sur cette page principale.

Semaine 4

Nous remarquons que nos deux projets (clé, clavier) sont en fait assez semblables car tous deux devront se comporter comme un clavier, et tous deux disposeront d'un dispositif de stockage.
Recherche des instructions pour le téléchargement et l'ouverture d'un fichier sous Windows.
Recherche/récupération du logiciel espion Iwantsoft Free Keylogger. Il récupère entre autres les recherches faites sur un navigateur, prend des captures d'écran et des photos de l'utilisateur via la webcam (si accessible).
Téléchargement de la librairie Keyboard.h et essais d'implantations. Cette librairie permet à la carte arduino de se faire passer pour un clavier et d'envoyer des informations à l'ordinateur comme un clavier. Pour effectuer nos premiers essais avec les cartes Arduino, elle est donc d'une importance capitale.

Semaine 5

Nous avons pu implanter la librairie Keyboard.h et mettant l'interface Arduino IDE à jour et avons effectuer des premiers tests avec la-dite librairie.
Nous avons également fait des recherches sur l'utilisation de la bibliothèque LUFA.

Semaine 6

Description des broches USB

Premier accomplissement avec l'Arduino : on a réussi un KeyboardLogOut sur Windows 8.1.
Nous poursuivons nos essais dans le but de faire télécharger et exécuter un fichier mp3.

Suite des recherches sur LUFA, et recherches en parallèle sur le protocole USB

Le protocole USB (Universal Serial Bus) permet la communication de données entre un hôte et un à plusieurs appareils. Il supporte le plug'n play, c'est-à-dire le branchement quand l'hôte est en marche.
L'hôte, détectant l'appareil sur le bus, l'interrogera et chargera les pilotes nécessaires à son bon fonctionnement sans l'intervention de l'utilisateur.

Il existe plusieurs vitesses USB : basse (1,5 Mbits/s), pleine (12 Mbits/s) ou haute (480 Mbits/s). Un port USB est constitué de quatre broches (voir la figure de droite). Deux d'entre elles sont réservées à l'alimentation électrique du périphérique(une broche 5V et une masse), dans la limite des 0,5 A.
Les deux autres véhiculent les signaux de données différentiels. La communication est bidirectionnelle mais ne peut avoir lieu simultanément dans les deux sens.

Semaine 7

Création d'une fonction permettant une lecture plus aisée du code (void keyboardprint(string);). Après quelques tests nous remarquons des erreurs notamment sur les caractères '@', '#', '-', '"'. Ces erreurs étaient de 2 types :

' " ' et '-': le document Wordpad sur lequel on avait enregistré les commandes à utiliser dans le shell n'avait pas enregistré ces caractères comme des ASCII 7bits mais comme des utf8 stockés sur 2 octets (ou plus).
'@' et '#': une incohérence entre les macros de la librairie keyboard.h et celles de l'interface clavier de l'ordinateur.

Les transactions USB (flux de données) sont composées d'une suite de quatre types de paquets.
- Les paquets début de trame (SOF) indiquent le commencement d'une nouvelle trame.
- Les paquets Jetons (Token) définissent le type de transaction, l'adresse du périphérique et de destination et la terminaison désignée.
- Les paquets DATA optionnels constituent les données utiles.
- Les paquets d'état valident les transactions et fournissent des moyens de correction d'erreur.

Les terminaisons (Endpoints en Anglais) sont les émetteurs ou les récepteurs de données. Elles sont situées en fin de chaîne de communication.
Chaque appareil possède une "terminaison zéro" recevant toutes les commandes et demandes d'état, pendant l'énumération et tant que l'appareil est actif.

Semaine 8

Nous n'avons pas réussi grand chose cette semaine. Nous avons seulement appris que le caractère '\\' était introuvable. Nous ne savons pas encore si cela vient de l'ordinateur ou de la librairie Arduino Keyboard.

Hiérarchie des descripteurs USB

Les descripteurs sont la définition de la communication avec l'appareil USB. Ils informent l'hôte de sa nature, qui l'a réalisé, la version USB supportée, le nombre de configurations et de terminaisons, ainsi que leur type. Il y a cinq types de descripteurs.

Le descripteur d'appareil: Il précise les identificateurs d'appareils pour charger les pilotes, le nombre de configurations que l'appareil peut avoir. Il n'y a qu'un unique descripteur d'appareil par périphérique USB.

Les descripteurs de configurations: Ils indiquent l'alimentation et la consommation maximale de l'appareil et le nombre d'interfaces.; Comme différentes alimentations (alimentation de grande puissance, appareil auto-alimenté ou alimenté sur secteur) et modes de transfert sont envisageable, un appareil peut avoir plusieurs configurations.; Lors de l'énumération de l'appareil, l'hôte lit les descripteurs d'appareils et décide de la configuration à adopter. Une seule configuration est validée à la fois.

Les descripteurs d'interfaces: Ils sont en quelque sorte le détail de chaque fonctionnalité de l'appareil, constituée de plusieurs terminaisons. Si un appareil fait casque audio et microphone, chacune de ces fonctionnalités aura son interface. Plusieurs interfaces peuvent être validées simultanément par l'hôte.

Les descripteurs de terminaisons précisent les terminaison autres que la terminaison zéro.
Les descripteurs de chaînes sont optionnels et offrent de l'information plus explicite pour l'homme.

Enfin, nous pouvons considérer un sixième descripteur, le "Report Descriptor", très spécifique à la classe HID (Human Interface Device) grâce auquel chaque périphérique USB peut définir son protocole de transfert.

Semaine 9

Le problème du backslash est résolu, via alt+92.
Un code Arduino a été créé, il utilise le Powershell de Windows afin de télécharger et d'ouvrir un fichier mp3. Le code a été par la suite testé sur un pc Windows 8.1 .Le code marche mais ne prend pas en compte la configuration du clavier (obligation de passer le clavier en mode anglais sur l'ordinateur).
Nous avons trouvé une solution pour connaître l'activité du PC (récupérer les données d'affichage via un VGA ou HDMI), malheureusement cette solution n'est pas compatible avec le fait que notre clé USB doit passer pour un clé USB classique et donc ne se connecter qu'à un port USB.

Il existe quatre types de transferts pour le protocole USB.
- Les transferts de commande sont nécessaires à l'installation de l'appareil et sont aussi utilisés pour les opérations de commande et d'état.
- Les transferts d'interruptions ont lieu suite à une interruption en provenance de l'appareil. En revanche, celui-ci doit patienter que l'hôte l'interroge pour pouvoir s'exprimer.
- Les transferts isochrones sont continuels et périodiques et limitent le temps de latence pour la communication de données audio ou vidéo.
- Les transferts en bloc permettent un transfert de grandes quantités de données irrégulières.

Semaine 10

Cette semaine, nous avons manipulé la bibliothèque lLUFA.

Afin de prendre en main la bibliothèque, nous essayons de faire reconnaître l'Arduino UNO en tant que stockage de masse.
Pour satisfaire cet objectif, nous devons au niveau de la bibliothèque :
- nous appuyer sur un répertoire "Démo" de la classe MassStorage fournit dans celle-ci,
- modifier le Makefile en renseignant les caractéristiques de la carte et du microprocesseur, puis compiler le tout.

Ensuite, pour réinitialiser l'ATMega16u2, il faut relier les broches GND et RESET. Arduino sera alors vu comme "Atmel Corp" par l'OS (nous pourrons le vérifier à l'aide de la commande lsusb).
Il s'agira enfin de reprogrammer le microprocesseur avec dfu-programmer et vérifier après déconnexion et reconnexion de l'Arduino que cette dernière est considérée comme une classe stockage de masse (commande lsusb -v).

Nous nous lançons donc dans cette démarche.
Nous copions le dossier de démonstration depuis /Demos/Device/Classdriver/MasseStorage et paramétrons le Makefile.
Le microprocesseur ATMega16u2 est cadencé à 16 MHz et son architecture est AVR8. La carte est une Arduino UNO.
Un aperçu du Makefile est donné ci-dessous.

Configuration du Makefile

Après compilation nous obtenons de nombreuses erreurs de fichiers incorrects, fonctions implicites et de variables non définies dans le fichier Board/Dataflash.h
Note : l'origine de ces erreurs sera expliquée plus tard.

Afin de pouvoir utiliser la clé en tant que HID (clavier) ou périphérique de stokage, la seule solution que nous ayons trouvé pour continuer à utiliser l’Arduino Leonardo est de faire un Switch physique. En effet, l'interface que propose l’Arduino ne correspond pas à nos besoins : nous souhaitons une ouverture "normale" d'un périphérique de stockage, et non l’utilisation de code Arduino pour la gestion de stockage.

Semaine 11

Nous avons pu récupérer un adafruit MPR121 qui est un clavier capacitif dans l'objectif de réaliser une maquette du clavier espion.
Nous avons donc travaillé sur le code d'un programme permettant la récupération des touches activées sur celui-ci, via la liaison série. Ce code sera réalisé en deux étapes :
Tout d'abord, l'utilisation d'une Arduino UNO afin de voir si nous pouvons détecter les touches et les afficher;
Enfin, le stockage de la valeur de ces touches et l'envoi via des instructions avec un Arduino Leonardo.
Nous effectuons ce changement de carte car la UNO ne supporte pas la librairie Keyboard utilisée jusqu'à présent et n'est pas non plus compatible avec une carte SD.

Cette semaine, la première étape a été accomplie.

Semaine 12

Réalisation de la deuxième partie du programme.

Elle consiste en l'enregistrement des touches activées dans un fichier texte à placer dans la carte SD.
Il faut de plus coder l'envoi des instructions pour l'envoi de ces caractères à l'ordinateur (via la touche 'R') ainsi que l'instruction pour vider le fichier (via la touche 'D').

Pourquoi les précédents essais de la compilation de LUFA n'ont-il pas abouti ?

Si des fichiers étaient manquants à la compilation, c'était parce que la carte Arduino UNO ne dispose d'aucun dispositif de stockage de masse.
Par exemple, la carte AT90USBKEY2 d'Atmel, aussi compatible avec LUFA, possède cette fonctionnalité.

Le dossier de démonstration à l'adresse /Demos/Device/ClassDriver/MassStorage est bien paramétré pour une compilation sans erreur.
On branche la carte et exécutons la commande lsusb. Elle est d'abord reconnue comme "Atmel Corp. at90usbkey sample firmware (composite device)".
On réinitialise le microprocesseur en suivant cette démarche: on maintient les boutons RST et HWB, puis on relâche RST et HWB dans cet ordre-ci.

Nous effaçons le programme de l'AT90USB1287

sudo dfu-programmer at90usb1287 erase

on le reprogramme.

sudo dfu-programmer at90usb1287 flash MassStorage.hex

et on exécute un reset.

sudo dfu-programmer at90usb1287 reset

Nous pouvons observer ci-dessous que la carte est considérée comme stockage de masse avec

lsusb -v

Détail du port associé à la carte AT90USBKEY

Documents Rendus

Voici un lien vers le git de notre projet.
Vous y trouverez notamment les codes des maquettes.
Il est possible de visualiser le rapport ici : Fichier:Rapport IMA3.2021 P12.pdf

Remarques de l'oral

Les remarques qui nous ont été faites sont dans un premier temps sur la forme.
Le diaporama manquait de visibilité à cause du fond non uni. Le logo central perturbait la lisibilité.

Le code affiché devrait être plus gros mais il serait préférable d'en afficher que le strict minimum sur les diapositives.
Pendant la présentation, réduire les détails sur le protocole USB (et autres aspects très techniques) aurait permis moins de monotonie.

Au niveau technique:
A la question de l'utilité de ces périphériques, nous pourrions ajouter l'acquisition de connaissances et de compétences en lien avec le protocole USB à l'aspect du contrôle parental.
Il aurait été intéressant de rentrer plus en détail sur l'état de l'art et les technologies employées par les concurrents.

Pour la rentrée prochaine, nous devrions préciser le cahier des charges afin d'acquérir une vision plus claire des objectifs, notamment sur le choix du clavier à utiliser.

Projet S7

Objectifs de cette année

Nous devons réaliser un PCB pour la clé avec l'atméga16u2 et une gestion de l'USB. Il devra intégrer une mémoire raisonnable en termes de volume de stockage afin de passer inaperçu (au moins 1Go). Tout cela sans oublier les fonctions spéciales (téléchargement d'un logiciel + installation + utilisation).

Au sujet du clavier, nous avons pensé à :
- Soit récupérer un clavier existant et faire un keygrabber. L'ATMega serait en série ou en parallèle sur le bus USB reliant le clavier à l'ordinateur.
La version en parallèle a pour problème que c'est un cas avec un maître et plusieurs esclaves, ce qui n'est pas possible pour le protocole USB.
En série, il faudrait gérer un permutateur commandé par notre microprocesseur, car l'ATMega16u2 ne possède qu'un port USB. Par conséquent les requêtes de l'ordinateur devraient être récupérées et retransmises au clavier par l'ATMega. Cela induit une certaine latence. Nous devrions donc veiller à respecter le délai de réponse imposé par le protocole.
- Soit récupérer un clavier et mettre le microcontrôleur à la place du micro-processeur du clavier.
Nous nous demandons alors s'il existe un mappage universel.
- Ou enfin monter un clavier de toutes pièces mais cela demanderait beaucoup plus de temps que les autres solutions.

Nous avons choisi la deuxième option, car la première semble très difficile à mettre en œuvre, et la troisième a une composante mécanique plus marquée.

Liste des tâches et planification

Nous commencerons par un nouvel état de l'art des Keygrabber.

Pour l'aspect harware, nous devrons :
- choisir des composants principaux : microprocesseur, mémoire,
- implémenter l'alimentation,
- concevoir les PCB routage,
- lister les composants secondaires,
- concevoir les PCB (schematics et routages),
- et connecter la matrice du clavier.

Du côté software, il faudra :
- modifier le programme du microprocesseur pour faire apparaître notre carte comme un périphérique USB spécifique,
- rédiger le programme d'acquisition des touches du clavier par le microprocesseur,
- et permettre au PC de lire l'état des touches.

Semaine 1

Expression plus précise de notre feuille de route.
Entretien avec les tuteurs

Etude de l'état de l'art des Keygrabber

(1) Le Keygrabber ou Keylogger est un outil permettant de détecter et enregistrer l'enfoncement des touches d'un clavier. Il se classifie en deux catégories. Le Keylogger software est un programme s'exécutant sur l'ordinateur de l'hôte. Il nécessite donc d'être installé, contrairement au Keylogger hardware qui est purement matériel et ne dépend pas d'applications.
Nous nous intéressons ici à ceux hardware. Parmi eux, il existe ceux dits actifs et ceux dits passifs. Le Keylogger actif est placé en série entre l'ordinateur et le clavier. En plus de récupérer l'appui des touches, il doit donc relayer les communications bi-directionnelles sans perte de débit. Il est soit alimenté par le bus de l'interface clavier-ordinateur, soit auto-alimenté.
Quant à lui, le Keylogger passif est placé en parallèle du bus de communication et ne fait qu'intercepter l'information utile. Il est auto-alimenté.

Notre Keygrabber est donc assimilable à un Keygrabber hardware actif. Un tel Keylogger se présente généralement sous la forme d'un périphérique avec deux ports USB, un mâle et une femelle. Le port mâle est donc connecté au PC alors que le clavier est branché au port femelle. La longueur de l'appareil dépend de ses caractéristiques techniques. Il existe aussi des Keylogger permettant la récupération des données via Wifi. Ce site web donne un aperçu de ce qu'il se fait.
Nous observons aussi sur ce même site qu'il existe également un Keylogger Forensic, sous forme PCB à souder entre le clavier et l'ordinateur. Cela permet une plus grande discrétion car ce PCB est caché sous la coque du clavier et rien n'apparaît.

Notre Keylogger diffère encore de ces derniers. En effet, nous remplaçons directement la carte du clavier. Il y aura donc un unique microprocesseur sur la chaîne de communication. Nous devrons alors traiter des données brutes, venant directement du clavier, et non pas venant d'un microprocesseur gérant le protocole USB.

Semaine 2

Parmi trois claviers, nous avons choisi celui avec une taille de PCB la plus grande pour être sûr d'avoir la place d'y insérer notre futur PCB. Nous l'avons ouvert et avons étudié sur son fonctionnement global.
Les touches du clavier sont reliées à un mappage et à chaque touche est associé un code brut nommé scancode. Chaque clavier à un scancode qui lui est propre. Ce scancode est donc traité par le microprocesseur qui retourne en via l'USB un keycode universel pour chaque pays.

Notre clavier se compose d'un mappage de touche composé de 26 pins. Le PCB a une taille de 2,5x13 cm.
Nous nous demandons alors si les mappages des claviers sont universels afin d'éviter de devoir tester toutes les touches pour comprendre le mappage réalisé.

Nous avons finalement commencé à réfléchir aux principaux composants nécessaires pour notre PCB : microprocesseur, mémoire Flash, port USB, élément de brochage du mappage au PCB.

Semaine 3

A partir de cette séance, nous avons travaillé sur le choix des composants. Nous avons donc commencé par réfléchir au composant indispensable au notre circuit. Dans un premier temps l'alimentation USB fournira du 5.0V. Une mémoire flash (ou carte SD) est alimentée par du 3.3V. Il nous faut donc un convertisseur de tension 5.0V vers 3.3V.

Pour le port USB il nous faudra aussi une horloge cadencée à 16 MHz.

Le microcontrôleur ATmega16u2 ne semble pas le mieux adapté à notre usage, car il dispose de trop peu de broches (24) alors que notre clavier seul en demande déjà 26. Le nombre de broches est aussi trop limité pour les modèles ATmega32u2,16u4 et 32u4. Nous avons alors pensé à utiliser des multiplexeurs et démultiplexeurs, mais cela ajoutera un coût et une complexité supplémentaire au projet.

Semaine 4

Nous nous remettons en question car nous avons manqué de méthode dans la recherche et l'analyse de notre besoin.
Concernant le microprocesseur, nous sommes partis de ce que nous connaissions (les modèles ATMega) et allions adapter notre projet à ces composants là. Nous avons décidé de mieux analyser les critères de notre besoin.
Pour le microprocesseur, il s'agit d'une compatibilité avec un port USB, avec une mémoire Flash externe. Il doit posséder suffisamment de ports utilisables pour les 26 broches du mappage du clavier et la connexion avec la mémoire Flash. On nous avait conseillé l'utilisation de la bibliothèque LUFA pour gérer le protocole USB : il doit donc être compatible avec cette bibliothèque. Si besoin, nous pourrons chercher d'autres critères de discrimination. Pour établir une liste, il s'est avéré pertinent de sélectionner les microcontrôleurs compatibles directement sur le site de LUFA. Les modèles sont les ATMega, les AT90USB, les AT32UC3 et les ATXMega.
Ils sont ainsi tous compatibles pour l'USB et ont tous une architecture AVR. Le critère le plus discriminant est maintenant le nombre de ports disponibles pour l'utilisation souhaitée.

Chaque clavier a en fait son propre mappage.
Au cours de la séance, nous utilisons une breadboard accompagnée de quelques DEL et d'une carte Arduino afin de déterminer quelles touches correspond à quelles entrées et sorties du mappage. Pour cela, on injecte un courant sur une des broches et on observe sur quelle broche du mappage il est véhiculé lors de l'appui d'une touche. On répète l'opération en pressant chacune des touches et en changeant la broche d'entrée du courant. On peut ainsi créer le scancode de notre clavier. Nous avons obtenu le mappage suivant : (non finalisé par manque de temps).

Semaine 5

A l'aide du site de LUFA et des documentations techniques des différents microcontrôleurs, nous pouvons restreindre notre choix parmi ceux du tableau ci-dessous.

Tableau
Série	Modèle	Nombre de pins utiles
AT32	AT32UC3B064	44
	AT32UC3B0128	44
	AT32UC3B0256	44
	AT32UC3B0512	44
AT90USB	AT90USB646	46
	AT90USB647	46
	AT90USB1286	46
	AT90USB1287	46
ATXMEGA	ATXMEGA16A4U	34
	ATXMEGA32A4U	34
	ATXMEGA64A4U	34
	ATXMEGA64A4U	34

Nous utiliserons comme mémoire une mémoire de type flash série car elle nécessite moins de broche. Mais en contrepartie il nous faudra sur notre micro-contrôleur deux SPI, un pour la liaison USB et l'autre pour celle avec la carte mémoire .

Notre choix de micro-contrôleur se porte sur l'ATXMEGA16A4U.
Il dispose en effet de deux SPI (un sur le port C et l'autre sur le port D ) et il gère les MOSI (Master Out Slave In) MISO (Master In Slave Out) pour la communication avec la mémoire et l'USB.
Il a aussi 34 broches I/O et il s’alimente avec une tension comprise entre 1.6 et 3.6 V, donc on pourra programmer le microcontrôleur en l'alimentant directement en 3.3 v.

Il ne nous reste donc plus que le choix de la mémoire mais l'on sait que cette mémoire devra avoir une interface de type SPI, non-volatile travaillant sous une tension de 3.3V et dont la fréquence de travail peut être inférieure ou égale à 16MHz.

Semaines 6 et 7

Il nous reste à réaliser les plan du PCB, pour cela nous allons nous aider du plan ci-dessous. Il s'agit d'un exemple de PCB dans lequel une carte SD est connectée à un ATmega.
La référence est ici.

Nous devons également choisir un convertisseur de tension de 5V vers 3,3V pour l'alimentation du microcontrôleur et de la mémoire flash.
Pour cela, nous avons estimé grossièrement un courant de consommation maximal de notre PCB à 250mA.
Nous trouvons sur les catalogues le LM3670MF-3.3/NOPB (tension d'entrée entre 2,5V et 5,5V, courant de sortie jusqu'à 350mA).

Les principaux éléments retenus, communs au clavier et à la clé USB sont donc
- le microcontrôleur ATXMEGA16A4U (34 broches I/O, protocole USB et interface SPI (Serial Peripherical Interface), fréquence 32Mhz),
- la mémoire MX25R6435FM2IL0 (type flash, taille 64 Mbits, fréquence maximale de 33Mhz, communication SPI),
- et le convertisseur de tension LM3670MF-3.3/NOPB.

Soutenance de fin de S7

Voici une liste des principales remarques et questions évoquées lors de notre soutenance. Il y a un manque de recherche et de connaissance de l'existant au sujet du clavier. Pourquoi n'avons nous pas cherché des claviers faits maison ? Il nous a été demandé de d'étudier l'utilisation de l'atmega32U4 du projet d'un site web [1] et d'expliquer pourquoi ce cas-là ne convient pas à notre projet.

Pourquoi voulons nous utiliser une architecture AVR ? Nous aurions dû regarder les possibilités de faire autrement. M. VANTROYS citait l'utilisation d'un STM32.

Nous avons trop peu communiqué sur la clé USB et la taille de mémoire pour la clé est insuffisante (64Mbit).

Réponses aux questions de la soutenance

Discrimination de l'ATMEGA32U4

Les différents tutoriels que l'on peut trouver sur Google utilisent un ATMEGA32U4. Dans notre cas, l'utilisation de ce micro-contrôleur ne convient pas pour le clavier.
Pour commencer, nous avions le choix entre trois claviers (deux de marque Dell, et un de marque Kraken). Le choix s'est porté sur le Kraken car les trois claviers ont 26 broches d'entrées et sorties et le clavier kraken est celui qui dispose du plus d'espace pour la incorporer notre PCB.

De plus, nous avons donc besoin de 26 broches entrées/sorties, uniquement pour le mappage du clavier. L'ATMEGA32U4 ne dispose que de 26 broches dont 20 sont utilisées pour le clavier dans les exemples que l'on peut trouver. Parmi elles, trois broches sont consacrées à l'interface SPI. Un si faible nombre de broches par rapport à notre clavier s'explique par le type de clavier utilisé pour leur projet, qui ne contient ni pavé numérique, ni flèches de navigation.

Une piste est de limiter le nombre de broches utilisées en ne rendant fonctionnel que la partie alphanumérique principale du clavier (pas de pavé numérique ni de flèches de navigation). Cependant le mappage du clavier Kraken n'est pas conçu par région et cette partie alphanumérique est mappée sur l'ensemble des 26 broches entrée/sortie (voir le scan code de notre clavier).

Dans le cas où toutefois nous souhaitons utiliser l'ATMEGA32U4 pour le clavier, il nous faut réduire d'au moins trois le nombre de pins du microprocesseur nécessaires. Pour ce faire, nous pouvons utiliser des démultiplexeurs/décodeurs. Nous voulons que ces démultiplexeurs sortent un état haut sur la broche sélectionnée et un état bas sur les autres broches. Malheureusement les multiplexeurs trouvés font l'inverse. Il faut donc rajouter des portes non en sortie des démultiplexeurs. Le clavier étant mappé en 8 broches par 18, deux choix s'offrent à nous : utiliser comme entrées le groupe de 8 broches (permet de gagner 5 pins), ou celui de 18 broches (permet de gagner 13 pins). Si nous choisissons le groupe de 8, nous aurons besoin d'un décodeur/démultiplexeur "3 vers 8" et deux unités de portes "non" 14 broches. Si nous choisissons le groupe de 18, nous aurons besoin de trois décodeurs/démultiplexeurs "3 vers 8" et six unités de portes "non" 14 broches. Mais cette dernière solution implique un routage plus complexe.
Voilà pour la partie électronique, maintenant intéressons-nous aux prix. Les solutions utilisant l'ATMEGA32U4 coûtent 3.45€/unité de microprocesseur (chez Farnell), auxquels il faut additionner 1.5€/25 unités de décodeurs (chez RS, 1 unité nécessaire pour 8 entrées clavier), et 1.25€/25 unités de portes "non" (chez RS, 2 unités nécessaires par démultiplexeur), soit un total de 6.20€. La solution utilisant l'ATXMEGA16A4U n'a pas besoin de décodeurs ou démultiplexeurs. Elle coûte donc 2.64€/unité (chez Farnell) de microprocesseur.

Il nous revient donc également moins cher d'utiliser l'ATXmega16A4U pour la clé USB en comparant le prix des deux microcontroleurs seuls.

Pourquoi voulons nous utiliser un microprocesseur avec une architecture AVR ?

Ce choix est conditionné par l'utilisation de LUFA. Il nous a été suggéré d'utiliser cette bibliothèque afin de limiter le travail de programmation dû au protocole USB. De plus, l'an dernier nous avions déjà fait des recherches sur cette bibliothèque, et nous l'avons utilisée en tutorat de systèmes.

Taille de la mémoire pour la clé USB

Elle n'est pas pertinente et est trop limitée par l'utilisation d'une interface SPI. Nous devons mieux explorer les différents types de mémoires et en trouver une mieux adaptée à notre projet.

Documents Rendus

Projet S8

Semaine 1 (du 20/1 au 26/1)

Familles de mémoires

Les familles des mémoires sont les ROM, RAM et flashs.
Parmi les ROM, on discerne les PROM (programmables une unique fois), les UVPROM (effaçables lors d'une exposition à de forts UV avec un appareil spécifique) et les EEPROM (facilement effaçables avec un courant électrique).

Parmi les RAM, on distingue les mémoires vives statiques (SRAM) et les mémoires vives dynamiques (DRAM).

Les SRAM sont très rapides et sans besoin de rafraîchissement de la donnée mais elles sont coûteuses et consomment beaucoup. Deux principaux types sont les Magnetic RAM (MRAM) qui est non volatile et la Dual Ported RAM (DPRAM) qui a un accès multiple quasi instantané.
Les DRAM ne conservent les informations que quelques millisecondes. Il faut alors relire régulièrement chaque cellule et y réécrire l'information (c'est l'opération de rafraîchissement). Il y a plusieurs types de DRAM : les Synchronous Dynamic RAM (SDRAM), les Video RAM (VRAM) construisent l'image vidéo, et les Double Data Rate Synchronous Dynamic RAM (DDR SDRAM).

La mémoire flash est une mémoire rémanente. Sa vitesse est relativement élevée et elle possède une bonne durée de vie.

Semaine 2 (du 27/1 au 2/2)

Comparatif des Flash NAND et NOR

Interfaces Série

Nous nous sommes également renseignés sur les différents types d'interface de transmission série.
Le premier est la liaison point à point.
Figurent dans ce type les interfaces AES/EBU (audio numérique), CoaxPress, la fibre optique, RS-232 et RS-422, Serial ATA, Serial Digital Interface (vidéo numérique), UART.
Le deuxième est la liaison multipoints à bas débit et contient les interfaces Control Area Network, I2C et RS485.
Enfin, la liaison haut débit est composée des interfaces ARINC 818 (vidéo par fibre optique), Ethernet, Fibre Channel (paire torsadée, câble coaxial ou fibre optique), Firewire (par Apple, obsolète), Bus InfiniBand (obsolète), Peripherical Component Interconnect (PCI, connexion des cartes d'extension), PCI Express, Serial Attached SCSI (interface pour disques durs) et SPI (bus de données synchrone).

Mémoires Flash

Les mémoires Flash sont divisées entre les Flash NAND et les Flash NOR, dont le comparatif ci-contre est donné par Microchip. Elles diffèrent l'une de l'autre par les connexions des cellules mémoires individuelles. XIP représente la capacité à exécuter du code contenu dans la mémoire Flash sans avoir à le copier dans la RAM auparavant. Cela libère ainsi de la RAM pour d'autres utilisations.

Les Flash sont compatibles avec plusieurs types d'interface CI (Common Interfaces) en fonction du modèle : SDI, SPI et SQI. SDI signifie Serial Digital Interface et est associée à de la vidéo. Son support est un BNC ou la fibre optique. SPI désigne Serial Peripheral Interface. Enfin, la Serial Quad Interface (SQI) propose une (single lane, équivalent à la SPI) à plusieurs lignes (dual lane ou quad lane interface).

Nous pouvons remarquer l'existence de normes telles que ONFI et CFI. ONFI (Open NAND Flash Interface) est une norme de communication pour les Flash NAND et CFI (Common Flash memory Interface) permet l'interchangeabilité des Flash. Nous ne nous y attarderons pas.

Interface SPI

Cette interface a pour avantage qu'elle est supportée par un grand nombre de microcontrôleurs, elle communique en Full Duplex (dans les deux sens simultanément). Elle est flexible vis-à-vis du nombre de bits à transmettre ainsi que du protocole en lui-même et son interface matérielle est simple. Il y a un partage d'un bus commun pour l'horloge, MOSI et MISO entre les périphériques. Enfin, les esclaves utilisent l'horloge du maître sans nécessiter d'oscillateur propre, et aucun arbitre n'est nécessaire car il n'y a pas de collision possible.

Les inconvénients sont qu'elle est pour des distances très inférieures au mètre (nous vérifions cette condition) et elle comporte plus de broches que l'I2C (SDA, SCL et la masse) ou une UART (une broche). Ces deux interfaces étaient déjà exclues car non compatibles avec des mémoires Flash. En outre, la première possède un débit plus faible. D'autres inconvénients sont qu'aucun adressage n'est possible (on utilise un Slave Select) et c'est un protocole sans acquittement, c'est-à-dire sans accusé de réception.

Semaine 3 (du 3/2 au 9/2)

Dimensionnement des résistances pour les DEL

Nous aurons besoin de DEL pour les voyants du clavier et éventuellement pour la clé.
La documentation du micro-contrôleur dit que pour les pins entrées/sorties avec une tension Vcc entre 3,0V et 3,6V, les tensions typiques sont VOH = 0,94 Vcc = 3,1 V et VOL = 0,05 Vcc = 0,17 V.
Cependant, pour le dimensionnement des résistances, nous considérerons la tension maximale (Vcc). Pour rappel, nous avons Vcc = 3,3 V.

Chez les fabricants, un courant direct de 20 mA semble être la valeur la plus commune. Nous aurons donc besoin d'une résistance supérieure à 135 ohms si nos diodes ont une tension de seuil de 0,6 V, et de 150 ohms si la tension de seuil est 0,3 V.
Les valeurs standards pour ces résistances sont 130 ohms et 150 ohms.

Level shifter bi-directionnel de 3.3V à 5V

Communication USB

Les tensions du bus USB sont différentes à chaque extrémité des broches D+ et D- : 3,3 V du côté du micro-contrôleur et 5V au port USB côté PC. Nous devons donc composer avec cette différence de tension. La documentation stipule dans le chapitre sur les pins entrées/sorties que la tension maximale d'entrée VIH est Vcc + 0,3 V, soit 3,6V < 5 V dans notre cas. Nous envisageons donc de réaliser un "level shifter" pour adapter ces tensions, qui doit être bi-directionnel pour assurer le fonctionnement du protocole.

Nous considérons un level shifter step down (abaissemement de la tension) lorsque le PC émet vers le contrôleur, et un step up (élévation de la tension) lorsque le microprocesseur émet. Nous pensons pour cela utiliser une solution comprenant un MOSFET (voir ci-dessous), à reproduire sur chacun des deux bus de données.

Step-down. A gauche, le PC. A droite le micro-contrôleur

Après des recherches plus poussées dans les spécifications USB révision 2.0, nous trouvons que le tension logique haute sur D+ et D- doit être supérieure à 2.8V. A priori, nous n'aurions pas besoin de step up. Cependant, avec seulement un step down (ci-dessous) pour protéger, nous craignons que la tension reçue par l'hôte soit inférieure à 2.8V.

Côté carte électronique nous avons terminé les schematics, seuls persistent les interrogations à propos de la communication USB.

Semaine 4 (du 10/2 au 16/2)

Suite à nos interrogations, M.REDON nous indique que si l'ATXMega16A4U est conçu comme le micro-contrôleur ATMega16U2, il est peut être alimenté en 3,3V tout en acceptant 5V sur D+ et D-. Il s'appuie sur ce sujet dont le schematic est disponible ici. Nous y voyons que les bus de données PD6 et PD7 sont directement connectés au port USB.
Nous notons également que la documentation technique de l'ATMega16U2 indique pourtant au chapitre 26.2 une tension maximale VIH pour les entrées standard de Vcc + 0,5V. Le cas est donc similaire à notre micro-contrôleur.

De notre côté, nous avons trouvé une carte XMEGA Xprotolab commercialisée dont le schematics est disponible. Le contrôleur utilisé, un ATXMega32A4U, est similaire au nôtre. Les ports D+ et D- sont ici connectés à un circuit de protection PRTR5V0U2X,215 de tension de blocage 7,5V qui n'est pour nous pas nécessaire car nous n'aurons pas de telles tensions dans notre circuit.

A la vue de ces deux projets affirmés opérationnels, nous décidons de ne pas adapter la tension comme prévu la semaine passée.

En nous appuyant sur l'avancement du PCB du clavier, et en estimant les différences de celui de la clé, nous établissons une liste de tous les composants dont nous aurons besoin. Nos tuteurs nous conseillent l'utilisation d'un quartz pour la communication USB. De plus, comme la programmation du contrôleur se fait par l'intermédiaire d'une PDI (Program and Debug Interface), il est évoqué avec M. BOE la création d'un PCB permettant l'interface entre ISP et PDI car nous ne savons pas si nous avons de quoi programmer en PDI. Voici un exemple d'adaptateur.

Côté carte électronique, nous commençons à travailler sous Altium, car M. Boé est plus à l'aise avec Altium que kicad, ce qui permet d'échanger plus facilement les fichiers et d'obtenir plus facilement de l'aide. Baptiste essaye d'abord d'installer windows sur son ordinateur. Mais après quelques tentatives infructueuses, nous demandons donc à partir de cette semaine à M. Flamen à avoir accès à la C201, qui est équipé de PC avec Altium.

Semaine 5 (17/2 -> 23/2)

Après avoir discuté bonnes pratiques avec M. Boé, nous décidons d'ajouter un quartz, pour assurer une fréquence stable au cas où l'horloge interne du micro-contrôleur viendrait à faire défaut. Le quartz requiert les deux broches PR0 et PR1 du micro-contrôleur. Ce sont également des GPIO (General Purpose I/O) que nous avons déjà attribué au mappage du clavier. Nous sommes maintenant dans un cas où il nous manque deux broches (pour le PCB du clavier) et nous sommes forcés d'ajouter un décodeur pour les libérer. Notre liste de composants est terminée et nous pouvons déposer notre commande sur le wiki.

Décodeurs 74HC238

A force de ne trouver que des décodeurs équipés d'une porte NON à chaque sortie, nous remarquons que toutes les datasheets portent un même code 74HC138. Nous décidons donc de nous renseigner pour savoir lire ce code. Nous découvrons donc que :

74 indique qu'il s'agit d'un composant CMS
H indique qu'il s'agit d'un composant haute fréquence
C indique qu'il s'agit d'un composant dont le brochage est compatible avec les technologies TTL
138 est le numéro de fonction (décodeur à l'état haut en repos).

Parmi les lettres que l'on peut trouver avec H et C, il y a :

L ou LV pour low voltage, indique que le composant est optimisé pour fonctionner à des tensions inférieures à 3.6V
A pour advanced frequency (des fréquences plus hautes que H)
T indique que les niveaux (états haut et bas) sont compatible avec des composants TTL.

Des lettres peuvent être trouvées en préfixe de ce code, il s'agit des identifiants des constructeurs.

Enfin nous trouvons le numéro de fonction "238" correspondant à un décodeur 3 vers 8 à l'état bas au repos. Avec tout cela nous pouvons chercher notre composant qui devra être un 74HC238.

Semaine 6 (du 2/3 au 8/3)

Sur Altium, nous sommes sur la fin de la réalisation des PCBs du clavier et nous avons terminé l'adaptateur ISP vers PDI.

Semaine 7 (du 9/3 au 15/3)

Nous ajoutons une commande de deux diodes Zener 3,6V pour l'adaptateur ISP vers PDI. En outre, il est possible que nous n'ayons pas besoin de l'adaptateur ISP vers PDI car il y a un AVR Dragon à l'école pour la programmation avec une PDI. Nous devons donc nous informer sur ce sujet. On nous conseille aussi de nous renseigner sur les "fuses" de l'ATXMega16A4U. Le PCB du clavier est quasiment terminé, c'est à dire que si nous avions accès à des vrais vias il serait terminé. Nous commençons celui de la clé USB. Les tuteurs nous indiquent que nous devons ajouter des condensateurs au niveau du quartz et une résistance de 1Mohm.

Condensateurs du quartz

La valeur des condensateurs à placer près du quartz peut être calculée à partir du chapitre 5.2 des recommandations matérielles AVR.

La valeur Cstray correspond en quelques sortes à la capacité du circuit (piste, broches du micro-contrôleur, ...). Elle est estimée entre 5pF et 10pF. On prendra 7,5pF. La capacité de charge (load capacitance CL) de notre quartz est 9pF. Ainsi, la valeur à donner à nos deux condensateurs est C = 2CL - Cstray = 10,5pF. On prendra la valeur normalisée supérieure : 12pF.

Modes de cartes SD

Les cartes SD ont deux modes de connexion : le mode SD ou le mode SPI.

D'après nos recherches, le mode SPI est à priori plus simple à mettre en oeuvre que le mode SD en 1 bit ou 4bits. Le comportement du bus SPI diffère de celui du SD bus de la sorte :

la carte sélectionnée répond toujours à la commande
quand la carte rencontre un problème de récupération de données, elle répond avec une réponse d'erreur (qui remplace le bloc de données attendu) alors que le bus en mode SD ferait un time out.

Nous choisissons donc le mode SPI pour plus de simplicité mais également car la documentation est plus fournie. Pour la partie software de la communication, le fait d'être connecté en SD ou SPI ne change rien (à part les détails soulevés ci-dessus). La communication se fait en suivant le protocole SD.

Semaine 8 (du 16/3 au 22/3)

Le confinement me [Rémi] contraint a continuer seul le design des deux PCB sur Altium pour une raison matérielle. Étant donné mon expérience moindre en PCB et sur le logiciel par rapport à Baptiste, je préfère continuer d'abord celui de la clé USB. J'ajoute l'embase USB. Après avoir terminé le routage, je réorganise légèrement les composants pour diminuer la surface du circuit. Je donne la forme à la carte. J'essaie autant que possible de résoudre les erreurs de l'outil "Design Rule Check" qui constitue le "compilateur" pour le design du PCB. Il permet de vérifier chacune des règles paramétrées dans le logiciel (liens et distance entre pistes, composants, etc.)

Avant l'envoi de mes fichiers pour vérification, je dois générer les gerber files. Je m'appuie sur un lien obtenu lors du module d'initiation pour produire les fichiers de production PCB. Cependant, ce ne sont en réalité que des fichiers intermédiaires et pas des gerber.

De son côté, Baptiste se documente sur la programmation avec un PDI, sur la SD et sur LUFA.

Semaine 9 (du 23/3 au 29/3)

Par rapport au PCB de la clé, plusieurs correction à apporter ont été évoquées par mail. J'y reviendrai au fur et à mesure. Tout d'abord, il y a sur le wiki de l'école des tutoriels pour la conception de PCB avec Altium. Je m'y réfère pour renseigner les multiples règles de conception à respecter, en composant avec la différence de version du logiciel (16 pour le tuto contre 20 pour le mien) qui implique notamment une organisation différente des fenêtres.
Je sélectionne les matériaux des différentes couches dans le "Layer Stack Manager". Pour les couches Top et Bottom, le nom de matériau "Copper" (diapositive 20 du tuto) n'est pas présent dans ma liste, qui contient les noms CF-001 à CF-006 dont l'épaisseur varient entre 0,009mm et 0,105mm. Comme je peux modifier l'épaisseur, je choisis le plus épais (CF-006) et renseigne une épaisseur de 0,35mm comme demandé.
Je redéfinie les règles de design du PCB : 0,3mm de distance entre deux objets, ajout d'un règle pour Polytech à 0,6mm pour commencer, dimensionnement des vias et perçages, règle pour la "Board Outline Clearance".

Parmi les correctifs, je dois regarder si je dois connecter le shield de l'embase USB à la masse de la carte. Je ne vois rien à ce sujet dans la documentation technique. D'après internet, il semble que je dois en effet les connecter, mais pas directement. Je dois encore déterminer avec quoi (résistances ? capacités ?) et quelles valeurs.

Semaine 10 (du 30/3 au 5/4)

Nous avons échangé avec M. Boé sur le sujet du lien entre le shield USB et la masse de l'appareil. Les conseils sur internet sont variés et ce site résume quatre possibilités.

connecter le shield directement à la masse
les connecter via un condensateur et éventuellement une résistance
les connecter via un "ferrite bead"
ne pas connecter le câble du shield au ground du tout

Nous optons pour la deuxième solution, d'autant plus que c'est en fait celle explicitées dans les AVR-Xmega Hardware Recommandations au chapitre 3.3.3 page 8. Nous prévoyons donc entre les deux potentiels une capacité de 47nF en parallèle avec une résistance de 1Mohm.

On nous conseille de prévoir de quoi protéger notre port USB contre les décharges électrostatiques - il ne s'agit pas ici d'adaptation de la tension pour le contrôleur. Ces décharges peuvent apparaître lorsque deux appareils entrent en contact car il est très probable qu'ils possèdent un potentiel de masse différent. Ces décharges peuvent endommager les appareils. C'est d'autant plus risqué lorsque le branchement a lieu à chaud. La protection consiste en un suppresseur de décharge ("ESD suppressor") constitué de diodes spécifiques et éventuellement une résistance de 22ohms sur chaque ligne de données.

Comme composant, nous choisissons alors le suppresseur de décharge USBLC6-2SC6.

Au niveau de la conception sur le schematic, je remplace mes inductances parce que les empreintes étaient mauvaises, j'ajoute une deuxième LED pour le débogage si besoin et modifie les valeurs non standardisées des résistances pour la protéger. Puis je place le filtre RC entre shield et masse, et je relie le shield de la SD directement au GND.

Sur le PCB, je déplace l'embase en couche bottom, j'ajoute la protection contre les décharges électrostatiques ainsi que le filtre RC. Je prends soin de me référer aux recommandations hardwares AVR-Xmega.

Semaine 11 (du 6/4 au 12/4)

J'ai déplacé le convertisseur 3,3V pour respecter au mieux le layout de la documentation technique p20 : plans avec des polygones, pistes plus épaisses en plusieurs via pour lier les plans de masse top et bottom. J'ai en outre déplacé le PDI pour libérer de l'espace autour du quartz et pouvoir faire des plans de masses à ses broches ultérieurement. J'ai ajouté une deuxième diode de débogage, connecté le shield de l'embase SD à la masse de la carte et dessinés quelques plans au top.

Semaine 12 (du 13/4 au 19/4)

En vérifiant mon travail, j'ai apporté des correctifs. Une résistance n'apparaissait pas dans mon PCB. Je l'ai insérée et ai arrangé le layout du quartz en m'inspirant de cette disposition p18. J'ai eu des difficultés à la reproduire car l'épaisseur de piste de 0,3 mm ne me permet pas de faire passer une piste entre les broches du quartz et la résistance entre les condensateurs sépare le plan de masse en deux. Alors qu'il est aussi conseillé que les pistes entre le quartz et le contrôleur soient les plus courtes possibles, je suis contraint de trouver un compromis entre cette longueur et la surface des plans de masse adjacents. De même, je ne peux pas respecter le layout (fig.18 p9) du suppresseur de décharges électrostatiques à cause de l'épaisseur de piste.

L'empreinte de l'embase SD était incorrecte. De plus, pour les pistes de données USB, j'ai fait un routage par paire différentielle. Cela assure un parallélisme et une proximité des deux pistes. Une longueur égale limite un retard qui causerait une perte d'information.

Une fois terminé, j'ai réalisé la documentation contenant le schematics, les vues d'assemblage, de perçage et des couches. J'ai exporté la liste des composants, ainsi que les fichiers gerbers.

Documents Rendus

Schematics et PCB

Archive de l'adaptateur ISP vers PDI : Fichier:ISP vers PDI.zip

PCB du clavier (schematics terminé mais PCB inachevé): Fichier:PCB clavier.zip

L'archive du PCB de la clé USB est téléchargeable ici : Fichier:PCB Clé.zip

Rapport et diaporama de soutenance

Rapport du projet pour ce semestre : Fichier:Rapport Projet P12 S8.pdf

Diaporama de la soutenance : Fichier:Diapo Soutenance Projet P12 S8.pdf

Bibliographie

[1] Thèse : Saptarshi Mallick, Physical Layer Detection of Hardware Keyloggers (2014), Logan, Utah : UTAH STATE UNIVERSITY http://index-of.es/System-Hacking/Keyloggers/54172d3c0dcc9b71943aa1d4c28fffa65f86.pdf

@@ Ligne 1 : / Ligne 1 : @@
+<include nopre noesc src="/home/pedago/pimasc/include/video-PeripheriqueUSBIMA32018-iframe.html" />
 __TOC__
 <br style="clear: both;"/>
-=Présentation générale=
+=I. Présentation générale=
 ==Description==
-périphériques sont envisagés :
+Trois périphériques sont envisagés :
 *un clavier
 *une souris
-*une clef USB
+* et une clef USB
+Chacun des périphériques sera construit autour d'un ATMEGA16u2 gérant le protocole USB.
+Le clavier aura pour fonction de gérer les entrées et quelques LED.<br>
+La fonctionnalité supplémentaire consiste à enregistrer des touches tapées par l'utilisateur. Le contenu de cet historique sera stocké dans la mémoire interne du clavier, et pourra être vidé ou supprimé via une combinaison de touches.
+La souris contrôlera le déplacement du curseur et possédera des boutons. <br>
+Elle contiendra également un mode "Berserk" qui cliquera aléatoirement sur l'écran. Ce mode sera déclenchable à distance.
+Enfin, la clef USB sera utilisée comme lecteur de carte SD.<br>
+En cas d'inactivité prolongée, elle émulera un clavier qui injectera une séquence d’actions préalablement enregistrée afin de télécharger un logiciel de surveillance sur le PC auquel elle est connectée.
 ==Objectifs==
-Notre objectif est de réaliser des périphériques USB artisanaux avec des sous fonctions.
+Notre objectif est de réaliser ces périphériques USB artisanaux avec les fonctionnalités supplémentaires décrites.
-=Analyse du projet=
+=II. Analyse du projet=
-==Positionnement par rapport à l'existant==
 ==Analyse du premier concurrent==
+[[Image:Keygrabber_16Mo.jpg|thumb|upright=0.8|KeyGrabber USB 16Mo]]
+Le premier concurrent, celui du clavier, est représenté par les produits de type Keylogger.
+Voici un des principaux concurrents de ce marché :<br>
+Nom du produit : KeyGrabber USB<br>
+Société : Keelog
+Description générale:
+Ce périphérique USB se connecte entre le port USB de l’ordinateur et celui du clavier. Il enregistre l’activité du clavier dans une mémoire interne. Les données peuvent être récupérées ou effacées avec la bonne combinaison de touches.
+Caractéristiques :
+Sa longueur est de 38mm. Elle a une capacité de stockage de 16Mo ou 8Go.<br>
+Les données présentes sont encryptées par un cryptage 128 bits, unique à chaque produit.<br>
+Son prix est 43.99$ pour la version 16Mo ou 83,99$ pour la version 8Go.
 ==Analyse du second concurrent==
+[[Image:USB_Rubber_Ducky.jpg|thumb|USB Rubber Ducky]]
+Le second concurrent est celui de la clé USB.
+Nom : USB RUBBER DUCKY<br>
+Société :hak5
+Description général:<br>
+Il s'agit d'un périphérique USB reconnu en tant que clavier. Il injecte des instructions présentes sur la carte micro SD.
+Il est facile d'utilisation car il suffit d'écrire les instructions dans un fichier texte, dans un langage spécifique.<br>
+Son prix est de 44,99$.
+==Positionnement par rapport à l'existant==
+En ce qui concerne le clavier, il aura à peu près les mêmes caractéristiques techniques que le KeyGrabber.
+La différence majeure réside dans la discrétion de celui-ci. En effet, le keygrabber est une clef USB et il est facilement repérable.
+Cela implique de le cacher à l'arrière de la tour.
+Or, notre dispositif Keylogger sera directement implémentée dans le clavier. Ainsi il restera inaperçu depuis l'extérieur, sur n'importe quelle machine.
+Ensuite, notre clé USB diffère de l'USB RUBBER DUCKY car elle sera en premier lieu utilisée comme lecteur de carte SD. On pourra donc s'en servir de stockage alors que chez le concurrent la carte micro SD sert de stockage pour les instructions à envoyer au PC.<br>
+Ce stockage rend donc moins suspect notre clé, qui pourra lancer le téléchargement du logiciel de surveillance en cas d'inactivité.
 ==Scénario d'usage du produit ou du concept envisagé==
+Prenons des parents qui laissent leurs enfants utilisés l'ordinateur familial pour leur devoir maison. Mais il aimeraient vérifier qu'ils ne fassent pas n'importe quoi et qu'ils ne jouent pas sans rester en permanence derrière eux. Dans ce cadre, ils pourraient utilisés nos périphériques.
+Le clavier, leur permettrait de récupérer les données tapées et de vérifier que celles-ci correspondent bien au travail qu'ils avaient à réaliser. Afin de récupéré les données même si ils ne sont pas chez eux, ils peuvent utilisés la clé pour qu'elle télécharge un logiciel, qui tous les certains temps enregistre ce qu'il a été fait et l'envoie sur leur adresse mail. Quand à la souris, elle pourrait si en passant dans le bureau ils s’aperçoivent que les enfants sont en train de jouer, de les en dissuader en activant le mode berserk qui rendrait la souris momentanément inutilisable.
 ==Réponse à la question difficile==
+Comment activer les fonctionnalités cachées des différents périphériques ?
+Pour le clavier, les fonctionnalités seront activées et désactivées à l'aide d'une combinaison de touches prédéfinies : <br>
+combinaison 1 : activation de l’enregistrement des touches<br>
+combinaison 2 : désactivation de l'enregistrement des touches<br>
+combinaison 3 : renvoie l'historique des touches pressées<br>
+combinaison 4 : suppression de la mémoire
+Au sujet de la clé, le périphérique va changer son mode de fonctionnement pour devenir un HID (clavier) après une certaine durée d'inactivité de celui-ci. Voir si nous pouvons détecter une mise en veille de Windows.
+L'activation de la fonctionnalité de la souris sera faite par le biais d'une télécommande infrarouge. La coque de la souris possèdera une partie laissant passer les infrarouges.
 ==Bibliographie et webographie==
-=Préparation du projet=
+Liens concernants les concurrents du clavier...
+Nom du produit :KeyGrabber USB<br>
+Société : Keelog<br>
+URL : http://www.keelog.com/fr/usb-keylogger/
+... et de la clé.
+Nom : USB RUBBER DUCKY<br>
+Société : hak5<br>
+URL : https://shop.hak5.org/products/usb-rubber-ducky-deluxe
+Voici des documentations pour Arduino :<br>
+https://www.arduino.cc/en/Tutorial/CharacterAnalysis<br>
+https://www.arduino.cc/reference/en/language/variables/data-types/stringobject/
+Les liens suivant concernent la bibliothèque LUFA:<br>
+Introduction à LUFA : https://www.engineersgarage.com/article/introduction-lufa <br>
+Résumé de la bibliothèque LUFA par M. REDON : https://rex.plil.fr/Enseignement/Systeme/Systeme.IMA4/ <br>
+Un projet IMA4 dans lequel une carte est reconnue en tant que souris à l'aide de LUFA : https://projets-ima.plil.fr/mediawiki/index.php/IMA4_2016/2017_ECP3
+Enfin, les liens suivants permettent une meilleure compréhension du protocole USB.<br>
+Protocole USB par Bernard ACQUIER :
+http://www.abcelectronique.com/acquier/usb.html <br>
+USB : classe HID (Human Interface Device):
+http://www.rennes.supelec.fr/ren/fi/elec/docs/usb/hid.html
+=III. Préparation du projet=
+==3.1 Cahier des charges du groupe==
+Pour chacun des périphériques nous allons utiliser un ATMega16 (u2 ou u4) combiné à la bibliothèque LUFA.
+==3.2 Cahier des charges des équipes==
+===Clavier===
+Création d'un clavier physique avec sa mémoire interne, son microcontrôleur, et son driver.
+Tout en permettant une utilisation classique, ce clavier devra assurer un enregistrement des entrées. Les fonctions inhérentes, activées via des combinaisons de touches, sont <br>
+- de récupérer les entrées clavier dans un document texte,<br>
+- de vider le stockage des entrées clavier,<br>
+- et d'activer et de désactiver le stockage des entrées clavier.
+===Clé USB===
+Création d'un périphérique du stockage USB doté d'un microcontrôleur.
+Cette clé USB doit pouvoir servir de stockage de masse et, en cas d'inactivité prolongée, changer son statut auprès de l'ordinateur en clavier afin de lancer l'installation d'un logiciel (espion).
+==3.3 Choix techniques : matériel et logiciel==
+===Objectifs===
+L'objectif du semestre 6 est de réaliser des prototypes de nos périphériques avec Arduino.<br>
+L'objectif final est de faire fonctionner le tout avec nos propres PCB avec un ATMega16U et la bibliothèque LUFA.
+===Clavier===
+Nous allons partir d'un clavier physique déjà existant. Mais nous n'excluons pas l'idée de créer notre propre clavier en cas de bonne avancée du projet.
+===Clé USB===
+Nous allons devoir créer cette clé de taille raisonnable, pour éviter d'éveiller des soupçons.
-==Cahier des charges du groupe==
+==3.4 Liste des tâches à effectuer==
-==Cahier des charges des équipes==
+Du côté de la réalisation des prototypes nous devrons réaliser un hardware qui permette d'avoir un prototype fonctionnel et les codes relatifs au fonctionnement des prototypes.
-===Equipe clavier===
-création d'un clavier physique et son driver
-===Equipe souris===
-création du souris physique et son driver
-===Equipe clé===
-==Choix techniques : matériel et logiciel==
+Nous devrons également nous documenter sur le protocole USB et l'utilisation de l'ATMega16U2.
-===Equipe 1===
-===Equipe 2===
-===Equipe 3===
-==Liste des tâches à effectuer==
+==3.5 Calendrier prévisionnel par semestre==
-===Equipe 1===
-===Equipe 2===
-===Equipe 3===
-==Calendrier prévisionnel==
+Protocole USB : Semestres 6 et 7 <br>
-Le calendrier prévisionnel peut se concrétiser sous la forme d'un diagramme de GANTT.
+Bibliothèque LUFA (compréhension et configuration) : Semestres 6 à 7 <br>
-===Equipe 1===
+Maquettes Arduino : Semestre 6 <br>
-===Equipe 2===
+Modélisation des PCB et des coques (clavier et clé) : Semestre 7 <br>
-===Equipe 3===
+Rédaction du code : Semestre 7 et 8 <br>
+Montage des périphériques : Semestres 7 et 8 <br>
+Implémentation : Semestre 8
-=Réalisation du Projet=
+=IV. Réalisation du Projet=
 ==Projet S6==
@@ Ligne 55 : / Ligne 175 : @@
 ===Semaine 4===
+Nous remarquons que nos deux projets (clé, clavier) sont en fait assez semblables car tous deux devront se comporter comme un clavier, et tous deux disposeront d'un dispositif de stockage. <br>
+Recherche des instructions pour le téléchargement et l'ouverture d'un fichier sous Windows. <br>
+Recherche/récupération du logiciel espion Iwantsoft Free Keylogger. Il récupère entre autres les recherches faites sur un navigateur, prend des captures d'écran et des photos de l'utilisateur via la webcam (si accessible). <br>
+Téléchargement de la librairie Keyboard.h et essais d'implantations. Cette librairie permet à la carte arduino de se faire passer pour un clavier et d'envoyer des informations à l'ordinateur comme un clavier. Pour effectuer nos premiers essais avec les cartes Arduino, elle est donc d'une importance capitale.
 ===Semaine 5===
+Nous avons pu implanter la librairie Keyboard.h et mettant l'interface Arduino IDE à jour et avons effectuer des premiers tests avec la-dite librairie. <br>
+Nous avons également fait des recherches sur l'utilisation de la bibliothèque LUFA.
 ===Semaine 6===
+[[Fichier:TypeUSB.png|300px|thumb|right|Description des broches USB]]
+Premier accomplissement avec l'Arduino : on a réussi un KeyboardLogOut sur Windows 8.1. <br>
+Nous poursuivons nos essais dans le but de faire télécharger et exécuter un fichier mp3.
+Suite des recherches sur LUFA, et recherches en parallèle sur le protocole USB
+Le protocole USB (Universal Serial Bus) permet la communication de données entre un hôte et un à plusieurs appareils. Il supporte le plug'n play, c'est-à-dire le branchement quand l'hôte est en marche.<br>
+L'hôte, détectant l'appareil sur le bus, l'interrogera et chargera les pilotes nécessaires à son bon fonctionnement sans l'intervention de l'utilisateur.
+Il existe plusieurs vitesses USB : basse (1,5 Mbits/s), pleine (12 Mbits/s) ou haute (480 Mbits/s).
+Un port USB est constitué de quatre broches (voir la figure de droite). Deux d'entre elles sont réservées à l'alimentation électrique du périphérique(une broche 5V et une masse), dans la limite des 0,5 A.<br>
+Les deux autres véhiculent les signaux de données différentiels. La communication est bidirectionnelle mais ne peut avoir lieu simultanément dans les deux sens.
 ===Semaine 7===
+Création d'une fonction permettant une lecture plus aisée du code (void keyboardprint(string);). Après quelques tests nous remarquons des erreurs notamment sur les caractères '@', '#', '-', '"'. Ces erreurs étaient de 2 types :
+*' " ' et '-': le document Wordpad sur lequel on avait enregistré les commandes à utiliser dans le shell n'avait pas enregistré ces caractères comme des ASCII 7bits mais comme des utf8 stockés sur 2 octets (ou plus).
+*'@' et '#': une incohérence entre les macros de la librairie keyboard.h et celles de l'interface clavier de l'ordinateur.
+Les transactions USB (flux de données) sont composées d'une suite de quatre types de paquets.<br>
+- Les paquets début de trame (SOF) indiquent le commencement d'une nouvelle trame.<br>
+- Les paquets Jetons (Token) définissent le type de transaction, l'adresse du périphérique et de destination et la terminaison désignée.<br>
+- Les paquets DATA optionnels constituent les données utiles.<br>
+- Les paquets d'état valident les transactions et fournissent des moyens de correction d'erreur.
+Les terminaisons (Endpoints en Anglais) sont les émetteurs ou les récepteurs de données. Elles sont situées en fin de chaîne de communication.<br>
+Chaque appareil possède une "terminaison zéro" recevant toutes les commandes et demandes d'état, pendant l'énumération et tant que l'appareil est actif.
 ===Semaine 8===
+Nous n'avons pas réussi grand chose cette semaine. Nous avons seulement appris que le caractère '\\' était introuvable. Nous ne savons pas encore si cela vient de l'ordinateur ou de la librairie Arduino Keyboard.
+[[Fichier:Usbtree.gif|900px|thumb|center|Hiérarchie des descripteurs USB]]
+Les descripteurs sont la définition de la communication avec l'appareil USB. Ils informent l'hôte de sa nature, qui l'a réalisé, la version USB supportée, le nombre de configurations et de terminaisons, ainsi que leur type. Il y a cinq types de descripteurs.
+; Le descripteur d'appareil
+: Il précise les identificateurs d'appareils pour charger les pilotes, le nombre de configurations que l'appareil peut avoir. Il n'y a qu'un unique descripteur d'appareil par périphérique USB.<br>
+; Les descripteurs de configurations
+: Ils indiquent l'alimentation et la consommation maximale de l'appareil et le nombre d'interfaces.
+: Comme différentes alimentations (alimentation de grande puissance, appareil auto-alimenté ou alimenté sur secteur) et modes de transfert sont envisageable, un appareil peut avoir plusieurs configurations.
+: Lors de l'énumération de l'appareil, l'hôte lit les descripteurs d'appareils et décide de la configuration à adopter. Une seule configuration est validée à la fois.
+; Les descripteurs d'interfaces
+: Ils sont en quelque sorte le détail de chaque fonctionnalité de l'appareil, constituée de plusieurs terminaisons. Si un appareil fait casque audio et microphone, chacune de ces fonctionnalités aura son interface. Plusieurs interfaces peuvent être validées simultanément par l'hôte.
+Les '''descripteurs de terminaisons''' précisent les terminaison autres que la terminaison zéro. <br>
+Les '''descripteurs de chaînes''' sont optionnels et offrent de l'information plus explicite pour l'homme.
+Enfin, nous pouvons considérer un sixième descripteur, le "Report Descriptor", très spécifique à la classe HID (Human Interface Device) grâce auquel chaque périphérique USB peut définir son protocole de transfert.
 ===Semaine 9===
+Le problème du backslash est résolu, via alt+92. <br>
+Un code Arduino a été créé, il utilise le Powershell de Windows afin de télécharger et d'ouvrir un fichier mp3. Le code a été par la suite testé sur un pc Windows 8.1 .Le code marche mais ne prend pas en compte la configuration du clavier (obligation de passer le clavier en mode anglais sur l'ordinateur). <br>
+Nous avons trouvé une solution pour connaître l'activité du PC (récupérer les données d'affichage via un VGA ou HDMI), malheureusement cette solution n'est pas compatible avec le fait que notre clé USB doit passer pour un clé USB classique et donc ne se connecter qu'à un port USB.
+Il existe quatre types de transferts pour le protocole USB. <br>
+- Les '''transferts de commande''' sont nécessaires à l'installation de l'appareil et sont aussi utilisés pour les opérations de commande et d'état. <br>
+- Les '''transferts d'interruptions''' ont lieu suite à une interruption en provenance de l'appareil. En revanche, celui-ci doit patienter que l'hôte l'interroge pour pouvoir s'exprimer. <br>
+- Les '''transferts isochrones''' sont continuels et périodiques et limitent le temps de latence pour la communication de données audio ou vidéo. <br>
+- Les '''transferts en bloc''' permettent un transfert de grandes quantités de données irrégulières.
 ===Semaine 10===
+Cette semaine, nous avons manipulé la bibliothèque lLUFA. <br>
+Afin de prendre en main la bibliothèque, nous essayons de faire reconnaître l'Arduino UNO en tant que stockage de masse.<br>
+Pour satisfaire cet objectif, nous devons au niveau de la bibliothèque :<br>
+- nous appuyer sur un répertoire "Démo" de la classe MassStorage fournit dans celle-ci,<br>
+- modifier le Makefile en renseignant les caractéristiques de la carte et du microprocesseur, puis compiler le tout.
+Ensuite, pour réinitialiser l'ATMega16u2, il faut relier les broches GND et RESET. Arduino sera alors vu comme "Atmel Corp" par l'OS (nous pourrons le vérifier à l'aide de la commande lsusb).<br>
+Il s'agira enfin de reprogrammer le microprocesseur avec dfu-programmer et vérifier après déconnexion et reconnexion de l'Arduino que cette dernière est considérée comme une classe stockage de masse (commande lsusb -v).
+Nous nous lançons donc dans cette démarche.<br>
+Nous copions le dossier de démonstration depuis /Demos/Device/Classdriver/MasseStorage et paramétrons le Makefile.<br>
+Le microprocesseur ATMega16u2 est cadencé à 16 MHz et son architecture est AVR8. La carte est une Arduino UNO.<br>
+Un aperçu du Makefile est donné ci-dessous.
+[[Fichier:Makefile UNO MassStorage.png|800px|thumb|center|Configuration du Makefile]]
+Après compilation nous obtenons de nombreuses erreurs de fichiers incorrects, fonctions implicites et de variables non définies dans le fichier Board/Dataflash.h <br>
+Note : l'origine de ces erreurs sera expliquée plus tard.
+Afin de pouvoir utiliser la clé en tant que HID (clavier) ou périphérique de stokage, la seule solution que nous ayons trouvé pour continuer à utiliser l’Arduino Leonardo est de faire un Switch physique. En effet, l'interface que propose l’Arduino ne correspond pas à nos besoins : nous souhaitons une ouverture "normale" d'un périphérique de stockage, et non l’utilisation de code Arduino pour la gestion de stockage.
 ===Semaine 11===
+Nous avons pu récupérer un adafruit MPR121 qui est un clavier capacitif dans l'objectif de réaliser une maquette du clavier espion.<br>
+Nous avons donc travaillé sur le code d'un programme permettant la récupération des touches activées sur celui-ci, via la liaison série.
+Ce code sera réalisé en deux étapes :<br>
+Tout d'abord, l'utilisation d'une Arduino UNO afin de voir si nous pouvons détecter les touches et les afficher;<br>
+Enfin, le stockage de la valeur de ces touches et l'envoi via des instructions avec un Arduino Leonardo.<br>
+Nous effectuons ce changement de carte car la UNO ne supporte pas la librairie Keyboard utilisée jusqu'à présent et n'est pas non plus compatible avec une carte SD.
+Cette semaine, la première étape a été accomplie.
 ===Semaine 12===
+Réalisation de la deuxième partie du programme.
+Elle consiste en l'enregistrement des touches activées dans un fichier texte à placer dans la carte SD.<br>
+Il faut de plus coder l'envoi des instructions pour l'envoi de ces caractères à l'ordinateur (via la touche 'R') ainsi que l'instruction pour vider le fichier (via la touche 'D').
+Pourquoi les précédents essais de la compilation de LUFA n'ont-il pas abouti ?
+Si des fichiers étaient manquants à la compilation, c'était parce que la carte Arduino UNO ne dispose d'aucun dispositif de stockage de masse.<br>
+Par exemple, la carte AT90USBKEY2 d'Atmel, aussi compatible avec LUFA, possède cette fonctionnalité.
+Le dossier de démonstration à l'adresse /Demos/Device/ClassDriver/MassStorage est bien paramétré pour une compilation sans erreur.<br>
+On branche la carte et exécutons la commande lsusb. Elle est d'abord reconnue comme "Atmel Corp. at90usbkey sample firmware (composite device)".<br>
+On réinitialise le microprocesseur en suivant cette démarche: on maintient les boutons RST et HWB, puis on relâche RST et HWB dans cet ordre-ci.
+Nous effaçons le programme de l'AT90USB1287
+ sudo dfu-programmer at90usb1287 erase
+on le reprogramme.
+ sudo dfu-programmer at90usb1287 flash MassStorage.hex
+et on exécute un reset.
+ sudo dfu-programmer at90usb1287 reset
+Nous pouvons observer ci-dessous que la carte est considérée comme stockage de masse avec
+ lsusb -v
+[[Fichier:USBKEY MassStorage LUFA.png|800px|thumb|center|Détail du port associé à la carte AT90USBKEY]]
 ===Documents Rendus===
+Voici un lien vers le [https://archives.plil.fr/bjeanlou/USB_devices.git git] de notre projet.<br>
+Vous y trouverez notamment les codes des maquettes.<br>
+Il est possible de visualiser le rapport ici : [[Fichier:Rapport IMA3.2021 P12.pdf]]
+===Remarques de l'oral===
+Les remarques qui nous ont été faites sont dans un premier temps sur la forme.<br>
+Le diaporama manquait de visibilité à cause du fond non uni. Le logo central perturbait la lisibilité.
+Le code affiché devrait être plus gros mais il serait préférable d'en afficher que le strict minimum sur les diapositives.<br>
+Pendant la présentation, réduire les détails sur le protocole USB (et autres aspects très techniques) aurait permis moins de monotonie.
+Au niveau technique:<br>
+A la question de l'utilité de ces périphériques, nous pourrions ajouter l'acquisition de connaissances et de compétences en lien avec le protocole USB à l'aspect du contrôle parental.<br>
+Il aurait été intéressant de rentrer plus en détail sur l'état de l'art et les technologies employées par les concurrents.
+Pour la rentrée prochaine, nous devrions préciser le cahier des charges afin d'acquérir une vision plus claire des objectifs, notamment sur le choix du clavier à utiliser.
 ==Projet S7==
+===Objectifs de cette année===
+Nous devons réaliser un PCB pour la clé avec l'atméga16u2 et une gestion de l'USB. Il devra intégrer une mémoire raisonnable en termes de volume de stockage afin de passer inaperçu (au moins 1Go). Tout cela sans oublier les fonctions spéciales (téléchargement d'un logiciel + installation + utilisation).
+Au sujet du clavier, nous avons pensé à : <br>
+- Soit récupérer un clavier existant et faire un keygrabber. L'ATMega serait en série ou en parallèle sur le bus USB reliant le clavier à l'ordinateur. <br>
+La version en parallèle a pour problème que c'est un cas avec un maître et plusieurs esclaves, ce qui n'est pas possible pour le protocole USB.<br>
+En série, il faudrait gérer un permutateur commandé par notre microprocesseur, car l'ATMega16u2 ne possède qu'un port USB. Par conséquent les requêtes de l'ordinateur devraient être récupérées et retransmises au clavier par l'ATMega. Cela induit une certaine latence. Nous devrions donc veiller à respecter le délai de réponse imposé par le protocole. <br>
+- Soit récupérer un clavier et mettre le microcontrôleur à la place du micro-processeur du clavier. <br>
+Nous nous demandons alors s'il existe un mappage universel. <br>
+- Ou enfin monter un clavier de toutes pièces mais cela demanderait beaucoup plus de temps que les autres solutions.
+Nous avons choisi la deuxième option, car la première semble très difficile à mettre en œuvre, et la troisième a une composante mécanique plus marquée.
+===Liste des tâches et planification===
+Nous commencerons par un nouvel état de l'art des Keygrabber.
+Pour l'aspect harware, nous devrons : <br>
+- choisir des composants principaux : microprocesseur, mémoire, <br>
+- implémenter l'alimentation, <br>
+- concevoir les PCB routage, <br>
+- lister les composants secondaires, <br>
+- concevoir les PCB (schematics et routages),<br>
+- et connecter la matrice du clavier.
+Du côté software, il faudra : <br>
+- modifier le programme du microprocesseur pour faire apparaître notre carte comme un périphérique USB spécifique, <br>
+- rédiger le programme d'acquisition des touches du clavier par le microprocesseur, <br>
+- et permettre au PC de lire l'état des touches.
+===Semaine 1===
+Expression plus précise de notre feuille de route. <br>
+Entretien avec les tuteurs <br>
+'''Etude de l'état de l'art des Keygrabber'''
+[http://index-of.es/System-Hacking/Keyloggers/54172d3c0dcc9b71943aa1d4c28fffa65f86.pdf (1)] Le Keygrabber ou Keylogger est un outil permettant de détecter et enregistrer l'enfoncement des touches d'un clavier. Il se classifie en deux catégories. Le Keylogger software est un programme s'exécutant sur l'ordinateur de l'hôte. Il nécessite donc d'être installé, contrairement au Keylogger hardware qui est purement matériel et ne dépend pas d'applications.<br>
+Nous nous intéressons ici à ceux hardware. Parmi eux, il existe ceux dits actifs et ceux dits passifs. Le Keylogger actif est placé en série entre l'ordinateur et le clavier. En plus de récupérer l'appui des touches, il doit donc relayer les communications bi-directionnelles sans perte de débit. Il est soit alimenté par le bus de l'interface clavier-ordinateur, soit auto-alimenté.<br>
+Quant à lui, le Keylogger passif est placé en parallèle du bus de communication et ne fait qu'intercepter l'information utile. Il est auto-alimenté.
+Notre Keygrabber est donc assimilable à un Keygrabber hardware actif.
+Un tel Keylogger se présente généralement sous la forme d'un périphérique avec deux ports USB, un mâle et une femelle. Le port mâle est donc connecté au PC alors que le clavier est branché au port femelle. La longueur de l'appareil dépend de ses caractéristiques techniques. Il existe aussi des Keylogger permettant la récupération des données via Wifi. Ce [http://airdrivewifi.com/?page=keyloggers site web] donne un aperçu de ce qu'il se fait. <br>
+Nous observons aussi sur ce même site qu'il existe également un Keylogger [http://airdrivewifi.com/?page=KG004CKMDSTD ''Forensic''], sous forme PCB à souder entre le clavier et l'ordinateur. Cela permet une plus grande discrétion car ce PCB est caché sous la coque du clavier et rien n'apparaît.
+Notre Keylogger diffère encore de ces derniers. En effet, nous remplaçons directement la carte du clavier. Il y aura donc un unique microprocesseur sur la chaîne de communication. Nous devrons alors traiter des données brutes, venant directement du clavier, et non pas venant d'un microprocesseur gérant le protocole USB.
+===Semaine 2===
+Parmi trois claviers, nous avons choisi celui avec une taille de PCB la plus grande pour être sûr d'avoir la place d'y insérer notre futur PCB. Nous l'avons ouvert et avons étudié sur son fonctionnement global. <br>
+Les touches du clavier sont reliées à un mappage et à chaque touche est associé un code brut nommé scancode. Chaque clavier à un scancode qui lui est propre. Ce scancode est donc traité par le microprocesseur qui retourne en via l'USB un keycode  universel pour chaque pays.
+Notre clavier se compose d'un mappage de touche composé de 26 pins. Le PCB a une taille de 2,5x13 cm.<br>
+Nous nous demandons alors si les mappages des claviers sont universels afin d'éviter de devoir tester toutes les touches pour comprendre le mappage réalisé.
+Nous avons finalement commencé à réfléchir aux principaux composants nécessaires pour notre PCB : microprocesseur, mémoire Flash, port USB, élément de brochage du mappage au PCB.
+===Semaine 3===
+A partir de cette séance, nous avons travaillé sur le choix des composants.
+Nous avons donc commencé par réfléchir au composant indispensable au notre circuit. Dans un premier temps l'alimentation USB fournira du 5.0V. Une mémoire flash (ou carte SD) est alimentée par du 3.3V. Il nous faut donc un convertisseur de tension 5.0V vers 3.3V.
+Pour le port USB il nous faudra aussi une horloge cadencée à 16 MHz.
+Le microcontrôleur ATmega16u2 ne semble pas le mieux adapté à notre usage, car il dispose de trop peu de broches (24) alors que notre clavier seul en demande déjà 26.
+Le nombre de broches est aussi trop limité pour les modèles ATmega32u2,16u4 et 32u4. Nous avons alors pensé à utiliser des multiplexeurs et démultiplexeurs, mais cela ajoutera un coût et une complexité supplémentaire au projet.
+===Semaine 4===
+Nous nous remettons en question car nous avons manqué de méthode dans la recherche et l'analyse de notre besoin. <br>
+Concernant le microprocesseur, nous sommes partis de ce que nous connaissions (les modèles ATMega) et allions adapter notre projet à ces composants là. Nous avons décidé de mieux analyser les critères de notre besoin.<br>
+Pour le microprocesseur, il s'agit d'une compatibilité avec un port USB, avec une mémoire Flash externe. Il doit posséder suffisamment de ports utilisables pour les 26 broches du mappage du clavier et la connexion avec la mémoire Flash. On nous avait conseillé l'utilisation de la bibliothèque LUFA pour gérer le protocole USB : il doit donc être compatible avec cette bibliothèque. Si besoin, nous pourrons chercher d'autres critères de discrimination.
+Pour établir une liste, il s'est avéré pertinent de sélectionner les microcontrôleurs compatibles directement sur le site de LUFA. Les modèles sont les ATMega, les AT90USB, les AT32UC3 et les ATXMega.<br>
+Ils sont ainsi tous compatibles pour l'USB et ont tous une architecture AVR. Le critère le plus discriminant est maintenant le nombre de ports disponibles pour l'utilisation souhaitée.
+Chaque clavier a en fait son propre mappage.<br>
+Au cours de la séance, nous utilisons une breadboard accompagnée de quelques DEL et d'une carte Arduino afin de déterminer quelles touches correspond à quelles entrées et sorties du mappage. Pour cela, on injecte un courant sur une des broches et on observe sur quelle broche du mappage il est véhiculé lors de l'appui d'une touche. On répète l'opération en pressant chacune des touches et en changeant la broche d'entrée du courant. On peut ainsi créer le scancode de notre clavier. Nous avons obtenu le mappage suivant : (non finalisé par manque de temps).
+[[Fichier:Scan_code.jpg]]
+===Semaine 5===
+A l'aide du site de LUFA et des documentations techniques des différents microcontrôleurs, nous pouvons restreindre notre choix parmi ceux du tableau ci-dessous.
+{| class="wikitable centre" style="width:40%;"
+|+ Tableau
+|-
+! scope=col | Série
+! scope=col | Modèle
+! scope=col | Nombre de pins utiles
+|-
+| style="width:6%;"  rowspan="4" |
+AT32
+| style="width:10%;" |
+AT32UC3B064
+| style="width:10%;" |
+|-
+| style="width:10%;" |
+AT32UC3B0128
+| style="width:10%;" |
+|-
+| style="width:10%;" |
+AT32UC3B0256
+| style="width:10%;" |
+|-
+| style="width:10%;" |
+AT32UC3B0512
+| style="width:10%;" |
+|-
+| style="width:6%;"  rowspan="4" |
+AT90USB
+| style="width:10%;" |
+AT90USB646
+| style="width:10%;" |
+|-
+| style="width:10%;" |
+AT90USB647
+| style="width:10%;" |
+|-
+| style="width:10%;" |
+AT90USB1286
+| style="width:10%;" |
+|-
+| style="width:10%;" |
+AT90USB1287
+| style="width:10%;" |
+|-
+| style="width:6%;"  rowspan="4" |
+ATXMEGA
+| style="width:10%;" |
+ATXMEGA16A4U
+| style="width:10%;" |
+|-
+| style="width:10%;" |
+ATXMEGA32A4U
+| style="width:10%;" |
+|-
+| style="width:10%;" |
+ATXMEGA64A4U
+| style="width:10%;" |
+|-
+| style="width:10%;" |
+ATXMEGA64A4U
+| style="width:10%;" |
+|}
+Nous utiliserons comme mémoire une mémoire de type flash série car elle nécessite moins de broche. Mais en contrepartie il nous faudra sur notre micro-contrôleur deux SPI, un pour la liaison USB et l'autre pour celle avec la carte mémoire .
+Notre choix de micro-contrôleur se porte sur l'ATXMEGA16A4U. <br>
+Il dispose en effet de deux SPI (un sur le port C et l'autre sur le port D ) et il gère les MOSI (Master Out Slave In) MISO (Master In Slave Out) pour la communication avec la mémoire et l'USB.<br>
+Il a aussi 34 broches I/O et il s’alimente avec une tension comprise entre 1.6 et 3.6 V, donc on pourra programmer le microcontrôleur en l'alimentant directement en 3.3 v.
+Il ne nous reste donc plus que le choix de la mémoire mais l'on sait que cette mémoire devra avoir une interface de type SPI, non-volatile travaillant sous une tension de 3.3V et dont la fréquence de travail peut être inférieure ou égale à 16MHz.
+===Semaines 6 et 7===
+[[Fichier:Atmega-cartesd-pcb.jpg|thumb|upright=1.3]]
+Il nous reste à réaliser les plan du PCB, pour cela nous allons nous aider du plan ci-dessous. Il s'agit d'un exemple de PCB dans lequel une carte SD est connectée à un ATmega.<br>
+La référence est [https://www.abcelectronique.com/annuaire/montages/cache/2485/comment-relier-electriquement-une-sd-card.html ici.] <br>
+Nous devons également choisir un convertisseur de tension de 5V vers 3,3V pour l'alimentation du microcontrôleur et de la mémoire flash. <br>
+Pour cela, nous avons estimé grossièrement un courant de consommation maximal de notre PCB à 250mA. <br>
+Nous trouvons sur les catalogues le LM3670MF-3.3/NOPB (tension d'entrée entre 2,5V et 5,5V, courant de sortie jusqu'à 350mA).
+Les principaux éléments retenus, communs au clavier et à la clé USB sont donc <br>
+- le microcontrôleur ATXMEGA16A4U (34 broches I/O, protocole USB et interface SPI (Serial Peripherical Interface), fréquence 32Mhz), <br>
+- la mémoire MX25R6435FM2IL0 (type flash, taille 64 Mbits, fréquence maximale de 33Mhz, communication SPI), <br>
+- et le convertisseur de tension LM3670MF-3.3/NOPB.
+===Soutenance de fin de S7===
+Voici une liste des principales remarques et questions évoquées lors de notre soutenance. Il y a un manque de recherche et de connaissance de l'existant au sujet du clavier. Pourquoi n'avons nous pas cherché des claviers faits maison ? Il nous a été demandé de d'étudier l'utilisation de l'atmega32U4 du projet d'un site web  [https://www.techspot.com/guides/1625-diy-build-your-own-mechanical-keyboard/] et d'expliquer pourquoi ce cas-là ne convient pas à notre projet.
+Pourquoi voulons nous utiliser une architecture AVR ? Nous aurions dû regarder les possibilités de faire autrement. M. VANTROYS citait l'utilisation d'un STM32.
+Nous avons trop peu communiqué sur la clé USB et la taille de mémoire pour la clé est insuffisante (64Mbit).
+=== Réponses aux questions de la soutenance ===
+'''Discrimination de l'ATMEGA32U4'''
+Les différents tutoriels que l'on peut trouver sur Google utilisent un ATMEGA32U4. Dans notre cas, l'utilisation de ce micro-contrôleur ne convient pas pour le clavier. <br>
+Pour commencer, nous avions le choix entre trois claviers (deux de marque Dell, et un de marque Kraken). Le choix s'est porté sur le Kraken car les trois claviers ont 26 broches d'entrées et sorties et le clavier kraken est celui qui dispose du plus d'espace pour la incorporer notre PCB.
+De plus, nous avons donc besoin de 26 broches entrées/sorties, uniquement pour le mappage du clavier. L'ATMEGA32U4 ne dispose que de 26 broches dont 20 sont utilisées pour le clavier dans les exemples que l'on peut trouver. Parmi elles, trois broches sont consacrées à l'interface SPI. Un si faible nombre de broches par rapport à notre clavier s'explique par le type de clavier utilisé pour leur projet, qui ne contient ni pavé numérique, ni flèches de navigation.
+Une piste est de limiter le nombre de broches utilisées en ne rendant fonctionnel que la partie alphanumérique principale du clavier (pas de pavé numérique ni de flèches de navigation). Cependant le mappage du clavier Kraken n'est pas conçu par région et cette partie alphanumérique est mappée sur l'ensemble des 26 broches entrée/sortie (voir le scan code de notre clavier).
+Dans le cas où toutefois nous souhaitons utiliser l'ATMEGA32U4 pour le clavier, il nous faut réduire d'au moins trois le nombre de pins du microprocesseur nécessaires.
+Pour ce faire, nous pouvons utiliser des démultiplexeurs/décodeurs. Nous voulons que ces démultiplexeurs sortent un état haut sur la broche sélectionnée et un état bas sur les autres broches.
+Malheureusement les multiplexeurs trouvés font l'inverse.
+Il faut donc rajouter des portes non en sortie des démultiplexeurs.
+Le clavier étant mappé en 8 broches par 18, deux choix s'offrent à nous : utiliser comme entrées le groupe de 8 broches (permet de gagner 5 pins), ou celui de 18 broches (permet de gagner 13 pins).
+Si nous choisissons le groupe de 8, nous aurons besoin d'un décodeur/démultiplexeur "3 vers 8" et deux unités de portes "non" 14 broches.
+Si nous choisissons le groupe de 18, nous aurons besoin de trois décodeurs/démultiplexeurs "3 vers 8" et six unités de portes "non" 14 broches. Mais cette dernière solution implique un routage plus complexe. <br>
+Voilà pour la partie électronique, maintenant intéressons-nous aux prix.
+Les solutions utilisant l'ATMEGA32U4 coûtent 3.45€/unité de microprocesseur (chez Farnell), auxquels il faut additionner 1.5€/25 unités de décodeurs (chez RS, 1 unité nécessaire pour 8 entrées clavier), et 1.25€/25 unités de portes "non" (chez RS, 2 unités nécessaires par démultiplexeur), soit un total de 6.20€.
+La solution utilisant l'ATXMEGA16A4U n'a pas besoin de décodeurs ou démultiplexeurs. Elle coûte donc 2.64€/unité (chez Farnell) de microprocesseur.
+Il nous revient donc également moins cher d'utiliser l'ATXmega16A4U pour la clé USB en comparant le prix des deux microcontroleurs seuls.
+'''Pourquoi voulons nous utiliser un microprocesseur avec une architecture AVR ?'''
+Ce choix est conditionné par l'utilisation de LUFA. Il nous a été suggéré d'utiliser cette bibliothèque afin de limiter le travail de programmation dû au protocole USB. De plus, l'an dernier nous avions déjà fait des recherches sur cette bibliothèque, et nous l'avons utilisée en tutorat de systèmes.
+'''Taille de la mémoire pour la clé USB'''
+Elle n'est pas pertinente et est trop limitée par l'utilisation d'une interface SPI. Nous devons mieux explorer les différents types de mémoires et en trouver une mieux adaptée à notre projet.
 ===Documents Rendus===
 ==Projet S8==
+===Semaine 1 (du 20/1 au 26/1)===
+'''Familles de mémoires'''
+Les familles des mémoires sont les ROM, RAM et flashs.<br>
+Parmi les ROM, on discerne les PROM (programmables une unique fois), les UVPROM (effaçables lors d'une exposition à de forts UV avec un appareil spécifique) et les EEPROM (facilement effaçables avec un courant électrique).
+Parmi les RAM, on distingue les mémoires vives statiques (SRAM) et les mémoires vives dynamiques (DRAM).
+Les SRAM sont très rapides et sans besoin de rafraîchissement de la donnée mais elles sont coûteuses et consomment beaucoup. Deux principaux types sont les Magnetic RAM (MRAM) qui est non volatile et la Dual Ported RAM (DPRAM) qui a un accès multiple quasi instantané.<br>
+Les DRAM ne conservent les informations que quelques millisecondes. Il faut alors relire régulièrement chaque cellule et y réécrire l'information (c'est l'opération de rafraîchissement). Il y a plusieurs types de DRAM : les Synchronous Dynamic RAM (SDRAM), les Video RAM (VRAM) construisent l'image vidéo, et les Double Data Rate Synchronous Dynamic RAM (DDR SDRAM).
+La mémoire flash est une mémoire rémanente. Sa vitesse est relativement élevée et elle possède une bonne durée de vie.
+===Semaine 2 (du 27/1 au 2/2)===
+[[Fichier:Comparatif Flash NAND et NOR.png|thumb|upright=1.3|Comparatif des Flash NAND et NOR]]
+'''Interfaces Série'''
+Nous nous sommes également renseignés sur les différents types d'interface de transmission série. <br>
+Le premier est la liaison point à point.<br>
+Figurent dans ce type les interfaces AES/EBU (audio numérique), CoaxPress, la fibre optique, RS-232 et RS-422, Serial ATA, Serial Digital Interface (vidéo numérique), UART.<br>
+Le deuxième est la liaison multipoints à bas débit et contient les interfaces Control Area Network, I2C et RS485.<br>
+Enfin, la liaison haut débit est composée des interfaces ARINC 818 (vidéo par fibre optique), Ethernet, Fibre Channel (paire torsadée, câble coaxial ou fibre optique), Firewire (par Apple, obsolète), Bus InfiniBand (obsolète), Peripherical Component Interconnect (PCI, connexion des cartes d'extension), PCI Express, Serial Attached SCSI (interface pour disques durs) et SPI (bus de données synchrone).
+'''Mémoires Flash'''
+Les mémoires Flash sont divisées entre les Flash NAND et les Flash NOR, dont le comparatif ci-contre est donné par [https://www.microchip.com/design-centers/memory/serial-parallel-flash/getting-started Microchip]. Elles diffèrent l'une de l'autre par les connexions des cellules mémoires individuelles. XIP représente la capacité à exécuter du code contenu dans la mémoire Flash sans avoir à le copier dans la RAM auparavant. Cela libère ainsi de la RAM pour d'autres utilisations.
+Les Flash sont compatibles avec plusieurs types d'interface CI (Common Interfaces) en fonction du modèle : SDI, SPI et SQI. SDI signifie Serial Digital Interface et est associée à de la vidéo. Son support est un BNC ou la fibre optique. SPI désigne Serial Peripheral Interface. Enfin, la Serial Quad Interface (SQI) propose une (single lane, équivalent à la SPI) à plusieurs lignes (dual lane ou quad lane interface).
+Nous pouvons remarquer l'existence de normes telles que ONFI et CFI. ONFI (Open NAND Flash Interface) est une norme de communication pour les Flash NAND et CFI (Common Flash memory Interface) permet l'interchangeabilité des Flash. Nous ne nous y attarderons pas.
+'''Interface SPI'''
+Cette interface a pour avantage qu'elle est supportée par un grand nombre de microcontrôleurs, elle communique en Full Duplex (dans les deux sens simultanément). Elle est flexible vis-à-vis du nombre de bits à transmettre ainsi que du protocole en lui-même et son interface matérielle est simple. Il y a un partage d'un bus commun pour l'horloge, MOSI et MISO entre les périphériques. Enfin, les esclaves utilisent l'horloge du maître sans nécessiter d'oscillateur propre, et aucun arbitre n'est nécessaire car il n'y a pas de collision possible.
+Les inconvénients sont qu'elle est pour des distances très inférieures au mètre (nous vérifions cette condition) et elle comporte plus de broches que l'I2C (SDA, SCL et la masse) ou une UART (une broche). Ces deux interfaces étaient déjà exclues car non compatibles avec des mémoires Flash. En outre, la première possède un débit plus faible. D'autres inconvénients sont qu'aucun adressage n'est possible (on utilise un Slave Select) et c'est un protocole sans acquittement, c'est-à-dire sans accusé de réception.
+===Semaine 3 (du 3/2 au 9/2)===
+'''Dimensionnement des résistances pour les DEL'''
+Nous aurons besoin de DEL pour les voyants du clavier et éventuellement pour la clé.<br>
+La documentation du micro-contrôleur dit que pour les pins entrées/sorties avec une tension Vcc entre 3,0V et 3,6V, les tensions typiques sont VOH = 0,94 Vcc = 3,1 V et VOL = 0,05 Vcc = 0,17 V.<br>
+Cependant, pour le dimensionnement des résistances, nous considérerons la tension maximale (Vcc). Pour rappel, nous avons Vcc = 3,3 V.
+Chez les fabricants, un courant direct de 20 mA semble être la valeur la plus commune. Nous aurons donc besoin d'une résistance supérieure à 135 ohms si nos diodes ont une tension de seuil de 0,6 V, et de 150 ohms si la tension de seuil est 0,3 V. <br>
+Les valeurs standards pour ces résistances sont 130 ohms et 150 ohms.
+[[Fichier:Bidirectonal-mosfet-level-shifter.png|thumb|left|Level shifter bi-directionnel de 3.3V à 5V]]
+'''Communication USB'''
+Les tensions du bus USB sont différentes à chaque extrémité des broches D+ et D- : 3,3 V du côté du micro-contrôleur et 5V au port USB côté PC. Nous devons donc composer avec cette différence de tension. La documentation stipule dans le chapitre sur les pins entrées/sorties que la tension maximale d'entrée VIH est Vcc + 0,3 V, soit 3,6V < 5 V dans notre cas. Nous envisageons donc de réaliser un "level shifter" pour adapter ces tensions, qui doit être bi-directionnel pour assurer le fonctionnement du protocole.
+Nous considérons un level shifter step down (abaissemement de la tension) lorsque le PC émet vers le contrôleur, et un step up (élévation de la tension) lorsque le microprocesseur émet. Nous pensons pour cela utiliser une solution comprenant un MOSFET (voir ci-dessous), à reproduire sur chacun des deux bus de données.
+[[Fichier:Step-down.png|thumb|upright=0.4|right|Step-down. A gauche, le PC. A droite le micro-contrôleur]]
+Après des recherches plus poussées dans les spécifications USB révision 2.0, nous trouvons que le tension logique haute sur D+ et D- doit être supérieure à 2.8V. A priori, nous n'aurions pas besoin de step up. Cependant, avec seulement un step down (ci-dessous) pour protéger, nous craignons que la tension reçue par l'hôte soit inférieure à 2.8V.
+Côté carte électronique nous avons terminé les schematics, seuls persistent les interrogations à propos de la communication USB.
+===Semaine 4 (du 10/2 au 16/2)===
+Suite à nos interrogations, M.REDON nous indique que si l'ATXMega16A4U est conçu comme le micro-contrôleur ATMega16U2, il est peut être alimenté en 3,3V tout en acceptant 5V sur D+ et D-. Il s'appuie sur ce [https://www.avrfreaks.net/forum/xmega-a4u-dragon-pdi-programming-issue sujet] dont le schematic est disponible [https://www.avrfreaks.net/sites/default/files/xmega16.png ici]. Nous y voyons que les bus de données PD6 et PD7 sont directement connectés au port USB.<br>
+Nous notons également que la documentation technique de [http://ww1.microchip.com/downloads/en/DeviceDoc/doc7799.pdf l'ATMega16U2] indique pourtant au chapitre 26.2 une tension maximale VIH pour les entrées standard de Vcc + 0,5V. Le cas est donc similaire à notre micro-contrôleur.
+De notre côté, nous avons trouvé une carte [http://www.gabotronics.com/development-boards/xmega-xprotolab.htm XMEGA Xprotolab] commercialisée dont le schematics est [https://www.gabotronics.com/download/xprotolab-portable/xprotolab-portable-schematics.pdf disponible.] Le contrôleur utilisé, un ATXMega32A4U, est similaire au nôtre.
+Les ports D+ et D- sont ici connectés à un circuit de protection [http://www.farnell.com/datasheets/109718.pdf PRTR5V0U2X,215] de tension de blocage 7,5V qui n'est pour nous pas nécessaire car nous n'aurons pas de telles tensions dans notre circuit.
+A la vue de ces deux projets affirmés opérationnels, nous décidons de ne pas adapter la tension comme prévu la semaine passée.
+En nous appuyant sur l'avancement du PCB du clavier, et en estimant les différences de celui de la clé, nous établissons une liste de tous les composants dont nous aurons besoin. Nos tuteurs nous conseillent l'utilisation d'un quartz pour la communication USB. De plus, comme la programmation du contrôleur se fait par l'intermédiaire d'une PDI (Program and Debug Interface), il est évoqué avec M. BOE la création d'un PCB permettant l'interface entre ISP et PDI car nous ne savons pas si nous avons de quoi programmer en PDI. Voici un [http://szulat.blogspot.com/2012/08/atxmega-programmer-for-050.html exemple d'adaptateur].
+Côté carte électronique, nous commençons à travailler sous Altium, car M. Boé est plus à l'aise avec Altium que kicad, ce qui permet d'échanger plus facilement les fichiers et d'obtenir plus facilement de l'aide. Baptiste essaye d'abord d'installer windows sur son ordinateur. Mais après quelques tentatives infructueuses, nous demandons donc à partir de cette semaine à M. Flamen à avoir accès à la C201, qui est équipé de PC avec Altium.
+===Semaine 5 (17/2 -> 23/2)===
+Après avoir discuté bonnes pratiques avec M. Boé, nous décidons d'ajouter un quartz, pour assurer une fréquence stable au cas où l'horloge interne du micro-contrôleur viendrait à faire défaut. Le quartz requiert les deux broches PR0 et PR1 du micro-contrôleur. Ce sont également des GPIO (General Purpose I/O) que nous avons déjà attribué au mappage du clavier. Nous sommes maintenant dans un cas où il nous manque deux broches (pour le PCB du clavier) et nous sommes forcés d'ajouter un décodeur pour les libérer. Notre liste de composants est terminée et nous pouvons déposer notre commande sur le wiki.
+'''Décodeurs 74HC238'''
+A force de ne trouver que des décodeurs équipés d'une porte NON à chaque sortie, nous remarquons que toutes les datasheets portent un même code 74HC138. Nous décidons donc de nous renseigner pour savoir lire ce code. Nous découvrons donc que :
+*74 indique qu'il s'agit d'un composant CMS
+*H indique qu'il s'agit d'un composant haute fréquence
+*C indique qu'il s'agit d'un composant dont le brochage est compatible avec les technologies TTL
+*138 est le numéro de fonction (décodeur à l'état haut en repos).
+Parmi les lettres que l'on peut trouver avec H et C, il y a :
+* L ou LV pour low voltage, indique que le composant est optimisé pour fonctionner à des tensions inférieures à 3.6V
+* A pour advanced frequency (des fréquences plus hautes que H)
+* T indique que les niveaux (états haut et bas) sont compatible avec des composants TTL.
+Des lettres peuvent être trouvées en préfixe de ce code, il s'agit des identifiants des constructeurs.
+Enfin nous trouvons le numéro de fonction "238" correspondant à un décodeur 3 vers 8 à l'état bas au repos. Avec tout cela nous pouvons chercher notre composant qui devra être un 74HC238.
+===Semaine 6 (du 2/3 au 8/3)===
+Sur Altium, nous sommes sur la fin de la réalisation des PCBs du clavier et nous avons terminé l'adaptateur ISP vers PDI.
+===Semaine 7 (du 9/3 au 15/3)===
+Nous ajoutons une commande de deux diodes Zener 3,6V pour l'adaptateur ISP vers PDI. En outre, il est possible que nous n'ayons pas besoin de l'adaptateur ISP vers PDI car il y a un AVR Dragon à l'école pour la programmation avec une PDI. Nous devons donc nous informer sur ce sujet. On nous conseille aussi de nous renseigner sur les "fuses" de l'ATXMega16A4U.
+Le PCB du clavier est quasiment terminé, c'est à dire que si nous avions accès à des vrais vias il serait terminé. Nous commençons celui de la clé USB.
+Les tuteurs nous indiquent que nous devons ajouter des condensateurs au niveau du quartz et une résistance de 1Mohm.
+'''Condensateurs du quartz'''
+La valeur des condensateurs à placer près du quartz peut être calculée à partir du chapitre 5.2 des [http://ww1.microchip.com/downloads/en/appnotes/atmel-2521-avr-hardware-design-considerations_applicationnote_avr042.pdf recommandations matérielles AVR].
+La valeur Cstray correspond en quelques sortes à la capacité du circuit (piste, broches du micro-contrôleur, ...). Elle est estimée entre 5pF et 10pF. On prendra 7,5pF. La capacité de charge (load capacitance CL) de notre quartz est 9pF. Ainsi, la valeur à donner à nos deux condensateurs est C = 2CL - Cstray = 10,5pF. On prendra la valeur normalisée supérieure : 12pF.
+'''Modes de cartes SD'''
+Les cartes SD ont deux modes de connexion : le mode SD ou le mode SPI.
+D'après nos recherches, le mode SPI est à priori plus simple à mettre en oeuvre que le mode SD en 1 bit ou 4bits.
+Le comportement du bus SPI diffère de celui du SD bus de la sorte :
+* la carte sélectionnée répond toujours à la commande
+<!-- * une structure de réponse de 8 ou 16 bits est utilisée -->
+* quand la carte rencontre un problème de récupération de données, elle répond avec une réponse d'erreur (qui remplace le bloc de données attendu) alors que le bus en mode SD ferait un time out.
+Nous choisissons donc le mode SPI pour plus de simplicité mais également car la documentation est plus fournie. Pour la partie software de la communication, le fait d'être connecté en SD ou SPI ne change rien (à part les détails soulevés ci-dessus). La communication se fait en suivant le protocole SD.
+===Semaine 8 (du 16/3 au 22/3)===
+Le confinement me [Rémi] contraint a continuer seul le design des deux PCB sur Altium pour une raison matérielle. Étant donné mon expérience moindre en PCB et sur le logiciel par rapport à Baptiste, je préfère continuer d'abord celui de la clé USB. J'ajoute l'embase USB. Après avoir terminé le routage, je réorganise légèrement les composants pour diminuer la surface du circuit. Je donne la forme à la carte. J'essaie autant que possible de résoudre les erreurs de l'outil "Design Rule Check" qui constitue le "compilateur" pour le design du PCB. Il permet de vérifier chacune des règles paramétrées dans le logiciel (liens et distance entre pistes, composants, etc.)
+Avant l'envoi de mes fichiers pour vérification, je dois générer les gerber files. Je m'appuie sur un [https://support.jlcpcb.com/article/42-how-to-export-altium-pcb-to-gerber-files lien] obtenu lors du module d'initiation pour produire les fichiers de production PCB. Cependant, ce ne sont en réalité que des fichiers intermédiaires et pas des gerber.
+De son côté, Baptiste se documente sur la programmation avec un PDI, sur la SD et sur LUFA.
+===Semaine 9 (du 23/3 au 29/3)===
+Par rapport au PCB de la clé, plusieurs correction à apporter ont été évoquées par mail. J'y reviendrai au fur et à mesure.
+Tout d'abord, il y a sur le wiki de l'école des tutoriels pour la conception de PCB avec Altium. Je [http://wikiportal.polytech-lille.fr/mediawiki/images/b/b4/2017_Altium_PCB_design.pdf m'y réfère] pour renseigner les multiples règles de conception à respecter, en composant avec la différence de version du logiciel (16 pour le tuto contre 20 pour le mien) qui implique notamment une organisation différente des fenêtres. <br>
+Je sélectionne les matériaux des différentes couches dans le "Layer Stack Manager". Pour les couches Top et Bottom, le nom de matériau "Copper" (diapositive 20 du tuto) n'est pas présent dans ma liste, qui contient les noms CF-001 à CF-006 dont l'épaisseur varient entre 0,009mm et 0,105mm. Comme je peux modifier l'épaisseur, je choisis le plus épais (CF-006) et renseigne une épaisseur de 0,35mm comme demandé. <br>
+Je redéfinie les règles de design du PCB : 0,3mm de distance entre deux objets, ajout d'un règle pour Polytech à 0,6mm pour commencer, dimensionnement des vias et perçages, règle pour la "Board Outline Clearance".
+Parmi les correctifs, je dois regarder si je dois connecter le shield de l'embase USB à la masse de la carte. Je ne vois rien à ce sujet dans la documentation technique. D'après internet, il semble que je dois en effet les connecter, mais pas directement. Je dois encore déterminer avec quoi (résistances ? capacités ?) et quelles valeurs.
+===Semaine 10 (du 30/3 au 5/4)===
+Nous avons échangé avec M. Boé sur le sujet du lien entre le shield USB et la masse de l'appareil. Les conseils sur internet sont variés et ce [https://forum.allaboutcircuits.com/threads/usb-device-cable-shield-connection-grounding-it-or-not.58811/ site] résume quatre possibilités.
+* connecter le shield directement à la masse
+* les connecter via un condensateur et éventuellement une résistance
+* les connecter via un "ferrite bead"
+* ne pas connecter le câble du shield au ground du tout
+Nous optons pour la deuxième solution, d'autant plus que c'est en fait celle explicitées dans les AVR-Xmega Hardware Recommandations au chapitre 3.3.3 page 8. Nous prévoyons donc entre les deux potentiels une capacité de 47nF en parallèle avec une résistance de 1Mohm.
+On nous conseille de prévoir de quoi protéger notre port USB contre les décharges électrostatiques - il ne s'agit pas ici d'adaptation de la tension pour le contrôleur. Ces décharges peuvent apparaître lorsque deux appareils entrent en contact car il est très probable qu'ils possèdent un potentiel de masse différent. Ces décharges peuvent endommager les appareils. C'est d'autant plus risqué lorsque le branchement a lieu à chaud.
+La protection consiste en un suppresseur de décharge ("ESD suppressor") constitué de diodes spécifiques et éventuellement une résistance de 22ohms sur chaque ligne de données.
+Comme composant, nous choisissons alors le suppresseur de décharge USBLC6-2SC6.
+Au niveau de la conception sur le schematic, je remplace mes inductances parce que les empreintes étaient mauvaises, j'ajoute une deuxième LED pour le débogage si besoin et modifie les valeurs non standardisées des résistances pour la protéger. Puis je place le filtre RC entre shield et masse, et je relie le shield de la SD directement au GND.
+Sur le PCB, je déplace l'embase en couche bottom, j'ajoute la protection contre les décharges électrostatiques ainsi que le filtre RC. Je prends soin de me référer aux recommandations hardwares AVR-Xmega.
+===Semaine 11 (du 6/4 au 12/4)===
+J'ai déplacé le convertisseur 3,3V pour respecter au mieux le layout de la [http://www.ti.com/lit/ds/symlink/lm3670.pdf documentation technique] p20 : plans avec des polygones, pistes plus épaisses en plusieurs via pour lier les plans de masse top et bottom. J'ai en outre déplacé le PDI pour libérer de l'espace autour du quartz et pouvoir faire des plans de masses à ses broches ultérieurement.
+J'ai ajouté une deuxième diode de débogage, connecté le shield de l'embase SD à la masse de la carte et dessinés quelques plans au top.
+===Semaine 12 (du 13/4 au 19/4)===
+En vérifiant mon travail, j'ai apporté des correctifs. Une résistance n'apparaissait pas dans mon PCB. Je l'ai insérée et ai arrangé le layout du quartz en m'inspirant de cette [http://ww1.microchip.com/downloads/en/appnotes/atmel-2521-avr-hardware-design-considerations_applicationnote_avr042.pdf disposition p18]. J'ai eu des difficultés à la reproduire car l'épaisseur de piste de 0,3 mm ne me permet pas de faire passer une piste entre les broches du quartz et la résistance entre les condensateurs sépare le plan de masse en deux. Alors qu'il est aussi conseillé que les pistes entre le quartz et le contrôleur soient les plus courtes possibles, je suis contraint de trouver un compromis entre cette longueur et la surface des plans de masse adjacents. De même, je ne peux pas respecter le layout (fig.18 p9) du [https://docs.rs-online.com/c890/0900766b807bd47e.pdf suppresseur de décharges électrostatiques] à cause de l'épaisseur de piste.
+L'empreinte de l'embase SD était incorrecte. De plus, pour les pistes de données USB, j'ai fait un routage par paire différentielle. Cela assure un parallélisme et une proximité des deux pistes. Une longueur égale limite un retard qui causerait une perte d'information.
+Une fois terminé, j'ai réalisé la documentation contenant le schematics, les vues d'assemblage, de perçage et des couches. J'ai exporté la liste des composants, ainsi que les fichiers gerbers.
 ===Documents Rendus===
+'''Schematics et PCB'''
+Archive de l'adaptateur ISP vers PDI : [[Fichier:ISP vers PDI.zip]]
+PCB du clavier (schematics terminé mais PCB inachevé): [[Fichier:PCB clavier.zip]]
+L'archive du PCB de la clé USB est téléchargeable ici : [[Fichier:PCB Clé.zip]]
+'''Rapport et diaporama de soutenance'''
+Rapport du projet pour ce semestre : [[Fichier:Rapport Projet P12 S8.pdf]]
+Diaporama de la soutenance : [[Fichier:Diapo Soutenance Projet P12 S8.pdf]]
+=Bibliographie=
+[1] Thèse : Saptarshi Mallick, Physical Layer Detection of Hardware Keyloggers (2014), Logan, Utah : UTAH STATE UNIVERSITY
+http://index-of.es/System-Hacking/Keyloggers/54172d3c0dcc9b71943aa1d4c28fffa65f86.pdf

IMA3/IMA4 2018/2020 P12 : Différence entre versions

Version actuelle datée du 4 mai 2020 à 11:23

Sommaire

I. Présentation générale

Description

Objectifs

II. Analyse du projet

Analyse du premier concurrent

Analyse du second concurrent

Positionnement par rapport à l'existant

Scénario d'usage du produit ou du concept envisagé

Réponse à la question difficile

Bibliographie et webographie

III. Préparation du projet

3.1 Cahier des charges du groupe

3.2 Cahier des charges des équipes

Clavier

Clé USB

3.3 Choix techniques : matériel et logiciel

Objectifs

Clavier

Clé USB

3.4 Liste des tâches à effectuer

3.5 Calendrier prévisionnel par semestre

IV. Réalisation du Projet

Projet S6

Semaine 4

Semaine 5

Semaine 6

Semaine 7

Semaine 8

Semaine 9

Semaine 10

Semaine 11

Semaine 12

Documents Rendus

Remarques de l'oral

Projet S7

Objectifs de cette année

Liste des tâches et planification

Semaine 1

Semaine 2

Semaine 3

Semaine 4

Semaine 5

Semaines 6 et 7

Soutenance de fin de S7

Réponses aux questions de la soutenance

Documents Rendus

Projet S8

Semaine 1 (du 20/1 au 26/1)

Semaine 2 (du 27/1 au 2/2)

Semaine 3 (du 3/2 au 9/2)

Semaine 4 (du 10/2 au 16/2)

Semaine 5 (17/2 -> 23/2)

Semaine 6 (du 2/3 au 8/3)

Semaine 7 (du 9/3 au 15/3)

Semaine 8 (du 16/3 au 22/3)

Semaine 9 (du 23/3 au 29/3)

Semaine 10 (du 30/3 au 5/4)

Semaine 11 (du 6/4 au 12/4)

Semaine 12 (du 13/4 au 19/4)

Documents Rendus

Bibliographie

Menu de navigation

Rechercher