= Projet IMA4 : Sex-toy connecté =

== Présentation du projet ==

L'objectif de ce projet est de développer un système d'échange entre deux partenaires distants afin de rendre plus facile la vie de couple à distance.

Pour ce faire, le dispositif sera constitué de deux sextoys connectés (un par appareil génital désiré) à leur téléphone portable respectif. Une application mobile permettra aux utilisateurs de s'échanger des données de manière sécurisé, ceci au travers d'un serveur embarqué dans le téléphone portable.

Les données échangées pourront être l'accélération ou la température. Elles seront traitées et transmises au sextoy qui adaptera sa vitesse, son retour vibratoire ou sa position en conséquence.

Les sextoys pourraient être composés de :
* Pour l'appareil masculin (dédié à la femme) :
:* un servomoteur ;
:* un vibreur ;
:* une sonde de température ;
:* un accéléromètre.
* Pour l'appareil féminin (dédié à l'homme) :
:* 4 servomoteurs (dans le but de "masser" en déplaçant le silicone);
:* des vibreurs ;
:* un accéléromètre.
* Pour les deux appareils :
:* un micro-contrôleur (Arduino mini) ;
:* un module de transmission / réception bluetooth afin de se connecter au téléphone ;
:* du silicone.

* L'application mobile devra :
:* mettre en place une communication cryptée à travers un serveur (embarqué ou bien intermédiaire ?) ;
:* effectuer un échange de données en bluetooth avec le sextoy connecté.

* L'application mobile pourra :
:* utiliser la vidéo-conférence ;
:* enregistrer les meilleurs moments et enventuellement pouvoir les partager ;
:* effectuer une recherche de partenaire aléatoire.

* S'il nous reste du temps, il peut être envisageable de :
:* mettre en place un réseau social interne à Polytech.

== Liste des tâches ==
* Conception de l'appareil masculin (Cédric)
:* mettre en place le bus I2C avec les différents capteurs ;
:* création d'un PCB au format gerber ;
:* création d'un prototype.

* Conception de l'appareil féminin (Cédric)
:* mettre en place le bus I2C ;
:* traitement des données afin d'en déduire la position et l'entrain de l'utilisateur ;
:* création d'un PCB ;
:* création d'un prototype.

* Communication bluetooth (Cédric et Thomas)
:* étudier l'émission/réception vue de l'arduino ;
:* étudier l'émission/réception vue du téléphone ;
:* mise en place du protocole ;
:* test de portée.

* Développement mobile (Thomas)
:* déterminer la meilleure approche : utilisation d'un serveur intermédiaire ou bien mise en place d'un "client-serveur" dans l'application mobile ;
:* mettre en place le choix retenu ;
:* tester dans un premier temps une transmission de texte ;
:* programmer le traitement de données reçues par bluetooth ;
:* rajouter un côté esthétique à l'application.

[[Fichier:Recapitulatif sextoy.png|center|recap]]

==Feuille d'heures==

{| class="wikitable"
! Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures vacances !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures vacances et après!! Total
|-
| Définition cahier des charges
| 2H
| 2H
| 1H
|
|
|
|
|
|
|
|
|
|
| 5H
|-
| Dimensionnement et établissement de la liste de matériel
|
| 3H
| 4H
|
| 4H
|
|
|
|
|
|
|
|
| 11H
|-
| Établissement de la liste et de la répartition des tâches
| 1H
|
|
|
|
|
|
|
|
|
|
|
|
| 1H
|-
| Appareil masculin : programmation
|
|
|
|
| 1H
| 2H
|
|
|
|
|
|
| 6H
| 9H
|-
| Appareil masculin : étude des datasheets
|
|
|
| 1H
| 1H
|
| 4H
|
|
|
|
| 1H
|
| 7H
|-
| Appareil masculin : PCB
|
|
|
|
|
|
|
|
|
| 4H
| 4H
| 6H
| 30H
| 44H
|-
| Appareil masculin : 3D
|
|
|
|
|
|
|
|
|
|
|
|
| 6H
| 6H
|-
| Conception de l'appareil féminin
|
|
|
|
|
| 2H
| 1H
|
|
|
|
|
|
| 3H
|-
| Liaison bluetooth (embarqué)
|
|
|
| 3H
| 1H
|
|
|
|
|
|
|
| 8H
| 12H
|-
| Liaison bluetooth (téléphone)
|
|
|
|
|
|
|
|
|
|
|
|
| 15H
| 15H
|-
| Recherche et discussion autour de la meilleure approche de communication
| 2H
| 2H
|
|
|
|
|
|
|
|
|
|
|
| 4H
|-
| Synchronisation temporelle des téléphones (par sms)
|
| 2H
| 4H
| 6H
| 8H
| 6H
|
|
|
|
|
|
|
| 26H
|-
| Transmission de paquets UDP
|
|
|
|
|
|
| 4H
| 4H
| 4H
|
|
|
| 6H
| 18H
|-
| Streaming video(UDP)
|
|
|
|
|
|
|
|
|
| 4H
| 4H
|
|
| 8H
|-
| Application et bases de données
|
|
|
|
|
|
|
|
|
|
|
| 6H
| 20H
| 26H
|-
| Total
|
|
|
|
|
|
|
|
|
|
|
|
|
| 195H
|}

==Conception des sextoys==
===Introduction===

La conception de sextoys doit respecter différents règles, notamment sanitaires. C'est pourquoi nous nous sommes intéressés à l'utilisation de silicone pour ce projet. Nous avons notamment rencontré un ingénieur compétant dans ce domaine afin de nous aiguiller sur cette éventuelle conception.

La conception passera également par une conception 3D que nous effectuerons à l'aide d'imprimantes 3D au fabricarium de Polytech Lille.

Enfin, les prototypes seront embarqués de cartes électroniques (aussi appelés PCB) que nous constituerons.

===Choix du silicone, rencontre avec Mario Sanz===

Le projet nécessite l'utilisation d'une matière souple et non irritante, c'est pourquoi nous avons choisi de nous tourner vers l'utilisation du silicone. Afin de choisir au mieux le produit correspondant à nos besoins, nous avons rencontré Mario Sanz, ingénieur à l'INRIA, qui travail régulièrement avec du silicone.

Ce dernier nous a expliqué les différents points importants sur lesquels nous baser afin de choisir au mieux un produit en accord avec le projet. Ne serait-ce que pour le choix de la dureté, il existe une échelle propre au silicone ("Shore hardness scale"), nous pensions au départ rechercher un silicone le plus mou possible, cependant, il faut savoir que le plus le silicone est mou, plus il a tendance à être "collant". Finalement, après discutions, un shore de 40A (correspondant à la dureté d'une gomme) suffisamment mince fera l'affaire pour la conception des prototypes.

Il nous a également expliqué que le silicone peut être travaillé à l'aide d'additifs et sous cloche à vide afin d'améliorer le moulage, l'absence de "bulles" sur la surface de la pièce et la souplesse. Nous pouvons cependant travailler sans tout cela car il n'est pas spécialement important, pour notre projet, de rechercher des propriétés physiques homogènes dans tout le sextoy.

Pour ce qui est de la création de moules, nous pourrons les effectuer via imprimante 3D. Il existe un bon nombre de tutoriels sur internet pour s'y référer en cas de soucis.

===Impression 3D===

Pour la création d'objets en 3D, de nombreux outils sont disponibles. Nous avons décidé d'utiliser Tinkercad, un outil qui s'intègre directement au navigateur internet utilisé.

L'avantage d'un tel outil est sa grande communauté qui permet un accès simple et rapide à une multitudes de projets dont on pourrait s'inspirer pour générer nos pièces.

====Création des moules====

A l'aide d'une imprimante 3D, nous pouvons concevoir des moules afin de créer des pièces en silicone. Il s'agit de la manière la plus rapide et accessible pour notre projet.

Cette méthode comporte des désavantages, dont le principal est la présence d'imperfection et de non homogénéité dans les pièces réalisées. Ceci n'a pas de grande importance dans la mesure où nous souhaitons du qualitatif.

====Création d'un prototype====

=====Pénis=====

Afin de visualiser qualitativement la forme et le passage des câbles, un prototype imprimé au Fabricarium de Polytech Lille a été réalisé.

Ce prototype se divise en 3 pièces : un boîtier (pour y loger le PCB), un cylindre (afin de reproduire la forme désirée) et un "tête" qui devait à l'origine être un moule en silicone (pour y loger le PCB du capteur de température).

[[Fichier:Sextoy_penis.png|400px|thumb|center|Prototype 3D pénis]]

===Conception des PCB===

Afin de diminuer un maximum la taille des cartes electroniques, nous utilisons principalement des composants CMS.

La conception des cartes peut-être effectué à l'aide de logicels de CAO tels qu'Altium ou Eagle. Dans notre cas, nous avons utilisé Eagle.

Ce travail consiste à créer une librairie regroupant l'intégralité des composants nécessaires et, ensuite, de créer un schéma du circuit. Une fois le schéma terminé, il ne restera plus qu'à faire le routage et exporter les fichiers au format "Gerber".

Pour ce projet, nous aurons besoin de deux cartes, une par prototype. Chaque carte embarquera des composants similaires, c'est pourquoi nous nous contenterons d'abord d'un seul PCB pour effectuer des tests. Si ces derniers sont concluants, nous pourrons graver le second.

====PCB du pénis====

Le premier PCB imprimé et soudé est celui du pénis. Une première carte avait été imprimé regroupant sur cette dernière : un support pour l'arduino, un accéléromètre, un module bluetooth.

[[Fichier:PCB_penis_VB.png|400px|thumb|center|PCB v1.0]]

Nous avons expérimentés des problèmes dûs aux dimensions de l'accéléromètre, l'utilisation d'un boîtier CMS de type TDFN10 2x2 était optimiste pour la réalisation du projet, compte tenu du matériel à disposition.

C'est pourquoi une seconde carte a été gravée, cette fois sans l'accéléromètre.

[[Fichier:PCB_penis_VF.png|400px|thumb|center|PCB v2.0]]

[[Fichier:PCB_VF.png|400px|thumb|center|PCB v2.0 schema]]

Ce prototype est sensé embarquer un capteur de température que nous avons décidé de mettre sur un PCB à part. Cette carte avait pour but d'être coulé dans le silicone, afin de mesurer la température au plus près de la zone intéressée.

[[Fichier:TEMPERATURE_PCB_VF.png|400px|thumb|center|PCB temperature]]

[[Fichier:TEMPERATURE_VF.png|400px|thumb|center|PCB temperature schema]]

====PCB du vagin====

Compte tenu des soucis rencontrés avec l'accéléromètre, la carte sera gravée afin de pouvoir y plugger un accéléromètre analogique en traversant. Le but étant d'avoir un prototype fonctionnel d'ici la fin du projet.

Nous avons également eu des problèmes avec le module bluetooth utilisé, ce dernier ne pouvant être reconfiguré manuellement par minicom, nous utiliserons le bluetooth HC-05 utilisé pour les essais de code. De même que pour l'accéléromètre, nous prévoirons un endroit pour le plugger sur la carte.

''image PCB vagin''

''Reste à graver le PCB du vagin''

==Gestion des composants==
===Introduction===

Notre projet implique l'utilisation de capteurs, de servomoteurs et de buzzers, constituant chacun une partie de la programmation embarquée.

Pour cette programmation, nous avons décidé d'utiliser AVR-gcc et ainsi coder les arduinos en C.

Les capteurs utilisés utilisent un protocole de communication IIC (ou I²C, I2C), ce protocole de multiples avantages que nous expliciterons par la suite. Cependant, comme un des capteurs (l'accéléromètre) prévus initialement nous a causé beaucoup de soucis, nous expliciterons également la mesure à l'aide de capteurs analogiques. Ces différents capteurs nous permettront de mesurer l'excitation d'un utilisateur.

Une fois l'excitation mesurée, il faut induire une réponse "physique". Pour ce faire, nous utilisons d'une part des servomoteurs dans le but de produire une sensation de massage.

D'autre part, nous utilisons également des buzzers.

'' Veuillez noter que le code ne sera pas détaillé dans le wiki, vous pouvez vous référer au dépôt git contenant les différents codes. ''

===Utilisation des capteurs===

====Capteurs par IIC====

Le choix de l'IIC n'était pas anodin. L'IIC permet, pour un bus de seulement deux fils (SDA et SCL), d'utiliser un nombre important de capteurs. Ainsi, si nous décidions au cours du projet de rajouter tel ou tel capteurs, nous n'avions qu'à les greffer à ce bus IIC.

[[Fichier:Iic.jpg|400px|center|Schema iic]]

Tout d’abord, nous devons initialiser le bus IIC de l’arduino. Pour ce faire, il suffit de préciser la fréquence désirée, ici 400KHz, dans les registres TWSR (prescaler) et TWBR. (fréquence désirée suivant la fonction TWBR = (Fcpu - 16 Fscl ) / (2 Fscl Prescaler) ) avant de lancer l'utilisation IIC via le bit TWIE.

Comme il peut y avoir potentiellement plusieurs capteurs sur ce bus, il faut respecter un certain protocole afin de récupérer la valeur du capteur de température. Attardons nous sur la lecture d’une valeur sur le capteur de température. Il faut :

* Lancer un message de start
* Envoyer l’adresse du capteur de température (0x98 dans notre cas)
* Envoyer l’adresse du registre qui nous intéresse (0x00 pour celui contenant la température), ceci placera le pointeur de registre du capteur sur cette adresse
* Restart la communication pour laisser la main au capteur
* Envoyer l’adresse du capteur en ajoutant 1 (Ceci permet de stipuler que nous désirons lire la valeur pointée)
* Lire la partie haute de la température
* Lire la partie basse de la température
* Envoyer un message de stop

Chaque action correspond à l'utilisation d'une fonction de la librairie IIC codée. (cf déport git) Et après chaque action, nous devons vérifier le status du bus dans le registre TWSR. Ce "status" nous donnera des indications sur le bon déroulement de la communication, à savoir la réception d'ACK (équivalent d'accusé de réception) ou confirmation d'envoie de start, restart, etc.

=====Test=====

Le test de la librairie iic s'est fait directement lorsque la carte du capteur de température a été soudée. Pour ce faire, nous utilisons une compilation en mode "DEBUG" (make debug upload) qui nous permettait de lire la valeur des "status" avec minicom.
Après différents tests, nous avons finalement réussi à faire fonctionner le capteur de température en IIC, ce dernier nous renvoyait bel et bien une valeur de température précise à 0.5degrés près, vérifié à l'aidé d'un autre capteur de température.

Il est néanmoins regrettable que ce capteur ne sera pas utilisable dans les prototypes finaux dans la mesure où il est greffé à une carte dont le module bluetooth n'est pas utilisable.

====Capteurs analogique====

Comme dit précédemment, nous avons abandonné l'utilisation de l’accéléromètre IIC prévu initialement dans le vagin car nous n'avons pas réussi à le souder sur les cartes du pénis. Nous avons donc utilisé ce qui était à notre disposition à savoir un capteur analogique.

La mesure analogique sous AVR se fait simplement via l'utilisation de la fonction ad_sample(numéro de la broche analogique lue). Elle renvoie directement une valeur entre 0 et 255 correspondant à une conversion analogique-numérique de la tension sur la broche lue du capteur.

===Contrôle des servomoteurs===

Un servomoteur se contrôle à l'aide d'un signal PWM (Pulse Width Modulation). Ce signal consiste à modifier la largeur de l'impulsion en fonction de la consigne désirée.

La génération de PWM via microcontrôleur se fait à l'aide de TIMERS. Il faut savoir qu'il existe une priorité dans les interruptions, pour un TIMER_X donné, plus le X est proche de 0, plus l'interruption sera prioritaire. Nos signaux PWM se doivent d'être le plus en accord avec nos consignes, c'est pourquoi nous avons choisi d'utiliser les TIMER les plus prioritaires pour les générer. (TIMER0 et TIMER1)

====PWM sur un seul servomoteur====

Notre première manière de procéder consistait à générer la PWM nous même à l'aide du vecteur d'interruption d'un TIMER. La méthode consistait à compter de 0 à 255 en permanence. Lorsque le compteur était inférieur à la consigne, on passait une sortie à l'état haut, sinon elle restait à l'état bas.

Cette méthode simulait plutôt bien le signal PWM et avait pour avantage d'être utilisable pour n'importe quelle de l'arduino. Cependant, cette méthode a le gros désavantage d'être sensible à l'utilisation d'autres interruptions, rendant le TIMER imprécis.

Or, notre projet utilisera d'autres procédures d'interruption. Nous avons donc décidé d'utiliser une méthode plus simple mais nous restreignant sur le choix de nos sorties.

En effet, un atmega possède des registres que l'on peut configurer pour générer des signaux PWM sur des broches spécifiques.

Ainsi, en configurant le registre TCCR0A à 0x81 et TCCR0B à 0x05, on se place en mode PWM non inversée à fréquence élevée. En résumé, cette configuration nous permet de faire varier les signaux PWM en introduisant une consigne dans le registre OCR0A.

Ainsi, nous pouvons donc contrôler le moteur simplement en changeant la consigne dans OCR0A.

====Tests====

Dans un premier lieu, les moteurs servomoteurs ne recevaient pas les consignes. Nous pensions que le fait que la PWM soit en 3V3 était l'origine du problème. Nous avons donc fait le montage à l'aide d'un transistor NPN monté en saturé. Le problème n'a pas été résolu.

Finalement, le soucis viendrait du fait que les tests étaient effectués avec des valeurs du registre OCR0A à 0 (pwm nulle). Nous n'aurons donc pas besoin d'un montage à transistor pour le PCB.

Le but des servomoteurs est d'effectuer un semblant de massage, nous allons donc modifier le code afin d'effectuer la tâche de manière périodique via l'utilisation d'un TIMER.

====Gestion d'un ensemble de servomoteurs====

Dans le vagin, nous utilisons 4 servomoteurs afin de masser l'utilisateur. Nous avons trouvé intéressant de diviser ces moteurs en deux couples afin d'intensifier ou non ce massage en fonction des seuils d'excitation détectés par les capteurs.

Pour ce faire, nous aurons besoin de deux signaux PWM différents, donc de l'utilisation de deux timers configurés en PWM.

Comme dit en introduction de cette section, nous nous imposons l'utilisation du TIMER1 pour cette deuxième PWM. Il existe une différence dans la configuration de cette dernière dans la mesure où le signal peut recevoir des consignes allant de 8 à 16bits en fonction de la configuration. Afin de simplifier les choses, nous avons configuré cette dernière sur 8bits pour lui envoyer les mêmes consignes que pour le TIMER0.

====Tests====

Avant tout, nous devions vérifier que la consigne avait une intensité suffisante pour être envoyée sur deux servomoteurs en même temps. Ce qui était le cas.

Ensuite, nous avons testés des changements de consignes plus ou moins rapides afin de déterminer ce qui répondrait le mieux à nos attentes.

Les tests concluants, nous pouvions passer à la suite.

===Utilisation des buzzers===

En fonction du niveau d'excitation, nous ferons vibrer un ou deux buzzers. Pour ce faire, nous avons fait le choix de souder leur broche GND au GND de nos cartes et ainsi souder leur potentiel VCC à une broche de l'arduino. Ainsi, si nous plaçons la broche à l'état bas, le tension dans le buzzer est nulle et si nous passons la broche à l'état haut, la tension aux bornes du buzzers devient 3.3V et il vibre.

Pour ce faire, nous utilisons simplement deux broches, ici PXX et PXX, que nous avons initialisés en tant que sorties en mettant à un leur bit correspondant dans le registre DDRX. Ainsi, il ne reste plus qu'à commander la valeur haute ou basse de ces broches en mettant à 1 ou 0 leur bit dans le registre PORTX.

====Tests====

Ceci a été testé sur breadboard et était fonctionnel. Cependant, une chose à quoi nous n'avions pas pensé était que lorsque nous les avons soudés sur le PCB, nous aurions dû utiliser des câbles plus épais, car comme nous n'avions pas de prototype sur quoi coller les buzzers, l'un des buzzers s'est arraché de la carte en vibrant.

===Résumé===

[[Fichier:Resume sextoy.png|center|recap]]

==Gestion de la communication bluetooth==
===Introduction===
Dans le cadre de notre projet, la communication entre le sextoy et le téléphone se fera à faible portée. C'est pourquoi nous avons considéré comme intéressante l'utilisation de la technologie bluetooth.

La première partie consiste à coder une librairie au niveau de l'arduino. Cette librairie, codée en C, consiste simplement en une lecture / écriture via les broches RX/TX de l'arduino et du module bluetooth.

La seconde partie conssite à coder la partie application mobile qui communiquera avec la arduino.

Une fois que cette transmission sera mise en place, il ne reste plus qu'à expliciter le protocole des paquets transmis.

===Arduino===

Afin de communiquer à travers le module bluetooth, il faut relier la broche RX de l'arduino à celle TX du module bluetooth et inversement. Pour tester nos codes, nous avons utilisé un module bluetooth HC-06 et l'application [https://play.google.com/store/apps/details?id=Qwerty.BluetoothTerminal&hl=fr| Bluetooth Terminal].

Dans la mesure où l'arduino devra traiter l'arrivée asynchrone de messages tout en effectuant le traitement des capteurs, il est intéressant d'effectuer des lectures à l'aide d'interruptions. Pour cela, nous utilisons le vecteur d'interruption USART_RXC_vect qui déclenchera la fonction de lecture d'un paquet à chaque fois qu'un message est reçu.

''Actuellement, la librarie est fonctionnelle, il ne reste plus qu'à faire l'utilisation par interruption.''

===Application mobile===
===Protocole de transmission===
===Module bluetooth utilisé===

Le module bluetooth embarqué sur le PCB est un module reprogrammable. Ainsi il était nécessaire de connaître la configuration par défaut du composant, dans le but de savoir s'il fallait ou non prévoir un pcb de reconfiguration.

Le CYBLE-012012 est configuré par défaut avec le firmware "EZ-Serial BLE Firmware". La configuration par défaut de ce firmware est la suivante :

* 115200 baud, 8bits de donnée, pas de bit de parité, 1bit de stop
* "UART flow control" désactivé
* firmware activé en mode "auto-start", qui correspond à une recherche automatique de connection bluetooth et de redirection RX-TX en cas de connection

Ces [http://www.cypress.com/file/285326/download| informations] sont importantes car, si elles sont vraiment respectées, nous n'auront pas à créer notre propre kit de développement, ce qui est un gain de temps considérable.

Qui plus est, l'utilisation d'une fonction "auto-start" est en adéquation avec le module bluetooth HC-05 utilisé pour les tests. Nous pouvons donc commencer la programmation mobile du bluetooth en parallèle de l'impression des pcb. Et, dans le cas où les pcb seraient disfonctionnels, nous pourront quand meme envisager un prototype sur breadboard.

====Test====

Après avoir alimenté la carte, nous n'avons pas pu nous connecter au module bluetooth, ce dernier n'étant même pas visible dans les appareils alentours.

Nous avons alors vérifié si la carte était correctement alimentée. Pour ce faire, nous avons mesuré différents points de tensions sensé être mis par défaut en PULL-DOWN ou PULL-UP à des niveaux de tensions d'1.7V. Ces niveaux étaient respectés. Le problème n'est donc pas d'ordre électronique.

Par la suite, nous avons voulu vérifier la communication du module. Ce dernier, en déclenchant l'auto start est sensé émettre (en suivant le protocole UART rappelé précédemment) un message START. Nous avons donc inspecté ceci en utilisant minicom. En effet, minicom reçoit un message, mais ne sait pas le déchiffré. Qui plus est, impossible d'envoyer un message au module afin de le reprogrammer (de manière similaire à un XBee).

Devant ces soucis, nous décidons donc d'abandonner ce module bluetooth et de poursuivre avec celui utilisé pour les essais de programmation, le HC-05.

==Conception de l'application Android==
===Envoie et réception de SMS===
Afin de ne pas utiliser de serveur, les deux appareils Android doivent synchroniser l'envoi de paquet UDP, pour cela nous avons voulu utiliser des SMS.
Les SMS permettent d'envoyer des informations, comme les adresses IP, les ports utilisés, l'heure à laquelle les deux téléphones vont envoyer leur premier paquet UDP.

Dans un premier temps nous avons créer une application pour envoyer les SMS:

L'application était très simple, l'envoi de SMS se faisait en deux lignes
// initialisation d'une variable sms gérant les sms
SmsManager sms = SmsManager.getDefault() ;
// envoie un sms comportant le texte de la variable message de type String au numéro contenu dans la variable num de type String
sms.sendTextMessage(num, null, message, null, null);

Dans un deuxième temps il fallait recevoir un SMS, ou plutôt savoir qu'un nouvel SMS avait été reçu :

Pour cela il fallait utiliser un thread qui était appelé par interruption avec la réception d'un SMS comme vecteur d’interruption.
Ce thread effectuait ce qui était demandé dans sa fonction onReceive(), comme par exemple lire les informations contenues dans le SMS:
public class IncomingSms extends BroadcastReceiver {
final SmsManager sms = SmsManager.getDefault();
public void onReceive(Context context, Intent intent) {
//Ce qui doit etre fait lors de la reception de SMS
}
}

Malheureusement ce programme ne marchait pas pendant des semaines, malgré de nombreuses modifications et de nombreux essais. Et le problème semblait être ma carte SIM, car en changeant de SIM, tous les programmes contenant ce code fonctionnaient parfaitement.

===Protocole UDP===
Afin d'effectuer un échange de données entre les deux utilisateurs, et essayer de faire une vidéo-conférence, nous avons choisi d'utiliser le protocole UDP.

Une première application permettait de tester l'envoi de paquet UDP, pour cela un serveur UDP a été utilisé sur un PC.
Le serveur attendait un message et l'affichait quand il le recevait.

Pour envoyer un paquet nous utilisons :

DatagramSocket ds = null;
ds = new DatagramSocket(PortA);
DatagramPacket dp;
InetAddress local = InetAddress.getByName(AdrIp);
dp = new DatagramPacket(message.getBytes(),message.length(),local,PortA );
ds.setBroadcast(true);
ds.send(dp);

Ce code crée un paquet qui comporte l’adresse et le port du destinataire, mais surtout les données à envoyer.
Ce paquet est ensuite envoyer grâce à un socket.

Une fois que tout fonctionnait comme il le fallait, nous avons pu créer une application qui comportait l'envoi et la réception de paquet.
En mettant l'application sur deux téléphones on pouvait tester si tout fonctionnait.
Les tests ont seulement été effectué sur un réseau local, on ne sait pas pour le moment si des box internet pourraient empêcher la transmission.
Pour la réception nous utilisons :
dsocket.receive(packet);
buff = packet.getData();

Pour récupérer les données du paquet dans la variable buff, il suffit ensuite de créer une boucle pour recevoir plusieurs messages.
La fonction de réception étant bloquante, il a été préférable de l'effectuer dans un thread.

L'application est donc composé de un thread d'écoute, un thread d'envoi et d'un thread principal gérant l'affichage et appelant le thread d'envoi lorsque que le bouton de l'application est appuyé.
Voici une image de l'application, les champs d’adresseIp et de port du destinataire sont à remplir avant d'envoyer un paquet UDP.
Et le port d'écoute est défini dans le code de cette application, ce qui n'est pas très pratique, mais suffisant pour les tests.

Le TextView est mis à jour à chaque que le bouton envoyer est appuyé, en prenant comme valeur celle d'un registre comprenant la valeurs du dernier paquet UDP reçu.

[[Fichier:ClientUdp.png]]

===Communication Bluetooth===
Pour gérer la communication entre le téléphone et un sextoys, il faut utiliser une communication Bluetooth.

Dans un premier temps il faut se connecter avec l'appareil:

new ConnectBT().execute();

Avec ConnectBT une classe trouvée sur internet.

Ensuite il faut communiquer :

Pour envoyer un message on utilise:

btSocket.getOutputStream().write(message);

Avec btSocket un socket Bluetooth ayant été connecté avec le sextoy dans la classe ConnectBT.

Ensuite il faut recevoir :

btSocket.getInputStream().read(mmBuffer);

Avec mmBuffer qui contient le message reçu.

Mais contrairement à la réception UDP, la réception Bluetooth n'est pas bloquante, ainsi on peut recevoir des messages nuls.

Pour éviter ce problème l'application envoie un paquet Bluetooth, et reçoit juste après, et le sextoy est configuré pour envoyer un paquet UDP, juste après en avoir reçu un.

===Application principale===
Afin d'être ergonomique,l'application doit pouvoir enregistrer des contacts, pour plus facilement communiquer avec eux.
Nous avons choisi de ne pas utiliser les contacts du téléphone, pour pouvoir avoir des contacts "confidentiels" qui ne seront que dans la base de donnée de l'application.

Il fallait donc créer une base de donnée, nous avons donc utilisé SQLite car cette bibliothèque est utilisée par Android comme base de données embarquée.
La base ne comporte qu'une seule table, avec seulement les pseudos et les numéros de téléphone.

Une fois la base crée, pour interagir avec, nous avons coder des activités:

- Ajout de contact:

Il faut entrer dans les champs de textes les informations pour la base de données,puis appuyer sur le bouton "Ajouter" pour créer un nouveau contact dans la base de donnée.

[[Fichier:AjoutContact.png]]

-Fiche de Contact:

Affiche le pseudo et le numéro de téléphone dans les "TextView", et permet de : supprimer le contact en cliquant sur la croix, envoyer un SMS en cliquant sur l'icone "Message", mais aussi commencer une communication UDP en cliquant sur le téléphone.

[[Fichier:FicheContact.png]]

-Liste de contact :

Affiche la liste de contacts, en cliquant sur un des contacts on arrive sur la page Fiche de Contact, et en cliquant sur le plus on arrive sur la page Ajout de Contact.

[[Fichier:ListView.png]]

Ensuite il faut ajouter la gestion de communication:

-Les SMS :

Il faut remplir les champs de texte et appuyer sur SMS pour envoyer un message du type

Message

"Address Ip :" Addresse Ip

"Port :" Port

Avec Message,Addresse Ip, et Port les champs à remplir, "Addresse Ip :" et "Port :" deux chaines de caractères.

[[Fichier:SMS.png]]

-Protocole UDP :

Quatre champs sont à remplir, cliquer sur Envoyer pour passez à l'activité de gestion Bluetooth.

Les champs sont:

-L'addresse Ip

-Le port destination

-Le port source

-L'heure qui n'est pas utilisée, qui devait servir pour la synchronisation.

Les valeurs des champs sont conservés pour la communication UDP à venir.

[[Fichier:UDP.png]]

-Gestion Bluetooth :

En cliquant sur "Paired Devices", l'application affichera la liste des appareils appairés.

Puis en cliquant un des appareils, l'application essayera de connecter avec, tout en lançant l'activité UDP avec Bluetooth.

Si l'on souhaite ne pas utiliser de périphérique Bluetooth, il suffit de cliquer sur le bouton moins en haut à droite.

L'activité UDP sans Bluetooth se lancera.

[[Fichier:Bluetooth.png]]

-Communication UDP avec Bluetooth:

Pour lancer la communication UDP, appuyer sur le bouton Off ,il passera en mode On.

Si vous cliquez sur le bouton On il passera en mode Off, et coupera la communication UDP.

Le bouton envoyer, permet de forcer l'envoi d'un paquet UDP.

Et le bouton croix coupe toutes les communications(UDP et Bluetooth), et retourne à la page précédente.

Lorsque l'application reçoit un paquet UDP, un message est envoyé via Bluetooth au sextoys.

Celui-ci répond automatiquement en envoyant une valeur moyennée des ses capteurs, cette valeur est récupérée et mise dans un registre.

En parallèle, toutes les secondes un paquet UDP est envoyé et les données envoyés sont celle du registre.

[[Fichier:Com.png]]

-Communication UDP sans Bluetooth.

Le bouton On/Off est utilisé comme dans l'activité "Communication UDP avec Bluetooth"

Les boutons de niveaux, mettent une valeur dans un même registre.

Chaque boutons correspond à une valeur, qui correspondent avec un niveau d'excitation du sextoys.

Ainsi toutes les secondes, un paquet UDP est envoyé avec comme donnée la valeur du registre.

Lorsqu'un paquet UDP est reçu, la donnée reçue est mise dans un registre qui détermine l’affichage du "TextView" en bas à droite.

Ce TextView est mis à jours en même temps qu'un paquet UDP est envoyé.

[[Fichier:Co2.png]]

== Rapport et codes ==

Rapport : [[Fichier:CR_sextoy_connecte.pdf]]

[https://archives.plil.fr/croussel/Projet_sextoy_connecte.git Codes]

Fichier:ClientUdp.png

2017-05-20T15:47:02Z

Tstieven :

IMA4 2016/2017 P14

2017-05-20T15:35:41Z

Tstieven :

= Projet IMA4 : Sex-toy connecté =

== Présentation du projet ==

L'objectif de ce projet est de développer un système d'échange entre deux partenaires distants afin de rendre plus facile la vie de couple à distance.

Pour ce faire, le dispositif sera constitué de deux sextoys connectés (un par appareil génital désiré) à leur téléphone portable respectif. Une application mobile permettra aux utilisateurs de s'échanger des données de manière sécurisé, ceci au travers d'un serveur embarqué dans le téléphone portable.

Les données échangées pourront être l'accélération ou la température. Elles seront traitées et transmises au sextoy qui adaptera sa vitesse, son retour vibratoire ou sa position en conséquence.

Les sextoys pourraient être composés de :
* Pour l'appareil masculin (dédié à la femme) :
:* un servomoteur ;
:* un vibreur ;
:* une sonde de température ;
:* un accéléromètre.
* Pour l'appareil féminin (dédié à l'homme) :
:* 4 servomoteurs (dans le but de "masser" en déplaçant le silicone);
:* des vibreurs ;
:* un accéléromètre.
* Pour les deux appareils :
:* un micro-contrôleur (Arduino mini) ;
:* un module de transmission / réception bluetooth afin de se connecter au téléphone ;
:* du silicone.

* L'application mobile devra :
:* mettre en place une communication cryptée à travers un serveur (embarqué ou bien intermédiaire ?) ;
:* effectuer un échange de données en bluetooth avec le sextoy connecté.

* L'application mobile pourra :
:* utiliser la vidéo-conférence ;
:* enregistrer les meilleurs moments et enventuellement pouvoir les partager ;
:* effectuer une recherche de partenaire aléatoire.

* S'il nous reste du temps, il peut être envisageable de :
:* mettre en place un réseau social interne à Polytech.

== Liste des tâches ==
* Conception de l'appareil masculin (Cédric)
:* mettre en place le bus I2C avec les différents capteurs ;
:* création d'un PCB au format gerber ;
:* création d'un prototype.

* Conception de l'appareil féminin (Cédric)
:* mettre en place le bus I2C ;
:* traitement des données afin d'en déduire la position et l'entrain de l'utilisateur ;
:* création d'un PCB ;
:* création d'un prototype.

* Communication bluetooth (Cédric et Thomas)
:* étudier l'émission/réception vue de l'arduino ;
:* étudier l'émission/réception vue du téléphone ;
:* mise en place du protocole ;
:* test de portée.

* Développement mobile (Thomas)
:* déterminer la meilleure approche : utilisation d'un serveur intermédiaire ou bien mise en place d'un "client-serveur" dans l'application mobile ;
:* mettre en place le choix retenu ;
:* tester dans un premier temps une transmission de texte ;
:* programmer le traitement de données reçues par bluetooth ;
:* rajouter un côté esthétique à l'application.

==Feuille d'heures==

{| class="wikitable"
! Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures vacances !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures vacances et après!! Total
|-
| Définition cahier des charges
| 2H
| 2H
| 1H
|
|
|
|
|
|
|
|
|
|
| 5H
|-
| Dimensionnement et établissement de la liste de matériel
|
| 3H
| 4H
|
| 4H
|
|
|
|
|
|
|
|
| 11H
|-
| Établissement de la liste et de la répartition des tâches
| 1H
|
|
|
|
|
|
|
|
|
|
|
|
| 1H
|-
| Appareil masculin : programmation
|
|
|
|
| 1H
| 2H
|
|
|
|
|
|
| 6H
| 9H
|-
| Appareil masculin : étude des datasheets
|
|
|
| 1H
| 1H
|
| 4H
|
|
|
|
| 1H
|
| 7H
|-
| Appareil masculin : PCB
|
|
|
|
|
|
|
|
|
| 4H
| 4H
| 6H
| 30H
| 44H
|-
| Appareil masculin : 3D
|
|
|
|
|
|
|
|
|
|
|
|
| 6H
| 6H
|-
| Conception de l'appareil féminin
|
|
|
|
|
| 2H
| 1H
|
|
|
|
|
|
| 3H
|-
| Liaison bluetooth (embarqué)
|
|
|
| 3H
| 1H
|
|
|
|
|
|
|
| 8H
| 12H
|-
| Liaison bluetooth (téléphone)
|
|
|
|
|
|
|
|
|
|
|
|
| 15H
| 15H
|-
| Recherche et discussion autour de la meilleure approche de communication
| 2H
| 2H
|
|
|
|
|
|
|
|
|
|
|
| 4H
|-
| Synchronisation temporelle des téléphones (par sms)
|
| 2H
| 4H
| 6H
| 8H
| 6H
|
|
|
|
|
|
|
| 26H
|-
| Transmission de paquets UDP
|
|
|
|
|
|
| 4H
| 4H
| 4H
|
|
|
| 6H
| 18H
|-
| Streaming video(UDP)
|
|
|
|
|
|
|
|
|
| 4H
| 4H
|
|
| 8H
|-
| Application et bases de données
|
|
|
|
|
|
|
|
|
|
|
| 6H
| 20H
| 26H
|-
| Total
|
|
|
|
|
|
|
|
|
|
|
|
|
| 195H
|}

==Conception des sextoys==
===Introduction===

La conception de sextoys doit respecter différents règles, notamment sanitaires. C'est pourquoi nous nous sommes intéressés à l'utilisation de silicone pour ce projet. Nous avons notamment rencontré un ingénieur compétant dans ce domaine afin de nous aiguiller sur cette éventuelle conception.

La conception passera également par une conception 3D que nous effectuerons à l'aide d'imprimantes 3D au fabricarium de Polytech Lille.

Enfin, les prototypes seront embarqués de cartes électroniques (aussi appelés PCB) que nous constituerons.

===Choix du silicone, rencontre avec Mario Sanz===

Le projet nécessite l'utilisation d'une matière souple et non irritante, c'est pourquoi nous avons choisi de nous tourner vers l'utilisation du silicone. Afin de choisir au mieux le produit correspondant à nos besoins, nous avons rencontré Mario Sanz, ingénieur à l'INRIA, qui travail régulièrement avec du silicone.

Ce dernier nous a expliqué les différents points importants sur lesquels nous baser afin de choisir au mieux un produit en accord avec le projet. Ne serait-ce que pour le choix de la dureté, il existe une échelle propre au silicone ("Shore hardness scale"), nous pensions au départ rechercher un silicone le plus mou possible, cependant, il faut savoir que le plus le silicone est mou, plus il a tendance à être "collant". Finalement, après discutions, un shore de 40A (correspondant à la dureté d'une gomme) suffisamment mince fera l'affaire pour la conception des prototypes.

Il nous a également expliqué que le silicone peut être travaillé à l'aide d'additifs et sous cloche à vide afin d'améliorer le moulage, l'absence de "bulles" sur la surface de la pièce et la souplesse. Nous pouvons cependant travailler sans tout cela car il n'est pas spécialement important, pour notre projet, de rechercher des propriétés physiques homogènes dans tout le sextoy.

Pour ce qui est de la création de moules, nous pourrons les effectuer via imprimante 3D. Il existe un bon nombre de tutoriels sur internet pour s'y référer en cas de soucis.

===Impression 3D===

Pour la création d'objets en 3D, de nombreux outils sont disponibles. Nous avons décidé d'utiliser Tinkercad, un outil qui s'intègre directement au navigateur internet utilisé.

L'avantage d'un tel outil est sa grande communauté qui permet un accès simple et rapide à une multitudes de projets dont on pourrait s'inspirer pour générer nos pièces.

====Création des moules====

A l'aide d'une imprimante 3D, nous pouvons concevoir des moules afin de créer des pièces en silicone. Il s'agit de la manière la plus rapide et accessible pour notre projet.

Cette méthode comporte des désavantages, dont le principal est la présence d'imperfection et de non homogénéité dans les pièces réalisées. Ceci n'a pas de grande importance dans la mesure où nous souhaitons du qualitatif.

====Création d'un prototype====

=====Pénis=====

Afin de visualiser qualitativement la forme et le passage des câbles, un prototype imprimé au Fabricarium de Polytech Lille a été réalisé.

Ce prototype se divise en 3 pièces : un boîtier (pour y loger le PCB), un cylindre (afin de reproduire la forme désirée) et un "tête" qui devait à l'origine être un moule en silicone (pour y loger le PCB du capteur de température).

[[Fichier:Sextoy_penis.png|400px|thumb|center|Prototype 3D pénis]]

===Conception des PCB===

Afin de diminuer un maximum la taille des cartes electroniques, nous utilisons principalement des composants CMS.

La conception des cartes peut-être effectué à l'aide de logicels de CAO tels qu'Altium ou Eagle. Dans notre cas, nous avons utilisé Eagle.

Ce travail consiste à créer une librairie regroupant l'intégralité des composants nécessaires et, ensuite, de créer un schéma du circuit. Une fois le schéma terminé, il ne restera plus qu'à faire le routage et exporter les fichiers au format "Gerber".

Pour ce projet, nous aurons besoin de deux cartes, une par prototype. Chaque carte embarquera des composants similaires, c'est pourquoi nous nous contenterons d'abord d'un seul PCB pour effectuer des tests. Si ces derniers sont concluants, nous pourrons graver le second.

====PCB du pénis====

Le premier PCB imprimé et soudé est celui du pénis. Une première carte avait été imprimé regroupant sur cette dernière : un support pour l'arduino, un accéléromètre, un module bluetooth.

[[Fichier:PCB_penis_VB.png|400px|thumb|center|PCB v1.0]]

Nous avons expérimentés des problèmes dûs aux dimensions de l'accéléromètre, l'utilisation d'un boîtier CMS de type TDFN10 2x2 était optimiste pour la réalisation du projet, compte tenu du matériel à disposition.

C'est pourquoi une seconde carte a été gravée, cette fois sans l'accéléromètre.

[[Fichier:PCB_penis_VF.png|400px|thumb|center|PCB v2.0]]

[[Fichier:PCB_VF.png|400px|thumb|center|PCB v2.0 schema]]

Ce prototype est sensé embarquer un capteur de température que nous avons décidé de mettre sur un PCB à part. Cette carte avait pour but d'être coulé dans le silicone, afin de mesurer la température au plus près de la zone intéressée.

[[Fichier:TEMPERATURE_PCB_VF.png|400px|thumb|center|PCB temperature]]

[[Fichier:TEMPERATURE_VF.png|400px|thumb|center|PCB temperature schema]]

====PCB du vagin====

Compte tenu des soucis rencontrés avec l'accéléromètre, la carte sera gravée afin de pouvoir y plugger un accéléromètre analogique en traversant. Le but étant d'avoir un prototype fonctionnel d'ici la fin du projet.

Nous avons également eu des problèmes avec le module bluetooth utilisé, ce dernier ne pouvant être reconfiguré manuellement par minicom, nous utiliserons le bluetooth HC-05 utilisé pour les essais de code. De même que pour l'accéléromètre, nous prévoirons un endroit pour le plugger sur la carte.

''image PCB vagin''

''Reste à graver le PCB du vagin''

==Gestion des composants==
===Introduction===

Notre projet implique l'utilisation de capteurs, de servomoteurs et de buzzers, constituant chacun une partie de la programmation embarquée.

Pour cette programmation, nous avons décidé d'utiliser AVR-gcc et ainsi coder les arduinos en C.

Les capteurs utilisés utilisent un protocole de communication IIC (ou I²C, I2C), ce protocole de multiples avantages que nous expliciterons par la suite. Cependant, comme un des capteurs (l'accéléromètre) prévus initialement nous a causé beaucoup de soucis, nous expliciterons également la mesure à l'aide de capteurs analogiques. Ces différents capteurs nous permettront de mesurer l'excitation d'un utilisateur.

Une fois l'excitation mesurée, il faut induire une réponse "physique". Pour ce faire, nous utilisons d'une part des servomoteurs dans le but de produire une sensation de massage.

D'autre part, nous utilisons également des buzzers.

===Utilisation des capteurs===

====Capteurs par IIC====

Le choix de l'IIC n'était pas anodins. L'IIC permet, pour un bus de seulement deux fils, d'utiliser un nombre important de capteurs. Ainsi, si nous décidions au cours du projet de rajouter tel ou tel capteurs, nous n'avions qu'à les greffer à ce bus IIC.

====Capteurs analogique====

Comme dit précédemment, nous avons abandonné l'utilisation de l’accéléromètre IIC prévu initialement dans le vagin car nous n'avons pas réussi à le souder sur les cartes du pénis. Nous avons donc utilisé ce qui était à notre disposition à savoir un capteur analogique.

La mesure analogique sous AVR se fait simplement via l'utilisation de la fonction ad_sample(numéro de la broche analogique lue). Elle renvoie directement une valeur entre 0 et 255 correspondant à une conversion analogique-numérique de la tension sur la broche lue du capteur.

===Contrôle des servomoteurs===

Un servomoteur se contrôle à l'aide d'un signal PWM (Pulse Width Modulation). Ce signal consiste à modifier la largeur de l'impulsion en fonction de la consigne désirée.

La génération de PWM via microcontrôleur se fait à l'aide de TIMERS. Il faut savoir qu'il existe une priorité dans les interruptions, pour un TIMER_X donné, plus le X est proche de 0, plus l'interruption sera prioritaire. Nos signaux PWM se doivent d'être le plus en accord avec nos consignes, c'est pourquoi nous avons choisi d'utiliser les TIMER les plus prioritaires pour les générer. (TIMER0 et TIMER1)

====PWM sur un seul servomoteur====

Notre première manière de procéder consistait à générer la PWM nous même à l'aide du vecteur d'interruption d'un TIMER. La méthode consistait à compter de 0 à 255 en permanence. Lorsque le compteur était inférieur à la consigne, on passait une sortie à l'état haut, sinon elle restait à l'état bas.

Cette méthode simulait plutôt bien le signal PWM et avait pour avantage d'être utilisable pour n'importe quelle de l'arduino. Cependant, cette méthode a le gros désavantage d'être sensible à l'utilisation d'autres interruptions, rendant le TIMER imprécis.

Or, notre projet utilisera d'autres procédures d'interruption. Nous avons donc décidé d'utiliser une méthode plus simple mais nous restreignant sur le choix de nos sorties.

En effet, un atmega possède des registres que l'on peut configurer pour générer des signaux PWM sur des broches spécifiques.

Ainsi, en configurant le registre TCCR0A à 0x81 et TCCR0B à 0x05, on se place en mode PWM non inversée à fréquence élevée. En résumé, cette configuration nous permet de faire varier les signaux PWM en introduisant une consigne dans le registre OCR0A.

Ainsi, nous pouvons donc contrôler le moteur simplement en changeant la consigne dans OCR0A.

====Tests====

Dans un premier lieu, les moteurs servomoteurs ne recevaient pas les consignes. Nous pensions que le fait que la PWM soit en 3V3 était l'origine du problème. Nous avons donc fait le montage à l'aide d'un transistor NPN monté en saturé. Le problème n'a pas été résolu.

Finalement, le soucis viendrait du fait que les tests étaient effectués avec des valeurs du registre OCR0A à 0 (pwm nulle). Nous n'aurons donc pas besoin d'un montage à transistor pour le PCB.

Le but des servomoteurs est d'effectuer un semblant de massage, nous allons donc modifier le code afin d'effectuer la tâche de manière périodique via l'utilisation d'un TIMER.

====Gestion d'un ensemble de servomoteurs====

Dans le vagin, nous utilisons 4 servomoteurs afin de masser l'utilisateur. Nous avons trouvé intéressant de diviser ces moteurs en deux couples afin d'intensifier ou non ce massage en fonction des seuils d'excitation détectés par les capteurs.

Pour ce faire, nous aurons besoin de deux signaux PWM différents, donc de l'utilisation de deux timers configurés en PWM.

Comme dit en introduction de cette section, nous nous imposons l'utilisation du TIMER1 pour cette deuxième PWM. Il existe une différence dans la configuration de cette dernière dans la mesure où le signal peut recevoir des consignes allant de 8 à 16bits en fonction de la configuration. Afin de simplifier les choses, nous avons configuré cette dernière sur 8bits pour lui envoyer les mêmes consignes que pour le TIMER0.

====Tests====

Avant tout, nous devions vérifier que la consigne avait une intensité suffisante pour être envoyée sur deux servomoteurs en même temps. Ce qui était le cas.

Ensuite, nous avons testés des changements de consignes plus ou moins rapides afin de déterminer ce qui répondrait le mieux à nos attentes.

Les tests concluants, nous pouvions passer à la suite.

===Utilisation des buzzers===

En fonction du niveau d'excitation, nous ferons vibrer un ou deux buzzers. Pour ce faire, nous avons fait le choix de souder leur broche GND au GND de nos cartes et ainsi souder leur potentiel VCC à une broche de l'arduino. Ainsi, si nous plaçons la broche à l'état bas, le tension dans le buzzer est nulle et si nous passons la broche à l'état haut, la tension aux bornes du buzzers devient 3.3V et il vibre.

Pour ce faire, nous utilisons simplement deux broches, ici PXX et PXX, que nous avons initialisés en tant que sorties en mettant à un leur bit correspondant dans le registre DDRX. Ainsi, il ne reste plus qu'à commander la valeur haute ou basse de ces broches en mettant à 1 ou 0 leur bit dans le registre PORTX.

====Tests====

Ceci a été testé sur breadboard et était fonctionnel. Cependant, une chose à quoi nous n'avions pas pensé était que lorsque nous les avons soudés sur le PCB, nous aurions dû utiliser des câbles plus épais, car comme nous n'avions pas de prototype sur quoi coller les buzzers, l'un des buzzers s'est arraché de la carte en vibrant.

===Résumé===

==Gestion de la communication bluetooth==
===Introduction===
Dans le cadre de notre projet, la communication entre le sextoy et le téléphone se fera à faible portée. C'est pourquoi nous avons considéré comme intéressante l'utilisation de la technologie bluetooth.

La première partie consiste à coder une librairie au niveau de l'arduino. Cette librairie, codée en C, consiste simplement en une lecture / écriture via les broches RX/TX de l'arduino et du module bluetooth.

La seconde partie conssite à coder la partie application mobile qui communiquera avec la arduino.

Une fois que cette transmission sera mise en place, il ne reste plus qu'à expliciter le protocole des paquets transmis.

===Arduino===

Afin de communiquer à travers le module bluetooth, il faut relier la broche RX de l'arduino à celle TX du module bluetooth et inversement. Pour tester nos codes, nous avons utilisé un module bluetooth HC-06 et l'application [https://play.google.com/store/apps/details?id=Qwerty.BluetoothTerminal&hl=fr| Bluetooth Terminal].

Dans la mesure où l'arduino devra traiter l'arrivée asynchrone de messages tout en effectuant le traitement des capteurs, il est intéressant d'effectuer des lectures à l'aide d'interruptions. Pour cela, nous utilisons le vecteur d'interruption USART_RXC_vect qui déclenchera la fonction de lecture d'un paquet à chaque fois qu'un message est reçu.

''Actuellement, la librarie est fonctionnelle, il ne reste plus qu'à faire l'utilisation par interruption.''

===Application mobile===
===Protocole de transmission===
===Module bluetooth utilisé===

Le module bluetooth embarqué sur le PCB est un module reprogrammable. Ainsi il était nécessaire de connaître la configuration par défaut du composant, dans le but de savoir s'il fallait ou non prévoir un pcb de reconfiguration.

Le CYBLE-012012 est configuré par défaut avec le firmware "EZ-Serial BLE Firmware". La configuration par défaut de ce firmware est la suivante :

* 115200 baud, 8bits de donnée, pas de bit de parité, 1bit de stop
* "UART flow control" désactivé
* firmware activé en mode "auto-start", qui correspond à une recherche automatique de connection bluetooth et de redirection RX-TX en cas de connection

Ces [http://www.cypress.com/file/285326/download| informations] sont importantes car, si elles sont vraiment respectées, nous n'auront pas à créer notre propre kit de développement, ce qui est un gain de temps considérable.

Qui plus est, l'utilisation d'une fonction "auto-start" est en adéquation avec le module bluetooth HC-05 utilisé pour les tests. Nous pouvons donc commencer la programmation mobile du bluetooth en parallèle de l'impression des pcb. Et, dans le cas où les pcb seraient disfonctionnels, nous pourront quand meme envisager un prototype sur breadboard.

====Test====

Après avoir alimenté la carte, nous n'avons pas pu nous connecter au module bluetooth, ce dernier n'étant même pas visible dans les appareils alentours.

Nous avons alors vérifié si la carte était correctement alimentée. Pour ce faire, nous avons mesuré différents points de tensions sensé être mis par défaut en PULL-DOWN ou PULL-UP à des niveaux de tensions d'1.7V. Ces niveaux étaient respectés. Le problème n'est donc pas d'ordre électronique.

Par la suite, nous avons voulu vérifier la communication du module. Ce dernier, en déclenchant l'auto start est sensé émettre (en suivant le protocole UART rappelé précédemment) un message START. Nous avons donc inspecté ceci en utilisant minicom. En effet, minicom reçoit un message, mais ne sait pas le déchiffré. Qui plus est, impossible d'envoyer un message au module afin de le reprogrammer (de manière similaire à un XBee).

Devant ces soucis, nous décidons donc d'abandonner ce module bluetooth et de poursuivre avec celui utilisé pour les essais de programmation, le HC-05.

==Conception de l'application Android==
===Envoie et réception de SMS===
Afin de ne pas utiliser de serveur, les deux appareils Android doivent synchroniser l'envoi de paquet UDP, pour cela nous avons voulu utiliser des SMS.
Les SMS permettent d'envoyer des informations, comme les adresses IP, les ports utilisés, l'heure à laquelle les deux téléphones vont envoyer leur premier paquet UDP.

Dans un premier temps nous avons créer une application pour envoyer les SMS:

L'application était très simple, l'envoi de SMS se faisait en deux lignes
// initialisation d'une variable sms gérant les sms
SmsManager sms = SmsManager.getDefault() ;
// envoie un sms comportant le texte de la variable message de type String au numéro contenu dans la variable num de type String
sms.sendTextMessage(num, null, message, null, null);

Dans un deuxième temps il fallait recevoir un SMS, ou plutôt savoir qu'un nouvel SMS avait été reçu :

Pour cela il fallait utiliser un thread qui était appelé par interruption avec la réception d'un SMS comme vecteur d’interruption.
Ce thread effectuait ce qui était demandé dans sa fonction onReceive(), comme par exemple lire les informations contenues dans le SMS:
public class IncomingSms extends BroadcastReceiver {
final SmsManager sms = SmsManager.getDefault();
public void onReceive(Context context, Intent intent) {
//Ce qui doit etre fait lors de la reception de SMS
}
}

Malheureusement ce programme ne marchait pas pendant des semaines, malgré de nombreuses modifications et de nombreux essais. Et le problème semblait être ma carte SIM, car en changeant de SIM, tous les programmes contenant ce code fonctionnaient parfaitement.

===Protocole UDP===
Afin d'effectuer un échange de données entre les deux utilisateurs, et essayer de faire une vidéo-conférence, nous avons choisi d'utiliser le protocole UDP.

Une première application permettait de tester l'envoi de paquet UDP, pour cela un serveur UDP a été utilisé sur un PC.
Le serveur attendait un message et l'affichait quand il le recevait.

Une fois que tout fonctionnait comme il le fallait, nous avons pu créer une application qui comportait l'envoi et la réception de paquet.
En mettant l'application sur deux téléphones on pouvait tester si tout fonctionnait.
Les tests ont seulement été effectué sur un réseau local, on ne sait pas pour le moment si des box internet pourraient empêcher la transmission.
L'application est composé de un thread d'écoute, un thread d'envoi et d'un thread principal gérant l'affichage et appelant le thread d'envoi lorsque que le bouton de l'application est appuyé.

===Communication Bluetooth===
Pour gérer la communication entre le téléphone et un sextoys, il faut utiliser une communication Bluetooth.

Dans un premier temps il faut se connecter avec l'appareil:

new ConnectBT().execute();

Avec ConnectBT une classe trouvée sur internet.

Ensuite il faut communiquer :

Pour envoyer un message on utilise:

btSocket.getOutputStream().write(message);

Avec btSocket un socket Bluetooth ayant été connecté avec le sextoy dans la classe ConnectBT.

Ensuite il faut recevoir :

btSocket.getInputStream().read(mmBuffer);

Avec mmBuffer qui contient le message reçu.

Mais contrairement à la réception UDP, la réception Bluetooth n'est pas bloquante, ainsi on peut recevoir des messages nuls.

Pour éviter ce problème l'application envoie un paquet Bluetooth, et reçoit juste après, et le sextoy est configuré pour envoyer un paquet UDP, juste après en avoir reçu un.

===Application principale===
Afin d'être ergonomique,l'application doit pouvoir enregistrer des contacts, pour plus facilement communiquer avec eux.
Nous avons choisi de ne pas utiliser les contacts du téléphone, pour pouvoir avoir des contacts "confidentiels" qui ne seront que dans la base de donnée de l'application.

Il fallait donc créer une base de donnée, nous avons donc utilisé SQLite car cette bibliothèque est utilisée par Android comme base de données embarquée.
La base ne comporte qu'une seule table, avec seulement les pseudos et les numéros de téléphone.

Une fois la base crée, pour interagir avec, nous avons coder des activités:

- Ajout de contact:

Il faut entrer dans les champs de textes les informations pour la base de données,puis appuyer sur le bouton "Ajouter" pour créer un nouveau contact dans la base de donnée.

[[Fichier:AjoutContact.png]]

-Fiche de Contact:

Affiche le pseudo et le numéro de téléphone dans les "TextView", et permet de : supprimer le contact en cliquant sur la croix, envoyer un SMS en cliquant sur l'icone "Message", mais aussi commencer une communication UDP en cliquant sur le téléphone.

[[Fichier:FicheContact.png]]

-Liste de contact :

Affiche la liste de contacts, en cliquant sur un des contacts on arrive sur la page Fiche de Contact, et en cliquant sur le plus on arrive sur la page Ajout de Contact.

[[Fichier:ListView.png]]

Ensuite il faut ajouter la gestion de communication:

-Les SMS :

Il faut remplir les champs de texte et appuyer sur SMS pour envoyer un message du type

Message

"Address Ip :" Addresse Ip

"Port :" Port

Avec Message,Addresse Ip, et Port les champs à remplir, "Addresse Ip :" et "Port :" deux chaines de caractères.

[[Fichier:SMS.png]]

-Protocole UDP :

Quatre champs sont à remplir, cliquer sur Envoyer pour passez à l'activité de gestion Bluetooth.

Les champs sont:

-L'addresse Ip

-Le port destination

-Le port source

-L'heure qui n'est pas utilisée, qui devait servir pour la synchronisation.

Les valeurs des champs sont conservés pour la communication UDP à venir.

[[Fichier:UDP.png]]

-Gestion Bluetooth :

En cliquant sur "Paired Devices", l'application affichera la liste des appareils appairés.

Puis en cliquant un des appareils, l'application essayera de connecter avec, tout en lançant l'activité UDP avec Bluetooth.

Si l'on souhaite ne pas utiliser de périphérique Bluetooth, il suffit de cliquer sur le bouton moins en haut à droite.

L'activité UDP sans Bluetooth se lancera.

[[Fichier:Bluetooth.png]]

-Communication UDP avec Bluetooth:

Pour lancer la communication UDP, appuyer sur le bouton Off ,il passera en mode On.

Si vous cliquez sur le bouton On il passera en mode Off, et coupera la communication UDP.

Le bouton envoyer, permet de forcer l'envoi d'un paquet UDP.

Et le bouton croix coupe toutes les communications(UDP et Bluetooth), et retourne à la page précédente.

Lorsque l'application reçoit un paquet UDP, un message est envoyé via Bluetooth au sextoys.

Celui-ci répond automatiquement en envoyant une valeur moyennée des ses capteurs, cette valeur est récupérée et mise dans un registre.

En parallèle, toutes les secondes un paquet UDP est envoyé et les données envoyés sont celle du registre.

[[Fichier:Com.png]]

-Communication UDP sans Bluetooth.

Le bouton On/Off est utilisé comme dans l'activité "Communication UDP avec Bluetooth"

Les boutons de niveaux, mettent une valeur dans un même registre.

Chaque boutons correspond à une valeur, qui correspondent avec un niveau d'excitation du sextoys.

Ainsi toutes les secondes, un paquet UDP est envoyé avec comme donnée la valeur du registre.

Lorsqu'un paquet UDP est reçu, la donnée reçue est mise dans un registre qui détermine l’affichage du "TextView" en bas à droite.

Ce TextView est mis à jours en même temps qu'un paquet UDP est envoyé.

[[Fichier:Co2.png]]

== Rapport et codes ==

Rapport : [[Fichier:CR_sextoy_connecte.pdf]]

[https://archives.plil.fr/croussel/Projet_sextoy_connecte.git Codes]

IMA4 2016/2017 P14

= Projet IMA3-SC 2015/2016 : MORPION =

== Cahier des charges ==
Notre projet "système communicant" aura pour but de créer une interface connectée du "morpion". L'objectif est de permettre à un joueur interagissant sur un site internet de jouer contre une autre personne qui, elle, jouera à l'aide d'un affichage fait à partir de leds.

Nous cherchons donc à exploiter la capacité asynchrone d'un websocket afin de permettre une partie en temps réel.

=== Matériel ===
* Une nanoboard
* Une raspberry pi
* Une matrice de leds 9x9 ou plus
* Un clavier numérique ou 9 boutons-poussoirs
* Des ordinateurs avec les logiciels de développement nécessaires

=== Optionnel ===
* Un buzzer afin d'avertir le joueur d'un choix incohérent
* Trois afficheurs sept segments afin d'ajouter un tableau des scores

===Schéma de principe===
[[Fichier:Principe.png||center|600px|Schema de principe|Schéma de principe]] 

== Séance 1 ==

=== Partie électronique ===
Le but de cette première séance était de se familiariser avec le logiciel de conception Altium Designer et de réfléchir à la façon d'aborder la conception électronique du morpion.

Cette conception se fera en plusieurs étapes :

* gérer le positionnement d'un curseur en fonction de l'état courant de la partie
* gérer l'affichage de la matrice en fonction des cases remplies / sélectionnées
* permettre la réception et l'envoie de données à l'aide de la liaison série
* traiter la remise à zéro du plateau en cas de fin de partie

====Positionnement du curseur et état de la partie====

Dans un premier lieu, il était nécessaire de traiter les actions entrantes. En effet, si ce n'est pas au tour du joueur "physique", l'utilisation des boutons doit être bloquée. 
Ceci consiste simplement à effectuer un ET logique entre un bit symbolisant le joueur courant (si 1 alors joueur physique, si 0 alors joueur en ligne) et l'action demandée. 
[[Fichier:Choisir.png|vignette|center|400px|alt=Schema de choix|Circuit logique de la permission d'action]] 

Une fois les choix accessibles, il faut désormais les traiter. Le traitement s'effectuera à l'aide de bascules, chaque case comportera deux bascules : une bascule de sélection (la case est-elle sélectionnée ?) et une bascule permettant de savoir si la case a déjà été jouée. 
Si la case a déjà été jouée, il ne faut empêcher l'utilisateur de la jouer. 
Nous considérerons que le joueur en ligne n'effectuera pas de choix erroné et nous testerons seulement les choix du joueur "physique". 

[[Fichier:Traitement.png|vignette|center|600px|alt=Schema de traitement|Circuit logique du traitement d'une action]] 
Les ronds verts permettent la distinction des 9 cases. 
Le rond jaune correspond à la zone des sorties d'état. Plus précisément, il s'agit de deux bus regroupant les cases remplies et le lieu de la case sélectionnée. 
Le rond noir correspond au choix de l'adversaire. 
Le rond orange correspond à la sortie "selection_done" qui effectue un état haut lorsqu'un choix valide a été fait par l'utilisateur. 
Le rond rouge met en évidence la zone permettant de traiter les décalage du bit de sélection. Ce décalage consiste à garder seulement UNE bascule à l'état haut en effectuant le passage logique d'une bascule à une autre en fonction du choix tout en appliquant un reset sur l'ancienne sélection. Le schéma de ce déplacement se trouve ci-dessous et est appliqué aux 9 cases. 

[[Fichier:Andor.png|vignette|center|alt=Schema permettant le déplacement|Circuit logique utilisé afin de déplacer le curseur]] 

===Complément à la séance 1===
====Affichage dynamique====

L'un des grands problèmes à la réalisation du morpion sur nanoboard est l'affichage dynamique. En effet, il va falloir à la fois stocker les valeurs, et stocker quel joueur a joué telle ou telle case, afin de savoir quel case s'allumera de la couleur désirée. Ceci rajouté à l'affichage dynamique de la sélection, ceci s'avère compliqué. 
La tâche a alors été décomposée en deux étapes :
* Le traitement des couleurs (Quelle couleur affilier à quelle case ?)
* L'affichage de ces couleurs
=====Traitement des couleurs=====

Le but était de se simplifier au maximum les choses. Le premier problème est de savoir quel joueur a joué une case, pour ceci, nous nous sommes servi de l'état du plateau fourni dans le bloc TRAITEMENT. Nous savons quelles cases sont à 1 et imposons donc une couleur rouge à toutes ces cases. 
De plus, nous savons qu'à chaque fois que le joueur "physique" effectue un choix valide, un front montant est appliqué sur la broche "selection_done" de TRAITEMENT. Nous avons alors re-créé 9 registres symbolisant les cases, mais cette fois ci, en fonction de l'endroit sélectionné par l'utilisateur, si ce dernier effectue un choix valide, le registre passera à 1. Le but de cette manipulation est de recenser tous les registres joués par le joueur physique. 
Maintenant, nous relions ces registres aux valeurs de couleur verte afin d'additionner le vert au rouge des cases jouées et obtiendrons finalement des cases de couleur jaune pour symboliser les cases du joueur physique et des cases de couleur rouge pour le jouer en ligne. 
Il ne reste qu'à relier directement la case sélectionnée (recensée par le bus Etat_selection de TRAITEMENT) à la couleur bleue. 
Finalement nous avons :
* joueur en ligne : rouge
* joueur physique : jaune
* sélection : magenta, cyan ou bleu

[[Fichier:Traitement_affichage.png|vignette|center|800px|Schéma du traitement pré affichage|Circuit logique du traitement pré-affichage]] 

=====Affichage=====

La matrice led employée est une matrice led à anode commune. Elle a pour avantage de permettre la sélection d'une ligne et de la couleur de chaque colonne. 
Cependant, nous ne pouvons donc choisir la couleur que d'une colonne. C'est pourquoi nous allons faire varier cet affichage ligne par ligne à une fréquence élevée afin que l’œil humain ne le remarque pas. Nous pourrons donc choisir quelle couleur sera affichée sur chaque ligne. 
Cet affichage ligne par ligne sera effectué via un multiplexeur donc le bus de sélection sera relié à un compteur 3bits cadencé sur une clock suffisamment rapide pour opérer une persistance rétinienne. 
Dans chaque bus nous avons imposé certains bits afin que la grille soit dessinée en bleu. 
Le bus multiplexé sera ensuite redirigé vers les pins de la matrice leds. 

[[Fichier:Affichage.png|vignette|center|800px|Schéma d'affichage|Circuit logique de l'affichage]] 

====Tests====

Le bloc d'affichage a été testé et deux problèmes ont été rencontrés :
* La sélection a été mal réfléchie
* Un phénomène de rebond a été remarqué sur l'oscilloscope numérique

=====La sélection=====

Dans la fonction d'affichage, on retourne la sélection de la ligne en logique inversée. Le problème est que dans la version 1.0 de l'affichage, un GND avait été placé en entrée du MUX de sélection. Nous n'avions pas pensé au fait que dans ce cas la, toutes les sorties seraient en permanence au GND... La correction a donc été de placer un VCC en entrée et d'inverser les sorties, ainsi une seul anode de ligne sera placée sur le GND. 

[[Fichier:Selection.PNG|vignette|center||400px|Schéma de selection|Correction de la sortie de selection]] 

Le schéma semble fonctionnel cependant d'autres tests restent à faire.

=====Le rebond=====

Lors du test de l'affichage, la clock d'affichage a été simulée par un bouton de la nanoboard et l'affichage a été relié sur une seule ligne. 
Nous étions sensé remarquer que lorsque la ligne s'allume, si on appuie sur le bouton, elle s’éteint et enfin si nous appuyons sept fois sur le bouton, la ligne se rallume. 
Rien ne se passait comme prévu, et plus précisément, il n'y avait même pas de logique dans la ré-apparition de la ligne. 
Ayant déjà été confronté à des problèmes de rebonds avec des boutons poussoir, ce phénomène a été testé sur l'oscilloscope numérique. 

[[Fichier:Rebond.png||center|Exemple de rebond|Exemple de rebond]] 

Nous demanderons alors aux référents quelle stratégie adopter : filtrer le signal avec un condensateur en parallèle au bouton ou bien utiliser une comparaison avec registre à décalage pour vérifier la stabilité du signal avant d'envoie du front montant. 
Certes la correction du bouton n'était pas nécessaire aux tests entrepris pour l'affichage (nous aurions pu mettre une clock interne) mais ceci nous servira pour filtrer les choix effectués par l'utilisateur (haut, droite, select). 

====Objectifs pour la séance prochaine====

Les schémas effectués restent des ébauches, il y a forcément eu des oublis. Néanmoins, comme chaque schéma se compile, le passage à l'étape de mise en place de la liaison série durant la séance 2 est envisageable. Il faudra donc créer un protocole plus concret afin de savoir qui doit jouer, quand envoyer, quand recevoir des données. Si le temps le permet, quelques programmes simples seront testés sur la nanoboard afin de vérifier le fonctionnement de l'affichage de la matrice après discutions avec les enseignants au sujet du phénomène de rebond.

=== Partie informatique ===
Dans cette première séance nous avons programmé l'arduino afin de créer le programme de morpion, pour pouvoir tester la partie informatique sans disposer de la partie électronique.
Pour cela nous avons due apprendre à utiliser une matrice de LED RGB à l'aide des codes fournit par SparkFun.

Puis nous avons pu commencer à programmer le morpion:

*le jeu se déroule dans une matrice 3x3.
*le position du curseur est représentée par une lumière bleue, celle des pions du joueurs 1 par une lumière rouge et celle des pions du joueurs 2 par une lumière verte.
*si le curseur est sur un pions les deux couleurs s'additionnent pour donner du magenta où du cyan.
*le joueur se déplace à l'aide de 2 boutons poussoir,l'un permettant d'aller vers le haut, l'autre permettant d'aller à droite
**pour éviter plusieurs déplacements d'un coup, un délais a été mis entre deux actions
*une fois tout en haut, si le joueur presse le bouton pour aller vers le haut le joueur se retrouve en bas.
*une fois tout à droite, si le joueur presse le bouton pour aller vers la droite le joueur se retrouve à gauche.
*enfin un dernier bouton poussoir permet de placer un pion à l'endroit où se trouve le curseur.

Une fois les mouvements programmés il fallait régir les règles du jeu:

*Ainsi le curseur commence toujours en haut à droite
*Si le un joueurs arrive a créer une ligne de 3, il gagne la partie
*Si aucun joueur n'arrive à gagner et que le terrain est remplit, la partie se termine sur un match nul
*Une fois la partie terminée, le terrain est remis à zéros

Les fonctions permettant les différentes actions ont été décrites dans la partie Arduino de la séance n°3.

== Séance 2 ==

=== Partie électronique ===

La matrice led ne pourra être alimentée par les différentes broches de la nanoboard sous peine de créer une chute de tension et risquer un reset du fpga. 
Ainsi, le but de cet séance est de réfléchir à la conception d'un prototype de carte permettant d'alimenter la matrice led de manière externe. 
====Utilisation de transistors====
L'utilisation de transistors en saturé paraît la meilleur chose à faire. En effet, ceci permettra de générer un gain en courant et de contrôler l'état des différentes couleurs ligne par ligne et colonne par colonne. 
Pour permettra la liaison de chaque led au VCC, on utilisera un transistor PNP. Pour permettre la liaison au GND, on utilisera un NPN. 

[[Fichier:Montage_roussel.PNG||center|upright = 0.5|Montage d'une branche|Montage d'une branche de led]] 

Comme il s'agit de transistor à anodes communes, il suffira de 8 transistors NPN. Notre choix s'est donc porté vers le ULN2803A, qui est un ensemble de 8 paires Darlington. 
L'utilisation de paires Darlington a l'avantage de permettre une génération élevée de courant. (Fort gain en courant) 

Pour ce qui est des cathodes, un problème de taille se pose. Il faudrait 24 transistors PNP pour gérer les 8 colonnes * 3couleurs. Ainsi, notre choix s'est plutôt déporté vers le buffer de portes trois états 74AS240. Cette famille de buffer 3 états a la capacité de délivrer un courant du même ordre de grandeur que l'ULN2803A. 

Maintenant il reste à dimensionner la résistance sur chaque branche. Après quelques tests à l'aide d'un multimètre et de la matrice, on remarque que chaque led a besoin de 2mA pour fonctionner. Donc le but est de générer un courant d'environ 2mA. Ainsi, si on impose une tension de 5.5V aux bornes du montage, R = 5.5 / 0.002 = 2700 Ohms. 

Nous avons désormais toutes les informations nécessaires pour le montage d'un prototype. 

====Le montage====
Au cours d'une séance supplémentaire, un plan a été élaboré et le prototype brasé. Voici donc le prototype achevé : 

[[Fichier:Driver.JPG||center|400px|Driver matrice|Driver de la matrice]] 

Sur chaque sortie se trouve une résistance de 2700ohms. Le mieux aurait été de réaliser ce montage avec un réseau résistif cependant, le temps nous faisant défaut, nous avons utilisé les résistances déjà présentes en magasin. 
Sur chaque entrée se trouver une broche qui sera reliée à la nanoboard. 
Tous les buffers ont leur GND et VCC reliés au générateur 5.5V. Les paires Darlington sont reliées à la même masse. 

Il ne restait plus qu'à relier la matrice led. Cette liaison parallèle a été réalisée en recyclant un vieux BUS d'ordinateur fixe. Finalement, voilà le montage final : 

[[Fichier:Matrice_roussel.JPG||center|400px|Montage final de la partie électronique|Montage final de la partie électronique]] 

=== Partie informatique ===
=====Arduino=====
Lors de cette séance nous avons pu finir le programme arduino, pour pouvoir jouer à deux sur une la carte.
Cette partie a été crée pour pouvoir tester les différentes fonctions, et sera modifier lors de prochaines séances.
La matrice LED affiche des clignotement irrégulier de couleur rouge, mais cela ne gêne pas pour jouer.

=====Raspberry=====
Nous avons pu enfin commencer notre travail sur la raspberry.
Apres avoir branché la raspberry en série à notre pc, nous avons pu la configurer afin qu'elle fonctionne avec le réseau de l'ecole.
Pour cela nous avons mis une adresse IP du réseau INSECURE de l'école sur la Raspberry, celle de notre raspberry est :172.26.79.12.
C'est à partir de cette adresse que nous allons acceder aux pages html du projet.
Pour effectuer cette configuration nous avons remplacé les lignes correspondant à la configuration de la carte Ethernet dans le fichier /etc/network/interfaces par les lignes
auto eth0
iface eth0 inet static
address 172.26.79.12
netmask 255.255.240.0
gateway 172.26.79.254

Et afin d'indiquer le serveur DNS dans /etc/resolv.conf nous avons rajouté:

nameserver 193.48.57.34

Une fois la raspberry configurée, nous pouvons accéder à notre raspberry sans liaisons série grâce à un ssh.
Afin d'effectuer notre projet nous avons besoin de deux bibliothèques:
*jquery.js que l'ont a telecharger sur http://jquery.com/ afin de faciliter la programmation en javascript
*une bibliothèque C de WebSocket trouvé sur http://libwebsockets.org afin de pouvoir effectuer notre programme en C utilisant le Websocket

Notre raspberry est maintenant prête pour notre projet, nous avons pu commencer notre fichier morpion.html qui permet de joueur au morpion à deux sur le même ordinateur, ce qui permet de tester les differentes fonctions utilisés pour la suite du projet.

== Séance 3 ==

=== Partie électronique ===

Le montage réalisé a été testé. Quelques soudures ont été refaites et un composant ne fonctionnait pas. Heureusement, nous avions placé des socles afin de pouvoir enlever/placer les buffers facilement. 

Cette mise en évidence de composant défaillant a pris beaucoup de temps, c'est pourquoi tout ce qui suit a été réalisé sur plusieurs séances supplémentaires. 

La première chose effectuée fut le branchement de la carte à la nanoboard. Pour cela, nous avons utilisé un plan créé au préalable et un schematic de vérification. 
Ce schematic consistait à afficher colonne par colonne et couleur par couleur chaque led, ainsi, si un branchement était mauvais, nous pouvions le voir directement. 

Le montage finalisé, nous pouvions commencer les tests des fonctions créées en première séance. Sur le principe, ces schematics marchaient plutôt bien mais comme nous souhaitions générer des simulations de données venant de la liaison série, nous n'avions pas assez de boutons pour utiliser ces premières schematics. 

Ainsi, le travail de traitement a dû être refait. 

====La seletion====
L'objectif est de créer un circuit numérique de sélection à l'aide de seulement deux boutons. 
Le choix s'est alors porté sur un compteur allant jusque 8. Ainsi, il y avait 9 possibilités de valeur et chaque valeur correspondra a une case. 
Le compteur devra s'incrémenter sur l'appuie d'un bouton de balayage. 

[[Fichier:Traite.JPG|vignette|center|600px|Selection|Selection]] 

La sélection du joueur physique doit être contrôlée afin que seul un choix valide soit accepté. Ainsi, un schematic de vérification a été créé. 

Pour savoir quelles cases ont déjà été jouées, nous avons décidé d'effectuer un OU logique entre les cases jouées par le joueur physique et les cases jouées par le joueur en ligne. Une fois le bus d'état global créé, il suffit d'effectuer un ET logique avec le choix de notre joueur physique. Si le choix se porte sur une case qui n'a jamais été jouée, le résultat de l'opération logique sera un bus nul. Nous comparons donc ce bus avec un bus nul. 
Finalement, le choix est valide si le comparateur sort une égalité ET le bouton de sélection a été appuyé. 

[[Fichier:Valider_choix.JPG|vignette|center|600px|Valider|Valider]] 

====L'affichage====
Les schematics d'affichage sont restés les mêmes qu'à la séance 1, mis à part quelques corrections tel l'inversion des sorties d'affichage car nous travaillons en logique inversée sur les portes 3 états. 
Le pré-affichage s'occupe toujours du stockage des cases cochées par le joueur physique si il est le joueur courant. 
Afin d'assurer une persistance rétinienne, on devra relier l'affichage à une horloge d'au moins 3KHz. 

[[Fichier:Traitement_preaffichage.JPG|vignette|center|500px|Pre-affichage|Pre-affichage]] [[Fichier:Affich.JPG|vignette|center|500px|Affichage|Affichage]] 

====Simulation de la liaison série====
Le but est de gérer des données semblables à ce que la raspberry pourrait nous envoyer. A savoir 1 bit de fin de partie, 1 bit de réception de donnée et 4 bits de choix de case. 
=====Conversion de l'adresse choisie=====
Il faut faire correspondre les 4 bits reçus à un bus de 9bits, chaque bit correspondant à une case. Ceci revient à faire un traitement similaire à la sélection du joueur physique... 

[[Fichier:Traite_adversaire.JPG|vignette|center|400px|Conversion de l'adresse|Conversion de l'adresse]] 

=====Stockage=====
Maintenant que nous savons convertir une adresse, on doit pouvoir mettre à jour les cases jouées par le joueur en ligne sur chaque réception de donnée. 
Pour effectuer ceci, on utilise 9 bascules pour stocker les choix dans différentes cases. Aucun traitement de choix valide n'est à faire car la raspberry s'en occupe déjà de son côté. 

[[Fichier:Stock_adv.JPG|vignette|center|600px|Stockage des cases de l'adversaire|Stockage des cases de l'adversaire]] 

=====Propre à la simulation=====
Pour générer l'adresse, on utilise le même principe de sélection que celui du joueur physique. 
Pour avoir un aspect visuel de cette sélection, on utilise un MUX qui, en fonction du joueur courant, afficher la sélection de tel ou tel joueur. 

[[Fichier:Traite_sel.JPG|vignette|center|600px|MUX de selection|MUX de la sélection]] 

Pour ce qui est du bit de fin de parti, on le symbolise par un bouton. 

=====Phénomène de rebond=====
Pour gérer le rebond des boutons poussoirs, la solution a été numérique. Un registre à décalage a été créé, cadencé sur une clock, il décale sur chaque front d'horloge la valeur courante d'un bouton. En utilisant un comparateur, on obtient alors un front montant seulement lorsque le bouton est dans un état stable (c'est à dire lorsque tous les bits ont la même valeurs)

[[Fichier:Dump.JPG|vignette|center|600px|Anti-rebond|Anti-rebond]] 

====TOPLEVEL====
Le schéma TOPLEVEL est alors le suivant :

[[Fichier:Toplevel.JPG|vignette|center|800px|TOPLEVEL|TOPLEVEL]] 

Ainsi, si nous avions eu le bloc de liaison série bidirectionnel, nous aurions simplement eu à :
* Remplacer la génération d'adresse par les 4bits de poids faible du message de 8bits reçu.
* Remplacer le bouton de reset par le bit de fin de partie.
* Remplacer le bit de choix de l'adversaire par celui de réception validée.
* Relier le bit d'émission à la sortie de "choix valide".
* Relier la sélection du joueur physique aux données à transmettre.
* Enlever le multiplexage de la sélection.

====Réflexion====
La partie électronique de ce projet a donc été menée à bout. Cependant, après coup, on se rend compte que la création d'un prototype aurait été meilleure en imprimant un PCB plutôt qu'en utilisant une piste à bandes. 
Nous aurions également pu éviter une configuration en parallèle du driver. Ainsi, à l'aide de registres à décalages alimentés en externe, la lisibilité du circuit aurait été meilleure. 
On peut néanmoins se satisfaire de la réalisation numérique du circuit car elle exploite toutes les possibilités qu'offrent la conception via schematics à l'aide d'Altium designer à savoir : 
* La création d'une bibliothèque
* La création de composants
* L'utilisation de composants configurables avec édition de pins 
D'ailleurs, on comprend d'autant plus l'intérêt du langage VHDL après la création d'autant de schematics pour un projet de cette envergure. 

=== Partie informatique ===
Nous avons commencé cette séance en continuant le morpion.html
Dans un premier temps nous avons crée "l'espace de jeu" en utilisant du code trouvé sur internet :
<!DOCTYPE html>
<head>
<meta charset="utf-8">
<style type="text/css">
.table{
width : 330px;
height : 330px;
border : solid 3px black;
border-collapse: collapse;
}
.td{
border : solid 3px black;
width : 33%;
height : 33%;
}
</style>
<title> Jeu morpion</title>
</head>
et
<body>
h1>Morpion</h1>
table class="table" align="center">
<tr>
<td class="td" onclick="placerSigne(0)" id="0"> </td>
<td class="td" onclick="placerSigne(1)" id="1"> </td>
<td class="td" onclick="placerSigne(2)" id="2"> </td>
</tr>
<tr>
<td class="td" onclick="placerSigne(3)" id="3"> </td>
<td class="td" onclick="placerSigne(4)" id="4"> </td>
<td class="td" onclick="placerSigne(5)" id="5"> </td>
</tr>
<tr>
<td class="td" onclick="placerSigne(6)" id="6"> </td>
<td class="td" onclick="placerSigne(7)" id="7"> </td>
<td class="td" onclick="placerSigne(8)" id="8"> </td>
</tr>
</table>
table style="border : solid 3px #3399FF;" align="center">
<tr>
<td style="border : solid 1px #3399FF;">Joueur 1</td>
<td style="border : solid 1px #3399FF;">Joueur 2</td>
</tr>
<tr>
<td style="border : solid 1px #3399FF;" id="scre1">0
</td>
<td style="border : solid 1px #3399FF;" id="scre2">0</td>
</tr>
</table>
</body>
</html>

Le code ci dessus n'est pas totalement bon, puisque nous avons du enlever des "<" afin d'afficher le code et non ce qu'il en résulte.

L'espacement entre deux lignes peut changer en fonction de la taille de ce qui est mis dedans.
Si on remplis de case blanche ("vide.png") de taille 100*100 on obtient:
[[Fichier:morpion1.png]]

A chaque clique sur une case la fonction placerSigne(n) va s'effectuer avec n le numéros de la case sélectionnée.
function placerSigne(idCase)
{
if(morpion[idCase] == 0)
{coup++;
morpion[idCase]=joueur;
if (joueur==1)
{
joueur=2;
document.getElementById(idCase).innerHTML = '<img src="croix.gif" alt="image !" />';

}
else {
joueur=1;
document.getElementById(idCase).innerHTML = '<img src="rond.gif" alt="image !" />';

}
if (coup>4)
{if (gagner(idCase))
{if (joueur==1)
{score2++;
alert("joueur 2 gagne ");
finpartie();
}
else{score1++;
alert("joueur 1 gagne ");
finpartie();
}

}
else {if (egalite()==0)
{alert("egalite");
finpartie();}
}
}
}
else{alert("pas le droit");}
}
Cette fonction place une image 100x100 de rond ou de croix dans la case sélectionnée en fonction du joueur qui doit jouer.
*Elle calcule les scores de chaque joueurs, et appelle gagner et egalite pour savoir si on est dans une fin de partie.
*Et elle alerte le joueur si la case sélectionnée ne peut pas être jouée.

Pour cela elle utilise le tableau morpion de taille 9 remplit de 0 à l'origine, et modifie la case sélectionnée en y mettant 1 ou 2 en fonction du joueur qui a joué.

La variable coup permet de déterminer le nombre de coup jouer, ce qui permet de ne pas verifier si une partie une gagnée tant que coup n'est pas supérieur à 4, puisqu'il faut au minimum 5 coup pour gagner.

function finpartie()
{for (var j=0;j<9;j++)
{ document.getElementById(j).innerHTML = '<img src="vide.png" alt="image !" />';
morpion[j]=0;
}
}

La fonction finpartie() met les variables morpion et coup à zéro, et place des images blanches dans toutes les cases.

Elle est appelé que si il y une victoire ou une égalité.

Dans morpionsc.html qui est le fichier html final, joueur est remis à 1 dans cette fonction.

Dans le fichier morpion.html cela n’étais pas cessionnaire et permettait en plus au joueur perdant de commencer.

Mais pour simplifier la suite nous avons préféré définir que toujours le même joueur commencerais.

function gagner(idCase)
{switch(idCase)
{
case 0:
return (diagonal1()||ligne1()||colonne1());
break;
case 1:
return (ligne1()||colonne2());
break;
case 2:
return (diagonal2()||ligne1()||colonne3());
break;
case 3:
return (ligne2()||colonne1());
break;

case 4:
return (diagonal1()||diagonal2()||ligne2()||colonne2());
break;
case 5:
return (ligne2()||colonne3());
break;
case 6:
return (diagonal2()||ligne3()||colonne1());
break;
case 7:
return (ligne3()||colonne2());
break;
case 8:
return (diagonal1()||ligne3()||colonne3());
break;
}
}
La fonction gagner appelle des fonctions diagonal,ligne,colonne qui retourne 1 si il y'a 3 même symboles sur leur domaines.

Gagner teste donc si il y a une suite de 3 symboles sur la ligne, colonne et les diagonales passant par la case qui a été joué.

function egalite()
{var cp=0;
for (var i=0;i < 9;i++)
{if (morpion[i]==0)
{cp++;}
}
return cp;
}
La fonction egalité teste si toutes les cases ont été joué.

On aurait pu utiliser la variable coup, si coup était égal à 9 alors égalité, mais la fonction egalité permet de vérifier si il n'y a pas eu de problème lors de la modification de la matrice.

Avec morpion.html nous avons pu apprendre le javascript, et poser les bases de notre fichier html final.

===Séances supplémentaires===

====HTML====
Pour le HTML/Javascript on garde les mêmes fonctions gagner et egalite.
On va ajouter lors de l'initialisation
window.WebSocket=(window.WebSocket||window.MozWebSocket);

var websocket=new WebSocket('ws://172.26.79.12:9000','myprotocol');

websocket.onopen=function(){ $('h1').css('color','green'); };

websocket.onerror=function(){ $('h1').css('color','red'); };
On modifie placerSigne:
*si ce n'est pas au tour du joueur 1 de jouer on lui envoie une alerte.
*si il y a une fin de partie on envoie 9 grâce a sendMessage.
*si il n'y a pas de fin de partie on envoie la case jouer toujours grâce à sendMessage:
function sendMessage(data){
websocket.send(data);
}
Pour finpartie on rajoute juste
joueur=1;

Pour faire jouer le second joueur il faut recevoir un message du websocket ainsi :
websocket.onmessage=function(message)
sera la fonction dans laquelle on fera jouer le joueur 2.

Le websocket envoie simplement la case en char* ainsi:
websocket.onmessage=function(message){
idCase=parseInt((message.data)-30);
console.log(idCase);

if(morpion[idCase] == 0)
{coup++;
morpion[idCase]=2;
joueur=1;
document.getElementById(idCase).innerHTML = '<img src="rond.gif" alt="image !" />';
if (coup>4)
{if (gagner(idCase))
{score2++;
alert("joueur 2 gagne ");
finpartie();
sendMessage(9);
}

else {if (egalite()==0)
{alert("egalite");
finpartie();
sendMessage(9);

}
}

}
}

}

Console.log permet d'afficher dans le debug, la valeur traitée.
On envoie toujours 9 si la partie se termine, sinon on effectue la même chose que dans placerSigne de morpion.html

====Fichier C====
Il faut maintenant créer la passerelle entre l'arduino et le fichier html.
Pour cela notre fichier doit utiliser des fonctions de websocket mais aussi de serial.c
Les fonctions de serial.c sont directement intégrées dans notre fichier, il n'y a donc pas besoin de lui faire appel pour compiler.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <fcntl.h>
#include <termios.h>
#include <strings.h>
#include <sys/types.h>
#include <sys/ioctl.h>
#include <sys/file.h>
#include <linux/serial.h>
#include <libwebsockets.h>

#define MAX_FRAME_SIZE 1024
#define WAIT_DELAY 50
#define MAX_MESSAGE 2

#define SERIAL_READ 0
#define SERIAL_WRITE 1
#define SERIAL_BOTH 2

#define SERIAL_DEVICE "/dev/ttyUSB0"

int sd;

//
// Open serial port device
//
int serialOpen(char *device,int mode){
int flags=(mode==SERIAL_READ?O_RDONLY:(mode==SERIAL_WRITE?O_WRONLY:O_RDWR));
int fd=open(device,flags|O_NOCTTY|O_NONBLOCK);
if(fd<0){ perror(device); exit(-1); }
return fd;
}

//
// Serial port configuration
//
void serialConfig(int fd,int speed){
struct termios new;
bzero(&new,sizeof(new));
new.c_cflag=CLOCAL|CREAD|speed|CS8;
new.c_iflag=0;
new.c_oflag=0;
new.c_lflag=0; /* set input mode (non-canonical, no echo,...) */
new.c_cc[VTIME]=0; /* inter-character timer unused */
new.c_cc[VMIN]=1; /* blocking read until 1 char received */
if(tcsetattr(fd,TCSANOW,&new)<0){ perror("serialInit.tcsetattr"); exit(-1); }
}

//
// Serial port termination
//
void serialClose(int fd){
close(fd);
}

static int callback_http(
struct libwebsocket_context *this,
struct libwebsocket *wsi,enum libwebsocket_callback_reasons reason,
void *user,void *in,size_t len)
{
return 0;
}

static struct libwebsocket_protocols protocols[] = {
{
"http-only", // name
callback_http, // callback
0, // data size
0 // maximum frame size
},
{"myprotocol",callback_my,0,MAX_FRAME_SIZE},
{NULL,NULL,0,0}
};

Ci-dessus se trouve le code se trouvant dans serial.c afin de créer serialOpen, serialClose et serialConfig, ainsi que l'initialisation de variables utilisées.

Mais aussi la fonction callback_http(),la structure libwebsocket_protocols, et l'initialisation de variables.

int main(void) {
int port=9000;
struct lws_context_creation_info info;
memset(&info,0,sizeof info);
info.port=port;
info.protocols=protocols;
info.gid=-1;
info.uid=-1;
struct libwebsocket_context *context=libwebsocket_create_context(&info);
if(context==NULL){
fprintf(stderr, "libwebsocket init failed\n");
return -1;
}
printf("starting server...\n");

sd=serialOpen(SERIAL_DEVICE,SERIAL_BOTH);
serialConfig(sd,B9600);

while(1){
libwebsocket_service(context,WAIT_DELAY);
}

serialClose(sd);

libwebsocket_context_destroy(context);
return 0;
}

Le main permet d'initialiser une liaison série de 9600 Baud et de lancer une boucle infini dans laquelle la passerelle entre arduino et html va s'effectuer.

static int callback_my(
struct libwebsocket_context * this,
struct libwebsocket *wsi,enum libwebsocket_callback_reasons reason,
void *user,void *in,size_t len)
{
static char message[2+LWS_SEND_BUFFER_PRE_PADDING+LWS_SEND_BUFFER_POST_PADDING];
static char valeur;
switch(reason){
case LWS_CALLBACK_ESTABLISHED:
printf("connection established\n");
// Declenchement d'un prochain envoi au navigateur
break;
case LWS_CALLBACK_RECEIVE:
// Ici sont traites les messages envoyes par le navigateur
//printf("received data: %s\n",(char *)in);
if(write(sd,in,sizeof(char))!=1){ perror("main.write"); exit(-1); }
printf("writen data: %s\n",(char *)in);
// Declenchement d'un prochain envoi au navigateur
libwebsocket_callback_on_writable(this,wsi);
break;
case LWS_CALLBACK_SERVER_WRITEABLE:
// Ici sont envoyes les messages au navigateur

if (read(sd,&valeur,sizeof(char))==1)
{
//printf("write data: %c\n",valeur);
char *out=message+LWS_SEND_BUFFER_PRE_PADDING;
sprintf(out,"%02x",valeur);
//printf("write data: %s\n",(char *)out);

libwebsocket_write(wsi,(unsigned char *)out,MAX_MESSAGE,LWS_WRITE_TEXT);
}
else{libwebsocket_callback_on_writable(this,wsi);
}
break;
default:
break;
}
return 0;
}

La fonction ci-dessus est celle qui definie la passerelle.

Si elle établit une liaison, elle imprime "connection established".

Une fois la connection établit on se retrouve dans le cas LWS_CALLBACK_RECEIVE si la page html envoie une valeur.

Dans ce cas la valeur pointée par in est écrite dans sd(liaison serie), puis on utilise :
libwebsocket_callback_on_writable(this,wsi);

Qui permet de passer en mode réception de message par la liaison série, qui est definit ici par le cas:
case LWS_CALLBACK_SERVER_WRITEABLE:
Dans ce cas on lit la valeur dans la liaison serie et on la met dans la variable valeur. Si il n'y a rien à lire pour le moment on utilise a nouveau:
libwebsocket_callback_on_writable(this,wsi);
Afin de rester dans le même case.

Si la valeur a été lu on crée out:
char *out=message+LWS_SEND_BUFFER_PRE_PADDING;
avec message :
static char message[2+LWS_SEND_BUFFER_PRE_PADDING+LWS_SEND_BUFFER_POST_PADDING];
out va etre du bon type et de la bonne taille pour pouvoir être envoyer a l'html.
On modife donc la valeur de out grâce à la valeur lue:
sprintf(out,"%02x",valeur);
Puis on l'envoie:
libwebsocket_write(wsi,(unsigned char *)out,MAX_MESSAGE,LWS_WRITE_TEXT);

====Arduino====
Pour l'affichage de la matrice LED nous avons utilisé un exemple trouvé sur le site de SparkFun Electronics:
//Example_RGBMatrix.ino
//By: Ryan Owens @ SparkFun Electronics
//
//modified 27 Oct 2014
//by Bobby Chan @ SparkFun Electronics

Nous avons ensuite crée:

void affichage(int je[3][3])
{
for (int i = 0; i < 3; i++)
{
for (int j = 0; j < 3; j++)
{ if (je[i][j] == 1)
{
color_buffer[0 + i + j * 8] = BLUE;
}
else if (je[i][j] == 2)
{
color_buffer[0 + i + j * 8] = RED;
}
else if (je[i][j] == 5)
{
color_buffer[0 + i + j * 8] = TEAL;
}
else if (je[i][j] == 4)
{
color_buffer[0 + i + j * 8] = GREEN;
}
else if (je[i][j] == 3) {
color_buffer[0 + i + j * 8] = MAGENTA;
}
else if (je[i][j] == 0) {
color_buffer[0 + i + j * 8] = BLACK;
}
}
}
}
Qui change la valeur des buffers sur une matrice 3x3, en fonction d'une matrice donnée en paramètre de taille 3x3.

Il faut ensuite matrix_write(); pour observer les resultats

void go(int joueur)
{if (joueur==2)
{color_buffer[7]=GREEN;}
else{color_buffer[7]=RED;}}
Cette fonction met un buffer vert si le joueur 2 peut jouer sinon rouge, le buffer se trouve en dehors de la zone de jeu et donc ne gène pas l'utilisateur.

Il faut ensuite matrix_write(); pour observer les resultats

void reset(int jeu[3][3])
{ joueur = 0;
color_buffer[7]=RED;
for (int i = 0; i < 3; i++)
{
for (int j = 0; j < 3; j++)
{ jeu[i][j] = 0;
}
}
jeu[0][0] = 1;
}
Cette fonction remet dispose la matrice LED comme lors d'un début de partie.
On aurait pu remettre a zéro certaines variables dans cette fonction.

Une fois ces fonctions crées, il faut crée la fonction loop:
void loop() {
go(joueur);
if (Serial.available() > 0)
{ int a = (Serial.read() - 48);
if (a == 9) {
reset(jeu);
}
else {
if (joueur == 0)
{ int b = (a) / 3;
int c = a - (b) * 3;
jeu[b][c] = 2;
joueur = 2;
if (jeu[0][0] == 2)
{
jeu[0][0] = 3;
}
}
}
}
else {
if (joueur == 2)
{ if (digitalRead(9) == 1)
{ jeu[l][h] = jeu[l][h] - 1;
h = (h + 1) % 3;
jeu[l][h]++;
delay(50);
}
else if (digitalRead(8) == 1)
{
jeu[l][h] = jeu[l][h] - 1;
l = (l + 1) % 3;
jeu[l][h]++;
delay(50);
}
else if (digitalRead(7) == 1)
{
if (jeu[l][h] == 1)
{ jeu[l][h] = 4;
Serial.write((l * 3 + h) + 48);

l = 0;
h = 0;
jeu[l][h] = jeu[l][h] + 1;
joueur = 0;
}
}
}
}

affichage(jeu);
matrix_write();
delay(100);
}
Cette fonction utilise en premier lieu go() pour indiquer au joueur si il peut jouer.
Ensuite il vérifie la liaison série.

On enlève 48 a ce que l'on a reçut, car on reçoit un char et on désire un int.

Ainsi on ajoutera 48 a ce qu'on enverra dans le Serial.write.

Si on reçoit 9, fin de partie.
Sinon on vérifie qui doit jouer et on le fais jouer si on peut ou on attend.

Le Joueur 0 équivaut au joueur 1 pour l'html.

Une fois les coups effectués, on affiche ce qui en résulte et ajoute un delay pour éviter d'appuyer deux fois d'affilée sans le vouloir.

En reliant en série notre arduino en USB à notre raspberry, nous pouvons jouer aux morpions à deux , un sur l'arduino à l'aide de bouton poussoir , et l'autre sur une page html grâce à sa souris.

====Test====
Une fois l'arduino branché en série avec la raspberry, la raspberry connecté en ethernet, et l’exécutable morpion lancé, on peut aller sur 172.26.79.12/morpionsc.html et observer les resultats ci-dessous:
[[Fichier:TestImage2.jpg]]
Le joueur sur la page html doit jouer en premier, ici il a sélectionné la case du milieu,ainsi une croix s'affiche sur la case sur la page html, et un point rouge est affiché sur l'aire de jeu de la matrice.

Maintenant c'est le tour du joueur sur arduino, c'est pourquoi la led tout en bas est de couleur verte, pour avertir le joueur.

Si le joueur sur html essaie de jouer, il verra une alerte "pas ton tour".

La led bleue sert de pointeur pour le joueur sur l'arduino, il va donc déplacer celui-ci afin de jouer, et une fois que la case désiré est pointé, il appuiera sur le bouton sélection pour jouer sur cette case

[[Fichier:ImageTest1.jpg]]
Sur la photo ci-dessus la led tout en bas est passé au rouge, ainsi le joueur arduino a joué.

Il a joué à l'endroit ou se trouve la led verte.

Ainsi sur la page html il y aura un rond au niveau de cette case.

La led bleue est replacé à sa position par défaut.

Tout fonctionne comme prévue.

== Démonstration ==
Présentation de la partie électronique : 

https://youtu.be/2FaJIIrb3Mw

Présentation de la partie informatique : 

https://youtu.be/8ZPqU17tZ9Q

== Conclusion ==

Cette expérience nous a appris à aborder un projet en ayant l'obligation de scinder les tâches. Ainsi, nous devions nous communiquer les informations essentielles afin que les produits finaux des différentes parties soient compatibles. 
Malheureusement, nous n'avons pas pu relier la partie informatique à celle électronique faute de programme de liaison série. Cependant, nous pouvons nous féliciter du fait qu'en simulant la liaison série, via une arduino ou en générant des signaux encodés de la même manière que ceux de la raspberry, tout était opérationnel. 
Finalement, ce projet nous a initié à la spécialité "Système Communicant" de par la création d'un circuit analogique/numérique et l’exploitation des capacités asynchrone d'un websocket.

Fichier:TestImage2.jpg

2016-06-17T21:32:25Z

Tstieven :

Fichier:ImageTest1.jpg

2016-06-17T21:31:50Z

Tstieven :

Projet IMA3 P1, 2015/2016, TD2

2016-06-16T23:14:11Z

Tstieven : /* Complément à la séance 3 */

= Projet IMA3-SC 2015/2016 : MORPION =

== Cahier des charges ==
Notre projet "système communicant" aura pour but de créer une interface connectée du "morpion". L'objectif est de permettre à un joueur interagissant sur un site internet de jouer contre une autre personne qui, elle, jouera à l'aide d'un affichage fait à partir de leds.

Nous cherchons donc à exploiter la capacité asynchrone d'un websocket afin de permettre une partie en temps réel.

=== Matériel ===
* Une nanoboard
* Une raspberry pi
* Une matrice de leds 9x9 ou plus
* Un clavier numérique ou 9 boutons-poussoirs
* Des ordinateurs avec les logiciels de développement nécessaires

=== Optionnel ===
* Un buzzer afin d'avertir le joueur d'un choix incohérent
* Trois afficheurs sept segments afin d'ajouter un tableau des scores

== Séance 1 ==

=== Partie électronique ===
Le but de cette première séance était de se familiariser avec le logiciel de conception Altium Designer et de réfléchir à la façon d'aborder la conception électronique du morpion.

Cette conception se fera en plusieurs étapes :

* gérer le positionnement d'un curseur en fonction de l'état courant de la partie
* gérer l'affichage de la matrice en fonction des cases remplies / sélectionnées
* permettre la réception et l'envoie de données à l'aide de la liaison série
* traiter la remise à zéro du plateau en cas de fin de partie

====Positionnement du curseur et état de la partie====

Dans un premier lieu, il était nécessaire de traiter les actions entrantes. En effet, si ce n'est pas au tour du joueur "physique", l'utilisation des boutons doit être bloquée. 
Ceci consiste simplement à effectuer un ET logique entre un bit symbolisant le joueur courant (si 1 alors joueur physique, si 0 alors joueur en ligne) et l'action demandée. 
[[Fichier:Choisir.png||center|alt=Schema de choix|Circuit logique de la permission d'action]] 

Une fois les choix accessibles, il faut désormais les traiter. Le traitement s'effectuera à l'aide de bascules, chaque case comportera deux bascules : une bascule de sélection (la case est-elle sélectionnée ?) et une bascule permettant de savoir si la case a déjà été jouée. 
Si la case a déjà été jouée, il ne faut empêcher l'utilisateur de la jouer. 
Nous considérerons que le joueur en ligne n'effectuera pas de choix erroné et nous testerons seulement les choix du joueur "physique". 

[[Fichier:Traitement.png||center|alt=Schema de traitement|Circuit logique du traitement d'une action]] 
Les ronds verts permettent la distinction des 9 cases. 
Le rond jaune correspond à la zone des sorties d'état. Plus précisément, il s'agit de deux bus regroupant les cases remplies et le lieu de la case sélectionnée. 
Le rond noir correspond au choix de l'adversaire. 
Le rond orange correspond à la sortie "selection_done" qui effectue un état haut lorsqu'un choix valide a été fait par l'utilisateur. 
Le rond rouge met en évidence la zone permettant de traiter les décalage du bit de sélection. Ce décalage consiste à garder seulement UNE bascule à l'état haut en effectuant le passage logique d'une bascule à une autre en fonction du choix tout en appliquant un reset sur l'ancienne sélection. Le schéma de ce déplacement se trouve ci-dessous et est appliqué aux 9 cases. 

[[Fichier:Andor.png||center|alt=Schema permettant le déplacement|Circuit logique utilisé afin de déplacer le curseur]] 

===Complément à la séance 1===
====Affichage dynamique====

L'un des grands problèmes à la réalisation du morpion sur nanoboard est l'affichage dynamique. En effet, il va falloir à la fois stocker les valeurs, et stocker quel joueur a joué telle ou telle case, afin de savoir quel case s'allumera de la couleur désirée. Ceci rajouté à l'affichage dynamique de la sélection, ceci s'avère compliqué. 
La tâche a alors été décomposée en deux étapes :
* Le traitement des couleurs (Quelle couleur affilier à quelle case ?)
* L'affichage de ces couleurs
=====Traitement des couleurs=====

Le but était de se simplifier au maximum les choses. Le premier problème est de savoir quel joueur a joué une case, pour ceci, nous nous sommes servi de l'état du plateau fourni dans le bloc TRAITEMENT. Nous savons quelles cases sont à 1 et imposons donc une couleur rouge à toutes ces cases. 
De plus, nous savons qu'à chaque fois que le joueur "physique" effectue un choix valide, un front montant est appliqué sur la broche "selection_done" de TRAITEMENT. Nous avons alors re-créé 9 registres symbolisant les cases, mais cette fois ci, en fonction de l'endroit sélectionné par l'utilisateur, si ce dernier effectue un choix valide, le registre passera à 1. Le but de cette manipulation est de recenser tous les registres joués par le joueur physique. 
Maintenant, nous relions ces registres aux valeurs de couleur verte afin d'additionner le vert au rouge des cases jouées et obtiendrons finalement des cases de couleur jaune pour symboliser les cases du joueur physique et des cases de couleur rouge pour le jouer en ligne. 
Il ne reste qu'à relier directement la case sélectionnée (recensée par le bus Etat_selection de TRAITEMENT) à la couleur bleue. 
Finalement nous avons :
* joueur en ligne : rouge
* joueur physique : jaune
* sélection : magenta, cyan ou bleu

[[Fichier:Traitement_affichage.png||center|Schéma du traitement pré affichage|Circuit logique du traitement pré-affichage]] 

=====Affichage=====

La matrice led employée est une matrice led à anode commune. Elle a pour avantage de permettre la sélection d'une ligne et de la couleur de chaque colonne. 
Cependant, nous ne pouvons donc choisir la couleur que d'une colonne. C'est pourquoi nous allons faire varier cet affichage ligne par ligne à une fréquence élevée afin que l’œil humain ne le remarque pas. Nous pourrons donc choisir quelle couleur sera affichée sur chaque ligne. 
Cet affichage ligne par ligne sera effectué via un multiplexeur donc le bus de sélection sera relié à un compteur 3bits cadencé sur une clock suffisamment rapide pour opérer une persistance rétinienne. 
Dans chaque bus nous avons imposé certains bits afin que la grille soit dessinée en bleu. 
Le bus multiplexé sera ensuite redirigé vers les pins de la matrice leds. 

[[Fichier:Affichage.png||center|Schéma d'affichage|Circuit logique de l'affichage]] 

====Tests====

Le bloc d'affichage a été testé et deux problèmes ont été rencontrés :
* La sélection a été mal réfléchie
* Un phénomène de rebond a été remarqué sur l'oscilloscope numérique

=====La sélection=====

Dans la fonction d'affichage, on retourne la sélection de la ligne en logique inversée. Le problème est que dans la version 1.0 de l'affichage, un GND avait été placé en entrée du MUX de sélection. Nous n'avions pas pensé au fait que dans ce cas la, toutes les sorties seraient en permanence au GND... La correction a donc été de placer un VCC en entrée et d'inverser les sorties, ainsi une seul anode de ligne sera placée sur le GND. 

[[Fichier:Selection.PNG||center|Schéma de selection|Correction de la sortie de selection]] 

Le schéma semble fonctionnel cependant d'autres tests restent à faire.

=====Le rebond=====

Lors du test de l'affichage, la clock d'affichage a été simulée par un bouton de la nanoboard et l'affichage a été relié sur une seule ligne. 
Nous étions sensé remarquer que lorsque la ligne s'allume, si on appuie sur le bouton, elle s’éteint et enfin si nous appuyons sept fois sur le bouton, la ligne se rallume. 
Rien ne se passait comme prévu, et plus précisément, il n'y avait même pas de logique dans la ré-apparition de la ligne. 
Ayant déjà été confronté à des problèmes de rebonds avec des boutons poussoir, ce phénomène a été testé sur l'oscilloscope numérique. 

[[Fichier:Rebond.png||center|Exemple de rebond|Exemple de rebond]] 

Nous demanderons alors aux référents quelle stratégie adopter : filtrer le signal avec un condensateur en parallèle au bouton ou bien utiliser une comparaison avec registre à décalage pour vérifier la stabilité du signal avant d'envoie du front montant. 
Certes la correction du bouton n'était pas nécessaire aux tests entrepris pour l'affichage (nous aurions pu mettre une clock interne) mais ceci nous servira pour filtrer les choix effectués par l'utilisateur (haut, droite, select). 

====Objectifs pour la séance prochaine====

Les schémas effectués restent des ébauches, il y a forcément eu des oublis. Néanmoins, comme chaque schéma se compile, le passage à l'étape de mise en place de la liaison série durant la séance 2 est envisageable. Il faudra donc créer un protocole plus concret afin de savoir qui doit jouer, quand envoyer, quand recevoir des données. Si le temps le permet, quelques programmes simples seront testés sur la nanoboard afin de vérifier le fonctionnement de l'affichage de la matrice après discutions avec les enseignants au sujet du phénomène de rebond.

=== Partie informatique ===
Dans cette première séance nous avons programmé l'arduino afin de créer le programme de morpion, pour pouvoir tester la partie informatique sans disposer de la partie électronique.
Pour cela nous avons due apprendre à utiliser une matrice de LED RGB à l'aide des codes fournit par SparkFun.

Puis nous avons pu commencer à programmer le morpion:

*le jeu se déroule dans une matrice 3x3.
*le position du curseur est représentée par une lumière bleue, celle des pions du joueurs 1 par une lumière rouge et celle des pions du joueurs 2 par une lumière verte.
*si le curseur est sur un pions les deux couleurs s'additionnent pour donner du magenta où du cyan.
*le joueur se déplace à l'aide de 2 boutons poussoir,l'un permettant d'aller vers le haut, l'autre permettant d'aller à droite
**pour éviter plusieurs déplacements d'un coup, un délais a été mis entre deux actions
*une fois tout en haut, si le joueur presse le bouton pour aller vers le haut le joueur se retrouve en bas.
*une fois tout à droite, si le joueur presse le bouton pour aller vers la droite le joueur se retrouve à gauche.
*enfin un dernier bouton poussoir permet de placer un pion à l'endroit où se trouve le curseur.

Une fois les mouvements programmés il fallait régir les règles du jeu:

*Ainsi le curseur commence toujours en haut à droite
*Si le un joueurs arrive a créer une ligne de 3, il gagne la partie
*Si aucun joueur n'arrive à gagner et que le terrain est remplit, la partie se termine sur un match nul
*Une fois la partie terminée, le terrain est remis à zéros

Les fonctions permettant les différentes actions ont été décrites dans la partie Arduino de la séance n°3.

== Séance 2 ==

=== Partie électronique ===

La matrice led ne pourra être alimentée par les différentes broches de la nanoboard sous peine de créer une chute de tension et risquer un reset du fpga. 
Ainsi, le but de cet séance est de réfléchir à la conception d'un prototype de carte permettant d'alimenter la matrice led de manière externe. 
====Utilisation de transistors====
L'utilisation de transistors en saturé paraît la meilleur chose à faire. En effet, ceci permettra de générer un gain en courant et de contrôler l'état des différentes couleurs ligne par ligne et colonne par colonne. 
Pour permettra la liaison de chaque led au VCC, on utilisera un transistor PNP. Pour permettre la liaison au GND, on utilisera un NPN. 

[[Fichier:Montage_roussel.PNG||center|upright = 0.5|Montage d'une branche|Montage d'une branche de led]] 

Comme il s'agit de transistor à anodes communes, il suffira de 8 transistors NPN. Notre choix s'est donc porté vers le ULN2803A, qui est un ensemble de 8 paires Darlington. 
L'utilisation de paires Darlington a l'avantage de permettre une génération élevée de courant. (Fort gain en courant) 

Pour ce qui est des cathodes, un problème de taille se pose. Il faudrait 24 transistors PNP pour gérer les 8 colonnes * 3couleurs. Ainsi, notre choix s'est plutôt déporté vers le buffer de portes trois états 74AS240. Cette famille de buffer 3 états a la capacité de délivrer un courant du même ordre de grandeur que l'ULN2803A. 

Maintenant il reste à dimensionner la résistance sur chaque branche. Après quelques tests à l'aide d'un multimètre et de la matrice, on remarque que chaque led a besoin de 2mA pour fonctionner. Donc le but est de générer un courant d'environ 2mA. Ainsi, si on impose une tension de 5.5V aux bornes du montage, R = 5.5 / 0.002 = 2700 Ohms. 

Nous avons désormais toutes les informations nécessaires pour le montage d'un prototype. 

====Le montage====
Au cours d'une séance supplémentaire, un plan a été élaboré et le prototype brasé. Voici donc le prototype achevé : 

[[Fichier:Driver.JPG||center|400px|Driver matrice|Driver de la matrice]] 

Sur chaque sortie se trouve une résistance de 2700ohms. Le mieux aurait été de réaliser ce montage avec un réseau résistif cependant, le temps nous faisant défaut, nous avons utilisé les résistances déjà présentes en magasin. 
Sur chaque entrée se trouver une broche qui sera reliée à la nanoboard. 
Tous les buffers ont leur GND et VCC reliés au générateur 5.5V. Les paires Darlington sont reliées à la même masse. 

Il ne restait plus qu'à relier la matrice led. Cette liaison parallèle a été réalisée en recyclant un vieux BUS d'ordinateur fixe. Finalement, voilà le montage final : 

[[Fichier:Matrice_roussel.JPG||center|400px|Montage final de la partie électronique|Montage final de la partie électronique]] 

=== Partie informatique ===
=====Arduino=====
Lors de cette séance nous avons pu finir le programme arduino, pour pouvoir jouer à deux sur une la carte.
Cette partie a été crée pour pouvoir tester les différentes fonctions, et sera modifier lors de prochaines séances.
La matrice LED affiche des clignotement irrégulier de couleur rouge, mais cela ne gêne pas pour jouer.

=====Raspberry=====
Nous avons pu enfin commencer notre travail sur la raspberry.
Apres avoir branché la raspberry en série à notre pc, nous avons pu la configurer afin qu'elle fonctionne avec le réseau de l'ecole.
Pour cela nous avons mis une adresse IP du réseau INSECURE de l'école sur la Raspberry, celle de notre raspberry est :172.26.79.12.
C'est à partir de cette adresse que nous allons acceder aux pages html du projet.
Pour effectuer cette configuration nous avons remplacé les lignes correspondant à la configuration de la carte Ethernet dans le fichier /etc/network/interfaces par les lignes
auto eth0
iface eth0 inet static
address 172.26.79.12
netmask 255.255.240.0
gateway 172.26.79.254

Et afin d'indiquer le serveur DNS dans /etc/resolv.conf nous avons rajouté:

nameserver 193.48.57.34

Une fois la raspberry configurée, nous pouvons accéder à notre raspberry sans liaisons série grâce à un ssh.
Afin d'effectuer notre projet nous avons besoin de deux bibliothèques:
*jquery.js que l'ont a telecharger sur http://jquery.com/ afin de faciliter la programmation en javascript
*une bibliothèque C de WebSocket trouvé sur http://libwebsockets.org afin de pouvoir effectuer notre programme en C utilisant le Websocket

Notre raspberry est maintenant prête pour notre projet, nous avons pu commencer notre fichier morpion.html qui permet de joueur au morpion à deux sur le même ordinateur, ce qui permet de tester les differentes fonctions utilisés pour la suite du projet.

== Séance 3 ==

=== Partie électronique ===

Le montage réalisé a été testé. Quelques soudures ont été refaites et un composant ne fonctionnait pas. Heureusement, nous avions placé des socles afin de pouvoir enlever/placer les buffers facilement. 

Cette mise en évidence de composant défaillant a pris beaucoup de temps, c'est pourquoi tout ce qui suit a été réalisé sur plusieurs séances supplémentaires. 

La première chose effectuée fut le branchement de la carte à la nanoboard. Pour cela, nous avons utilisé un plan créé au préalable et un schematic de vérification. 
Ce schematic consistait à afficher colonne par colonne et couleur par couleur chaque led, ainsi, si un branchement était mauvais, nous pouvions le voir directement. 

Le montage finalisé, nous pouvions commencer les tests des fonctions créées en première séance. Sur le principe, ces schematics marchaient plutôt bien mais comme nous souhaitions générer des simulations de données venant de la liaison série, nous n'avions pas assez de boutons pour utiliser ces premières schematics. 

Ainsi, le travail de traitement a dû être refait. 

====La seletion====
L'objectif est de créer un circuit numérique de sélection à l'aide de seulement deux boutons. 
Le choix s'est alors porté sur un compteur allant jusque 8. Ainsi, il y avait 9 possibilités de valeur et chaque valeur correspondra a une case. 
Le compteur devra s'incrémenter sur l'appuie d'un bouton de balayage. 

[[Fichier:Traite.JPG|vignette|center|600px|Selection|Selection]] 

La sélection du joueur physique doit être contrôlée afin que seul un choix valide soit accepté. Ainsi, un schematic de vérification a été créé. 

Pour savoir quelles cases ont déjà été jouées, nous avons décidé d'effectuer un OU logique entre les cases jouées par le joueur physique et les cases jouées par le joueur en ligne. Une fois le bus d'état global créé, il suffit d'effectuer un ET logique avec le choix de notre joueur physique. Si le choix se porte sur une case qui n'a jamais été jouée, le résultat de l'opération logique sera un bus nul. Nous comparons donc ce bus avec un bus nul. 
Finalement, le choix est valide si le comparateur sort une égalité ET le bouton de sélection a été appuyé. 

[[Fichier:Valider_choix.JPG|vignette|center|600px|Valider|Valider]] 

====L'affichage====
Les schematics d'affichage sont restés les mêmes qu'à la séance 1, mis à part quelques corrections tel l'inversion des sorties d'affichage car nous travaillons en logique inversée sur les portes 3 états. 
Le pré-affichage s'occupe toujours du stockage des cases cochées par le joueur physique si il est le joueur courant. 
Afin d'assurer une persistance rétinienne, on devra relier l'affichage à une horloge d'au moins 3KHz. 

[[Fichier:Traitement_preaffichage.JPG|vignette|center|500px|Pre-affichage|Pre-affichage]] [[Fichier:Affich.JPG|vignette|center|500px|Affichage|Affichage]] 

====Simulation de la liaison série====
Le but est de gérer des données semblables à ce que la raspberry pourrait nous envoyer. A savoir 1 bit de fin de partie, 1 bit de réception de donnée et 4 bits de choix de case. 
=====Conversion de l'adresse choisie=====
Il faut faire correspondre les 4 bits reçus à un bus de 9bits, chaque bit correspondant à une case. Ceci revient à faire un traitement similaire à la sélection du joueur physique... 

[[Fichier:Traite_adversaire.JPG|vignette|center|400px|Conversion de l'adresse|Conversion de l'adresse]] 

=====Stockage=====
Maintenant que nous savons convertir une adresse, on doit pouvoir mettre à jour les cases jouées par le joueur en ligne sur chaque réception de donnée. 
Pour effectuer ceci, on utilise 9 bascules pour stocker les choix dans différentes cases. Aucun traitement de choix valide n'est à faire car la raspberry s'en occupe déjà de son côté. 

[[Fichier:Stock_adv.JPG|vignette|center|600px|Stockage des cases de l'adversaire|Stockage des cases de l'adversaire]] 

=====Propre à la simulation=====
Pour générer l'adresse, on utilise le même principe de sélection que celui du joueur physique. 
Pour avoir un aspect visuel de cette sélection, on utilise un MUX qui, en fonction du joueur courant, afficher la sélection de tel ou tel joueur. 

[[Fichier:Traite_sel.JPG|vignette|center|600px|MUX de selection|MUX de la sélection]] 

Pour ce qui est du bit de fin de parti, on le symbolise par un bouton. 

=====Phénomène de rebond=====
Pour gérer le rebond des boutons poussoirs, la solution a été numérique. Un registre à décalage a été créé, cadencé sur une clock, il décale sur chaque front d'horloge la valeur courante d'un bouton. En utilisant un comparateur, on obtient alors un front montant seulement lorsque le bouton est dans un état stable (c'est à dire lorsque tous les bits ont la même valeurs)

[[Fichier:Dump.JPG|vignette|center|600px|Anti-rebond|Anti-rebond]] 

====TOPLEVEL====
Le schéma TOPLEVEL est alors le suivant :

[[Fichier:Toplevel.JPG|vignette|center|800px|TOPLEVEL|TOPLEVEL]] 

Ainsi, si nous avions eu le bloc de liaison série bidirectionnel, nous aurions simplement eu à :
* Remplacer la génération d'adresse par les 4bits de poids faible du message de 8bits reçu.
* Remplacer le bouton de reset par le bit de fin de partie.
* Remplacer le bit de choix de l'adversaire par celui de réception validée.
* Relier le bit d'émission à la sortie de "choix valide".
* Relier la sélection du joueur physique aux données à transmettre.
* Enlever le multiplexage de la sélection.

====Réflexion====
La partie électronique de ce projet a donc été menée à bout. Cependant, après coup, on se rend compte que la création d'un prototype aurait été meilleure en imprimant un PCB plutôt qu'en utilisant une piste à bandes. 
Nous aurions également pu éviter une configuration en parallèle du driver. Ainsi, à l'aide de registres à décalages alimentés en externe, la lisibilité du circuit aurait été meilleure. 
On peut néanmoins se satisfaire de la réalisation numérique du circuit car elle exploite toutes les possibilités qu'offrent la conception via schematics à l'aide d'Altium designer à savoir : 
* La création d'une bibliothèque
* La création de composants
* L'utilisation de composants configurables avec édition de pins 
D'ailleurs, on comprend d'autant plus l'intérêt du langage VHDL après la création d'autant de schematics pour un projet de cette envergure. 

=== Partie informatique ===
Nous avons commencé cette séance en continuant le morpion.html
Dans un premier temps nous avons crée "l'espace de jeu" en utilisant du code trouvé sur internet :
<!DOCTYPE html>
<head>
<meta charset="utf-8">
<style type="text/css">
.table{
width : 330px;
height : 330px;
border : solid 3px black;
border-collapse: collapse;
}
.td{
border : solid 3px black;
width : 33%;
height : 33%;
}
</style>
<title> Jeu morpion</title>
</head>
et
<body>
h1>Morpion</h1>
table class="table" align="center">
<tr>
<td class="td" onclick="placerSigne(0)" id="0"> </td>
<td class="td" onclick="placerSigne(1)" id="1"> </td>
<td class="td" onclick="placerSigne(2)" id="2"> </td>
</tr>
<tr>
<td class="td" onclick="placerSigne(3)" id="3"> </td>
<td class="td" onclick="placerSigne(4)" id="4"> </td>
<td class="td" onclick="placerSigne(5)" id="5"> </td>
</tr>
<tr>
<td class="td" onclick="placerSigne(6)" id="6"> </td>
<td class="td" onclick="placerSigne(7)" id="7"> </td>
<td class="td" onclick="placerSigne(8)" id="8"> </td>
</tr>
</table>
table style="border : solid 3px #3399FF;" align="center">
<tr>
<td style="border : solid 1px #3399FF;">Joueur 1</td>
<td style="border : solid 1px #3399FF;">Joueur 2</td>
</tr>
<tr>
<td style="border : solid 1px #3399FF;" id="scre1">0
</td>
<td style="border : solid 1px #3399FF;" id="scre2">0</td>
</tr>
</table>
</body>
</html>

Le code ci dessus n'est pas totalement bon, puisque nous avons du enlever des "<" afin d'afficher le code et non ce qu'il en résulte.

L'espacement entre deux lignes peut changer en fonction de la taille de ce qui est mis dedans.
Si on remplis de case blanche ("vide.png") de taille 100*100 on obtient:
[[Fichier:morpion1.png]]

A chaque clique sur une case la fonction placerSigne(n) va s'effectuer avec n le numéros de la case sélectionnée.
function placerSigne(idCase)
{
if(morpion[idCase] == 0)
{coup++;
morpion[idCase]=joueur;
if (joueur==1)
{
joueur=2;
document.getElementById(idCase).innerHTML = '<img src="croix.gif" alt="image !" />';

}
else {
joueur=1;
document.getElementById(idCase).innerHTML = '<img src="rond.gif" alt="image !" />';

}
if (coup>4)
{if (gagner(idCase))
{if (joueur==1)
{score2++;
alert("joueur 2 gagne ");
finpartie();
}
else{score1++;
alert("joueur 1 gagne ");
finpartie();
}

}
else {if (egalite()==0)
{alert("egalite");
finpartie();}
}
}
}
else{alert("pas le droit");}
}
Cette fonction place une image 100x100 de rond ou de croix dans la case sélectionnée en fonction du joueur qui doit jouer.
*Elle calcule les scores de chaque joueurs, et appelle gagner et egalite pour savoir si on est dans une fin de partie.
*Et elle alerte le joueur si la case sélectionnée ne peut pas être jouée.

Pour cela elle utilise le tableau morpion de taille 9 remplit de 0 à l'origine, et modifie la case sélectionnée en y mettant 1 ou 2 en fonction du joueur qui a joué.

La variable coup permet de déterminer le nombre de coup jouer, ce qui permet de ne pas verifier si une partie une gagnée tant que coup n'est pas supérieur à 4, puisqu'il faut au minimum 5 coup pour gagner.

function finpartie()
{for (var j=0;j<9;j++)
{ document.getElementById(j).innerHTML = '<img src="vide.png" alt="image !" />';
morpion[j]=0;
}
}

La fonction finpartie() met les variables morpion et coup à zéro, et place des images blanches dans toutes les cases.

Elle est appelé que si il y une victoire ou une égalité.

Dans morpionsc.html qui est le fichier html final, joueur est remis à 1 dans cette fonction.

Dans le fichier morpion.html cela n’étais pas cessionnaire et permettait en plus au joueur perdant de commencer.

Mais pour simplifier la suite nous avons préféré définir que toujours le même joueur commencerais.

function gagner(idCase)
{switch(idCase)
{
case 0:
return (diagonal1()||ligne1()||colonne1());
break;
case 1:
return (ligne1()||colonne2());
break;
case 2:
return (diagonal2()||ligne1()||colonne3());
break;
case 3:
return (ligne2()||colonne1());
break;

case 4:
return (diagonal1()||diagonal2()||ligne2()||colonne2());
break;
case 5:
return (ligne2()||colonne3());
break;
case 6:
return (diagonal2()||ligne3()||colonne1());
break;
case 7:
return (ligne3()||colonne2());
break;
case 8:
return (diagonal1()||ligne3()||colonne3());
break;
}
}
La fonction gagner appelle des fonctions diagonal,ligne,colonne qui retourne 1 si il y'a 3 même symboles sur leur domaines.

Gagner teste donc si il y a une suite de 3 symboles sur la ligne, colonne et les diagonales passant par la case qui a été joué.

function egalite()
{var cp=0;
for (var i=0;i < 9;i++)
{if (morpion[i]==0)
{cp++;}
}
return cp;
}
La fonction egalité teste si toutes les cases ont été joué.

On aurait pu utiliser la variable coup, si coup était égal à 9 alors égalité, mais la fonction egalité permet de vérifier si il n'y a pas eu de problème lors de la modification de la matrice.

Avec morpion.html nous avons pu apprendre le javascript, et poser les bases de notre fichier html final.

===Séances supplémentaires===

====HTML====
Pour le HTML/Javascript on garde les mêmes fonctions gagner et egalite.
On va ajouter lors de l'initialisation
window.WebSocket=(window.WebSocket||window.MozWebSocket);

var websocket=new WebSocket('ws://172.26.79.12:9000','myprotocol');

websocket.onopen=function(){ $('h1').css('color','green'); };

websocket.onerror=function(){ $('h1').css('color','red'); };
On modifie placerSigne:
*si ce n'est pas au tour du joueur 1 de jouer on lui envoie une alerte.
*si il y a une fin de partie on envoie 9 grâce a sendMessage.
*si il n'y a pas de fin de partie on envoie la case jouer toujours grâce à sendMessage:
function sendMessage(data){
websocket.send(data);
}
Pour finpartie on rajoute juste
joueur=1;

Pour faire jouer le second joueur il faut recevoir un message du websocket ainsi :
websocket.onmessage=function(message)
sera la fonction dans laquelle on fera jouer le joueur 2.

Le websocket envoie simplement la case en char* ainsi:
websocket.onmessage=function(message){
idCase=parseInt((message.data)-30);
console.log(idCase);

if(morpion[idCase] == 0)
{coup++;
morpion[idCase]=2;
joueur=1;
document.getElementById(idCase).innerHTML = '<img src="rond.gif" alt="image !" />';
if (coup>4)
{if (gagner(idCase))
{score2++;
alert("joueur 2 gagne ");
finpartie();
sendMessage(9);
}

else {if (egalite()==0)
{alert("egalite");
finpartie();
sendMessage(9);

}
}

}
}

}

Console.log permet d'afficher dans le debug, la valeur traitée.
On envoie toujours 9 si la partie se termine, sinon on effectue la même chose que dans placerSigne de morpion.html

====Fichier C====
Il faut maintenant créer la passerelle entre l'arduino et le fichier html.
Pour cela notre fichier doit utiliser des fonctions de websocket mais aussi de serial.c
Les fonctions de serial.c sont directement intégrées dans notre fichier, il n'y a donc pas besoin de lui faire appel pour compiler.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <fcntl.h>
#include <termios.h>
#include <strings.h>
#include <sys/types.h>
#include <sys/ioctl.h>
#include <sys/file.h>
#include <linux/serial.h>
#include <libwebsockets.h>

#define MAX_FRAME_SIZE 1024
#define WAIT_DELAY 50
#define MAX_MESSAGE 2

#define SERIAL_READ 0
#define SERIAL_WRITE 1
#define SERIAL_BOTH 2

#define SERIAL_DEVICE "/dev/ttyUSB0"

int sd;

//
// Open serial port device
//
int serialOpen(char *device,int mode){
int flags=(mode==SERIAL_READ?O_RDONLY:(mode==SERIAL_WRITE?O_WRONLY:O_RDWR));
int fd=open(device,flags|O_NOCTTY|O_NONBLOCK);
if(fd<0){ perror(device); exit(-1); }
return fd;
}

//
// Serial port configuration
//
void serialConfig(int fd,int speed){
struct termios new;
bzero(&new,sizeof(new));
new.c_cflag=CLOCAL|CREAD|speed|CS8;
new.c_iflag=0;
new.c_oflag=0;
new.c_lflag=0; /* set input mode (non-canonical, no echo,...) */
new.c_cc[VTIME]=0; /* inter-character timer unused */
new.c_cc[VMIN]=1; /* blocking read until 1 char received */
if(tcsetattr(fd,TCSANOW,&new)<0){ perror("serialInit.tcsetattr"); exit(-1); }
}

//
// Serial port termination
//
void serialClose(int fd){
close(fd);
}

static int callback_http(
struct libwebsocket_context *this,
struct libwebsocket *wsi,enum libwebsocket_callback_reasons reason,
void *user,void *in,size_t len)
{
return 0;
}

static struct libwebsocket_protocols protocols[] = {
{
"http-only", // name
callback_http, // callback
0, // data size
0 // maximum frame size
},
{"myprotocol",callback_my,0,MAX_FRAME_SIZE},
{NULL,NULL,0,0}
};

Ci-dessus se trouve le code se trouvant dans serial.c afin de créer serialOpen, serialClose et serialConfig, ainsi que l'initialisation de variables utilisées.

Mais aussi la fonction callback_http(),la structure libwebsocket_protocols, et l'initialisation de variables.

int main(void) {
int port=9000;
struct lws_context_creation_info info;
memset(&info,0,sizeof info);
info.port=port;
info.protocols=protocols;
info.gid=-1;
info.uid=-1;
struct libwebsocket_context *context=libwebsocket_create_context(&info);
if(context==NULL){
fprintf(stderr, "libwebsocket init failed\n");
return -1;
}
printf("starting server...\n");

sd=serialOpen(SERIAL_DEVICE,SERIAL_BOTH);
serialConfig(sd,B9600);

while(1){
libwebsocket_service(context,WAIT_DELAY);
}

serialClose(sd);

libwebsocket_context_destroy(context);
return 0;
}

Le main permet d'initialiser une liaison série de 9600 Baud et de lancer une boucle infini dans laquelle la passerelle entre arduino et html va s'effectuer.

static int callback_my(
struct libwebsocket_context * this,
struct libwebsocket *wsi,enum libwebsocket_callback_reasons reason,
void *user,void *in,size_t len)
{
static char message[2+LWS_SEND_BUFFER_PRE_PADDING+LWS_SEND_BUFFER_POST_PADDING];
static char valeur;
switch(reason){
case LWS_CALLBACK_ESTABLISHED:
printf("connection established\n");
// Declenchement d'un prochain envoi au navigateur
break;
case LWS_CALLBACK_RECEIVE:
// Ici sont traites les messages envoyes par le navigateur
//printf("received data: %s\n",(char *)in);
if(write(sd,in,sizeof(char))!=1){ perror("main.write"); exit(-1); }
printf("writen data: %s\n",(char *)in);
// Declenchement d'un prochain envoi au navigateur
libwebsocket_callback_on_writable(this,wsi);
break;
case LWS_CALLBACK_SERVER_WRITEABLE:
// Ici sont envoyes les messages au navigateur

if (read(sd,&valeur,sizeof(char))==1)
{
//printf("write data: %c\n",valeur);
char *out=message+LWS_SEND_BUFFER_PRE_PADDING;
sprintf(out,"%02x",valeur);
//printf("write data: %s\n",(char *)out);

libwebsocket_write(wsi,(unsigned char *)out,MAX_MESSAGE,LWS_WRITE_TEXT);
}
else{libwebsocket_callback_on_writable(this,wsi);
}
break;
default:
break;
}
return 0;
}

La fonction ci-dessus est celle qui definie la passerelle.

Si elle établit une liaison, elle imprime "connection established".

Une fois la connection établit on se retrouve dans le cas LWS_CALLBACK_RECEIVE si la page html envoie une valeur.

Dans ce cas la valeur pointée par in est écrite dans sd(liaison serie), puis on utilise :
libwebsocket_callback_on_writable(this,wsi);

Qui permet de passer en mode réception de message par la liaison série, qui est definit ici par le cas:
case LWS_CALLBACK_SERVER_WRITEABLE:
Dans ce cas on lit la valeur dans la liaison serie et on la met dans la variable valeur. Si il n'y a rien à lire pour le moment on utilise a nouveau:
libwebsocket_callback_on_writable(this,wsi);
Afin de rester dans le même case.

Si la valeur a été lu on crée out:
char *out=message+LWS_SEND_BUFFER_PRE_PADDING;
avec message :
static char message[2+LWS_SEND_BUFFER_PRE_PADDING+LWS_SEND_BUFFER_POST_PADDING];
out va etre du bon type et de la bonne taille pour pouvoir être envoyer a l'html.
On modife donc la valeur de out grâce à la valeur lue:
sprintf(out,"%02x",valeur);
Puis on l'envoie:
libwebsocket_write(wsi,(unsigned char *)out,MAX_MESSAGE,LWS_WRITE_TEXT);

====Arduino====
Pour l'affichage de la matrice LED nous avons utilisé un exemple trouvé sur le site de SparkFun Electronics:
//Example_RGBMatrix.ino
//By: Ryan Owens @ SparkFun Electronics
//
//modified 27 Oct 2014
//by Bobby Chan @ SparkFun Electronics

Nous avons ensuite crée:

void affichage(int je[3][3])
{
for (int i = 0; i < 3; i++)
{
for (int j = 0; j < 3; j++)
{ if (je[i][j] == 1)
{
color_buffer[0 + i + j * 8] = BLUE;
}
else if (je[i][j] == 2)
{
color_buffer[0 + i + j * 8] = RED;
}
else if (je[i][j] == 5)
{
color_buffer[0 + i + j * 8] = TEAL;
}
else if (je[i][j] == 4)
{
color_buffer[0 + i + j * 8] = GREEN;
}
else if (je[i][j] == 3) {
color_buffer[0 + i + j * 8] = MAGENTA;
}
else if (je[i][j] == 0) {
color_buffer[0 + i + j * 8] = BLACK;
}
}
}
}
Qui change la valeur des buffers sur une matrice 3x3, en fonction d'une matrice donnée en paramètre de taille 3x3.

Il faut ensuite matrix_write(); pour observer les resultats

void go(int joueur)
{if (joueur==2)
{color_buffer[7]=GREEN;}
else{color_buffer[7]=RED;}}
Cette fonction met un buffer vert si le joueur 2 peut jouer sinon rouge, le buffer se trouve en dehors de la zone de jeu et donc ne gène pas l'utilisateur.

Il faut ensuite matrix_write(); pour observer les resultats

void reset(int jeu[3][3])
{ joueur = 0;
color_buffer[7]=RED;
for (int i = 0; i < 3; i++)
{
for (int j = 0; j < 3; j++)
{ jeu[i][j] = 0;
}
}
jeu[0][0] = 1;
}
Cette fonction remet dispose la matrice LED comme lors d'un début de partie.
On aurait pu remettre a zéro certaines variables dans cette fonction.

Une fois ces fonctions crées, il faut crée la fonction loop:
void loop() {
go(joueur);
if (Serial.available() > 0)
{ int a = (Serial.read() - 48);
if (a == 9) {
reset(jeu);
}
else {
if (joueur == 0)
{ int b = (a) / 3;
int c = a - (b) * 3;
jeu[b][c] = 2;
joueur = 2;
if (jeu[0][0] == 2)
{
jeu[0][0] = 3;
}
}
}
}
else {
if (joueur == 2)
{ if (digitalRead(9) == 1)
{ jeu[l][h] = jeu[l][h] - 1;
h = (h + 1) % 3;
jeu[l][h]++;
delay(50);
}
else if (digitalRead(8) == 1)
{
jeu[l][h] = jeu[l][h] - 1;
l = (l + 1) % 3;
jeu[l][h]++;
delay(50);
}
else if (digitalRead(7) == 1)
{
if (jeu[l][h] == 1)
{ jeu[l][h] = 4;
Serial.write((l * 3 + h) + 48);

l = 0;
h = 0;
jeu[l][h] = jeu[l][h] + 1;
joueur = 0;
}
}
}
}

affichage(jeu);
matrix_write();
delay(100);
}
Cette fonction utilise en premier lieu go() pour indiquer au joueur si il peut jouer.
Ensuite il vérifie la liaison série.

On enlève 48 a ce que l'on a reçut, car on reçoit un char et on désire un int.

Ainsi on ajoutera 48 a ce qu'on enverra dans le Serial.write.

Si on reçoit 9, fin de partie.
Sinon on vérifie qui doit jouer et on le fais jouer si on peut ou on attend.

Le Joueur 0 équivaut au joueur 1 pour l'html.

Une fois les coups effectués, on affiche ce qui en résulte et ajoute un delay pour éviter d'appuyer deux fois d'affilée sans le vouloir.

En reliant en série notre arduino en USB à notre raspberry, nous pouvons jouer aux morpions à deux , un sur l'arduino à l'aide de bouton poussoir , et l'autre sur une page html grâce à sa souris.

== Démonstration ==

== Conclusion ==

Projet IMA3 P1, 2015/2016, TD2

2016-06-16T23:13:38Z

Tstieven : /* Partie informatique */

= Projet IMA3-SC 2015/2016 : MORPION =

== Cahier des charges ==
Notre projet "système communicant" aura pour but de créer une interface connectée du "morpion". L'objectif est de permettre à un joueur interagissant sur un site internet de jouer contre une autre personne qui, elle, jouera à l'aide d'un affichage fait à partir de leds.

Nous cherchons donc à exploiter la capacité asynchrone d'un websocket afin de permettre une partie en temps réel.

=== Matériel ===
* Une nanoboard
* Une raspberry pi
* Une matrice de leds 9x9 ou plus
* Un clavier numérique ou 9 boutons-poussoirs
* Des ordinateurs avec les logiciels de développement nécessaires

=== Optionnel ===
* Un buzzer afin d'avertir le joueur d'un choix incohérent
* Trois afficheurs sept segments afin d'ajouter un tableau des scores

== Séance 1 ==

=== Partie électronique ===
Le but de cette première séance était de se familiariser avec le logiciel de conception Altium Designer et de réfléchir à la façon d'aborder la conception électronique du morpion.

Cette conception se fera en plusieurs étapes :

* gérer le positionnement d'un curseur en fonction de l'état courant de la partie
* gérer l'affichage de la matrice en fonction des cases remplies / sélectionnées
* permettre la réception et l'envoie de données à l'aide de la liaison série
* traiter la remise à zéro du plateau en cas de fin de partie

====Positionnement du curseur et état de la partie====

Dans un premier lieu, il était nécessaire de traiter les actions entrantes. En effet, si ce n'est pas au tour du joueur "physique", l'utilisation des boutons doit être bloquée. 
Ceci consiste simplement à effectuer un ET logique entre un bit symbolisant le joueur courant (si 1 alors joueur physique, si 0 alors joueur en ligne) et l'action demandée. 
[[Fichier:Choisir.png||center|alt=Schema de choix|Circuit logique de la permission d'action]] 

Une fois les choix accessibles, il faut désormais les traiter. Le traitement s'effectuera à l'aide de bascules, chaque case comportera deux bascules : une bascule de sélection (la case est-elle sélectionnée ?) et une bascule permettant de savoir si la case a déjà été jouée. 
Si la case a déjà été jouée, il ne faut empêcher l'utilisateur de la jouer. 
Nous considérerons que le joueur en ligne n'effectuera pas de choix erroné et nous testerons seulement les choix du joueur "physique". 

[[Fichier:Traitement.png||center|alt=Schema de traitement|Circuit logique du traitement d'une action]] 
Les ronds verts permettent la distinction des 9 cases. 
Le rond jaune correspond à la zone des sorties d'état. Plus précisément, il s'agit de deux bus regroupant les cases remplies et le lieu de la case sélectionnée. 
Le rond noir correspond au choix de l'adversaire. 
Le rond orange correspond à la sortie "selection_done" qui effectue un état haut lorsqu'un choix valide a été fait par l'utilisateur. 
Le rond rouge met en évidence la zone permettant de traiter les décalage du bit de sélection. Ce décalage consiste à garder seulement UNE bascule à l'état haut en effectuant le passage logique d'une bascule à une autre en fonction du choix tout en appliquant un reset sur l'ancienne sélection. Le schéma de ce déplacement se trouve ci-dessous et est appliqué aux 9 cases. 

[[Fichier:Andor.png||center|alt=Schema permettant le déplacement|Circuit logique utilisé afin de déplacer le curseur]] 

===Complément à la séance 1===
====Affichage dynamique====

L'un des grands problèmes à la réalisation du morpion sur nanoboard est l'affichage dynamique. En effet, il va falloir à la fois stocker les valeurs, et stocker quel joueur a joué telle ou telle case, afin de savoir quel case s'allumera de la couleur désirée. Ceci rajouté à l'affichage dynamique de la sélection, ceci s'avère compliqué. 
La tâche a alors été décomposée en deux étapes :
* Le traitement des couleurs (Quelle couleur affilier à quelle case ?)
* L'affichage de ces couleurs
=====Traitement des couleurs=====

Le but était de se simplifier au maximum les choses. Le premier problème est de savoir quel joueur a joué une case, pour ceci, nous nous sommes servi de l'état du plateau fourni dans le bloc TRAITEMENT. Nous savons quelles cases sont à 1 et imposons donc une couleur rouge à toutes ces cases. 
De plus, nous savons qu'à chaque fois que le joueur "physique" effectue un choix valide, un front montant est appliqué sur la broche "selection_done" de TRAITEMENT. Nous avons alors re-créé 9 registres symbolisant les cases, mais cette fois ci, en fonction de l'endroit sélectionné par l'utilisateur, si ce dernier effectue un choix valide, le registre passera à 1. Le but de cette manipulation est de recenser tous les registres joués par le joueur physique. 
Maintenant, nous relions ces registres aux valeurs de couleur verte afin d'additionner le vert au rouge des cases jouées et obtiendrons finalement des cases de couleur jaune pour symboliser les cases du joueur physique et des cases de couleur rouge pour le jouer en ligne. 
Il ne reste qu'à relier directement la case sélectionnée (recensée par le bus Etat_selection de TRAITEMENT) à la couleur bleue. 
Finalement nous avons :
* joueur en ligne : rouge
* joueur physique : jaune
* sélection : magenta, cyan ou bleu

[[Fichier:Traitement_affichage.png||center|Schéma du traitement pré affichage|Circuit logique du traitement pré-affichage]] 

=====Affichage=====

La matrice led employée est une matrice led à anode commune. Elle a pour avantage de permettre la sélection d'une ligne et de la couleur de chaque colonne. 
Cependant, nous ne pouvons donc choisir la couleur que d'une colonne. C'est pourquoi nous allons faire varier cet affichage ligne par ligne à une fréquence élevée afin que l’œil humain ne le remarque pas. Nous pourrons donc choisir quelle couleur sera affichée sur chaque ligne. 
Cet affichage ligne par ligne sera effectué via un multiplexeur donc le bus de sélection sera relié à un compteur 3bits cadencé sur une clock suffisamment rapide pour opérer une persistance rétinienne. 
Dans chaque bus nous avons imposé certains bits afin que la grille soit dessinée en bleu. 
Le bus multiplexé sera ensuite redirigé vers les pins de la matrice leds. 

[[Fichier:Affichage.png||center|Schéma d'affichage|Circuit logique de l'affichage]] 

====Tests====

Le bloc d'affichage a été testé et deux problèmes ont été rencontrés :
* La sélection a été mal réfléchie
* Un phénomène de rebond a été remarqué sur l'oscilloscope numérique

=====La sélection=====

Dans la fonction d'affichage, on retourne la sélection de la ligne en logique inversée. Le problème est que dans la version 1.0 de l'affichage, un GND avait été placé en entrée du MUX de sélection. Nous n'avions pas pensé au fait que dans ce cas la, toutes les sorties seraient en permanence au GND... La correction a donc été de placer un VCC en entrée et d'inverser les sorties, ainsi une seul anode de ligne sera placée sur le GND. 

[[Fichier:Selection.PNG||center|Schéma de selection|Correction de la sortie de selection]] 

Le schéma semble fonctionnel cependant d'autres tests restent à faire.

=====Le rebond=====

Lors du test de l'affichage, la clock d'affichage a été simulée par un bouton de la nanoboard et l'affichage a été relié sur une seule ligne. 
Nous étions sensé remarquer que lorsque la ligne s'allume, si on appuie sur le bouton, elle s’éteint et enfin si nous appuyons sept fois sur le bouton, la ligne se rallume. 
Rien ne se passait comme prévu, et plus précisément, il n'y avait même pas de logique dans la ré-apparition de la ligne. 
Ayant déjà été confronté à des problèmes de rebonds avec des boutons poussoir, ce phénomène a été testé sur l'oscilloscope numérique. 

[[Fichier:Rebond.png||center|Exemple de rebond|Exemple de rebond]] 

Nous demanderons alors aux référents quelle stratégie adopter : filtrer le signal avec un condensateur en parallèle au bouton ou bien utiliser une comparaison avec registre à décalage pour vérifier la stabilité du signal avant d'envoie du front montant. 
Certes la correction du bouton n'était pas nécessaire aux tests entrepris pour l'affichage (nous aurions pu mettre une clock interne) mais ceci nous servira pour filtrer les choix effectués par l'utilisateur (haut, droite, select). 

====Objectifs pour la séance prochaine====

Les schémas effectués restent des ébauches, il y a forcément eu des oublis. Néanmoins, comme chaque schéma se compile, le passage à l'étape de mise en place de la liaison série durant la séance 2 est envisageable. Il faudra donc créer un protocole plus concret afin de savoir qui doit jouer, quand envoyer, quand recevoir des données. Si le temps le permet, quelques programmes simples seront testés sur la nanoboard afin de vérifier le fonctionnement de l'affichage de la matrice après discutions avec les enseignants au sujet du phénomène de rebond.

=== Partie informatique ===
Dans cette première séance nous avons programmé l'arduino afin de créer le programme de morpion, pour pouvoir tester la partie informatique sans disposer de la partie électronique.
Pour cela nous avons due apprendre à utiliser une matrice de LED RGB à l'aide des codes fournit par SparkFun.

Puis nous avons pu commencer à programmer le morpion:

*le jeu se déroule dans une matrice 3x3.
*le position du curseur est représentée par une lumière bleue, celle des pions du joueurs 1 par une lumière rouge et celle des pions du joueurs 2 par une lumière verte.
*si le curseur est sur un pions les deux couleurs s'additionnent pour donner du magenta où du cyan.
*le joueur se déplace à l'aide de 2 boutons poussoir,l'un permettant d'aller vers le haut, l'autre permettant d'aller à droite
**pour éviter plusieurs déplacements d'un coup, un délais a été mis entre deux actions
*une fois tout en haut, si le joueur presse le bouton pour aller vers le haut le joueur se retrouve en bas.
*une fois tout à droite, si le joueur presse le bouton pour aller vers la droite le joueur se retrouve à gauche.
*enfin un dernier bouton poussoir permet de placer un pion à l'endroit où se trouve le curseur.

Une fois les mouvements programmés il fallait régir les règles du jeu:

*Ainsi le curseur commence toujours en haut à droite
*Si le un joueurs arrive a créer une ligne de 3, il gagne la partie
*Si aucun joueur n'arrive à gagner et que le terrain est remplit, la partie se termine sur un match nul
*Une fois la partie terminée, le terrain est remis à zéros

Les fonctions permettant les différentes actions ont été décrites dans la partie Arduino de la séance n°3.

== Séance 2 ==

=== Partie électronique ===

La matrice led ne pourra être alimentée par les différentes broches de la nanoboard sous peine de créer une chute de tension et risquer un reset du fpga. 
Ainsi, le but de cet séance est de réfléchir à la conception d'un prototype de carte permettant d'alimenter la matrice led de manière externe. 
====Utilisation de transistors====
L'utilisation de transistors en saturé paraît la meilleur chose à faire. En effet, ceci permettra de générer un gain en courant et de contrôler l'état des différentes couleurs ligne par ligne et colonne par colonne. 
Pour permettra la liaison de chaque led au VCC, on utilisera un transistor PNP. Pour permettre la liaison au GND, on utilisera un NPN. 

[[Fichier:Montage_roussel.PNG||center|upright = 0.5|Montage d'une branche|Montage d'une branche de led]] 

Comme il s'agit de transistor à anodes communes, il suffira de 8 transistors NPN. Notre choix s'est donc porté vers le ULN2803A, qui est un ensemble de 8 paires Darlington. 
L'utilisation de paires Darlington a l'avantage de permettre une génération élevée de courant. (Fort gain en courant) 

Pour ce qui est des cathodes, un problème de taille se pose. Il faudrait 24 transistors PNP pour gérer les 8 colonnes * 3couleurs. Ainsi, notre choix s'est plutôt déporté vers le buffer de portes trois états 74AS240. Cette famille de buffer 3 états a la capacité de délivrer un courant du même ordre de grandeur que l'ULN2803A. 

Maintenant il reste à dimensionner la résistance sur chaque branche. Après quelques tests à l'aide d'un multimètre et de la matrice, on remarque que chaque led a besoin de 2mA pour fonctionner. Donc le but est de générer un courant d'environ 2mA. Ainsi, si on impose une tension de 5.5V aux bornes du montage, R = 5.5 / 0.002 = 2700 Ohms. 

Nous avons désormais toutes les informations nécessaires pour le montage d'un prototype. 

====Le montage====
Au cours d'une séance supplémentaire, un plan a été élaboré et le prototype brasé. Voici donc le prototype achevé : 

[[Fichier:Driver.JPG||center|400px|Driver matrice|Driver de la matrice]] 

Sur chaque sortie se trouve une résistance de 2700ohms. Le mieux aurait été de réaliser ce montage avec un réseau résistif cependant, le temps nous faisant défaut, nous avons utilisé les résistances déjà présentes en magasin. 
Sur chaque entrée se trouver une broche qui sera reliée à la nanoboard. 
Tous les buffers ont leur GND et VCC reliés au générateur 5.5V. Les paires Darlington sont reliées à la même masse. 

Il ne restait plus qu'à relier la matrice led. Cette liaison parallèle a été réalisée en recyclant un vieux BUS d'ordinateur fixe. Finalement, voilà le montage final : 

[[Fichier:Matrice_roussel.JPG||center|400px|Montage final de la partie électronique|Montage final de la partie électronique]] 

=== Partie informatique ===
=====Arduino=====
Lors de cette séance nous avons pu finir le programme arduino, pour pouvoir jouer à deux sur une la carte.
Cette partie a été crée pour pouvoir tester les différentes fonctions, et sera modifier lors de prochaines séances.
La matrice LED affiche des clignotement irrégulier de couleur rouge, mais cela ne gêne pas pour jouer.

=====Raspberry=====
Nous avons pu enfin commencer notre travail sur la raspberry.
Apres avoir branché la raspberry en série à notre pc, nous avons pu la configurer afin qu'elle fonctionne avec le réseau de l'ecole.
Pour cela nous avons mis une adresse IP du réseau INSECURE de l'école sur la Raspberry, celle de notre raspberry est :172.26.79.12.
C'est à partir de cette adresse que nous allons acceder aux pages html du projet.
Pour effectuer cette configuration nous avons remplacé les lignes correspondant à la configuration de la carte Ethernet dans le fichier /etc/network/interfaces par les lignes
auto eth0
iface eth0 inet static
address 172.26.79.12
netmask 255.255.240.0
gateway 172.26.79.254

Et afin d'indiquer le serveur DNS dans /etc/resolv.conf nous avons rajouté:

nameserver 193.48.57.34

Une fois la raspberry configurée, nous pouvons accéder à notre raspberry sans liaisons série grâce à un ssh.
Afin d'effectuer notre projet nous avons besoin de deux bibliothèques:
*jquery.js que l'ont a telecharger sur http://jquery.com/ afin de faciliter la programmation en javascript
*une bibliothèque C de WebSocket trouvé sur http://libwebsockets.org afin de pouvoir effectuer notre programme en C utilisant le Websocket

Notre raspberry est maintenant prête pour notre projet, nous avons pu commencer notre fichier morpion.html qui permet de joueur au morpion à deux sur le même ordinateur, ce qui permet de tester les differentes fonctions utilisés pour la suite du projet.

== Séance 3 ==

=== Partie électronique ===

Le montage réalisé a été testé. Quelques soudures ont été refaites et un composant ne fonctionnait pas. Heureusement, nous avions placé des socles afin de pouvoir enlever/placer les buffers facilement. 

Cette mise en évidence de composant défaillant a pris beaucoup de temps, c'est pourquoi tout ce qui suit a été réalisé sur plusieurs séances supplémentaires. 

La première chose effectuée fut le branchement de la carte à la nanoboard. Pour cela, nous avons utilisé un plan créé au préalable et un schematic de vérification. 
Ce schematic consistait à afficher colonne par colonne et couleur par couleur chaque led, ainsi, si un branchement était mauvais, nous pouvions le voir directement. 

Le montage finalisé, nous pouvions commencer les tests des fonctions créées en première séance. Sur le principe, ces schematics marchaient plutôt bien mais comme nous souhaitions générer des simulations de données venant de la liaison série, nous n'avions pas assez de boutons pour utiliser ces premières schematics. 

Ainsi, le travail de traitement a dû être refait. 

====La seletion====
L'objectif est de créer un circuit numérique de sélection à l'aide de seulement deux boutons. 
Le choix s'est alors porté sur un compteur allant jusque 8. Ainsi, il y avait 9 possibilités de valeur et chaque valeur correspondra a une case. 
Le compteur devra s'incrémenter sur l'appuie d'un bouton de balayage. 

[[Fichier:Traite.JPG|vignette|center|600px|Selection|Selection]] 

La sélection du joueur physique doit être contrôlée afin que seul un choix valide soit accepté. Ainsi, un schematic de vérification a été créé. 

Pour savoir quelles cases ont déjà été jouées, nous avons décidé d'effectuer un OU logique entre les cases jouées par le joueur physique et les cases jouées par le joueur en ligne. Une fois le bus d'état global créé, il suffit d'effectuer un ET logique avec le choix de notre joueur physique. Si le choix se porte sur une case qui n'a jamais été jouée, le résultat de l'opération logique sera un bus nul. Nous comparons donc ce bus avec un bus nul. 
Finalement, le choix est valide si le comparateur sort une égalité ET le bouton de sélection a été appuyé. 

[[Fichier:Valider_choix.JPG|vignette|center|600px|Valider|Valider]] 

====L'affichage====
Les schematics d'affichage sont restés les mêmes qu'à la séance 1, mis à part quelques corrections tel l'inversion des sorties d'affichage car nous travaillons en logique inversée sur les portes 3 états. 
Le pré-affichage s'occupe toujours du stockage des cases cochées par le joueur physique si il est le joueur courant. 
Afin d'assurer une persistance rétinienne, on devra relier l'affichage à une horloge d'au moins 3KHz. 

[[Fichier:Traitement_preaffichage.JPG|vignette|center|500px|Pre-affichage|Pre-affichage]] [[Fichier:Affich.JPG|vignette|center|500px|Affichage|Affichage]] 

====Simulation de la liaison série====
Le but est de gérer des données semblables à ce que la raspberry pourrait nous envoyer. A savoir 1 bit de fin de partie, 1 bit de réception de donnée et 4 bits de choix de case. 
=====Conversion de l'adresse choisie=====
Il faut faire correspondre les 4 bits reçus à un bus de 9bits, chaque bit correspondant à une case. Ceci revient à faire un traitement similaire à la sélection du joueur physique... 

[[Fichier:Traite_adversaire.JPG|vignette|center|400px|Conversion de l'adresse|Conversion de l'adresse]] 

=====Stockage=====
Maintenant que nous savons convertir une adresse, on doit pouvoir mettre à jour les cases jouées par le joueur en ligne sur chaque réception de donnée. 
Pour effectuer ceci, on utilise 9 bascules pour stocker les choix dans différentes cases. Aucun traitement de choix valide n'est à faire car la raspberry s'en occupe déjà de son côté. 

[[Fichier:Stock_adv.JPG|vignette|center|600px|Stockage des cases de l'adversaire|Stockage des cases de l'adversaire]] 

=====Propre à la simulation=====
Pour générer l'adresse, on utilise le même principe de sélection que celui du joueur physique. 
Pour avoir un aspect visuel de cette sélection, on utilise un MUX qui, en fonction du joueur courant, afficher la sélection de tel ou tel joueur. 

[[Fichier:Traite_sel.JPG|vignette|center|600px|MUX de selection|MUX de la sélection]] 

Pour ce qui est du bit de fin de parti, on le symbolise par un bouton. 

=====Phénomène de rebond=====
Pour gérer le rebond des boutons poussoirs, la solution a été numérique. Un registre à décalage a été créé, cadencé sur une clock, il décale sur chaque front d'horloge la valeur courante d'un bouton. En utilisant un comparateur, on obtient alors un front montant seulement lorsque le bouton est dans un état stable (c'est à dire lorsque tous les bits ont la même valeurs)

[[Fichier:Dump.JPG|vignette|center|600px|Anti-rebond|Anti-rebond]] 

====TOPLEVEL====
Le schéma TOPLEVEL est alors le suivant :

[[Fichier:Toplevel.JPG|vignette|center|800px|TOPLEVEL|TOPLEVEL]] 

Ainsi, si nous avions eu le bloc de liaison série bidirectionnel, nous aurions simplement eu à :
* Remplacer la génération d'adresse par les 4bits de poids faible du message de 8bits reçu.
* Remplacer le bouton de reset par le bit de fin de partie.
* Remplacer le bit de choix de l'adversaire par celui de réception validée.
* Relier le bit d'émission à la sortie de "choix valide".
* Relier la sélection du joueur physique aux données à transmettre.
* Enlever le multiplexage de la sélection.

====Réflexion====
La partie électronique de ce projet a donc été menée à bout. Cependant, après coup, on se rend compte que la création d'un prototype aurait été meilleure en imprimant un PCB plutôt qu'en utilisant une piste à bandes. 
Nous aurions également pu éviter une configuration en parallèle du driver. Ainsi, à l'aide de registres à décalages alimentés en externe, la lisibilité du circuit aurait été meilleure. 
On peut néanmoins se satisfaire de la réalisation numérique du circuit car elle exploite toutes les possibilités qu'offrent la conception via schematics à l'aide d'Altium designer à savoir : 
* La création d'une bibliothèque
* La création de composants
* L'utilisation de composants configurables avec édition de pins 
D'ailleurs, on comprend d'autant plus l'intérêt du langage VHDL après la création d'autant de schematics pour un projet de cette envergure. 

=== Partie informatique ===
Nous avons commencé cette séance en continuant le morpion.html
Dans un premier temps nous avons crée "l'espace de jeu" en utilisant du code trouvé sur internet :
<!DOCTYPE html>
<head>
<meta charset="utf-8">
<style type="text/css">
.table{
width : 330px;
height : 330px;
border : solid 3px black;
border-collapse: collapse;
}
.td{
border : solid 3px black;
width : 33%;
height : 33%;
}
</style>
<title> Jeu morpion</title>
</head>
et
<body>
h1>Morpion</h1>
table class="table" align="center">
<tr>
<td class="td" onclick="placerSigne(0)" id="0"> </td>
<td class="td" onclick="placerSigne(1)" id="1"> </td>
<td class="td" onclick="placerSigne(2)" id="2"> </td>
</tr>
<tr>
<td class="td" onclick="placerSigne(3)" id="3"> </td>
<td class="td" onclick="placerSigne(4)" id="4"> </td>
<td class="td" onclick="placerSigne(5)" id="5"> </td>
</tr>
<tr>
<td class="td" onclick="placerSigne(6)" id="6"> </td>
<td class="td" onclick="placerSigne(7)" id="7"> </td>
<td class="td" onclick="placerSigne(8)" id="8"> </td>
</tr>
</table>
table style="border : solid 3px #3399FF;" align="center">
<tr>
<td style="border : solid 1px #3399FF;">Joueur 1</td>
<td style="border : solid 1px #3399FF;">Joueur 2</td>
</tr>
<tr>
<td style="border : solid 1px #3399FF;" id="scre1">0
</td>
<td style="border : solid 1px #3399FF;" id="scre2">0</td>
</tr>
</table>
</body>
</html>

Le code ci dessus n'est pas totalement bon, puisque nous avons du enlever des "<" afin d'afficher le code et non ce qu'il en résulte.

L'espacement entre deux lignes peut changer en fonction de la taille de ce qui est mis dedans.
Si on remplis de case blanche ("vide.png") de taille 100*100 on obtient:
[[Fichier:morpion1.png]]

A chaque clique sur une case la fonction placerSigne(n) va s'effectuer avec n le numéros de la case sélectionnée.
function placerSigne(idCase)
{
if(morpion[idCase] == 0)
{coup++;
morpion[idCase]=joueur;
if (joueur==1)
{
joueur=2;
document.getElementById(idCase).innerHTML = '<img src="croix.gif" alt="image !" />';

}
else {
joueur=1;
document.getElementById(idCase).innerHTML = '<img src="rond.gif" alt="image !" />';

}
if (coup>4)
{if (gagner(idCase))
{if (joueur==1)
{score2++;
alert("joueur 2 gagne ");
finpartie();
}
else{score1++;
alert("joueur 1 gagne ");
finpartie();
}

}
else {if (egalite()==0)
{alert("egalite");
finpartie();}
}
}
}
else{alert("pas le droit");}
}
Cette fonction place une image 100x100 de rond ou de croix dans la case sélectionnée en fonction du joueur qui doit jouer.
*Elle calcule les scores de chaque joueurs, et appelle gagner et egalite pour savoir si on est dans une fin de partie.
*Et elle alerte le joueur si la case sélectionnée ne peut pas être jouée.

Pour cela elle utilise le tableau morpion de taille 9 remplit de 0 à l'origine, et modifie la case sélectionnée en y mettant 1 ou 2 en fonction du joueur qui a joué.

La variable coup permet de déterminer le nombre de coup jouer, ce qui permet de ne pas verifier si une partie une gagnée tant que coup n'est pas supérieur à 4, puisqu'il faut au minimum 5 coup pour gagner.

function finpartie()
{for (var j=0;j<9;j++)
{ document.getElementById(j).innerHTML = '<img src="vide.png" alt="image !" />';
morpion[j]=0;
}
}

La fonction finpartie() met les variables morpion et coup à zéro, et place des images blanches dans toutes les cases.

Elle est appelé que si il y une victoire ou une égalité.

Dans morpionsc.html qui est le fichier html final, joueur est remis à 1 dans cette fonction.

Dans le fichier morpion.html cela n’étais pas cessionnaire et permettait en plus au joueur perdant de commencer.

Mais pour simplifier la suite nous avons préféré définir que toujours le même joueur commencerais.

function gagner(idCase)
{switch(idCase)
{
case 0:
return (diagonal1()||ligne1()||colonne1());
break;
case 1:
return (ligne1()||colonne2());
break;
case 2:
return (diagonal2()||ligne1()||colonne3());
break;
case 3:
return (ligne2()||colonne1());
break;

case 4:
return (diagonal1()||diagonal2()||ligne2()||colonne2());
break;
case 5:
return (ligne2()||colonne3());
break;
case 6:
return (diagonal2()||ligne3()||colonne1());
break;
case 7:
return (ligne3()||colonne2());
break;
case 8:
return (diagonal1()||ligne3()||colonne3());
break;
}
}
La fonction gagner appelle des fonctions diagonal,ligne,colonne qui retourne 1 si il y'a 3 même symboles sur leur domaines.

Gagner teste donc si il y a une suite de 3 symboles sur la ligne, colonne et les diagonales passant par la case qui a été joué.

function egalite()
{var cp=0;
for (var i=0;i < 9;i++)
{if (morpion[i]==0)
{cp++;}
}
return cp;
}
La fonction egalité teste si toutes les cases ont été joué.

On aurait pu utiliser la variable coup, si coup était égal à 9 alors égalité, mais la fonction egalité permet de vérifier si il n'y a pas eu de problème lors de la modification de la matrice.

Avec morpion.html nous avons pu apprendre le javascript, et poser les bases de notre fichier html final.

===Complément à la séance 3===

====HTML====
Pour le HTML/Javascript on garde les mêmes fonctions gagner et egalite.
On va ajouter lors de l'initialisation
window.WebSocket=(window.WebSocket||window.MozWebSocket);

var websocket=new WebSocket('ws://172.26.79.12:9000','myprotocol');

websocket.onopen=function(){ $('h1').css('color','green'); };

websocket.onerror=function(){ $('h1').css('color','red'); };
On modifie placerSigne:
*si ce n'est pas au tour du joueur 1 de jouer on lui envoie une alerte.
*si il y a une fin de partie on envoie 9 grâce a sendMessage.
*si il n'y a pas de fin de partie on envoie la case jouer toujours grâce à sendMessage:
function sendMessage(data){
websocket.send(data);
}
Pour finpartie on rajoute juste
joueur=1;

Pour faire jouer le second joueur il faut recevoir un message du websocket ainsi :
websocket.onmessage=function(message)
sera la fonction dans laquelle on fera jouer le joueur 2.

Le websocket envoie simplement la case en char* ainsi:
websocket.onmessage=function(message){
idCase=parseInt((message.data)-30);
console.log(idCase);

if(morpion[idCase] == 0)
{coup++;
morpion[idCase]=2;
joueur=1;
document.getElementById(idCase).innerHTML = '<img src="rond.gif" alt="image !" />';
if (coup>4)
{if (gagner(idCase))
{score2++;
alert("joueur 2 gagne ");
finpartie();
sendMessage(9);
}

else {if (egalite()==0)
{alert("egalite");
finpartie();
sendMessage(9);

}
}

}
}

}

Console.log permet d'afficher dans le debug, la valeur traitée.
On envoie toujours 9 si la partie se termine, sinon on effectue la même chose que dans placerSigne de morpion.html

====Fichier C====
Il faut maintenant créer la passerelle entre l'arduino et le fichier html.
Pour cela notre fichier doit utiliser des fonctions de websocket mais aussi de serial.c
Les fonctions de serial.c sont directement intégrées dans notre fichier, il n'y a donc pas besoin de lui faire appel pour compiler.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <fcntl.h>
#include <termios.h>
#include <strings.h>
#include <sys/types.h>
#include <sys/ioctl.h>
#include <sys/file.h>
#include <linux/serial.h>
#include <libwebsockets.h>

#define MAX_FRAME_SIZE 1024
#define WAIT_DELAY 50
#define MAX_MESSAGE 2

#define SERIAL_READ 0
#define SERIAL_WRITE 1
#define SERIAL_BOTH 2

#define SERIAL_DEVICE "/dev/ttyUSB0"

int sd;

//
// Open serial port device
//
int serialOpen(char *device,int mode){
int flags=(mode==SERIAL_READ?O_RDONLY:(mode==SERIAL_WRITE?O_WRONLY:O_RDWR));
int fd=open(device,flags|O_NOCTTY|O_NONBLOCK);
if(fd<0){ perror(device); exit(-1); }
return fd;
}

//
// Serial port configuration
//
void serialConfig(int fd,int speed){
struct termios new;
bzero(&new,sizeof(new));
new.c_cflag=CLOCAL|CREAD|speed|CS8;
new.c_iflag=0;
new.c_oflag=0;
new.c_lflag=0; /* set input mode (non-canonical, no echo,...) */
new.c_cc[VTIME]=0; /* inter-character timer unused */
new.c_cc[VMIN]=1; /* blocking read until 1 char received */
if(tcsetattr(fd,TCSANOW,&new)<0){ perror("serialInit.tcsetattr"); exit(-1); }
}

//
// Serial port termination
//
void serialClose(int fd){
close(fd);
}

static int callback_http(
struct libwebsocket_context *this,
struct libwebsocket *wsi,enum libwebsocket_callback_reasons reason,
void *user,void *in,size_t len)
{
return 0;
}

static struct libwebsocket_protocols protocols[] = {
{
"http-only", // name
callback_http, // callback
0, // data size
0 // maximum frame size
},
{"myprotocol",callback_my,0,MAX_FRAME_SIZE},
{NULL,NULL,0,0}
};

Ci-dessus se trouve le code se trouvant dans serial.c afin de créer serialOpen, serialClose et serialConfig, ainsi que l'initialisation de variables utilisées.

Mais aussi la fonction callback_http(),la structure libwebsocket_protocols, et l'initialisation de variables.

int main(void) {
int port=9000;
struct lws_context_creation_info info;
memset(&info,0,sizeof info);
info.port=port;
info.protocols=protocols;
info.gid=-1;
info.uid=-1;
struct libwebsocket_context *context=libwebsocket_create_context(&info);
if(context==NULL){
fprintf(stderr, "libwebsocket init failed\n");
return -1;
}
printf("starting server...\n");

sd=serialOpen(SERIAL_DEVICE,SERIAL_BOTH);
serialConfig(sd,B9600);

while(1){
libwebsocket_service(context,WAIT_DELAY);
}

serialClose(sd);

libwebsocket_context_destroy(context);
return 0;
}

Le main permet d'initialiser une liaison série de 9600 Baud et de lancer une boucle infini dans laquelle la passerelle entre arduino et html va s'effectuer.

static int callback_my(
struct libwebsocket_context * this,
struct libwebsocket *wsi,enum libwebsocket_callback_reasons reason,
void *user,void *in,size_t len)
{
static char message[2+LWS_SEND_BUFFER_PRE_PADDING+LWS_SEND_BUFFER_POST_PADDING];
static char valeur;
switch(reason){
case LWS_CALLBACK_ESTABLISHED:
printf("connection established\n");
// Declenchement d'un prochain envoi au navigateur
break;
case LWS_CALLBACK_RECEIVE:
// Ici sont traites les messages envoyes par le navigateur
//printf("received data: %s\n",(char *)in);
if(write(sd,in,sizeof(char))!=1){ perror("main.write"); exit(-1); }
printf("writen data: %s\n",(char *)in);
// Declenchement d'un prochain envoi au navigateur
libwebsocket_callback_on_writable(this,wsi);
break;
case LWS_CALLBACK_SERVER_WRITEABLE:
// Ici sont envoyes les messages au navigateur

if (read(sd,&valeur,sizeof(char))==1)
{
//printf("write data: %c\n",valeur);
char *out=message+LWS_SEND_BUFFER_PRE_PADDING;
sprintf(out,"%02x",valeur);
//printf("write data: %s\n",(char *)out);

libwebsocket_write(wsi,(unsigned char *)out,MAX_MESSAGE,LWS_WRITE_TEXT);
}
else{libwebsocket_callback_on_writable(this,wsi);
}
break;
default:
break;
}
return 0;
}

La fonction ci-dessus est celle qui definie la passerelle.

Si elle établit une liaison, elle imprime "connection established".

Une fois la connection établit on se retrouve dans le cas LWS_CALLBACK_RECEIVE si la page html envoie une valeur.

Dans ce cas la valeur pointée par in est écrite dans sd(liaison serie), puis on utilise :
libwebsocket_callback_on_writable(this,wsi);

Qui permet de passer en mode réception de message par la liaison série, qui est definit ici par le cas:
case LWS_CALLBACK_SERVER_WRITEABLE:
Dans ce cas on lit la valeur dans la liaison serie et on la met dans la variable valeur. Si il n'y a rien à lire pour le moment on utilise a nouveau:
libwebsocket_callback_on_writable(this,wsi);
Afin de rester dans le même case.

Si la valeur a été lu on crée out:
char *out=message+LWS_SEND_BUFFER_PRE_PADDING;
avec message :
static char message[2+LWS_SEND_BUFFER_PRE_PADDING+LWS_SEND_BUFFER_POST_PADDING];
out va etre du bon type et de la bonne taille pour pouvoir être envoyer a l'html.
On modife donc la valeur de out grâce à la valeur lue:
sprintf(out,"%02x",valeur);
Puis on l'envoie:
libwebsocket_write(wsi,(unsigned char *)out,MAX_MESSAGE,LWS_WRITE_TEXT);

====Arduino====
Pour l'affichage de la matrice LED nous avons utilisé un exemple trouvé sur le site de SparkFun Electronics:
//Example_RGBMatrix.ino
//By: Ryan Owens @ SparkFun Electronics
//
//modified 27 Oct 2014
//by Bobby Chan @ SparkFun Electronics

Nous avons ensuite crée:

void affichage(int je[3][3])
{
for (int i = 0; i < 3; i++)
{
for (int j = 0; j < 3; j++)
{ if (je[i][j] == 1)
{
color_buffer[0 + i + j * 8] = BLUE;
}
else if (je[i][j] == 2)
{
color_buffer[0 + i + j * 8] = RED;
}
else if (je[i][j] == 5)
{
color_buffer[0 + i + j * 8] = TEAL;
}
else if (je[i][j] == 4)
{
color_buffer[0 + i + j * 8] = GREEN;
}
else if (je[i][j] == 3) {
color_buffer[0 + i + j * 8] = MAGENTA;
}
else if (je[i][j] == 0) {
color_buffer[0 + i + j * 8] = BLACK;
}
}
}
}
Qui change la valeur des buffers sur une matrice 3x3, en fonction d'une matrice donnée en paramètre de taille 3x3.

Il faut ensuite matrix_write(); pour observer les resultats

void go(int joueur)
{if (joueur==2)
{color_buffer[7]=GREEN;}
else{color_buffer[7]=RED;}}
Cette fonction met un buffer vert si le joueur 2 peut jouer sinon rouge, le buffer se trouve en dehors de la zone de jeu et donc ne gène pas l'utilisateur.

Il faut ensuite matrix_write(); pour observer les resultats

void reset(int jeu[3][3])
{ joueur = 0;
color_buffer[7]=RED;
for (int i = 0; i < 3; i++)
{
for (int j = 0; j < 3; j++)
{ jeu[i][j] = 0;
}
}
jeu[0][0] = 1;
}
Cette fonction remet dispose la matrice LED comme lors d'un début de partie.
On aurait pu remettre a zéro certaines variables dans cette fonction.

Une fois ces fonctions crées, il faut crée la fonction loop:
void loop() {
go(joueur);
if (Serial.available() > 0)
{ int a = (Serial.read() - 48);
if (a == 9) {
reset(jeu);
}
else {
if (joueur == 0)
{ int b = (a) / 3;
int c = a - (b) * 3;
jeu[b][c] = 2;
joueur = 2;
if (jeu[0][0] == 2)
{
jeu[0][0] = 3;
}
}
}
}
else {
if (joueur == 2)
{ if (digitalRead(9) == 1)
{ jeu[l][h] = jeu[l][h] - 1;
h = (h + 1) % 3;
jeu[l][h]++;
delay(50);
}
else if (digitalRead(8) == 1)
{
jeu[l][h] = jeu[l][h] - 1;
l = (l + 1) % 3;
jeu[l][h]++;
delay(50);
}
else if (digitalRead(7) == 1)
{
if (jeu[l][h] == 1)
{ jeu[l][h] = 4;
Serial.write((l * 3 + h) + 48);

l = 0;
h = 0;
jeu[l][h] = jeu[l][h] + 1;
joueur = 0;
}
}
}
}

affichage(jeu);
matrix_write();
delay(100);
}
Cette fonction utilise en premier lieu go() pour indiquer au joueur si il peut jouer.
Ensuite il vérifie la liaison série.

On enlève 48 a ce que l'on a reçut, car on reçoit un char et on désire un int.

Ainsi on ajoutera 48 a ce qu'on enverra dans le Serial.write.

Si on reçoit 9, fin de partie.
Sinon on vérifie qui doit jouer et on le fais jouer si on peut ou on attend.

Le Joueur 0 équivaut au joueur 1 pour l'html.

Une fois les coups effectués, on affiche ce qui en résulte et ajoute un delay pour éviter d'appuyer deux fois d'affilée sans le vouloir.

En reliant en série notre arduino en USB à notre raspberry, nous pouvons jouer aux morpions à deux , un sur l'arduino à l'aide de bouton poussoir , et l'autre sur une page html grâce à sa souris.

== Démonstration ==

== Conclusion ==

Projet IMA3 P1, 2015/2016, TD2

2016-06-16T23:12:15Z

Tstieven : /* Arduino */

= Projet IMA3-SC 2015/2016 : MORPION =

== Cahier des charges ==
Notre projet "système communicant" aura pour but de créer une interface connectée du "morpion". L'objectif est de permettre à un joueur interagissant sur un site internet de jouer contre une autre personne qui, elle, jouera à l'aide d'un affichage fait à partir de leds.

Nous cherchons donc à exploiter la capacité asynchrone d'un websocket afin de permettre une partie en temps réel.

=== Matériel ===
* Une nanoboard
* Une raspberry pi
* Une matrice de leds 9x9 ou plus
* Un clavier numérique ou 9 boutons-poussoirs
* Des ordinateurs avec les logiciels de développement nécessaires

=== Optionnel ===
* Un buzzer afin d'avertir le joueur d'un choix incohérent
* Trois afficheurs sept segments afin d'ajouter un tableau des scores

== Séance 1 ==

=== Partie électronique ===
Le but de cette première séance était de se familiariser avec le logiciel de conception Altium Designer et de réfléchir à la façon d'aborder la conception électronique du morpion.

Cette conception se fera en plusieurs étapes :

* gérer le positionnement d'un curseur en fonction de l'état courant de la partie
* gérer l'affichage de la matrice en fonction des cases remplies / sélectionnées
* permettre la réception et l'envoie de données à l'aide de la liaison série
* traiter la remise à zéro du plateau en cas de fin de partie

====Positionnement du curseur et état de la partie====

Dans un premier lieu, il était nécessaire de traiter les actions entrantes. En effet, si ce n'est pas au tour du joueur "physique", l'utilisation des boutons doit être bloquée. 
Ceci consiste simplement à effectuer un ET logique entre un bit symbolisant le joueur courant (si 1 alors joueur physique, si 0 alors joueur en ligne) et l'action demandée. 
[[Fichier:Choisir.png||center|alt=Schema de choix|Circuit logique de la permission d'action]] 

Une fois les choix accessibles, il faut désormais les traiter. Le traitement s'effectuera à l'aide de bascules, chaque case comportera deux bascules : une bascule de sélection (la case est-elle sélectionnée ?) et une bascule permettant de savoir si la case a déjà été jouée. 
Si la case a déjà été jouée, il ne faut empêcher l'utilisateur de la jouer. 
Nous considérerons que le joueur en ligne n'effectuera pas de choix erroné et nous testerons seulement les choix du joueur "physique". 

[[Fichier:Traitement.png||center|alt=Schema de traitement|Circuit logique du traitement d'une action]] 
Les ronds verts permettent la distinction des 9 cases. 
Le rond jaune correspond à la zone des sorties d'état. Plus précisément, il s'agit de deux bus regroupant les cases remplies et le lieu de la case sélectionnée. 
Le rond noir correspond au choix de l'adversaire. 
Le rond orange correspond à la sortie "selection_done" qui effectue un état haut lorsqu'un choix valide a été fait par l'utilisateur. 
Le rond rouge met en évidence la zone permettant de traiter les décalage du bit de sélection. Ce décalage consiste à garder seulement UNE bascule à l'état haut en effectuant le passage logique d'une bascule à une autre en fonction du choix tout en appliquant un reset sur l'ancienne sélection. Le schéma de ce déplacement se trouve ci-dessous et est appliqué aux 9 cases. 

[[Fichier:Andor.png||center|alt=Schema permettant le déplacement|Circuit logique utilisé afin de déplacer le curseur]] 

===Complément à la séance 1===
====Affichage dynamique====

L'un des grands problèmes à la réalisation du morpion sur nanoboard est l'affichage dynamique. En effet, il va falloir à la fois stocker les valeurs, et stocker quel joueur a joué telle ou telle case, afin de savoir quel case s'allumera de la couleur désirée. Ceci rajouté à l'affichage dynamique de la sélection, ceci s'avère compliqué. 
La tâche a alors été décomposée en deux étapes :
* Le traitement des couleurs (Quelle couleur affilier à quelle case ?)
* L'affichage de ces couleurs
=====Traitement des couleurs=====

Le but était de se simplifier au maximum les choses. Le premier problème est de savoir quel joueur a joué une case, pour ceci, nous nous sommes servi de l'état du plateau fourni dans le bloc TRAITEMENT. Nous savons quelles cases sont à 1 et imposons donc une couleur rouge à toutes ces cases. 
De plus, nous savons qu'à chaque fois que le joueur "physique" effectue un choix valide, un front montant est appliqué sur la broche "selection_done" de TRAITEMENT. Nous avons alors re-créé 9 registres symbolisant les cases, mais cette fois ci, en fonction de l'endroit sélectionné par l'utilisateur, si ce dernier effectue un choix valide, le registre passera à 1. Le but de cette manipulation est de recenser tous les registres joués par le joueur physique. 
Maintenant, nous relions ces registres aux valeurs de couleur verte afin d'additionner le vert au rouge des cases jouées et obtiendrons finalement des cases de couleur jaune pour symboliser les cases du joueur physique et des cases de couleur rouge pour le jouer en ligne. 
Il ne reste qu'à relier directement la case sélectionnée (recensée par le bus Etat_selection de TRAITEMENT) à la couleur bleue. 
Finalement nous avons :
* joueur en ligne : rouge
* joueur physique : jaune
* sélection : magenta, cyan ou bleu

[[Fichier:Traitement_affichage.png||center|Schéma du traitement pré affichage|Circuit logique du traitement pré-affichage]] 

=====Affichage=====

La matrice led employée est une matrice led à anode commune. Elle a pour avantage de permettre la sélection d'une ligne et de la couleur de chaque colonne. 
Cependant, nous ne pouvons donc choisir la couleur que d'une colonne. C'est pourquoi nous allons faire varier cet affichage ligne par ligne à une fréquence élevée afin que l’œil humain ne le remarque pas. Nous pourrons donc choisir quelle couleur sera affichée sur chaque ligne. 
Cet affichage ligne par ligne sera effectué via un multiplexeur donc le bus de sélection sera relié à un compteur 3bits cadencé sur une clock suffisamment rapide pour opérer une persistance rétinienne. 
Dans chaque bus nous avons imposé certains bits afin que la grille soit dessinée en bleu. 
Le bus multiplexé sera ensuite redirigé vers les pins de la matrice leds. 

[[Fichier:Affichage.png||center|Schéma d'affichage|Circuit logique de l'affichage]] 

====Tests====

Le bloc d'affichage a été testé et deux problèmes ont été rencontrés :
* La sélection a été mal réfléchie
* Un phénomène de rebond a été remarqué sur l'oscilloscope numérique

=====La sélection=====

Dans la fonction d'affichage, on retourne la sélection de la ligne en logique inversée. Le problème est que dans la version 1.0 de l'affichage, un GND avait été placé en entrée du MUX de sélection. Nous n'avions pas pensé au fait que dans ce cas la, toutes les sorties seraient en permanence au GND... La correction a donc été de placer un VCC en entrée et d'inverser les sorties, ainsi une seul anode de ligne sera placée sur le GND. 

[[Fichier:Selection.PNG||center|Schéma de selection|Correction de la sortie de selection]] 

Le schéma semble fonctionnel cependant d'autres tests restent à faire.

=====Le rebond=====

Lors du test de l'affichage, la clock d'affichage a été simulée par un bouton de la nanoboard et l'affichage a été relié sur une seule ligne. 
Nous étions sensé remarquer que lorsque la ligne s'allume, si on appuie sur le bouton, elle s’éteint et enfin si nous appuyons sept fois sur le bouton, la ligne se rallume. 
Rien ne se passait comme prévu, et plus précisément, il n'y avait même pas de logique dans la ré-apparition de la ligne. 
Ayant déjà été confronté à des problèmes de rebonds avec des boutons poussoir, ce phénomène a été testé sur l'oscilloscope numérique. 

[[Fichier:Rebond.png||center|Exemple de rebond|Exemple de rebond]] 

Nous demanderons alors aux référents quelle stratégie adopter : filtrer le signal avec un condensateur en parallèle au bouton ou bien utiliser une comparaison avec registre à décalage pour vérifier la stabilité du signal avant d'envoie du front montant. 
Certes la correction du bouton n'était pas nécessaire aux tests entrepris pour l'affichage (nous aurions pu mettre une clock interne) mais ceci nous servira pour filtrer les choix effectués par l'utilisateur (haut, droite, select). 

====Objectifs pour la séance prochaine====

Les schémas effectués restent des ébauches, il y a forcément eu des oublis. Néanmoins, comme chaque schéma se compile, le passage à l'étape de mise en place de la liaison série durant la séance 2 est envisageable. Il faudra donc créer un protocole plus concret afin de savoir qui doit jouer, quand envoyer, quand recevoir des données. Si le temps le permet, quelques programmes simples seront testés sur la nanoboard afin de vérifier le fonctionnement de l'affichage de la matrice après discutions avec les enseignants au sujet du phénomène de rebond.

=== Partie informatique ===
Dans cette première séance nous avons programmé l'arduino afin de créer le programme de morpion, pour pouvoir tester la partie informatique sans disposer de la partie électronique.
Pour cela nous avons due apprendre à utiliser une matrice de LED RGB à l'aide des codes fournit par SparkFun.

Puis nous avons pu commencer à programmer le morpion:

*le jeu se déroule dans une matrice 3x3.
*le position du curseur est représentée par une lumière bleue, celle des pions du joueurs 1 par une lumière rouge et celle des pions du joueurs 2 par une lumière verte.
*si le curseur est sur un pions les deux couleurs s'additionnent pour donner du magenta où du cyan.
*le joueur se déplace à l'aide de 2 boutons poussoir,l'un permettant d'aller vers le haut, l'autre permettant d'aller à droite
**pour éviter plusieurs déplacements d'un coup, un délais a été mis entre deux actions
*une fois tout en haut, si le joueur presse le bouton pour aller vers le haut le joueur se retrouve en bas.
*une fois tout à droite, si le joueur presse le bouton pour aller vers la droite le joueur se retrouve à gauche.
*enfin un dernier bouton poussoir permet de placer un pion à l'endroit où se trouve le curseur.

Une fois les mouvements programmés il fallait régir les règles du jeu:

*Ainsi le curseur commence toujours en haut à droite
*Si le un joueurs arrive a créer une ligne de 3, il gagne la partie
*Si aucun joueur n'arrive à gagner et que le terrain est remplit, la partie se termine sur un match nul
*Une fois la partie terminée, le terrain est remis à zéros

== Séance 2 ==

=== Partie électronique ===

La matrice led ne pourra être alimentée par les différentes broches de la nanoboard sous peine de créer une chute de tension et risquer un reset du fpga. 
Ainsi, le but de cet séance est de réfléchir à la conception d'un prototype de carte permettant d'alimenter la matrice led de manière externe. 
====Utilisation de transistors====
L'utilisation de transistors en saturé paraît la meilleur chose à faire. En effet, ceci permettra de générer un gain en courant et de contrôler l'état des différentes couleurs ligne par ligne et colonne par colonne. 
Pour permettra la liaison de chaque led au VCC, on utilisera un transistor PNP. Pour permettre la liaison au GND, on utilisera un NPN. 

[[Fichier:Montage_roussel.PNG||center|upright = 0.5|Montage d'une branche|Montage d'une branche de led]] 

Comme il s'agit de transistor à anodes communes, il suffira de 8 transistors NPN. Notre choix s'est donc porté vers le ULN2803A, qui est un ensemble de 8 paires Darlington. 
L'utilisation de paires Darlington a l'avantage de permettre une génération élevée de courant. (Fort gain en courant) 

Pour ce qui est des cathodes, un problème de taille se pose. Il faudrait 24 transistors PNP pour gérer les 8 colonnes * 3couleurs. Ainsi, notre choix s'est plutôt déporté vers le buffer de portes trois états 74AS240. Cette famille de buffer 3 états a la capacité de délivrer un courant du même ordre de grandeur que l'ULN2803A. 

Maintenant il reste à dimensionner la résistance sur chaque branche. Après quelques tests à l'aide d'un multimètre et de la matrice, on remarque que chaque led a besoin de 2mA pour fonctionner. Donc le but est de générer un courant d'environ 2mA. Ainsi, si on impose une tension de 5.5V aux bornes du montage, R = 5.5 / 0.002 = 2700 Ohms. 

Nous avons désormais toutes les informations nécessaires pour le montage d'un prototype. 

====Le montage====
Au cours d'une séance supplémentaire, un plan a été élaboré et le prototype brasé. Voici donc le prototype achevé : 

[[Fichier:Driver.JPG||center|400px|Driver matrice|Driver de la matrice]] 

Sur chaque sortie se trouve une résistance de 2700ohms. Le mieux aurait été de réaliser ce montage avec un réseau résistif cependant, le temps nous faisant défaut, nous avons utilisé les résistances déjà présentes en magasin. 
Sur chaque entrée se trouver une broche qui sera reliée à la nanoboard. 
Tous les buffers ont leur GND et VCC reliés au générateur 5.5V. Les paires Darlington sont reliées à la même masse. 

Il ne restait plus qu'à relier la matrice led. Cette liaison parallèle a été réalisée en recyclant un vieux BUS d'ordinateur fixe. Finalement, voilà le montage final : 

[[Fichier:Matrice_roussel.JPG||center|400px|Montage final de la partie électronique|Montage final de la partie électronique]] 

=== Partie informatique ===
=====Arduino=====
Lors de cette séance nous avons pu finir le programme arduino, pour pouvoir jouer à deux sur une la carte.
Cette partie a été crée pour pouvoir tester les différentes fonctions, et sera modifier lors de prochaines séances.
La matrice LED affiche des clignotement irrégulier de couleur rouge, mais cela ne gêne pas pour jouer.

=====Raspberry=====
Nous avons pu enfin commencer notre travail sur la raspberry.
Apres avoir branché la raspberry en série à notre pc, nous avons pu la configurer afin qu'elle fonctionne avec le réseau de l'ecole.
Pour cela nous avons mis une adresse IP du réseau INSECURE de l'école sur la Raspberry, celle de notre raspberry est :172.26.79.12.
C'est à partir de cette adresse que nous allons acceder aux pages html du projet.
Pour effectuer cette configuration nous avons remplacé les lignes correspondant à la configuration de la carte Ethernet dans le fichier /etc/network/interfaces par les lignes
auto eth0
iface eth0 inet static
address 172.26.79.12
netmask 255.255.240.0
gateway 172.26.79.254

Et afin d'indiquer le serveur DNS dans /etc/resolv.conf nous avons rajouté:

nameserver 193.48.57.34

Une fois la raspberry configurée, nous pouvons accéder à notre raspberry sans liaisons série grâce à un ssh.
Afin d'effectuer notre projet nous avons besoin de deux bibliothèques:
*jquery.js que l'ont a telecharger sur http://jquery.com/ afin de faciliter la programmation en javascript
*une bibliothèque C de WebSocket trouvé sur http://libwebsockets.org afin de pouvoir effectuer notre programme en C utilisant le Websocket

Notre raspberry est maintenant prête pour notre projet, nous avons pu commencer notre fichier morpion.html qui permet de joueur au morpion à deux sur le même ordinateur, ce qui permet de tester les differentes fonctions utilisés pour la suite du projet.

== Séance 3 ==

=== Partie électronique ===

Le montage réalisé a été testé. Quelques soudures ont été refaites et un composant ne fonctionnait pas. Heureusement, nous avions placé des socles afin de pouvoir enlever/placer les buffers facilement. 

Cette mise en évidence de composant défaillant a pris beaucoup de temps, c'est pourquoi tout ce qui suit a été réalisé sur plusieurs séances supplémentaires. 

La première chose effectuée fut le branchement de la carte à la nanoboard. Pour cela, nous avons utilisé un plan créé au préalable et un schematic de vérification. 
Ce schematic consistait à afficher colonne par colonne et couleur par couleur chaque led, ainsi, si un branchement était mauvais, nous pouvions le voir directement. 

Le montage finalisé, nous pouvions commencer les tests des fonctions créées en première séance. Sur le principe, ces schematics marchaient plutôt bien mais comme nous souhaitions générer des simulations de données venant de la liaison série, nous n'avions pas assez de boutons pour utiliser ces premières schematics. 

Ainsi, le travail de traitement a dû être refait. 

====La seletion====
L'objectif est de créer un circuit numérique de sélection à l'aide de seulement deux boutons. 
Le choix s'est alors porté sur un compteur allant jusque 8. Ainsi, il y avait 9 possibilités de valeur et chaque valeur correspondra a une case. 
Le compteur devra s'incrémenter sur l'appuie d'un bouton de balayage. 

[[Fichier:Traite.JPG|vignette|center|600px|Selection|Selection]] 

La sélection du joueur physique doit être contrôlée afin que seul un choix valide soit accepté. Ainsi, un schematic de vérification a été créé. 

Pour savoir quelles cases ont déjà été jouées, nous avons décidé d'effectuer un OU logique entre les cases jouées par le joueur physique et les cases jouées par le joueur en ligne. Une fois le bus d'état global créé, il suffit d'effectuer un ET logique avec le choix de notre joueur physique. Si le choix se porte sur une case qui n'a jamais été jouée, le résultat de l'opération logique sera un bus nul. Nous comparons donc ce bus avec un bus nul. 
Finalement, le choix est valide si le comparateur sort une égalité ET le bouton de sélection a été appuyé. 

[[Fichier:Valider_choix.JPG|vignette|center|600px|Valider|Valider]] 

====L'affichage====
Les schematics d'affichage sont restés les mêmes qu'à la séance 1, mis à part quelques corrections tel l'inversion des sorties d'affichage car nous travaillons en logique inversée sur les portes 3 états. 
Le pré-affichage s'occupe toujours du stockage des cases cochées par le joueur physique si il est le joueur courant. 
Afin d'assurer une persistance rétinienne, on devra relier l'affichage à une horloge d'au moins 3KHz. 

[[Fichier:Traitement_preaffichage.JPG|vignette|center|500px|Pre-affichage|Pre-affichage]] [[Fichier:Affich.JPG|vignette|center|500px|Affichage|Affichage]] 

====Simulation de la liaison série====
Le but est de gérer des données semblables à ce que la raspberry pourrait nous envoyer. A savoir 1 bit de fin de partie, 1 bit de réception de donnée et 4 bits de choix de case. 
=====Conversion de l'adresse choisie=====
Il faut faire correspondre les 4 bits reçus à un bus de 9bits, chaque bit correspondant à une case. Ceci revient à faire un traitement similaire à la sélection du joueur physique... 

[[Fichier:Traite_adversaire.JPG|vignette|center|400px|Conversion de l'adresse|Conversion de l'adresse]] 

=====Stockage=====
Maintenant que nous savons convertir une adresse, on doit pouvoir mettre à jour les cases jouées par le joueur en ligne sur chaque réception de donnée. 
Pour effectuer ceci, on utilise 9 bascules pour stocker les choix dans différentes cases. Aucun traitement de choix valide n'est à faire car la raspberry s'en occupe déjà de son côté. 

[[Fichier:Stock_adv.JPG|vignette|center|600px|Stockage des cases de l'adversaire|Stockage des cases de l'adversaire]] 

=====Propre à la simulation=====
Pour générer l'adresse, on utilise le même principe de sélection que celui du joueur physique. 
Pour avoir un aspect visuel de cette sélection, on utilise un MUX qui, en fonction du joueur courant, afficher la sélection de tel ou tel joueur. 

[[Fichier:Traite_sel.JPG|vignette|center|600px|MUX de selection|MUX de la sélection]] 

Pour ce qui est du bit de fin de parti, on le symbolise par un bouton. 

=====Phénomène de rebond=====
Pour gérer le rebond des boutons poussoirs, la solution a été numérique. Un registre à décalage a été créé, cadencé sur une clock, il décale sur chaque front d'horloge la valeur courante d'un bouton. En utilisant un comparateur, on obtient alors un front montant seulement lorsque le bouton est dans un état stable (c'est à dire lorsque tous les bits ont la même valeurs)

[[Fichier:Dump.JPG|vignette|center|600px|Anti-rebond|Anti-rebond]] 

====TOPLEVEL====
Le schéma TOPLEVEL est alors le suivant :

[[Fichier:Toplevel.JPG|vignette|center|800px|TOPLEVEL|TOPLEVEL]] 

Ainsi, si nous avions eu le bloc de liaison série bidirectionnel, nous aurions simplement eu à :
* Remplacer la génération d'adresse par les 4bits de poids faible du message de 8bits reçu.
* Remplacer le bouton de reset par le bit de fin de partie.
* Remplacer le bit de choix de l'adversaire par celui de réception validée.
* Relier le bit d'émission à la sortie de "choix valide".
* Relier la sélection du joueur physique aux données à transmettre.
* Enlever le multiplexage de la sélection.

====Réflexion====
La partie électronique de ce projet a donc été menée à bout. Cependant, après coup, on se rend compte que la création d'un prototype aurait été meilleure en imprimant un PCB plutôt qu'en utilisant une piste à bandes. 
Nous aurions également pu éviter une configuration en parallèle du driver. Ainsi, à l'aide de registres à décalages alimentés en externe, la lisibilité du circuit aurait été meilleure. 
On peut néanmoins se satisfaire de la réalisation numérique du circuit car elle exploite toutes les possibilités qu'offrent la conception via schematics à l'aide d'Altium designer à savoir : 
* La création d'une bibliothèque
* La création de composants
* L'utilisation de composants configurables avec édition de pins 
D'ailleurs, on comprend d'autant plus l'intérêt du langage VHDL après la création d'autant de schematics pour un projet de cette envergure. 

=== Partie informatique ===
Nous avons commencé cette séance en continuant le morpion.html
Dans un premier temps nous avons crée "l'espace de jeu" en utilisant du code trouvé sur internet :
<!DOCTYPE html>
<head>
<meta charset="utf-8">
<style type="text/css">
.table{
width : 330px;
height : 330px;
border : solid 3px black;
border-collapse: collapse;
}
.td{
border : solid 3px black;
width : 33%;
height : 33%;
}
</style>
<title> Jeu morpion</title>
</head>
et
<body>
h1>Morpion</h1>
table class="table" align="center">
<tr>
<td class="td" onclick="placerSigne(0)" id="0"> </td>
<td class="td" onclick="placerSigne(1)" id="1"> </td>
<td class="td" onclick="placerSigne(2)" id="2"> </td>
</tr>
<tr>
<td class="td" onclick="placerSigne(3)" id="3"> </td>
<td class="td" onclick="placerSigne(4)" id="4"> </td>
<td class="td" onclick="placerSigne(5)" id="5"> </td>
</tr>
<tr>
<td class="td" onclick="placerSigne(6)" id="6"> </td>
<td class="td" onclick="placerSigne(7)" id="7"> </td>
<td class="td" onclick="placerSigne(8)" id="8"> </td>
</tr>
</table>
table style="border : solid 3px #3399FF;" align="center">
<tr>
<td style="border : solid 1px #3399FF;">Joueur 1</td>
<td style="border : solid 1px #3399FF;">Joueur 2</td>
</tr>
<tr>
<td style="border : solid 1px #3399FF;" id="scre1">0
</td>
<td style="border : solid 1px #3399FF;" id="scre2">0</td>
</tr>
</table>
</body>
</html>

Le code ci dessus n'est pas totalement bon, puisque nous avons du enlever des "<" afin d'afficher le code et non ce qu'il en résulte.

L'espacement entre deux lignes peut changer en fonction de la taille de ce qui est mis dedans.
Si on remplis de case blanche ("vide.png") de taille 100*100 on obtient:
[[Fichier:morpion1.png]]

A chaque clique sur une case la fonction placerSigne(n) va s'effectuer avec n le numéros de la case sélectionnée.
function placerSigne(idCase)
{
if(morpion[idCase] == 0)
{coup++;
morpion[idCase]=joueur;
if (joueur==1)
{
joueur=2;
document.getElementById(idCase).innerHTML = '<img src="croix.gif" alt="image !" />';

}
else {
joueur=1;
document.getElementById(idCase).innerHTML = '<img src="rond.gif" alt="image !" />';

}
if (coup>4)
{if (gagner(idCase))
{if (joueur==1)
{score2++;
alert("joueur 2 gagne ");
finpartie();
}
else{score1++;
alert("joueur 1 gagne ");
finpartie();
}

}
else {if (egalite()==0)
{alert("egalite");
finpartie();}
}
}
}
else{alert("pas le droit");}
}
Cette fonction place une image 100x100 de rond ou de croix dans la case sélectionnée en fonction du joueur qui doit jouer.
*Elle calcule les scores de chaque joueurs, et appelle gagner et egalite pour savoir si on est dans une fin de partie.
*Et elle alerte le joueur si la case sélectionnée ne peut pas être jouée.

Pour cela elle utilise le tableau morpion de taille 9 remplit de 0 à l'origine, et modifie la case sélectionnée en y mettant 1 ou 2 en fonction du joueur qui a joué.

La variable coup permet de déterminer le nombre de coup jouer, ce qui permet de ne pas verifier si une partie une gagnée tant que coup n'est pas supérieur à 4, puisqu'il faut au minimum 5 coup pour gagner.

function finpartie()
{for (var j=0;j<9;j++)
{ document.getElementById(j).innerHTML = '<img src="vide.png" alt="image !" />';
morpion[j]=0;
}
}

La fonction finpartie() met les variables morpion et coup à zéro, et place des images blanches dans toutes les cases.

Elle est appelé que si il y une victoire ou une égalité.

Dans morpionsc.html qui est le fichier html final, joueur est remis à 1 dans cette fonction.

Dans le fichier morpion.html cela n’étais pas cessionnaire et permettait en plus au joueur perdant de commencer.

Mais pour simplifier la suite nous avons préféré définir que toujours le même joueur commencerais.

function gagner(idCase)
{switch(idCase)
{
case 0:
return (diagonal1()||ligne1()||colonne1());
break;
case 1:
return (ligne1()||colonne2());
break;
case 2:
return (diagonal2()||ligne1()||colonne3());
break;
case 3:
return (ligne2()||colonne1());
break;

case 4:
return (diagonal1()||diagonal2()||ligne2()||colonne2());
break;
case 5:
return (ligne2()||colonne3());
break;
case 6:
return (diagonal2()||ligne3()||colonne1());
break;
case 7:
return (ligne3()||colonne2());
break;
case 8:
return (diagonal1()||ligne3()||colonne3());
break;
}
}
La fonction gagner appelle des fonctions diagonal,ligne,colonne qui retourne 1 si il y'a 3 même symboles sur leur domaines.

Gagner teste donc si il y a une suite de 3 symboles sur la ligne, colonne et les diagonales passant par la case qui a été joué.

function egalite()
{var cp=0;
for (var i=0;i < 9;i++)
{if (morpion[i]==0)
{cp++;}
}
return cp;
}
La fonction egalité teste si toutes les cases ont été joué.

On aurait pu utiliser la variable coup, si coup était égal à 9 alors égalité, mais la fonction egalité permet de vérifier si il n'y a pas eu de problème lors de la modification de la matrice.

Avec morpion.html nous avons pu apprendre le javascript, et poser les bases de notre fichier html final.

===Complément à la séance 3===

====HTML====
Pour le HTML/Javascript on garde les mêmes fonctions gagner et egalite.
On va ajouter lors de l'initialisation
window.WebSocket=(window.WebSocket||window.MozWebSocket);

var websocket=new WebSocket('ws://172.26.79.12:9000','myprotocol');

websocket.onopen=function(){ $('h1').css('color','green'); };

websocket.onerror=function(){ $('h1').css('color','red'); };
On modifie placerSigne:
*si ce n'est pas au tour du joueur 1 de jouer on lui envoie une alerte.
*si il y a une fin de partie on envoie 9 grâce a sendMessage.
*si il n'y a pas de fin de partie on envoie la case jouer toujours grâce à sendMessage:
function sendMessage(data){
websocket.send(data);
}
Pour finpartie on rajoute juste
joueur=1;

Pour faire jouer le second joueur il faut recevoir un message du websocket ainsi :
websocket.onmessage=function(message)
sera la fonction dans laquelle on fera jouer le joueur 2.

Le websocket envoie simplement la case en char* ainsi:
websocket.onmessage=function(message){
idCase=parseInt((message.data)-30);
console.log(idCase);

if(morpion[idCase] == 0)
{coup++;
morpion[idCase]=2;
joueur=1;
document.getElementById(idCase).innerHTML = '<img src="rond.gif" alt="image !" />';
if (coup>4)
{if (gagner(idCase))
{score2++;
alert("joueur 2 gagne ");
finpartie();
sendMessage(9);
}

else {if (egalite()==0)
{alert("egalite");
finpartie();
sendMessage(9);

}
}

}
}

}

Console.log permet d'afficher dans le debug, la valeur traitée.
On envoie toujours 9 si la partie se termine, sinon on effectue la même chose que dans placerSigne de morpion.html

====Fichier C====
Il faut maintenant créer la passerelle entre l'arduino et le fichier html.
Pour cela notre fichier doit utiliser des fonctions de websocket mais aussi de serial.c
Les fonctions de serial.c sont directement intégrées dans notre fichier, il n'y a donc pas besoin de lui faire appel pour compiler.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <fcntl.h>
#include <termios.h>
#include <strings.h>
#include <sys/types.h>
#include <sys/ioctl.h>
#include <sys/file.h>
#include <linux/serial.h>
#include <libwebsockets.h>

#define MAX_FRAME_SIZE 1024
#define WAIT_DELAY 50
#define MAX_MESSAGE 2

#define SERIAL_READ 0
#define SERIAL_WRITE 1
#define SERIAL_BOTH 2

#define SERIAL_DEVICE "/dev/ttyUSB0"

int sd;

//
// Open serial port device
//
int serialOpen(char *device,int mode){
int flags=(mode==SERIAL_READ?O_RDONLY:(mode==SERIAL_WRITE?O_WRONLY:O_RDWR));
int fd=open(device,flags|O_NOCTTY|O_NONBLOCK);
if(fd<0){ perror(device); exit(-1); }
return fd;
}

//
// Serial port configuration
//
void serialConfig(int fd,int speed){
struct termios new;
bzero(&new,sizeof(new));
new.c_cflag=CLOCAL|CREAD|speed|CS8;
new.c_iflag=0;
new.c_oflag=0;
new.c_lflag=0; /* set input mode (non-canonical, no echo,...) */
new.c_cc[VTIME]=0; /* inter-character timer unused */
new.c_cc[VMIN]=1; /* blocking read until 1 char received */
if(tcsetattr(fd,TCSANOW,&new)<0){ perror("serialInit.tcsetattr"); exit(-1); }
}

//
// Serial port termination
//
void serialClose(int fd){
close(fd);
}

static int callback_http(
struct libwebsocket_context *this,
struct libwebsocket *wsi,enum libwebsocket_callback_reasons reason,
void *user,void *in,size_t len)
{
return 0;
}

static struct libwebsocket_protocols protocols[] = {
{
"http-only", // name
callback_http, // callback
0, // data size
0 // maximum frame size
},
{"myprotocol",callback_my,0,MAX_FRAME_SIZE},
{NULL,NULL,0,0}
};

Ci-dessus se trouve le code se trouvant dans serial.c afin de créer serialOpen, serialClose et serialConfig, ainsi que l'initialisation de variables utilisées.

Mais aussi la fonction callback_http(),la structure libwebsocket_protocols, et l'initialisation de variables.

int main(void) {
int port=9000;
struct lws_context_creation_info info;
memset(&info,0,sizeof info);
info.port=port;
info.protocols=protocols;
info.gid=-1;
info.uid=-1;
struct libwebsocket_context *context=libwebsocket_create_context(&info);
if(context==NULL){
fprintf(stderr, "libwebsocket init failed\n");
return -1;
}
printf("starting server...\n");

sd=serialOpen(SERIAL_DEVICE,SERIAL_BOTH);
serialConfig(sd,B9600);

while(1){
libwebsocket_service(context,WAIT_DELAY);
}

serialClose(sd);

libwebsocket_context_destroy(context);
return 0;
}

Le main permet d'initialiser une liaison série de 9600 Baud et de lancer une boucle infini dans laquelle la passerelle entre arduino et html va s'effectuer.

static int callback_my(
struct libwebsocket_context * this,
struct libwebsocket *wsi,enum libwebsocket_callback_reasons reason,
void *user,void *in,size_t len)
{
static char message[2+LWS_SEND_BUFFER_PRE_PADDING+LWS_SEND_BUFFER_POST_PADDING];
static char valeur;
switch(reason){
case LWS_CALLBACK_ESTABLISHED:
printf("connection established\n");
// Declenchement d'un prochain envoi au navigateur
break;
case LWS_CALLBACK_RECEIVE:
// Ici sont traites les messages envoyes par le navigateur
//printf("received data: %s\n",(char *)in);
if(write(sd,in,sizeof(char))!=1){ perror("main.write"); exit(-1); }
printf("writen data: %s\n",(char *)in);
// Declenchement d'un prochain envoi au navigateur
libwebsocket_callback_on_writable(this,wsi);
break;
case LWS_CALLBACK_SERVER_WRITEABLE:
// Ici sont envoyes les messages au navigateur

if (read(sd,&valeur,sizeof(char))==1)
{
//printf("write data: %c\n",valeur);
char *out=message+LWS_SEND_BUFFER_PRE_PADDING;
sprintf(out,"%02x",valeur);
//printf("write data: %s\n",(char *)out);

libwebsocket_write(wsi,(unsigned char *)out,MAX_MESSAGE,LWS_WRITE_TEXT);
}
else{libwebsocket_callback_on_writable(this,wsi);
}
break;
default:
break;
}
return 0;
}

La fonction ci-dessus est celle qui definie la passerelle.

Si elle établit une liaison, elle imprime "connection established".

Une fois la connection établit on se retrouve dans le cas LWS_CALLBACK_RECEIVE si la page html envoie une valeur.

Dans ce cas la valeur pointée par in est écrite dans sd(liaison serie), puis on utilise :
libwebsocket_callback_on_writable(this,wsi);

Qui permet de passer en mode réception de message par la liaison série, qui est definit ici par le cas:
case LWS_CALLBACK_SERVER_WRITEABLE:
Dans ce cas on lit la valeur dans la liaison serie et on la met dans la variable valeur. Si il n'y a rien à lire pour le moment on utilise a nouveau:
libwebsocket_callback_on_writable(this,wsi);
Afin de rester dans le même case.

Si la valeur a été lu on crée out:
char *out=message+LWS_SEND_BUFFER_PRE_PADDING;
avec message :
static char message[2+LWS_SEND_BUFFER_PRE_PADDING+LWS_SEND_BUFFER_POST_PADDING];
out va etre du bon type et de la bonne taille pour pouvoir être envoyer a l'html.
On modife donc la valeur de out grâce à la valeur lue:
sprintf(out,"%02x",valeur);
Puis on l'envoie:
libwebsocket_write(wsi,(unsigned char *)out,MAX_MESSAGE,LWS_WRITE_TEXT);

====Arduino====
Pour l'affichage de la matrice LED nous avons utilisé un exemple trouvé sur le site de SparkFun Electronics:
//Example_RGBMatrix.ino
//By: Ryan Owens @ SparkFun Electronics
//
//modified 27 Oct 2014
//by Bobby Chan @ SparkFun Electronics

Nous avons ensuite crée:

void affichage(int je[3][3])
{
for (int i = 0; i < 3; i++)
{
for (int j = 0; j < 3; j++)
{ if (je[i][j] == 1)
{
color_buffer[0 + i + j * 8] = BLUE;
}
else if (je[i][j] == 2)
{
color_buffer[0 + i + j * 8] = RED;
}
else if (je[i][j] == 5)
{
color_buffer[0 + i + j * 8] = TEAL;
}
else if (je[i][j] == 4)
{
color_buffer[0 + i + j * 8] = GREEN;
}
else if (je[i][j] == 3) {
color_buffer[0 + i + j * 8] = MAGENTA;
}
else if (je[i][j] == 0) {
color_buffer[0 + i + j * 8] = BLACK;
}
}
}
}
Qui change la valeur des buffers sur une matrice 3x3, en fonction d'une matrice donnée en paramètre de taille 3x3.

Il faut ensuite matrix_write(); pour observer les resultats

void go(int joueur)
{if (joueur==2)
{color_buffer[7]=GREEN;}
else{color_buffer[7]=RED;}}
Cette fonction met un buffer vert si le joueur 2 peut jouer sinon rouge, le buffer se trouve en dehors de la zone de jeu et donc ne gène pas l'utilisateur.

Il faut ensuite matrix_write(); pour observer les resultats

void reset(int jeu[3][3])
{ joueur = 0;
color_buffer[7]=RED;
for (int i = 0; i < 3; i++)
{
for (int j = 0; j < 3; j++)
{ jeu[i][j] = 0;
}
}
jeu[0][0] = 1;
}
Cette fonction remet dispose la matrice LED comme lors d'un début de partie.
On aurait pu remettre a zéro certaines variables dans cette fonction.

Une fois ces fonctions crées, il faut crée la fonction loop:
void loop() {
go(joueur);
if (Serial.available() > 0)
{ int a = (Serial.read() - 48);
if (a == 9) {
reset(jeu);
}
else {
if (joueur == 0)
{ int b = (a) / 3;
int c = a - (b) * 3;
jeu[b][c] = 2;
joueur = 2;
if (jeu[0][0] == 2)
{
jeu[0][0] = 3;
}
}
}
}
else {
if (joueur == 2)
{ if (digitalRead(9) == 1)
{ jeu[l][h] = jeu[l][h] - 1;
h = (h + 1) % 3;
jeu[l][h]++;
delay(50);
}
else if (digitalRead(8) == 1)
{
jeu[l][h] = jeu[l][h] - 1;
l = (l + 1) % 3;
jeu[l][h]++;
delay(50);
}
else if (digitalRead(7) == 1)
{
if (jeu[l][h] == 1)
{ jeu[l][h] = 4;
Serial.write((l * 3 + h) + 48);

l = 0;
h = 0;
jeu[l][h] = jeu[l][h] + 1;
joueur = 0;
}
}
}
}

affichage(jeu);
matrix_write();
delay(100);
}
Cette fonction utilise en premier lieu go() pour indiquer au joueur si il peut jouer.
Ensuite il vérifie la liaison série.

On enlève 48 a ce que l'on a reçut, car on reçoit un char et on désire un int.

Ainsi on ajoutera 48 a ce qu'on enverra dans le Serial.write.

Si on reçoit 9, fin de partie.
Sinon on vérifie qui doit jouer et on le fais jouer si on peut ou on attend.

Le Joueur 0 équivaut au joueur 1 pour l'html.

Une fois les coups effectués, on affiche ce qui en résulte et ajoute un delay pour éviter d'appuyer deux fois d'affilée sans le vouloir.

En reliant en série notre arduino en USB à notre raspberry, nous pouvons jouer aux morpions à deux , un sur l'arduino à l'aide de bouton poussoir , et l'autre sur une page html grâce à sa souris.

== Démonstration ==

== Conclusion ==

Projet IMA3 P1, 2015/2016, TD2

2016-06-16T21:57:42Z

Tstieven : /* Partie informatique */

Projet IMA3 P1, 2015/2016, TD2

2016-06-16T20:46:06Z

Tstieven : /* Partie informatique */

Projet IMA3 P1, 2015/2016, TD2

2016-05-25T18:29:29Z

Tstieven : /* Partie informatique */