Communication série, 2013/2014, TD1

De Wiki de Projets IMA

Introduction



L'objectif de ce projet est de réaliser un circuit électronique qui avait pour mission de gérer le port série présent sur la carte FPGA de la NanoBoard (dans les deux sens c'est-à-dire émission et réception) ainsi que de réaliser une interface de gestion du port série présent sur la Foxboard.

Gestion du port série de la Nanoboard

Le module RS232 se décompose en deux sous-modules, à savoir une partie émission et une partie réception.

  • un bit start
  • 8 bits de données
  • un bit stop
  • Pas de bit de parité
Serial-trame.png


Matériel utilisé :

  • le port série du PC
  • le logiciel hyperterminal de windows pour transmettre et recevoir les données


Gestion de la Foxboard

Il s'agit de réaliser une interface Web qui va permettre :

1- d'envoyer une chaine de caractères au port série de la FoxBoard 

2- d'afficher les caractères reçus sur ce même port série.

Organisation du projet



Répartition des tâches

Nous nous sommes partagé le travail en 2 parties :

1- Partie informatique réalisée par Sandra Hage Chehade et Ghada El Bez

2- Partie électronique réalisée par Romain Imbert et Louis Chauchard

Progression projet

Nous avons consacré la première séance à la compréhension du sujet et à la prise en main des différents outils de travail(La librairie Jquery permettant les requêtes Ajax, le logiciel Altium …).

Ensuite, nous avons essayé de chercher des solutions adéquates pour la transmission et pour la réception que ce soit pour la partie informatique, mais également pour la partie électronique.

Enfin, nous avons pu effectuer différents tests afin de vérifier le bon fonctionnement de notre liaison série.

Partie Informatique


Mise en situation

La partie informatique consiste à réaliser une interface Web qui permet de communiquer avec le port série du serveur. Notre site doit être composé d'une seule page HTML qui contient :

  • Une zone de texte pour l'émission.
  • Une zone de texte pour la réception.
  • Un bouton qui permet de commencer.

Les langages utilisés pour notre interface sont : HTML, JavaScript, PHP. Nous avons aussi utilisé des requêtes Ajax pour combiner tous ces langages. Pour cela, nous avons installé la librairie jQuery. Nous avons réalisé d'abord nos tests en utilisant un serveur local. Nous avons ensuite copié nos fichiers sur la Foxboard, afin de rendre celle-ci comme un serveur.

Séance 1 (07/05/2014)

Cette séance était consacrée à la compréhension du sujet et à la découverte des différents langages qu'on allait utiliser. Nous avons aussi commencé à faire la page HTML ainsi que quelques fonctions en javascript.

Séance 2 (14/05/2014)

Pendant cette séance nous avons réalisé les deux fichiers PHP d'émission et de réception. Par contre, en testant en utilisant l'Arduino, on recevait bien des informations mais l'émission des données ne fonctionnait pas.

Séance 3 (21/05/2014)

Nous avons corrigé nos erreurs qui se trouvaient dans notre code. Et nous avons configuré notre Foxboard avec le réseau polytech.

Séances supplémentaires

Nous avons copié nos fichiers sur la Foxboard. Et nous avons rédigé le wiki.

Transmission

Nous avons décidé de commencer par cette partie car elle était plus simple que la partie réception. En effet, il suffit d'ouvrir le port série et d'écrire la chaîne de caractères tapée par l'utilisateur dans le port série. Nos avons donc utilisé le langage PHP pour réaliser cette mission.
Voici notre code correspondant :


   <?php 
/*Récupération des données de l'url*/ $entree=$_REQUEST['id'];
/*Ouverture du port série*/ define('SERIAL_DEVICE','/dev/ttyACM0'); $f=fopen(SERIAL_DEVICE,'w');
/*Ecrire la chaine 'entree' dans le port série */ if($f==FALSE) die('fopen\n'); if(fwrite($f,"$entree\n")<=0) die("fwrite \n");
fclose($f);
?>


Cette fonction sera appelée quand l'utilisateur clique sur le bouton 'valider'. En effet, l'appui sur le bouton permet d'appeler une fonction javascript qui, grâce à des requêtes Ajax, va pouvoir enregistrer des données dans l'url. Ainsi, la fonction PHP pourra avoir les données nécessaires.
Voici le code correspondant à la fonction javascript envoyer() :

    function envoyer(){ 
/*Récupération de la chaîne de caractères entrée par l'utilisatuer*/ var chaine = $('#entree').val(); var parameters={id: chaine};
/*Requête Ajax*/ $.ajax({url: 'envoyer.php', type: 'post', data: parameters});
}

Nous avons pu tester en premier temps la transmission grâce à une carte Arduino qui allume une led pour dire que la carte a bien reçu une information.

Réception

Cette partie consiste à lire les caractères qui se trouvent sur le port série. Ce qui change par rapport à la Transmission, c'est qu'on doit arreter le programme pendant un certain temps même s'il aucun octet n'est reçu. Pour cela, nous avons utilisé la fonction usleep() qui permet d'arrêter le programme pendant quelques microsecondes à définir en paramètre de la fonction.
Voici notre code qui correspond à la lecture du port série:

    <?php
define('SERIAL_DEVICE','/dev/ttyACM0'); $f=fopen(SERIAL_DEVICE,'r');
stream_set_blocking($f, 0); /*en mode non bloquant*/
$sortir=0; $ecrire=0; $temps=50000; /*en microseconde*/ $max=20; /* on attendra 1 seconde */ $cpt_sec=0; $caractere= ;
While($cpt_sec<$max && $sortir==0){   $caractere=fread($f,1);   if($caractere==){     if($ecrire==0){ /*la chaîne est vide et on n'avait rien écrit avant*/       $cpt_sec=$cpt_sec+1;       usleep($temps); /* on attend pendant 0.5 s */     }     else $sortir=1 ; /* chaîne est vide et on a déjà écrit quelque chose => on sort*/   }   else{     if($caractere!="\r") echo $caractere; /* il y a un caractère à lire (non vide) */     $ecrire=1;   } } fclose($f);
?>

La fonction lecture est appelée en permanence:

    <body onLoad="javascript:lecture();">

Comme la partie transmission, nous avons pu vérifier le fonctionnement de notre algorithme grâce à la carte Arduino. Nous avons donc testé nos programmes sur le serveur local avant de les installer sur la Foxboard.

Implémentation sur la Foxboard

Après avoir configuré notre Foxboard, nous avons pu nous connecter, en ssh, à notre ordinateur fixe. Nous avons ensuite copié nos programmes sur la Foxboard.
N'ayant que quelques notions de réseau, nous avons rencontré quelques difficultés lors de l'implémentation sur la Foxboard.
Voici notre interface web :

Interface Web

Partie Électronique


Comme on a pu le voir précédemment,la valeur par défaut est à l'état haut. L'envoi du bit de start est représenté par le passage de l'état haut à l'état bas. Ensuite les 8 bits de données sont envoyés à chaque front d'horloge et le dernier (10ème bit) correspond au bit de stop qui permet la remise à la valeur par défaut. De plus, le bit de poids faible est transmis en tête.

Émission

(Séance 1 et Séance 2)

Pour la toute première séance, suite au choix définitif du sujet et de sa compréhension, nous avons effectué plusieurs recherches sur le fonctionnement de la liaison série.

Avant de commencer directement sur le projet, nous avons réalisé le tutoriel d'Altium Designer proposé. Ce qui nous a permis de nous familiariser avec l'utilisation de ce logiciel. En effet, cela nous a permis de comprendre le fonctionnement de la Nanoboard avec les composants des différentes librairies "FPGA".

Ensuite, nous avons commencé réellement le projet, en nous intéressant dans un premier temps à la partie émission, qui nous semblait plus facile. Nous avons rapidement choisi d'utiliser un registre à décalage étant donné que l'on avait eu, au premier semestre, un TP de logique qui permettait de charger des données en parallèle et qui les transmettait ensuite en série.

Nous avons donc débuté avec un montage simple qui comporte les éléments suivants:

  • Un registre à décalage SR16CLES pour convertir Parallèle/Série
  • Un Configurable Digital IO qui permet de générer les 8 bits de données, reliés au niveau des 8 premières broches du registre à décalage. Les autres sont reliées au VCC. Seule la broche D8 est reliée au GND (masse) pour représenter le bit de start qui est un passage de 1 à 0.
  • Des LEDs pour visualiser la bonne conversion parallèle/série


Suite à ce test, on a pu constater que le registre à décalage fonctionne.

Pour la seconde séance, nous avions prévu de continuer et de terminer la partie émission et si possible de commencer la partie réception.

Nous avons gardé le schéma de la première séance, mais nous avons ajouté en plus la possibilité de sélectionner parmi deux vitesses différentes d'émission (sous conseil de nos professeurs). L'utilisation d'un multiplexeur nous a permis de faire cette sélection.

Il suffit de relier deux générateurs de fréquence sur les deux entrées du multiplexeur. L'appui sur un bouton de type switch, qui doit être complémenté, sélectionne l'une des deux entrées à générer.

On utilise une bascule D afin de mémoriser le premier appui puis lors du deuxième appui, la valeur mémorisée est complémentée. Ce qui permet d'alterner entre les deux vitesses de transmission possibles, à chaque appui du bouton.

De plus,un second bouton switch est utilisé pour le chargement des données parallèles.

Émission


Une fois le schéma réalisé, nous avons effectué des tests en envoyant des trames avec le DIO ainsi que les générateurs d'horloge. Un générateur d'horloge était configuré pour réaliser une vitesse de transmission de 9600 bauds et un autre générateur d'horloge était configuré pour réaliser une vitesse de 4800 bauds.

Puis nous avons visualisé avec l'analyseur logique ce que nous obtenions sur une broche du port A de la nanoboard. On remarque bien le bit de start, représenté par le passage de l'état haut à l'état bas.

Trame de 8 bits alternés 0101 0101
visualisation à l'analyseur logique

On remarque que l'on reçoit bien les bits alternés à l'envers, ce qui s'explique par le fait que le bit de poids faible est en-tête. L'émission de bits de données fonctionne donc parfaitement.

Nous avons de plus, visualisé les fréquences des trames reçues afin de vérifier si nous obtenions bien les deux vitesses de transmissions désirées. On constate que la structure fonctionne bien. En effet, dès l'appui du bouton, on passe d'une vitesse de transmission de 9600 bauds (9.6 KHz) à une vitesse de transmission de 4800 bauds (4.8 KHZ).


visualisation de la vitesse de transmission de 9600 bauds
visualisation de la vitesse de transmission de 4800 bauds

Réception

(Séance 2 et Séance 3)

La partie émission fonctionnant, nous nous sommes penchés sur la partie Réception du système qui est apparue bien plus complexe.

Suite à l'explication de Monsieur Boé, nous avons compris que pour cette partie, il était nécessaire d'utiliser deux générateurs d'horloge de fréquence différente. En effet, si l'on souhaite détecter correctement un bit, il faut se positionner en plein milieu du bit et non pas au niveau d'un front (montant ou descendant) afin d'être sûr de détecter un bit et non une perturbation quelconque. Pour se faire, il faut utiliser une deuxième horloge de fréquence deux fois plus rapide pour pouvoir être au milieu du bit.

On reçoit la trame de 10 bits en série à partir de la broche RS RX. Puis le premier front descendant (correspondant au bit de start) doit être détecté pour démarrer le compteur.

La porte AND donnera un 1 logique lorsque ce front sera détecté et que la valeur du compteur sera inférieure ou égale à 1. Ceci va provoquer un front montant au niveau de l’horloge de la bascule D ce qui va permettre le chargement de la valeur de D en sortie (Q).

Cette sortie va donc permettre la mise en route du compteur (broche CE). Ce compteur est donc comparé à la valeur 10 qui valide l’entrée CE du registre U10 pour permettre le décalage.

Si le compteur est strictement supérieur à 10, l’entrée CE du registre U10 (série vers parallèle) devient donc bloquée et ceci va entraîner le blocage du décalage. Au même moment, on remet le compteur à 0 en envoyant un 1 sur son entrée CLR et la sortie Q de la bascule repasse donc à 0 ce qui bloque le compteur U12. Si le compteur est supérieur ou égal à 1, l’entrée de sélection du multiplexeur est égale à 1 ce qui va donc changer la fréquence du compteur.


Schéma complet de la partie Émission et Réception

Malheureusement, cette seconde partie n'a pas donné de résultats concluants, nous n'avons donc pas pu valider son bon fonctionnement.

Conclusion

Pour conclure, la partie informatique fonctionne. Pour la partie électronique, seule la partie émission fonctionne convenablement, la partie réception ne donne pas les résultats attendus. Ce qui malheureusement, bloque la possibilité de relier les deux parties du projet...