Communication série, 2012/2013, TD2

Evaluation informatique et électronique

Gestion de projet / rédaction Wiki

• Informatique :
• Electronique :

Note .

Test fonctionnels

• Sous-système.
  • Sous-système informatique :
  • Sous-système électronique :

Qualité de la réalisation

• Informatique : Note .
  • procédure de test :
  • pages HTML et Javascript :
  • scripts PHP ou programmes C :
  • installation sur FoxBoard :
• Electronique : Note .
  • qualité de la réalisation :
  • tests autonomes :

Bilan

Note finale :

Rapports des élèves

Description du projet

---

Mise en situation

Photo d'une nanoboard contenant le FPGA

Dans le cadre de la fin d'année à Polytech' Lille il nous est demandé de mener un projet qui nous permet d'appliquer les connaissances aquisent tout au long de l'année et aussi de développer notre auto apprentissage pour apprendre manier des outils nouveaux. Au cours de ce projet nous devrons travailler en différent groupe, principalement une partie informatique et une partie électronique. Il faut pour cela diviser les tâches mais garder contact entre les différentes partie car le projet reste commun et le but final est de faire fonctionner les deux partie ensemble en autonomie sur une serveur basé sur la Foxboard.

Sujet

Le but du projet est de réaliser une communication série entre la carte FPGA d'une nanoboard et une interface Web 2.0 héberger sur la Foxboard. Le sujet est facilement différentiable en une partie électronique qui développera le système d'émission et de transmission qur la carte FPGA et la partie informatique qui fera de même sur l'interface Web:

• La partie électronique programme la FPGA avec un logiciel de programmation graphique qui ne permet que la programmation de manière concurrente. Il leur faudra gérer l'envoie séquentielle des données sur la broche RS232 en transformant une donnée parallèle en donnée série selon le protocol suivant : 1 bit de start (niveau bas), 8 bits de données et un bit de stop (niveau haut) sans parité et sans contrôle de flux. Sans émission ni réception, les broche RX et TX sont au niveau haut.

• La partie informatique consiste à créer une interface Web afin de communiquer avec le port série. Pour cela il sera nécessaire d'utiliser du PHP et du javascript et donc pour les liées des requêtes Ajax. La partie PHP qui s’exécute du coté serveur permet d'interroger le port série branché sur la Foxboard et la partie javascript qui s’exécute coté client permet d'avoir une page dynamique qui se rafraichit automatiquement et qui appelle les requêtes Ajax. L'utilisateur aura accès à un champs ou il pourra écrire des données texte envoyées sur le port lors de l'appuie sur un bouton, et d'une zone de texte ou toutes les informations émise et reçu sur le port série serons affiché. La difficulté de cette partie sera de géré la scrutation du port qui se fait donc du coté serveur et qui bloque donc le chargement de la page coté client qui attend les données.

Materiel et outils

Pour réaliser notre projet nous avons besoin de support physique afin de programmer mais aussi d'outils telle que des librairies et des compilateurs afin de pouvoir travailler. Voici une liste normalement exhaustive du matériel que nous avons utilisé lors des scéances:

Relatif à la partie électronique

• Une carte nanoboard avec FPGA intégré
• Le logiciel Altium designer pour programmer
• La librairie Altium relative au FPGA programmé
• Un ordinateur avec une liaison série et hyperterminal afin de tester notre carte

Carte Arduino

Relatif à la partie informatique

• Un ordinateur sous Debian
• Un serveur local pour exécuter le PHP
• Un navigateur web pour exécuter le javascript
• La librairie Jquery permettant les requettes Ajax
• Une carte Arduino pré-programmer pour tester notre programme

Relatif au deux partie

• Une Foxboard pour héberger l'interface et connecter la nanoboard afin de liée les deux parties

Groupe de Projet

Division des tâches

Notre projet supposait fortement de découper le travaille en deux groupe même si cela n'était pas obligatoire. Nous avons décider que Matthieu Marcadet et Meunier Vincent serais plus approprié à la partie électronique car ils ont déjà travailler sur des projets similaire lors de leur DUT tandis que Fondu Hugo et Chalono Kévin serait plus adaptés à la partie informatique. Les groupes n'était pas fixé et Matthieu et Vincent ont put venir aider pour développer la partie informatique à partir de la 3ème séance après avoir finir la partie électronique. Les deux partie ce sont découpé le travaille approximativement de la même manière: dans un premier temps la réalisation de la transmission qui est généralement plus facile puis la gestion de la réception. Ensuite les test de fonctionnements sont effectuer puis l'implémentation avec la Foxboard et le système global.

Feuille de route

Séance 1 :

• Compréhension du sujet
• Début de la transmission sous Altium Designer
• Prise en main du javascript et des requêtes Ajax

Séance 2 :

• Fin de la transmission sous Altium Designer
• Conception complète de la réception sous Altium Designer
• Début de la transmission avec PHP

Séance 3 :

• Test de la partie électronique
• Fin de la transmission en PHP
• Début du wiki

Heures supplémentaires :

• Recompréhension du protocole de réception en PHP
• Fin de la réception en PHP
• Test de la partie informatique
• Implémentation sur la Foxboard
• Test du montage complet
• Tournage de la vidéo
• Fin du wiki

Diagramme de Gantt

Pour mieux comprendre la réalisation des tâches voici les diagramme de Gantt prévisionnel et réel.

• Ce diagramme de Gantt représente la répartition des tâche que nous avions prévu au début du projet. Nous ne pensions pas déborder énormément des séances et aboutir rapidement à un résultat :

• Ce diagramme de Gantt quant à lui représente mieux la réelle répartition des tâches dans le temps. En effet nous avons longtemps bloqué sur certaines tâche ce qui à eu pour effet de retarder tout le reste :

On peut voir qu'en dehors d'une ou deux tâches, les délais sont plutôt représentatif dans le diagramme prévisionnel. Cependant, le temps réelle de travaille fut plus long, comme toujours.

Partie électronique

---

Réalisation de la transmission

Description :

La transmission des données de la Foxboard se fait donc suivant le protocole du sujet qui est :

• 1 bit de start
• 8 bits de données
• 1 bits de stop

débit : 9600 bauds, contrôle de flux : aucun, parité : aucune.

Il faut un niveaux haut sur le port série lorsque rien ne se passe et que le bit de donnée soit envoyer lors de l'appuie sur un bouton poussoir (nous avons choisit de détecter l'appuie et non le relâchement du bouton).

Réalisation :

Pour transmettre les données séquentiellement ils nous est directement venu à l'idée d'utilisé un multiplexeur qui serais attaquer par les informations a transmettre et parcourut à l'aide d'une compteur cadencé par la vitesse de transmission. On y retrouve aux extrémités, deux entrées niveaux hauts et une entrée niveau bas qui correspondent aux bits de start et de stop balayé au début et le niveau de repos. Nous avons donc un compteur de 0 à 10 qui joue de sélecteur pour le multiplexeur, ce compteur est cadencer par une horloge de 9600Hz ce qui nous permet d'avoir la bonne vitesse de transmission. La partie compliqué de la transmission consiste à repérer l'appuie sur une bouton poussoir (supposé extrêmement rapide car pourrais théoriquement être remplacer par une commande provenant d'un ordinateur) et de n'envoyer qu'une seule fois la donnée. Pour cela nous avons créé un sous bloc qui permet de détecter un front ou un comptage du compteur entre 1 et 10 et qui utilise l'horloge à 50MHz de la nanoboard. Ce bloc est expliqué par la suite et réutilisé dans la partie réception, il permet de relancer le compteur lors d'un front montant ou de le bloquer lorsque qu'il arrive à sa position '0' (position de repos).

-> Nous avons rencontrer quelques difficulté à la création du bloc permettant de gérer la détection du bouton poussoir car l'horloge était différente de celle du compteur, en effet l'horloge à 50 MHz est obligatoire pour surveiller les fronts du bouton poussoir. Une foi le bloc gérant le compteur fait le reste fut plutôt intuitif.

Schéma de la transmission :

• Le bloque DIGITAL_IO correspond à la donnée à emmètre
• L'entrée SW_USER0 correspond au bouton poussoir
• L'entrée CLOCK_BRD correspond à l'horloge de la nanoboard à 50 MHz
• Le fil var_clock correspondant à l'horloge variable (dans ce cas à 9600Hz)
• Le Bloc_CE correspond au sous programme de commande du compteur
• La sortie RS_TX correspond à la broche TX du port série

Le bloqueur/compteur

Description :

Le Bloc_CE, correspondant à Bloc Clock Enable, permet de gérer l'entrée CE du compteur. L'entrée CE du compteur permet donc d'activer on de désactiver l'horloge du compteur ce qui permet de le bloquer. Pour contrôler le compteur nous avons définit 2 conditions :

• Le compteur doit commencer à compteur lors d'un front sur le bouton poussoir
• Le compteur doit s’arrêter de compter lorsqu'il est revenue à sa position initiale '0'

Réalisation :

-> La réalisation de ce bloc fut la partie la plus compliqué, nous avons dut détecter un front avec une horloge à 50 MHz pour activer un compteur à 9600Hz. Notre première table de vérité fut celle suivante :

   S = ( BP . /BP-1 ) + Compteur

Compteur valant un niveau haut sauf à '0' l'idée nous semblait bien mais la sortie ne restait pas au niveau haut assez longtemps, donc le compteur ne s'activait pas. Nous avons dut rajouter une fonction bloquante à l'aide d'une bascule D qui permette de garder un niveau haut après le front montant tant que le compteur n'a pas commencer à compter. Nous avons donc remplacer l'équation par :

   Front = BP . /BP-1
   C = ( /Compteur . C-1 ) + Front
   S = C + Compteur

De cette manière la sortie reste à un niveau haut tant que le compteur n'a pas commencer à compter. Cela règle me problème de la valeur front qui reste uniquement à un niveau haut pendant un coup d'horloge à 50MHz.

Schéma Bloc_CE :

• L'entrée Bp correspondant au bouton poussoir
• L'entrée clk correspondant à la clock à 50Mhz
• L'entrée Counter[3..0] correspondant au bus du compteur
• La sortie CE_out correspondant à la sortie du système gérant l'entrée CE du compteur

Réalisation de la réception

Description :

La réception est basée sur le même protocole que la transmission. Il est en plus nécessaire de ranger les donnée dans un registre afin de les mémoriser.

Réalisation :

La réception est à peut près basée sur le même principe que la transmission. Lors d'un front descendant (correspondant au bit de start) sur la broche RX, le Bloc_CE active le compteur jusqu'à ce que la donnée soit reçue. La donnée est envoyé dans le bloc registre qui mémorise chaque valeur une à une à sa place grâce au compteur.

-> La partie un peu compliqué fut de gérer la bonne mémorisation dans le bloc registre Reg_reception, expliquer ci-après.

Pour pouvoir recevoir, nous devons détecter le front descendant du bit de start, pour cela nous avons réutiliser le Bloc_CE décrit plus haut. Celui-ci est toujours connecté à un compteur permettant donc de compter chaque bit reçue. La sortie de ce compteur est connectée à un autre bloc de composant que nous avons réalisé permettant de composant la réception et d'y retrouver les 8 bits de données.

Schéma de la réception :

• L'entrée RS_RX correspond à la broche RX du port série
• Le bloc Reg_reception correspond au bloc qui mémorise la donnée
• Le bloc DIGITAL_IO correspond au bloc qui affiche la valeur
• L'entrée CLOCK_BRD correspond à l'horloge de la nanoboard à 50 MHz
• Le bloc CLOCKGEN correspond au bloc qui génère l'horloge variable (dans ce cas 9600 Hz)
• Le fil var_clock correspondant à l'horloge variable (dans ce cas à 9600Hz)
• Le Bloc_CE correspond au sous programme de commande du compteur

Le registre de mémorisation

Description :

Le but de se bloc est de mémoriser les données reçues. L'idée d'un registre de bascule D nous est venu naturellement. Nous pensions que c'était un moyen à la fois efficace et facile a manipuler pour enregistrer des valeurs. Il faut que chaque bit d'information soit ranger à la suite dans chaque bascule, c'est la seule difficulté de ce montage.

Réalisation :

Pour gérer la mémorisation séquentielle nous avons pensé a contrôler les entrée d'horloge des bascule D car se sont les entrée qui gèrent les moment de mémorisation. Le compteur va donc maintenant contrôler un décodeur à l'inverse de l'émission. Ce décodeur va activer la mémorisation de chaque bascule les unes après les autres et se bloquer à sa position initiale qui ne correspond à aucune bascule D. Nous avions eu une erreur car il ne faut pas oublier le bit de start qui ne correspond à aucune information et qui correspond à la sortie du décodeur dans le vide.

Schéma de Reg_reception :

• L'entrée Counter[3..0] correspond au bus du compteur
• L'entrée Rx_in correspond à la broche RX du port série
• La sortie E est un niveau haut si aucune mémorisation est en cour, niveau bas sinon (non utilisé)
• La sortie car[7..0] correspond au bus du caractère reçu

Test de fonctionnement

Nous avons en premier lieu testé l'émission et la réception indépendamment et observer les signaux pour vérifier que le système fonctionnement tel que nous l'avions prévu. Pour cela il faut configurer l'oscilloscope en mode single shot afin d'observer uniquement le moment ou la trame d'information passe. Ensuite nous avons testé le système complet relié à l'ordinateur.

Test séparé :

• Pour l'émission nous avons envoyé un caractère sur le port série, voila le chronogramme relevé à l'oscilloscope des signaux Clock (9600Hz), Data (broche TX) et le compteur :

• Pour la réception nous avons envoyé un caractère grâce à la liaison série de l'ordinateur et Hyper Terminal et relevé les signaux Clock (9600Hz), Data (broche RX) et le compteur :

Schéma complet de la partie Electronique

Test complet :

Nous avons testé la liaison entre la nanoboard et l'ordinateur en faisant plusieurs échange de caractères. Tous s'affichait normalement sur Hyper Terminal et de même sur la nanoboard. Nous craignons que des erreurs surviennent car l'horloge n'étant pas synchronisé avec la trame, les fronts montant aurait put se confondre et provoqué des erreurs de lectures mais après plusieurs tests nous n'avons eu aucune erreur. Nous aurions put recréer une horloge pour ajuster les fronts mais cela nous semblait être beaucoup de travail inutile.

Partie Informatique

---

Interface Web

Interface Web de communication avec le port série

Le principe de cette interface est d'offrir un moyen ludique de communiquer avec le port série du serveur. Elle doit posséder :

• Une première zone de texte ou les informations qui transit sur le port série sont affichées
• Une deuxième zone de texte ou l'on y entrera les caractère que l'on souhaite transmettre
• Un bouton qui permettra d'envoyer les caractère lors de son appuis (via un fonction javascript)
• Un peu de design parce que c'est toujours important le design :p

Les requêtes Ajax

Les requête Ajax sont essentielle dans ce projet. En effet, le javascript étant un langage dit client-side, c'est-à-dire qu'il s'exécute sur l'ordinateur demandant la page, il ne permet pas de communiquer avec le port série situé sur le serveur (la Foxboard). Pour cela il faut utilisé le PHP qui est un langage dit server-side, c'est-à-dire qu'il s'exécute sur le serveur. Les requête Ajax grâce à la librairie JQuery nous permette de rappeler un page web afin d'en récupérer des informations sans que l'utilisateur n'est à réinterroger le serveur.

Les requêtes Ajax se présente sous la forme :

   $.Ajax{
       aaeazea
       azeazeaze
       azeaeaze
       azeaeaze
   }

A COMPLETER !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

La transmission

La transmission sur le port série est plutôt aisée. En effet il suffit d'appeler une fonction PHP qui s'occupe d'écrire sur le port et qui s'arrête aussi-tôt. Il n'y a aucune contradiction de temps ou de blocage dans cette partie la. Avec le bouton html codé comme ceci nus pouvons lancer la fonction demandé à chaque appuie :

   <input type="submit" value="Envoyer" onclick="javascript:envoyer();" />

La fonction envoyer appelle uniquement un requête Ajax qui fait appelle à une page PHP qui, elle, écrit l'information sur le port série.

A FINIRRRRRRR !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

La réception

Nous avons longtemps bloqué sur la réception dut à une mauvaise compréhension du sujet. Après avoir retravailler le protocole de base nous avons put en déduire cette fonction :

  ae
  aze
  aeaze

A FINIIIIIIIIIIIIIIIIIIIIR !!!!!!!!!!!!!!!!!!!!!

---