IMA4 2017/2018 P35 : Différence entre versions

De Wiki de Projets IMA
(Programmation)
(Programmation: PS4 et 1er Test SPI sur atmega328p)
Ligne 776 : Ligne 776 :
  
 
'''Raspberry Pi Zero W et PS4'''
 
'''Raspberry Pi Zero W et PS4'''
 +
 +
Les premiers tests sur Windows ne nous donner pas satisfaction. En effet, l'ordinateur détectait bien le nouvel appareil avec son nom mais l'origine rester inconnue.
 +
 +
Lors des tests sur Linux on a pu voir des erreurs via la commande 'dmesg' :
 +
 +
[193229.758782] usb 4-1.2: new high-speed USB device number 6 using ehci-pci
 +
[193230.270780] usb 4-1.2: new high-speed USB device number 7 using ehci-pci
 +
[193235.510842] usb 4-1.2: device descriptor read/64, error -110
 +
[193251.127043] usb 4-1.2: device descriptor read/64, error -110
 +
[193251.315043] usb 4-1.2: new high-speed USB device number 8 using ehci-pci
 +
[193256.503135] usb 4-1.2: device descriptor read/64, error -110
 +
[193272.119331] usb 4-1.2: device descriptor read/64, error -110
 +
[193272.307331] usb 4-1.2: new high-speed USB device number 9 using ehci-pci
 +
[193282.999473] usb 4-1.2: device not accepting address 9, error -110
 +
[193283.079485] usb 4-1.2: new high-speed USB device number 10 using ehci-pci
 +
[193293.751588] usb 4-1.2: device not accepting address 10, error -110
 +
[193293.751771] usb 4-1-port2: unable to enumerate USB device
 +
[193387.196861] usb 4-1.2: new high-speed USB device number 11 using ehci-pci
 +
[193392.440941] usb 4-1.2: device descriptor read/64, error -110
 +
[193407.933152] usb 4-1.1: new high-speed USB device number 12 using ehci-pci
 +
[193413.177227] usb 4-1.1: device descriptor read/64, error -110
 +
  
 
'''Modules Atmega328p et SPI'''
 
'''Modules Atmega328p et SPI'''
Ligne 836 : Ligne 858 :
 
Dans la loop main, on traite la requête et on utilise '''SPI.transfer(envoi);''' pour transferer à la RPi les données souhaitées.  
 
Dans la loop main, on traite la requête et on utilise '''SPI.transfer(envoi);''' pour transferer à la RPi les données souhaitées.  
  
Durant cette semaine, nous avons également commencé des programmes de test SPI pour la RPi. Il s'agit principalement de programmes de tests tout faits permettant de vérifier la connexion entre cette dernière et l'arduino. Par exemple, la RPI envoie "bonjour" et l'arduino lui retourne ce qu'elle reçoit, soit "bonjour". Sans succés alors.  
+
Durant cette semaine, nous avons également commencé des programmes de test SPI pour la RPi. Il s'agit principalement de programmes de tests tout faits permettant de vérifier la connexion entre cette dernière et l'arduino. Par exemple, la RPI envoie "bonjour" et l'arduino lui retourne ce qu'elle reçoit, soit "bonjour". Sans succés alors.
  
 
====Electronique : Fritzing révision====
 
====Electronique : Fritzing révision====

Version du 5 mai 2018 à 20:03

Sommaire


Présentation générale: Manette modulable

Description

Tout le monde joue aux jeux vidéo cependant, les manettes ne sont pas adaptées aux personnes ayant un handicap pouvant toucher les bras ou les mains. C’est le cas, de plusieurs patients dans les centres de soins et de rééducation.

Pour ce projet IMA4, nous travaillerons avec le centre SSR (soin de suite et de réadaptation) Marc Sautelet de Villeneuve d’Ascq. Un adolescent, patient de Marc Sautelet, est passionné par les jeux vidéo. En effet, ayant perdu la motricité d’une partie de son corps, il ne peut pas jouer à deux mains. Pour cela, il bloque la manette entre son épaule et son coude, usant de la mâchoire et des doigts pour contrôler les joysticks et les boutons. Cet exercice peut s’avérer fatiguant et pénible.

Ainsi, nous chercherons à concevoir une manette PS4 adaptée au handicap de l’adolescent. Cette manette devra aussi être adaptée pour d’autres patients présentant également des handicaps moteurs. Ainsi nous prendrons pour cibles: tous les patients du centre voulant jouer; et non pas que les enfants et adolescents.



Membre du projet

Transley Gracias et Camille Saad

Cible

Patient présentant un handicap moteur

Période du projet

janvier 2018 - mai 2018

Partenaire/Client

Centre SSR Marc Sautelet à Villeneuve d'Ascq

Objectifs

Ce projet a pour objectif de créer un prototype de manette qui puisse interagir avec la console PS4 et dont le paramétrage se fait à l’aide d’une application mobile et/ou web. Cette manette devra suivre les demandes du patient ainsi que des aides-soignantes du centre, dans la mesure du possible.

Plus précisément, pour le premier prototype, nous mettrons en œuvre l'utilisation de quelques boutons spécifiques:

  • Un joystick (type L/R)
  • Quelques boutons poussoirs (type Croix/Triangle/Carré/Rond/R1/L1/Start/...)
  • Des boutons gâchettes progressives (type L2/R2).

Le but serait donc dans un premier temps de rendre fonctionnel un bouton de chaque type, puis de les multiplier une fois cela fait. Tous ces boutons réunis constituent une manette fonctionnelle.Ainsi, la manette sera ajustable, c’est à dire qu’elle devra s’adapter aux différents handicaps moteurs possibles.

Analyse du projet

Positionnement par rapport à l'existant

Notre prototype aura une présentation unique par rapport à l’existant. En effet, les concurrents et produits existants ciblent pour la majorité un seul handicap. Cela engendre une solution fermée à beaucoup de patients. Notre projet propose une mobilité des mouvements et également un choix large dans la composition et le design de notre manette. Le patient n’est pas retreint à jouer à une seule main, à utiliser beaucoup de force...Il y a moins de technique dans la manipulation et on ne joue pas avec une manette adaptée uniquement pour un droitier ou un gaucher. Cependant, cela nous limitera peut-être dans le choix possible des types de jeux. Tout comme les autres manettes adapté, l’utilisateur nécessitera un peu d’entrainement.

Analyse du premier concurrent

Jouer aux jeux vidéo à une main n’est pas une idée d’aujourd’hui. En 1990, Nintendo propose le Power Glove. Mais il tombe très rapidement aux oubliettes suite à des problèmes techniques.

Un autre gant a fait son apparition quelques années plus tard. Celui-ci, plus technique, il faut office de manette Play Station: le Reality Quest Power Glove.Cette idée de manette-gant, permet de jouer à la PS avec une seule main, elle a était conçue et présentée pour les E3, un salon d’exposition de gaming.Le gant est conçu pour contrôler l’équivalent des 14 boutons et 2 joysticks à l’aide d’une seule main. La « manette » est fixée dans la pomme de la main. L’utilisateur contrôle les mouvements verticaux et horizontaux en pivotant le poignet, et utilisent les 4 boutons d’action principaux et L1/R1 avec les doigts. Les autres boutons sont accessibles par un seul bouton rond contrôlé par le pouce. La manette est adaptée pour beaucoup de jeux vidéo, dont les plus simples sont les jeux de voitures et de combats (arcade).

Problèmes
  • Besoin de toute la motricité de la main, c’est-à-dire que si le patient à un doigt paralysé ou manquant, il ne pourra pas jouer avec ce gant
  • Design obligatoirement droitier
  • Les boutons de contrôle sont peu sensibles et peuvent nécessiter de la force
  • Design compliqué et nécessitant beaucoup d’entrainement.
Lien 
https://www.youtube.com/watch?v=qV0SxSJDCYg


Analyse du second concurrent

Ben Heck, de son vrai nom Benjamin J.Heckendorn, est un concepteur de mods de consoles (mods pour modification, soit « manettes modifiées ») et une star du net grâce à ses vidéos tutoriels.Il propose alors énormément de produits adaptés ou dérivés en guise de manettes. Parmi les mods qu’il a réalisé, il a modifié une manette de PS4 afin de la rendre accessible à une personne ne pouvant jouer qu’à une main. Pour cela, il a déplacé les boutons en respectant l’ergonomie de la main valide et modifie les connexions. Il peut lui arriver de rajouter des boutons pour en remplacer un autre. Il réalise également le même système avec la Xbox. Sur la photo ci-dessous, il a adapté la manette pour un droitier.

Problèmes
  • Besoin de toute la motricité de la main, c’est-à-dire que si le patient à un doigt paralysé ou manquant, il ne pourra pas jouer avec cette ma
  • Design obligatoirement droitier ou gaucher, une modification = une manette= une personne
  • Besoin obligé du pouce et de l’index, même si avantage : 3 doigts nécessaire.
Lien 
: https://www.youtube.com/watch?v=LieHIscadjk

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

La technologie est ,aujourd’hui, omniprésente dans notre vie. Les consoles de jeux ont envahies les maisons avec plus de 7 personnes sur 10 jouant aux jeux vidéos sur consoles en France (chiffre de l’Express). 0,18% des français sont handicapés cela représente 12 millions de français. Dans ce chiffre, 13,4% des personnes ont un handicap moteur. En 2017, les grands groupes comme Sony ou Microsoft avec respectivement PlayStation et Xbox ne permettent pas à tout le monde de jouer avec une manette. Les manettes sont prévues pour des personnes ayant leurs membres valides, plus précisément les mains et les bras.

Après un accident de voiture, un jeune garçon a perdu la motricité d’un côté du corps. Passionné de jeux vidéo, il se retrouve avec des difficultés à jouer sur sa console PS4. Ingénieux, il utilise la manette en la coinçant entre son épaule et le creux du cou. Usant de la mâchoire et de sa main valide pour contrôler les joysticks et les boutons. L'exercice étant inconfortable et fatiguant il eu l’idée de proposer à des futurs ingénieurs de lui proposer une manette adaptée à son handicap.

Les deux pré-ingénieurs ,avec leur tuteur, ont une idée révolutionnaire : La manette modulable ! Elle permettrait au jeune garçon, ainsi que d’autres joueurs, de pouvoir continuer de s’amuser ou même de commencer à jouer au jeux sur console. Cette manette aidera fortement dans les centre de rééducation pour faire passer le temps et donner du plaisir à des personnes qui ne peuvent plus s’amuser avec leur console traditionnelle. Elle pourra aussi ouvrir de nouvelles possibilités pour certaines personnes qui n’auraient jamais essayé jusqu'à présent. Comme son nom l'indique, elle sera modulaire et s'adaptera à différents handicaps. Accompagnée de son application d’initialisation, elle sera accessible aussi bien aux enfants, patients, parents et aides soignantes.

Quelques mois plus tard...Le jeune patient fan de Need For Speed, peut maintenant piloter sa voiture comme un vrai professionnel grâce à l'un des joysticks qu'il utilisera avec sa main valide et il pourra accélérer à des vitesses folles à l'aide de boutons poussoirs au niveau de son pied valide et gagner la partie. Son ami venu lui rendre visite, pourra en lieu et place des aides soignantes configurer à l'aide de la tablette (portable) la manette du patient. Si le patient change de jeu pour Tekken et que la configuration des modules ne lui convient plus, il peut interchanger les éléments de la manette selon son envie et son confort. Ainsi il peut faire sauter son personnage, il utilisera un module bouton supplémentaire, qu'il actionnera avec le poing.

Fonctionnement

Suite à une analyse fonctionnelle et à la formulation de notre projet, nous avons pu définir le fonctionnement de notre système. Notre produit, la manette, doit être accessible d’après nos objectifs à différents types de handicaps moteurs. Ainsi, l’idéal serait de concevoir une manette modulable afin qu’elle puisse s’adapter à toutes les situations. Ce n’est plus au patient de s’adapter à la manette mais à la manette de s’adapter au patient. Cela signifie que la manette sera, dans la limite du possible et de la sensibilité du corps du patient, composée de plusieurs parties dites « modules » comportant un ou plusieurs actionneurs (boutons, joysticks, gâchettes...). Ces modules seront déplaçables afin d’être utilisé avec différents membres du corps : un doigt, une main, une jambe ou même un pied. Il suffira de les connectés entre eux suivant l’organisation souhaitée, le Gameplay du jeu ou en fonction du handicap. Le tout sera relié à une application. L’application sera alors mise en place pour connecter les différentes parties du point de vue software pour prérégler la manette en fonction du patient. Il pourra alors choisir les boutons en fonction du jeu, de ses mouvements mais aussi choisir la sensibilité.

L’application et les modules devront être intuitifs et faciles d’utilisation. De cette manière des utilisateurs non avertis dans le domaine informatique ou jeunes pourront eux-mêmes gérer les connexions.


Réponse à la question difficile

Question : Comment interconnecter les différents modules de la manette ?

Il nous faut pour ce projet interconnecter les modules modélisant la manette qui seront connectés à la consoles PS4 via une Raspberry Pi 3. Le choix de la Raspberry Pi 3 nous permet d'utiliser son module Bluetooth pour communiquer avec la PS4, ce choix est plus adaptée au projet que du filaire. Concernant l'interconnexion des modules, nous travaillerons en deux étapes "preuves concept" : filaire et sans fils (Bluetooth).

Objectif 1 : Preuve concept filaire

Dans cette première partie de projet, nous souhaitons avoir une 1ère preuve de prototype rapidement. Nous nous concentrerons alors sur la communication entre la RPi3 et la PS4 ainsi que sur la conception des modules. Pour les modules, nous réaliserons des cartes électronique pour chaque module avec un micro-contrôleur. La communication filaire nous permettra d'interconnecter les modules à la RPi3 avec un bus SPI.

Objectif 2: preuve concept sans fils

Une deuxième étape du projet est la réalisation de la solution idéale sans fils. Celle-ci pourra commencer à être développée petit à petit en parallèle avec l'objectif 1. Le but ici, est d'interconnecter les modules en Bluetooth. Nous avons choisi le Bluetooth pour garder une connexion commune sur toute la chaîne. Nous rajouterons alors un module bluetooth à chaque module de la manette.

Objectif 3: possibilité d'adapter les boutons (capuchon en 3D)

Préparation du projet

Cahier des charges

Chef de projet: Alexandre Boé
Responsables: Xavier Redon, Thomas Vantroys
Partenariat: Marc Sautelet (non etablie)
Elèves-ingénieurs: Camille Saâd, Transley Gracias

Sujet : Manette modulable pour personne à déficience moteur compatible PlayStation 4

Objectifs principal (1er POC) :

Faire transmettre des informations issus des actionneurs (ex:boutons poussoires) via des arduinos jusqu’à la Raspberry Pi 3 en SPI.
Envoyer les données reçues vers la PS4 en USB

Objectifs secondaire (2e POC):

Créer des modules avec un microcontrôleur et une puce bluetooth pour permettre une meilleurs flexibilité (c-àd pouvoirs avoir une meilleure ergonomie et une connexion sans fil)
Connecter la Raspberry Pi 3 en Bluetooth à la PS4

Bete a corne manette

Choix techniques : matériel et logiciel

Liste de matériel :

Modules boutons/joysticks/gachettes

3 Push buttons :
- O X Y Carré R3 L3
- Guide PS
- start/back
--> 0,45€/unité TTC [1]

1 Thumbstick original:
Joystick analogique 4 directions --> 4,25€/unité TTC [2]

1 buttons trigger L1 L2 => 1x Thumbstick original

Cartes Atmega328p /connexion spi/

3 Arduino UNO
1 Arduino UNO atmega328p retirable
4 capacite 22pF traversantes
2 resistances 10 kOhm traversantes (à récupérer)
2 oscillateurs quartz 16MHz traversante
2 atmega328p-pu et support


Cartes module bluetooth nrf52810

6 capacités 100nF 0603
6 capacités 12pF 0603
2 capacités 4,7pF 0603
2 capacités 1µF 0603
2 capacités 100pF=0,1nF 0603 (à récupérer)
2 capacités 0,8pF 0603 (a acheter, commande en cours)
2 inductance 3,9nH 0603 (a acheter, commande en cours)
2 oscillateur quartz 32 MHz

Connexions et autres

1 Led RGB neopixel [3]
1 Raspberry Pi 3
--> ~36,23€/unité TTC [4]
1 Raspberry Pi Zero W (commandée) [5]
6 Alimentations 5V ou 3,3V </u>
par exemple, 12 piles de type CR2016 3V rechargeables ou 24 piles AAA 1,5 V rechargeables 5 modules Bluetooth nrf de Nordic : nRF52810-QFAA-R
--> 3,17€/unité + frais expédition [6] 5 Lignes broches mâles

Logiciels:

- IDE arduino - Altium - FreeCAD ou Inkscape

Liste des tâches à effectuer

Etape 1 : Gestion du projet

  • Définition des cahiers des charges fonctionnel et technique, choix d'orientation...
  • Recherche techniques sur les différentes connexions possibles entre les modules, la RPi 3 et la console PS4
  1. Recherche connexion SPI entre les modules et la RPi3
  2. Recherche connexion bluetooth entre la RPi3 et la PS4
  3. Recherche connexion bluetooth pour les modules
  4. Recherche carte avec montage Atmega328P-PU et anticipation module bluetooth
  • Détermination du matériel nécessaire
  • Réflexion sur l'application

Etape 2: Réalisation du projet

Partie 1: Preuve concept manette en filaire

  • Conception de cartes électroniques pour 2 modules (/!\ prévoir modules bluetooth)
  • Réalisation connexion SPI avec 2 modules : programmation des Atmega328p en liaison série.
  • Si tests concluant, ajouter des modules jusqu'à en avoir 5 (1 pour chaque type de boutons)
  • Connexion bluetooth entre la PS4 et la RPi3
  • Réalisation du support des modules avec fixations possibles (imprimante 3D)

Partie 2: Preuve concept manette en bluetooth

  • Ajout des modules bluetooth aux cartes électroniques
  • Connexion bluetooth entre les modules

Partie 3: Application Android : paramétrage de la manette

  • Créer une application sur tablette ou smartphone (Android) afin de configurer la manette aux besoins (inter-connexion des modules et console)

Calendrier prévisionnel

Date

Tache à réaliser

17/01/18-24/01/18

Faire des recherches sur les différentes interconnexions du système : Bluetooth, RPi-Atmega328 (SPI), RPi-PS4 Continuer liste des taches, matériel, Début recherches + réflexion fixation support des modules

31/01/18

Recherche technique connexion PS4-RPi3 et connexion SPI RPi3-Module + code

31/01/18-07/03/18

Réalisation 1er prototype (+ début prototype 2)

07/03/18

Seance 7 : Test prototype filaire

07/03/18-09/05/18

Réalisation 2eme prototype + application Android

09/05/18

Seance 14 : Test prototype Bluetooth

14/05/18

Video projet

15/05/18

Finalisation projet et Rapport

16/05/18-17/05/18

Soutenances Projet

Réalisation du Projet

Feuille d'heures

Voici le tableau d'heures du binôme:

Tâche Prélude Heures S1 Heures S2 Heures S3 Heures S4 Heures S5 Heures S6 Heures S7 Heures S8 Heures S9 Heures S10 Heures S11 Heures S12 Heures S13et+ Total
Analyse du projet 10 2 1 1 1 20min 15h20
Cherches techniques 3 4 4 2 2 1 1 1 18
Rédaction du wiki et rapport de projet 1 1 1 1 30min 1 2 30min 30min 2 10h30
Programmation 3 2 3 5 4 7 8 6 5 43
Cartes électroniques 6 8 4 6 2 1 2 2 31
Application
Total Semaine 10 6 6 6 7 10h30 13 9 12 9h30 10h30 9 9h20 117h50

Prologue

Avant la réalisation et conception d'un projet, il est important d'analyser celui-ci. Nous avons allons consacré le prologue à l'analyse fonctionnelle de la manette. Nous avons également eu une réflexion sur l'analyse technique, cela nous a permis de réaliser une liste de matériel. Il est important de définir les objectifs ainsi que les besoins afin de ne rien oublier. (Voir ci-dessus Analyse projet) Nous avons également organisé notre travail, pour le partage de documents de recherches et la rédaction de compte-rendu final nous avons réalisé un google drive. Par la suite, nous créerons un projet Git.

Durant ce temps, nous avons décidé de réaliser 5 modules. Les modules sont les différents boutons de la manettes qui nous pourrons placer selon nos choix (boutons modulaires) pour notre prototype projet pour chaque type des boutons d'une manette PS4. Ces modules devrons être connectés à la console et interconnectés. Le tout sera lié à une application Android. Suite à quelques recherches et nos analyses, nous avons décidé les points suivants :

- On commencera avec 2 modules et on les multipliera par la suite. - Les premiers tests sont réalisés avec des boutons petits pour assurer leur caractéristique "modulaires", par la suite nous pourrons ajouter des capuchons de taille plus importante (imprimante 3D ou achat) - Conception modules : réalisation de carte avec un microcontrôleur atmega328 programmable pour chaque module (anticiper le module Bluetooth) - Projet en 2 parties : prototype filaire et prototype Bluetooth

  1. Prototype filaire : connexions entre les modules et la RPi3 en SPI, connexion Rpi3-PS4 en Bluetooth, avec l'application en filaire à la RPi3
  2. Prototype Bluetooth: connexion Bluetooth entre modules-RPi3-PS4-apllication
Concept manette modulable

Semaine 1

Durant la séance, nous nous sommes concentrés les recherches afin de définir clairement le cahier des charges technique. Il s'agit des réalisations à mettre en œuvre pour les inter-connexions des éléments de la manette. Ainsi, nous avons fait des recherches sur :

Connexion SPI entre les modules (Atmega328p) et la RPi3

SPI: Serial périphérique interface BUS

Concept manette modulable

Comme indiqué sur l'image ci-dessus, la Raspberry pi 3 peut communiquer en SPI avec ses broches CS0 (24), CS1 (26), SCLK (23), MISO (21), MOSI (19). Celles-ci permettent de communiquer avec un ou plusieurs esclaves (dans notre cas, des Atmega328p) en reliant directement les broches concernées de la RPi3 à celles des composants esclaves. Chaque broche CS0 (24) ou CS1 (26) ne peut être connectée qu'à l'entrée SS (aussi appelé CS) d'un seul esclave. C'est a dire que chaque CS est lié à un esclave afin de choisir avec lequel la communication est établie à un moment donné, et les MISO sont reliées entre elles en cascade, de même pour les SCLK et les MOSI. On peut noter que le maître impose la fréquence d’horloge et sélectionne l’esclave auquel les données sont envoyées. 8 MHz est le plus rapide supportable a 3,3V

Connexion SPI multi-esclaves

Voici un schéma du fonctionnement souhaité :

Comme nous souhaitons avoir 5 modules environ il nous faudra rajouter un composant en plus afin d'augmenter les possibilités de sélection, par exemple des démultiplexeurs. Dans un premier temps nous essaierons avec 2 esclaves, puis on augmentera le nombre.


Connexion Bluetooth PS4-RPi3

Les recherches portent également sur la connexion entre la manette PS4 et la console. Elles concernent le protocole de communication via Bluetooth

Caracteristique pour la PS4: Bluetooth®v4.0, Qualcomm Atheros AR3002 Buetooth LE: 2,4-2,5 GHz

Caracteristique de la connexion :

  • Vitesse de transmission >> 3 Mbit/s 8N1
  • Relevé tous les 1.3 millisecond (peut-être)
  • Chaque manette à une adresse unique BD_ADDR qui correspond à l’adresse MAC de la carte Réseau
  • Protocole de détection est le SDP basé sur une emission reception PDU
  • L’Attribut ID est representer en TLV Type Length Value
  • Communication HCI ACL Data Packet

Rélisation des cartes électroniques

matériel nécessaire pour un PCB :

  • breadboard
  • câbles
  • 1 x 10k Ohm résistance
  • Quartz 16Mhz clock crystal
  • 2 x 22 pF capaciteurs
  • Atmega328P-PU

Ressources: [[7]] [[8]] [[9]]

Semaine 2

Durant la semaine deux et durant la séance, nous avons continué et approfondie nos recherches sur le projet. Nous avons pu ainsi affiner nos taches de réalisation et donc notre cahier des charges.

Connexion aux modules: SPI et Bluetooth

CORRIGER

voir https://peip-ima.plil.fr/mediawiki/index.php/BE_2017-2018#Configuration_du_syst.C3.A8me_embarqu.C3.A9

(sudo apt-get install pi-bluetooth)

connexion sur la raspberry par ssh:

su
update-rc.d ssh enable
invoke-rc.d ssh start 
ssh pi@172.26.79.1XX


bluetooth

bluetoothctl
agent on
default-agent
scan on
pair [device Bluetooth address]  (exemple: pair XX:XX:XX:XX:XX:XX )

NOUVELLE REFLEXION : Connexion SPI entre les modules (Atmega328p) et la RPi3 --> MODULES BLUETOOTH

Si multi-esclaves= plusieurs modules : Il faut ajouter des sélections pour les SPI → démultiplexeurs OU ne pas utiliser les CS0 et CS1, et plutôt des pins entrée/sortie de la RPi3 lié au SS comme ça on choisit direct le module esclave voulu.

IMPORTANT: Nous avons étudié à nouveau la datasheet de notre module bluetooth nrf de Nordik. Le module bluetooth comporte déjà un microprocesseur ! Un module plutôt peut donc jouer le rôle de notre atmega328p. Il n'y a alors pas besoin de réaliser des cartes électroniques de type arduino standalone. Nos PCB regrouperont alors uniquement l'alimentation, un actionneur (bouton, joystick), le module bluetooth et les broches de connexion si besoin...

Cette séance nous a alors permise de revoir entièrement le matériel nécessaire. Notre liste de matériel nous semble alors plus réfléchie et limitée au nécessaire.

Connexion Bluetooth PS4-RPi3

Suite à nos recherches de la semaine précédente, nous avons sélectionné deux sites bien renseignés :

SITES

Ils nous ont permis de comprendre la communication entre la manette et la console. En effet, ils nous expliquent les échanges de trames Bluetooth. EXPLICATIONS 1 exemple

Semaine 3 : Début premier prototype

Connexion SPI RPi3-Arduino

Comme vu durant les semaines précédentes, nous souhaitons réaliser une connexion Multi-esclaves en SPI entre la Raspberry pi et plusieurs modules. Cette semaine nous avons vu que la réalisation de notre premier prototype doit aller vite. Il ne nous est pas nécessaire d’attendre les modules bluetooth si il nous faut dans cette partie uniquement utiliser son microprocesseur. Ainsi pour chaque module nous utilisons une arduino UNO. Nous réaliserons les programmes en C afin de pouvoir les réutiliser avec les modules bluetooth par la suite. Une fois la connexion réalisable nous adapterons les programmes aux modules bluetooth Nordik. En effet, ceux-ci comporte déjà un microprocesseur, le module peut jouer le rôle de notre atmega328p. Il n'y a aurait alors pas besoin de réaliser des cartes électroniques arduino standalone sur PCB, mais directement des cartes électronique avec le module et le module voulu (bouton, joystick...) et l'alimentation. Durant la séance nous avons alors revu la liste de matériel nécessaire.

connexion filaire prototype 1 filaire arduino

Durant la séance, nous avons recherches des exemples de codes et de librairies pour Arduino SPI et RaspberryPI SPI.

Nous avons également commencé le programme de la connexion SPI pour l'arduino et récupéré les bibliothéques SPI.h avec SPI.c. Nous nous sommes alors concentrer à les comprendre, pour pouvoir l'utiliser.

Réalisation du projet Git

Création du projet IMA4_Projet35_ManetteModulable sur Git et partage de celui-ci. Les premiers dossier crées cette la séance : -Arduino (connexion SPI arduino) : ProtoSpi.c + dossier librairie SPI + Makefile -RPI (dossier codes pour Rpi) -Readme.md Ces dossiers seront amenés à être modifiés au cours des séances.

Protocole Bluetooth PS4

Suite à l'étude des trames Bluetooth, on a pu voir que ces dernières étaient incomplètes. Le modèle de communication étant propriétaire, on n'y a pas accès directement. Cela nous empêche donc de mettre en oeuvre cette communication. Déveloper

On a décidé de commencer par une connexion USB (pour laquelle on dispose de toutes les informations) celle-ci étant plus complète.

Semaine 4

Pour le prototype 1 FILAIRE nous réaliserons les étapes suivantes :

  1. Réalisation du programme SPI pour arduino
  2. Réalisation du programme SPI pour la RPi
  3. Connexion USB avec la PS4 ou ordinateur
  4. Réalisation de cartes électroniques atmega328p-pu standalone (remplacer les Arduinos)
  5. Remplacer les "PCB arduino" par le module bluetooth et adapter la connexion
  6. Conception 3D de la délimitation 1 axe pour le joystick "gâchette"
  7. Réalisation de l'application Androïde.

Une fois ces étapes réalisées nous auront alors une preuve de concept filaire et nous pourrons alors passer à une connexion bluetooth. Le passage à la connexion bluetooth sera le deuxième prototype et le cas idéal de la réalisation de la manette modulable.

Mise à jour Matériel

- Modéliser les boutons gâchettes L1/2 R1/2 de la manette PS4 (boutons sensibles à la pression) --> un joystick dont nous bloquerons un axe (imprimante 3D) - Remplacer la RPi 3 par une Rpi zero W qui nous permettrait de réaliser plus facilement une connexion USB tout en gardant l'avantage du bluetooth. - Choix de l’alimentation pour les 5 modules Bluetooth: nécessitent 3V --> utiliser des piles rechargeables 1,2V AAA plutôt que piles rondes 3V.

Nous avons également besoin du matériel cité en semaine 1 pour réaliser des cartes électroniques atmega328p-pu standalone. ( nous revenons alors sur les décisions de la semaine 3)

Connexion SPI RPi3-Arduino

Montage Raspberrypi et 1 arduino en PSI + 1 bouton + 1 led. Voici le choix des branchements :

MASTER = RPi   
SLAVE= Arduino

SPI sur Arduino:

MOSI -> GPIO11 //PB3  //master OUT to the slave IN
MISO -> GPIO12 //PB4 //slave OUT to the master IN
SCLK -> GPIO13 //PB5 //serial clock
SS -> GPIO10   //PB2  //slave select

Led, bouton et autre...

LED --> GPIO6  //PD6
GND
+5V (if required)

SPI sur la Raspberry Pi

SPIO MOSI -> PIN19 
SPIO MISO -> PIN21
SCLK -> PIN23
SPIO CS0 -> PIN24

Continuation du code pour faire clignoter Led branchée à une arduino depuis la Rpi, en connexion SPI.

Connexion USB PS4-RPi3

Durant cette, nous avons regardé comment faire cohabiter bluetooth, Application Androïd, USB, PS4, SPI et les module.

Il est alors important de savoir comment utiliser le port série sur la RPi3, soit utiliser les UART.

Nous avons réaliser qu'il n'était pas aussi simple d'utiliser le port serie USB de la Raspberry Pi 3, en effet le SoC est un BCM2837 . De plus nous ne pouvons pas utiliser le même port pour l'alimentation et la connexion.

Il nous faut alors trouver une alternative ou une solution à ce problème.

Semaine 5

Programmation: Réflexion définitives prototypes filaire

La semaine dernière, nous avons rencontré une difficulté liée aux ports séries UART. Une des solutions à cette difficulté serait d'utiliser une RPi ZERO W à défaut d'une RPi 3. On pourrait alors avoir un port d'alimentation avec connexion USB mais également retrouver la connexion Bluetooth dont nous avons besoin.

Ensuite, nous avons continué la réalisation du prototype filaire par l'avancé du code SPI ainsi que les recherches concernant le protocole PS4.

La Raspberry Pi zero W peut également être utile pour la connexion entre la PS4 et les différents modules en jouant le rôle d'intermédiaire. Nous avons alors commandé une Rpi zero W pour notre projet. En attendant la réception de la commande, nous nous sommes penché sur les recherches pour les programmes et la configuration nécessaire à l'utilisation de la RPi zero W.

Electronique

PCB bouton
atmega328p-pu branchement test

Du coté électronique, nous avons réalisé sur fritzing certaines cartes électroniques. Les Arduino Uno servant actuellement de test, seront remplacées par des PCB atmega328p-pu standalone avec des broches permettant les branchements nécessaires SPI ou encore aux modules "boutons/joystick". Pour les boutons, nous avons également réalisé un pcb afin de faciliter les branchements.

Il nous faut alors également une 3eme carte qui nous sera nécessaire pour la réalisation du prototype sans fil. Dans notre liste de matériel, nous avons des composants nrf52810 bluetooth, ceci doivent être soudé avec les capacités de protection mais également des broches de communication. Nous avons alors commencé cette carte électronique sur Altium avec le fichier projet PCB du distributeur à modifier.

PCB atmega328p-pu

Construction 3D

Enfin, nous avons commencé à réaliser des boîtiers 3D pour certains modules. Par exemple, comme nous l'avions vu précédemment, un des joysticks servira de bouton-gâchette en utilisant un seul de ses axes. Il nous faut alors réaliser un boitier qui bloque l'un des axes, mais également une tige qui nous permettra de pousser le joystick de manière simplifiée.

Semaine 6

Programmation: configuration RPi Zero W

Ayant reçu la Raspberry Pi zero W en début de semaine, nous nous sommes concentrés sur la programmation et la configuration de celle-ci. Cette partie étant compliquée, elle nous a pris du temps. En effet, il était difficile de connecter la RPi en SSH car il n'est pas possible d'y connecter un clavier directement et on avait besoin de la prise OTG pour "interfacer" la manette.

Electronique: PCB nrf52810

Les cartes réalisées en semaine 5 sont validées et en attente de réalisation.

Cette semaine a permis la réalisation et la finalisation de la carte électronique nrf52810. Il nous a fallu recommencé cette carte deux fois. En effet, une fois finie sur Altium nous avons réalisé que les empreintes des CMS sur PCB fourni par le constructeur ne correspondent pas au matériel CMS de l'école. Face à cette inattention de notre part, nous avons décidé de refaire entièrement la carte électronique sur fritzing. Ayant la datasheet et des plans d'inspiration PCB, nous avons pu refaire la carte entièrement. Sur celle-ci nous avons ajouté des broches de connexion au besoin, un branchement Jtag et ICSP pour la programmation et la connexion SPI. La carte est en attente de validation, puis validation.

PCB carte nrf52810


Révision matériel

Pour la réalisation de nos composants électroniques, il nous a fallu faire une révision des composants disponibles à l'école: (les quantités indiquées ci-dessous pourront être augmentée si nécessaire,pour avoir dans l'idéal un module de chaque type de la manette, ici on se concentre sur BOUTON et JOYSTICK)

Cartes Arduino:

  • 4 capacite 22pF traversantes
  • 2 resistances 10 kOhm traversantes (à récupérer)
  • 2 oscillateurs quartz 16MHz traversante
  • 2 atmega328p-pu et support

Cartes nrf52810

  • 6 capacités 100nF 0603
  • 6 capacités 12pF 0603
  • 2 capacités 4,7pF 0603
  • 2 capacités 1µF 0603
  • 2 capacités 100pF=0,1nF 0603 (à récupérer)
  • 2 capacités 0,8pF 0603 (commande en cours)
  • 2 inductance 3,9nH 0603 (commande en cours)
  • 2 oscillateur quartz 32 MHz

Cartes modules Boutons

  • un sachet de broches mâles (qu'on utilisera également pour les autres cartes, à récupérer/acheté)

Nous avons alors mis-à-jour la liste de composant située plus haut, ainsi que celle de la page IMA4 2017/2018 [10]

Semaine 7

Programmation: connexion wifi RPi Zero W et Bootloader sur Atmega328p-pu

Pendant cette semaine, nous avons continué la programmation et la configuration des Raspberry Pi 3 et Zero W. Concernant la configuration ssh, nous avons utilisé un téléphone en guise de point d’accès à la RPi Zero W en wifi. Nous avons aussi directement configurer l'OS Jessie, utilisé pour la RPi Zero. On a modifié le fichier cmd.txt et ...pour pouvoir programmer un USB gadget sur le port OTG. Ci-dessus expliquer fichiers

Nous avons également continuer les programmes de récupération de données : état des boutons et du joystick. Ces programmes sont appliqué sur l'atmega328p-pu standalone sur la plaque d'essai en attendant que le PCB soit opérationnel. Pour pouvoir programmer l'atemega328p-pu comme une arduino UNO, il nous faut suivre plusieurs étapes :

1.Flasher le Bootloader Nous avons 2 Atmega328p-pu neufs, ainsi il nous faut flasher le bootloader sur chacun d'eux afin de pouvoir les utiliser et les programmer sur une breadboard dans un montage minimaliste arduino-standalone. Pour cela, on peut utiliser une carte arduino UNO. On vérifie le port et le type de carte sélectionnés dans le menu >Outils. Sur cette carte on téléverse le fichier arduinoISP.ino qui se trouve dans les exemples en étant en progrmamateur AVr ISP mkll (>outils>programmateur) Puis on met l'atmega328p-pu qui nous intéresse sur le suppor socket de la carte. On change de nouveau le programmateur pour Arduino as ISP et on fait >tools>burn bootloader, soit >graver la sequence d'initialisation. Ces étapes faites, on peut retirer notre microcontroleur et le replacer correctement dans le montage.

2.Programmation atmega328 sur breadboard Une fois l'atmega328p-pu préparé, on peut le programmer. On peut le faire simplement à l'aide de la carte arduino UNO utilisée précédemment.On branche les Tx et Rx en commun ainsi que le reset, le GND et le VCC.

Nous avons réaliser des codes basiques tels que le clignotement d'une led rouge ou encore l'affichage de "hello world" sur le moniteur série pour vérifier la bonne fonctionnalité du montage. Cela fait nous avons pu écrire sous Arduino IDE le code de lecture des états.

programmation modules arduino sur breadboard

Electronique : soudure carte de test modules

Comme nous l'avons déja vu lors de la réalisation des PCB, si l'on souhaite programmer un atmega328p-pu en bootloader, le montage est simple. Il peut être minimaliste en utilisant une arduino UNO, un atmega328, une breadboard et 3 composants: 1 quartz 16MHZ crystal, 1 résistance 10kOhm et 2 capacitors céramiques de 22pF. Durant la semaine 7, nous avons soudé les composants traversants de la carte électronique correspondant à ce montage ainsi que le PCB du bouton.

Semaine 8

Programmation

Après moult recherche sur les différents site web bien fournis pour le coups on as pu trouvé une amorce à la programmation de l'OTG via un script qui agit au niveau du kernel dans le sous dossier usg_gadget. Ce script donne les informations nécessaires pour pouvoirs échangé les données. Avec le script trouvé et les informations des sites web décryptant les trames de la manette, on a toujours pas réussit à faire passer notre RPi Zero W pour une manette de PS4. Néanmoins il nous manque la trame HID complète de la manette pour avoir un test effectif.

Electronique : Correction soudure et soudure CMS

Durant cette semaine, nous avions souhaité programmer la carte électronique atmega328p-pu. Cependant, nous avons réaliser que nous avions fait une erreur lors de l'envoie du PCB à la production. En effet, celui-ci avait été fait en Top sur le logiciel Fritzing et non en Bottom. Hors nous avions soudé les composants (durant la semaine 7) comme pour un circuit imprimé en bottom, l'atmega328p-pu se retrouve alors inversé par rapport aux pistes. Comme solution, nous avons choisi de souder un deuxième support pour l'atmega328 de l'autre coté de la carte avant de la refaire au propre. En effet, avant de la refaire il nous faut vérifier si la carte est bien programmable. Une fois cela fait nous avions pu programmer la carte mais, nous avions également réalisé la pin 2 de l'atmega328 était prise par le bouton poussoir. Or, nous avons besoin des pin 2 et 3 pour le RX et TX permettant la programmation de l'atmega à partir d'une arduino, les pistes branchement RX-TX n'ont également pas été prévus pour le téléversement des programmes sur la carte. Il nous faut alors couper une piste et souder des câbles pour utiliser toutes les pistes souhaitées.

PCB arduino correction

Durant cette semaine, nous avons également souhaité souder les CMS et le composant bluetooth nrf52810 sur la carte imprimé et reçu lors de la semaine 7. Pour cela, nous avons convenu de travailler dans la C202 durant la séance du mercredi.

carte electroniques imprimées

Comment souder des CMS ?

les CMS sont des composants montés en surface c'est à dire qu'ils sont montés du même côté que les pistes cuivrées (à l'opposé des composants traversants) et sont de petite tailles souvent de l'ordre du millimètre. La taille est déterminée par 4 chiffres : les 2 premiers pour la longueur et les 2 derniers pour la largeur. On a du 1206,0805,0603 ou encore 0402. Il est même possible de trouver plus petit. A l'école nous utilisons souvent du 0603, c'est le cas de nos composants. Pour souder des CMS 0603, il nous faut utiliser une autre méthode qui n'est pas le fer à souder :

  1. Préparer la veille la pâte à braser la veille (dans une seringue)
  2. Gommer la carte pour éviter l'oxydation (attention à ne pas retirer les miettes de gomme en soufflant dessus)
  3. Appliquer avec la seringue la pâte sur les empreintes et piste souhaitées. Pour les endroits difficile à atteindre ou avec 2 pistes proches les unes des autres, il est possible de mettre la même goutte de pâte sur les 2 pistes. Cela de causera pas de court-circuit par la suite. En effet, la pâte est composée d’alliage qui sous la chaleur va se fluidifier et se coller uniquement aux pistes métallique. Le reste fondera sous la chaleur du four.
  4. Appliquer les CMS sur la pâte au fur et à mesure (attention ! ne jamais toucher les CMS avec les doigts, tjrs utiliser une pince)
  5. Mettre au four

Bilan soudure nrf52810

Cependant, une fois le matériel nécessaire préparé, et la pâte mise sur les pistes souhaitées, au moment de déposer le composant, nous avons réalisé que celui-ci était beaucoup plus petit que l'empreinte sur le PCB. Il s'agit d'un composant boitier QFN48. Fritzing ne proposant au plus proche des boitiers QFN24 ou LQFP48, celui-ci a basculé automatiquement pour un boitier LQFN48, de dimension plus grande. Face à ce manque de vigilance, nous avions cependant commencer par le nrf52810 (composant concerné) évitant ainsi de gaspiller d'autres CMS. Nous avons souhaité refaire la carte sous Altium à partir des fichiers fournis par le concepteur (chose que nous avons commencé à faire aux alentours de la semaine 5) Après la réalisation du schématic, et de la modification des empreintes de capacités, inductances et autres composants de 0402 à 0603. Notre matériel ne permettant que des empreintes 0603.

Lors du routage, une erreur de chevauchement des pistes est notifiée par Altium au niveau du nrf52810. Celles-ci ne présentent pas d'angles et sont déjà de taille 8mil, il nous faut alors passer les pistes en 6mil. Mais 8mil est la taille minimale pour la production à Polytech, nous avons regardé pour envoyer les cartes à faire ailleurs mais le 6mil n'est pas beaucoup conseillé. De plus, il n'est peut-être pas judicieux de continuer avec le composant microcontrôleur-bluetooth Nrf52810 qui prend du temps, donc la carte est difficilement réalisable et peut-être très long à programmer.

Ainsi en cette fin de semaine, nous avons décider face à l'avancer du projet de laisser les nrf52810 de coté et de les remplacer par des modules sans fils plus simples d'utilisation et complets. Ainsi nous aurions plus de chance d'avoir une connexion sans fils entre les modules. Nous pourrions par exemples utiliser des Xbee, des modules Rf...


Semaine 9

Programmation: PS4 et 1er Test SPI sur atmega328p

Raspberry Pi Zero W et PS4

Les premiers tests sur Windows ne nous donner pas satisfaction. En effet, l'ordinateur détectait bien le nouvel appareil avec son nom mais l'origine rester inconnue.

Lors des tests sur Linux on a pu voir des erreurs via la commande 'dmesg' :

[193229.758782] usb 4-1.2: new high-speed USB device number 6 using ehci-pci
[193230.270780] usb 4-1.2: new high-speed USB device number 7 using ehci-pci
[193235.510842] usb 4-1.2: device descriptor read/64, error -110
[193251.127043] usb 4-1.2: device descriptor read/64, error -110
[193251.315043] usb 4-1.2: new high-speed USB device number 8 using ehci-pci
[193256.503135] usb 4-1.2: device descriptor read/64, error -110
[193272.119331] usb 4-1.2: device descriptor read/64, error -110
[193272.307331] usb 4-1.2: new high-speed USB device number 9 using ehci-pci
[193282.999473] usb 4-1.2: device not accepting address 9, error -110
[193283.079485] usb 4-1.2: new high-speed USB device number 10 using ehci-pci
[193293.751588] usb 4-1.2: device not accepting address 10, error -110
[193293.751771] usb 4-1-port2: unable to enumerate USB device
[193387.196861] usb 4-1.2: new high-speed USB device number 11 using ehci-pci
[193392.440941] usb 4-1.2: device descriptor read/64, error -110
[193407.933152] usb 4-1.1: new high-speed USB device number 12 using ehci-pci
[193413.177227] usb 4-1.1: device descriptor read/64, error -110


Modules Atmega328p et SPI

Une carte PCB arduino fonctionnant, nous pouvons la programme pour simuler un module. Celle-ci a été designée afin de s'adapter au module que l'on souhaite. Il suffit de brancher le bouton, le joystick ou autre élèment de manette souhaité. Cette semaine ci, nous avons alors configurer la partie communication SPI pour l'arduino.

Que voulons-nous faire avec les atmegas ? Les cartes électroniques atmega328p vont nous permettre de recevoir les requêtes SPI envoyées par la raspberry pi et d'y répondre. La Raspberry enverra un message, par exemple "1", et l'Arduino lira alors l'état du module qui lui est connecté. Une fois l'état récupéré elle le renvoie à la raspberry pi.

Durant cette semaine, nous avons programmé l'atmega afin qu'il soit en esclave, qu'il reçoive un de la RPi "1" et retourne une valeur sauvegardé "int envoi". Nous avons également commencé les tests pour la lecture de l'état d'un bouton (d'après les tests réalisés les semaines précédentes).

Code Comme nous l'avons vu précedement lors de nos recherches (semaines 1 à 4) : La communication SPI nécessite l'utilisation des pins:

MOSI -> GPIO11 //PB3 //master OUT to the slave IN MISO -> GPIO12 //PB4 //slave OUT to the master IN SCLK -> GPIO13 //PB5 //serial clock SS -> GPIO10 //PB2 //slave select

Il faut également paramétrer l'atmega328p en Slave. On note que dans un premier temps, le programme sera codé avec l'arduino IDE (fichiers .ino). Une fois l'ensemble SPI RaspberryPi-Arduino fonctionnant, on remplacera ces codes par du langage C ou C++.

Pour faire la connexion SPI sur l'atmega328p, on utilise la librairie arduino SPI.h, on a alors directement les fonctions nécessaires intervenant sur les registres souhaités : SPCR (spi control register), SPSR (spi status register) et SPDR (spi data register).

 #include <SPI.h>

Il est important d'initialise d'abord le setup et on active le port série pour pourvoir utiliser le moniteur série. (Cela servira à verifier la valeur envoyée par la RPi)

void setup (void)
{
  Serial.begin (9600);  
  pinMode(MISO, OUTPUT);  //configuration en esclave *master in slave out*
  pinMode(buttonPin,INPUT);  //config pin bouton
  // turn on SPI in slave mode
  SPCR |= _BV(SPE);
  // preparation interruptions
  pos = 0;   // buffer empty
  process_it = false;
  // activation interruptions
  SPI.attachInterrupt();
}  

On oublie pas de déclarer les interruptions afin de bien lire la requête reçue.

// SPI interrupt routine ISR (SPI_STC_vect) {

 byte c = SPDR;  // grab byte from SPI Data Register
 // add to buffer if room
 if (pos < sizeof buf)
   {
   buf [pos++] = c;
   // example: newline means time to process buffer
   if (c == '\n')
     process_it = true;
   }  // end of room available

} // end of interrupt routine SPI_STC_vect

Dans la loop main, on traite la requête et on utilise SPI.transfer(envoi); pour transferer à la RPi les données souhaitées.

Durant cette semaine, nous avons également commencé des programmes de test SPI pour la RPi. Il s'agit principalement de programmes de tests tout faits permettant de vérifier la connexion entre cette dernière et l'arduino. Par exemple, la RPI envoie "bonjour" et l'arduino lui retourne ce qu'elle reçoit, soit "bonjour". Sans succés alors.

Electronique : Fritzing révision

Lors de la semaine, le modèle PCB de la carte arduino a été réalisé de nouveau sous fritzing avec les broches et connections manquantes. Nous avons également revu la configuration du bouton reset et ajouté une led d'état de l'alimentation. Nous avons ainsi envoyé deux cartes identiques à la réalisation. La carte déjà soudée lors des derniers jours fonctionnant, elle nous sert de prototype de programmation. Nous pouvons ainsi avancer à la fois sur la programmation des modules mais aussi sur leur réalisation.


Semaine 10

Programmation : PS4 et SPI sur RPi

Raspberry Pi Zero W et PS4

Modules Raspberry PI et SPI

Durant cette semaine, pour la partie Atmega328p-Modules, nous nous sommes concentrés sur la programmation de la communication SPI avec la raspberry pi. Cette semaine a permis une étude plus approfondit sur le fonctionnement pour la RPi.

On rappelle, comme vu des semaines 1 à 4, pour la RPI3 (tout comme la RPi Zero W) utilise les broches : SCLK (23), MISO(21), MOSI (19) et SPI CS0 (24), SPI CS1 (26). On la programme en Master. A l'aide des fichiers tests d'inspiration, on pourra directement programmer la RPi en C. Lors de la réalisation du code, il y a 3 étapes : l'initialisation/parametrage en SPI pour être maître, l'envoie de la requête puis la réception de données en retour.

Programmant en C, il ne faut pas oublier les librairies suivantes :

#include <stdint.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <getopt.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <linux/types.h>
#include <linux/spi/spidev.h>   //pour SPI

On va déclarer des variables globales permettant le paramétrage :

static const char *device = "/dev/spidev0.0";  //si on veut CS0 pour atteindre notre SS
static uint8_t mode;       //mode est par défaut à 0
static uint8_t bits = 8;    //bits par mot échangé
static uint32_t speed = 500000;  
static uint16_t delay;

Dans notre main, on ouvre le port (la connexion) au device souhaité, on vérifie les paramètres (registres, connexions...) puis exécute la fonction transfer(fd). transfer(fd) transmet la requête et s'occupe de la réception.

fd = open(device, O_RDWR);
transfer(fd);
close(fd);

Semaine 11

Programmation: PS4, SSH et tests SPI (RPi3&Atemga328p)

Raspberry Pi Zero W et PS4

Raspberry PI, Atmega328p et SPI

Afin de facilité la programmation en utilisant Ethernet, nous avons installer et configuré la RPi pour l'utiliser en SSH depuis les ordinateurs de la E306. En effet, SSH permet de se connecter à distance sur une machine en utilisant un compte utilisateur de la dite machine. En mettant ssh, on pourra directement agir sur les fichiers de la raspberry depuis un terminal de notre PC. Pour cela, on a d'abord vérifier l'adresse IP de notre raspberry pi : 172.26.145.106 avec un écran mais on peut aussi utiliser les commandes ip a et ifconfig. Puis activer le ssh sur la raspberry pi. On modifie alors le fichier config.txt mais également etc/network/interfaces pour configurer la bonne interface Ethernet sur la raspberry pi.

config ssh ethernet

Il nous suffit alors de taper la commande : ssh pi@172.26.145.106 pour accéder à notre RPi.

Nous avons continué à réaliser la communication SPI avec des tests entre une arduino UNO et la RPI3. Nous avons commencé par des tests simples inspirés des études de deux semaines précédentes et modulés selon notre utilité. Nous arrivons alors à lire l'état envoyer "bonjour" et recevoir "ça va" ou encore "1" et recevoir "3". Il faut noter que le SPI échange des trames, la RPI reçoit alors des hexadécimaux. Nous avons alors continué pour recevoir l'état du bouton ou du joystick lors de l'envoie de "1" sur l'Arduino328p. La semaine prochaine nous testerons ces même codes fonctionnels sur les cartes atmeg327p.

A la fin de cette semaine, nous avons alors des codes Arduino-SPI (.ino) et des codes Raspberry-SPI (.c) permettant l'échange de données. Le but est maintenant de l'adapter aux cartes imprimées et de le rendre pleinement fonctionnel pour plusieurs cartes à la fois, puis ajouter une boucle de vérification en continue jusqu'à une deuxième requête de la RPi.

Electronique: réalisation au propres des PCB modules

Suite à une nouvelle erreur de réalisation cartes électronique, nous avons refait et renvoyé à nouveau les cartes imprimées atmega328p. Nous les souhaitons au propre pour une version finale. Une fois celle-ci imprimées nous pourrons en avoir 3 , un pour chaque module. Les cartes étaient bien imprimées en bottom mais lors du passage des traversants de bottom à top, le logiciel ne les a pas fait miroiter. Par manque d'attention nous avons alors envoyé les fichiers gerber pour des cartes ayant les composants du même coté que la couche de cuivre. Les cartes électroniques actuelles sont alors correctes et fonctionnelles mais difficile à souder. Pour eviter les erreurs et continuer sur des prototypes de carte nous préférons attendre en nous concentrant sur la programmation PSI de la Raspberry Pi.


Semaine 12

Programmation

Raspberry Pi Zero W et PS4

Raspberry PI, Atmega328p et SPI

- réflexion: penser à faire boucler sur l'arduino une fois la requête reçu, ça veut dire que la manette est ON et donc vérifier continuellement les modules sur chaque atmega. - SPI raspberry pi - arduino recuperation état du bouton avec les cartes modules (/!\ récuperation à faire dans une variable)

-SSH perso adresse Rasppi: 192.168.137.10

Electronique: Finalisation soudure Modules

Soudure au propre et finale d'une carte atmega328p et donc envoie pour la réalisation de 2 autres cartes similaires et récupération de matériel Soudure des 2 autres cartes, + tests sur les états = fonctionnelles. On a donc bien 3 cartes pour les 3 modules de types différents (1 bouton, 1 joystick, 1 gachette) PCB pour les 2 joysticks (qui serviront de thumbstick et gachette)

Semaine 13 et plus

Programmation

Raspberry Pi Zero W et PS4

Modules Atmega328p et SPI

Electronique

Documents Rendus

(à mettre rapport + git + drive)

Datasheets