Gestion du port RS232

Objectif

Comme vous devez déja le savoir, il existe beaucoup de protocoles de communication série utilisés pour échanger des informations entre les équipements informatiques. Mais, si vous devez n'en connaître qu'un seul, c'est bien le protocole rs232. C'est en effet le moyen le plus simple de dialoguer avec un PC ou un termninal. Il est également utilisé par les cartes à puce pour serrure codée (standard iso7816).

Aujourd'hui, il va nous permettre d'utiliser un PC comme terminal. Notez bien que les alternatives, pour un PC sont: l'USB, l'infrarouge (IrDA), le firewire (IEEE1394), ou encore l'ethernet. Nous n'aurons aucun mal à vous convaincre de la simplicité du rs232 vis à vis de ses concurents, tant sur le plan de la mise en oeuvre que sur le plan du protocole de communication. Nous verrons plus tard que le bus I2C, bien que plus perfectionné que le rs232, ne se trouve pas à l'arrière des PC.

Pour l'heure, nous allons faire plusieurs expériences de communication:

• La première va consister à envoyer un caractère ascii vers le palm par le port rs232 du pic lorsqu'on appuiera sur le bouton poussoir. Ce caractère sera réceptionné et affiché par le palm configuré en terminal vt100.
• La seconde va consister à recevoir un caractère depuis le palm, à afficher son code ascii sur le port D, et à le réémettre vers le palm.
• La troisième ce sera comme la deuxième, mais le pic transformera tous les caractères minuscules en majuscules.
• La quatrième, si vous êtes un peu rapide, transformera le pic en calculatrice !!... pour des chiffres de 0 à 9 (opérateurs + et -), et si vous êtes trop fort des nombres codés sur 8 bits.

Protocole RS232

Présentation

Le standard RS232 définit un protocole de communication série full-duplex point à point. Communication série signifie que tous les bits d'un mot sont transférés en séquence sur un seul fil électrique. Full-duplex signifie que le transfert peut se faire dans les deux sens en même temps (sur deux fils différents). Point à point signifie qu'il n'y a qu'un seul émetteur et qu'un seul récepteur. Le protocole définit la manière dont démarre une transaction (handshaking), dont un mot est mis en série, il définit le débit de transfert des bits, s'il y a de la redondance pour la détection d'erreur, etc.

Le protocole RS232 a été conçu dans les années 60 pour standardiser la communication entre les terminaux et les ordinateurs via le réseau téléphonique interfacé par des modems. Un terminal (ou DTE pour Data Terminal Equipement) est ainsi connecté à un modem (ou DCE pour Data Communication Equipement) par une liaison RS232, puis ce modem communique avec un autre modem par une liaison téléphonique, lequel modem est relié à un autre ordinateur (DTE) par une liaison RS232.

Ce standard simple et bon marché a ensuite été utilisé pour la communication entre les ordinateurs et toute sorte de périphériques (imprimante, lecteur de bande, etc), et pour la communication directe entre ordinateurs sans passer par un modem (DTE à DTE: cable null-modem).

Le standard de base autorise des transferts jusqu'à 20 Kbits/sec (19600 bauds) sur une distance de 16 mètres au maximum. Le standard a été depuis étendu afin d'améliorer le débit et la distance.

Dans ce TP, vous utiliserez le protocole dans un cas particulier et nous vous fournirons seulement les informations dont vous aurez besoin. Si vous êtes intéressés, ou si vous avez des besoins spécifiques, vous pourrez trouver une description plus complète sur internet (par exemple):

• ​http://www2.rad.com/networks/1995/rs232/rs232.htm
• ​http://retired.beyondlogic.org/serial/serial.htm

Liste des signaux

Il existe deux brochages de base différents, le premier sur un connecteur DB-25, le second sur un connecteur DB-9. Tous les signaux ne sont pas impérativement nécessaires pour établir une liaison.

En fait, dans sa forme la plus simple, une interface rs232 est réduite à 2 fils pour le transport des données, plus un fil de masse (GND). Les autres fils servent au contrôle de flux, mais ne sont pas obligatoirement gérés. Dans le cas d'une connexion terminal-terminal, chacun parle sur TX (DB9/3) et écoute sur RX (DB9/2). On parle de cable croisé dit null-modem.

Le tableau suivant donne la liste des signaux sur un DB-9 et un DB-25.

DB-25	DB-9	Nom	Description
2	3	TX	Transmitted Data, TxD
3	2	RX	Received Data, RxD
4	7	RTS	Request To Send
5	8	CTS	Clear To Send
6	6	DSR	Data Set Ready
7	5	SG	Signal Ground
8	1	DCD	Data Carrier Detect
20	4	DTR	Data Terminal Ready
22	9	RI	Ring Indicator

• RX entrée des données du correspondant vers l'ordinateur.
• TX sortie des données de l'ordinateur vers le correspondant.
• GND masse de référence.
• DTR sortie active à l'état haut qui permet à l'ordinateur de signaler au correspondant que le port série a été libéré et qu'il peut être utilisé s'il le souhaite.
• DSR entrée active à l'état haut qui permet au correspondant de signaler qu'une donnée est prête.
• RTS sortie active à l'état haut qui indique au correspondant que l'ordinateur veut lui transmettre des données.
• CTS entrée active à l'état haut qui indique à l'ordinateur que le correspondant est prêt à recevoir des données.
• RI entrée active à l'état haut qui permet à l'ordinateur de savoir qu'un correspondant veut initier une communication avec lui.
• DCD entrée active à l'état haut qui signale à l'ordinateur qu'une liaison a été établie avec un correspondant.

Pour un cable null-modem complet on croise les lignes DSR et DTR qui vont permettre de faire une poignée de main pour ouvrir une communication et on croise RTS et CTS qui vont permettre une poignée de main pour démarrer la communication, après qu'elle ait été ouverte. Quand on ne connecte pas ces lignes, c'est parce que l'on fait l'hypothèse que la ligne est toujours ouverte et que les interlocuteurs sont toujours prêts.

paramètres de la communication

La liaison série est paramétrable en termes de: nombre de bits de données des mots échangés, fréquence de transfert, nombre de bits de synchronisation, et enfin présence ou non et type de bit de parité pour la détection d'erreurs de communication. Le protocole fait l'hypothèse que les interlocuteurs se mettent d'accord sur ces paramètres AVANT de commencer la communication. Il est toujours possible de découvrir ces paramètres par un protocole de démarrage spécifique mais ce n'est pas une méthode standard.

nombre de bits

nombre de bits de données est compris entre 5 et 8.
Le pic ne sait échanger que 8 bits de données.

débit

en bit par second (baud) est à choisir, a priori pour chaque sens, parmi une liste prédéfinie (50, 75, 110, 130, 150, 200, 300, 600, 1200, 1800, 2400, 4800, 9600, 19200, 38400, 57600, 76800, 115200). Le débit définit la largeur temporelle d'un bit : à 200 baud, la largeur est de 5 ms.
Le pic peut dialoguer jusqu'à 57600 bauds. Vous allez voir que les fréquences qu'il propose s'éloignent de quelques pourcents par rapport aux fréquences officielles, mais c'est sans importance car les trames de données sont courtes et les horloges d'émission et de réceptions resynchronisent leur phases à chaque début de trame. Autre remarque concernant le débit, dans le pic, il est le même en émission et en réception.

parité

la parité est optionnelle et peut être paire ou impaire. Quand elle est paire, on compte le nombre de bits à 1 du mot envoyé et on complète par 0 ou 1 pour que le nombre total de bits à 1 devienne pair. Pour la parité impaire, on cherche à obtenir un nombre de bit à 1 impair.
Le pic réserve un espace pour la parité, mais laisse à l'utilisateur le soin de la produire et de la valider.

stop

bits à 1 servant à la synchronisation ajouté à la fin des mots au nombre de 1, 1.5 ou 2.
Le pic place toujours un seul bit de stop.

Forme du signal et niveau électrique

Quand rien ne circule sur la ligne, celle-ci est stable à l'état haut (1 logique). Le transfert d'un mot commence par 1 bit de start à 0, puis viennent les bits de données du mot en commencant par le poids faible et en finissant par le poids fort, puis on ajoute éventuellement le bit de parité, et enfin on termine par 1 ou 2 bits de stop à l'état haut. Le transfert suivant peut démarrer dès le cycle qui suit le dernier stop. La durée d'un bit (start, data, par ou stop) dépend du débit choisi pour l'échange.

Sur la ligne le niveau éléctrique représentant le 1 logique est compris entre -3 et -15. Le niveau pour 0 est compris entre +3 et +15. Le pic ne fournit bien entendu pas ces valeurs sur ses sorties, ni ne les accepte sur ses entrées.

Pour faire l'adaptation on interpose un circuit max3232 qui prend d'un coté les niveaux CMOS (0V pour le 0 logique, 3.3V ou 5V pour le 1 logique) et qui prend de l'autre les niveaux RS232. Ce circuit est alimenté en 3.3V ou 5V et ne nécessite que 4 capacités auxiliaires.

Par exemple, pour le transfert d'un 'A', avec parité paire et un bit de stop.

Le module USART du pic en mode asynchrone

L'USART (Universel Synchronous Asynchronous Receiver Transmitter) du pic autorise deux modes de fonctionnement, un fonctionnement synchrone avec une horloge et une donnée, et un fonctionnement asynchrone avec deux données de sens opposé. C'est ce second mode qui nous intéresse ici.

L'USART est décrite 8_pic16f877_usart.pdf aux pages 95 à 109, mais seules les pages de 95 à 102, vont être nécessaires aujourd'hui. Cette USART peut produire des trames de 8 ou 9 bits, suivi d'un bit de stop. Elle permet, en utilisant une astuce, de produire des trames de 5 à 8 bits de données, suivi d'une parité, suivi d'un bit de stop. Le calcul et la vérification de la parité ne sont pas pris en charge par le pic, c'est au programmeur de le faire. Pour ce TME, nous ne l'utiliserons pas. Vous noterez dans ce qui est dit plus bas, que les drapeaux d'interruption de l'émetteur et du récepteur sont effacés, non pas en écrivant 0 dedans comme toutes les autres interruptions, mais respectivement en écrivant dans le registre d'émission (TXREG) ou en lisant le registre de réception (RCREG).

Registres de commandes généraux

• Les pages 95 et 96 décrivent les deux registres de commande de l'USART. Bien que l'un se nomme TXSTA et l'autre RCSTA, les deux sont nécessaires, même si on ne fait que de l'emission ou que de la réception. Nous allons revenir sur la signification des différents bits au momment où il faudra faire la procédure de démarrage du module.

Baud Rate Generator

• Les deux pages suivantes, 97 et 98, décrivent le BRG (Baud Rate Generator). C'est le générateur de fréquence programmable qui permet d'obtenir les débits standards. Le générateur a deux modes de fonctionnement suivant que l'USART est en mode synchrone ou asynchrone. Pour le mode asynchrone qui nous intéresse aujourd'hui, il est programmé par l'intermédiaire du registre SPBRG et du bit TXSTA(BRGH). Les tables de la page 98 donne les fréquences accessibles, en haut quand BRGH est à 0, en bas quand BRGH est à 1. Pour le TME nous allons travailler à 9600 bauds, c'est à dire 9.6kbauds. Pour l'obtenir, puisque l'horloge externe est à 20MHz, vous devez mettre BRGH à 1 et SPBRG à 129. Vous noterez que les fréquences proposées ne sont pas exactement celles standards, elles sont différentes de quelques pourcents. mais ça marche quand même car les trames rs232 sont courtes.

L'émetteur

• Les deux pages suivantes, 99 et 100, décrivent l'émetteur, dont le schéma est résumé par le figure 10-1, et le mode opératoire est donné en haut de la page 100. Pour utiliser l'émetteur, il faut l'initialiser, et pour ça il faut:
  • Initialiser le BRG. Ici TXSTA.BRGH à 1 et SPBRG doit prendre la valeur 129, afin d'obtenir 9600 bauds. Cette programmation est commune à l'émetteur et au récepteur. On ne la fait qu'une fois et elle est valable pour les deux.
  • Programmer l'USART en mode asynchrone, en mettant à 0 TXSTA(SYNC). On nous demande à ce stade d'allumer l'USART en activant le bit RCSTA(SPEN) (mise à 1). On va le faire, mais à la fin, car RCSTA est dans le bank0 alors que TXSTA est dans le bank1.
  • Mettre à 1 PIE1(TXIE), pour le cas où on utilise les interruptions. Au début on ne va pas les utiliser, on le laisse donc à 0.
  • Mettre le bit TXSTA(TX9) à 1, si on veut une trame de 9 bits. Nous on n'en veut pas, on le met à 0. Notez que comme les octets ne font que 8 bits, le 9ième bit de donnée est ailleurs. Il est en TXSTA(TX9D).
  • Autoriser les emissions en activant TXSTA(TXEN). On nous dit, ici que le fait d'allumer l'émetteur lève une interruption PIR1(TXIF). C'est un des points subtiles de l'USART. En effet, l'interruption d'emission est levée dès que l'USART est prète à emettre une donnée et non pas comme on pourrait le croire naïvement (c'était mon cas) quand il a terminé un envoi. Ça signifie que si on à rien à émettre, il faut eliminer l'interruption, soit en la masquant par PIE1(TXIE) à 0, soit carrément en éteignant l'émetteur TXSTA(TXEN) à 0. Notez aussi, que pour baisser le drapeau d'interruption PIR1(TXIF), il faut emettre quelque chose en écrivant dans le registre TXREG.
  • Il est nécessaire de programmer la broche PORTC6(TX) en sortie, car le fait d'activer l'USART en emission ne suffit pas.
  • Enfin démarrer l'USART en mettant à 1 le bit RCSTA(SPEN).

• Ensuite pour utiliser l'emetteur, et envoyer des données, il faut:
  • Initialiser le bit TXSTA(TX9D), si on utilise ce 9ième bit, ce qui n'est pas notre cas.
  • Ecrire dans TXREG. La transmission démarre aussitôt. Comme vous pouvez le voir sur la figure 10-1, TXREG est recopié dans un registre à décalage nommé TSR register, et se trouve donc vide presque aussitôt. Si on a demandé les interruptions, ce qui n'est pas notre cas ici, le fait d'avoir un TXREG vide nous fait partir en interuption. PIR1(TXIF) nous dit quand est-ce que TXREG est vide et qu'on peut le remplir, mais si on veut savoir quand est-ce que la donnée est vraiment partie, il faut scruter (polling) le bit TXSTA(TMRT). Ce bit indique la fin d'emission du stop bit.

Le recepteur

• Les 2 pages suivantes, de 101 à 102, décrivent le fonctionnement de base du récepteur, dont la structure est résumée sur la figure 10-4 et le mode opératoire est donné page 102. Pour utiliser le récepteur, il faut l'initialiser, et pour ça il faut:
  • Initialiser le Baud Rate Generator, sauf si cela a déjà été fait pour l'émetteur (cf. plus haut).
  • Programmer l'USART en mode asynchrone, sauf si cela a déjà été fait pour l'émetteur (cf. plus haut). On ne démarre pas encore l'USART par RCSTA(SPEN), on va le faire à la fin.
  • Mettre à 1 PIE1(RCIE), pour le cas où on utilise les interruptions, et nous allons effectivement les utiliser.
  • Mettre le bit RCSTA(RX9) à 1, si on attend une trame de 9 bits. Nous on n'en veut pas, on le met à 0. Le 9ième bit de donnée est en RCSTA(RX9D).
  • Autoriser les réceptions en activant RCSTA(CREN). Faîtes attention, c'est CREN et pas RCEN, comme on pourrait s'y attendre. Le pire est que RCEN existe, c'est le bit 3 du registre SSPCON2, donc l'assembleur ne détecte aucune erreur. On nous dit que le récepteur lève le drapeau PIR1(RCIF) dès qu'une donnée à été reçue, ce qui fait partir en interruption, si le bit PIE1(RCIE) est à 1 (et aussi INTCON(PEIE) et INTCON(GIE)).
  • Enfin démarrer l'USART en mettant à 1 le bit RCSTA(SPEN), sauf si cela a déjà été fait pour l'émetteur (cf. plus haut)..

• Ensuite pour utiliser le récepteur. Une donnée est arrivée dès que PIR1(RCIF) passe à 1. On le sait par scrutation, ou parce qu'on a demandé à être interrompu. Nous avons demandé à être interrompu, on ferra donc le travail dans l'ISR_RC (la routine dédiée à l'interruption RC). Il faut:
  • Lire le bit RCSTA(RX9D), si on s'attend à recevoir 9 bits, ce qui n'est pas notre cas, aujourd'hui.
  • Lire le bit RCSTA(FERR) qui indique s'il y a eu une erreur de frame (le bit stop n'était pas présent). Dans une vraie application, il est souhaitable que l'utilisateur soit tenu informé. Pour cela, on utilisera sans doute un bit dans un registre USTATUS spécifique. Aujourd'hui on ne va pas le faire, on ferra juste le minimun. Pour régler le problème de frame, on ne fait rien. La lecture du registre RCREG contenant la donnée suffit à remettre le bit RCSTA(FERR) à 0. Notez quand même que la donnée est fausse!
  • Lire la donnée reçue dans RCREG. Attention, quand le récepteur dit qu'il a reçu une donnée, ça signifie en fait qu'il dispose d'une ou deux données. RCREG est une fifo. Il faut lire le registre RCREG, jusqu'à ce que PIR1(RCIF) revienne à 0. Plus exactement, il faut recommencer les 3 étapes (RX9D, FERR, RCREG). Pour aujourd'hui, on ne va pas le faire, car étant donné le débit choisi et le taux d'occupation du pic, il y a peu de chance, d'avoir deux données en attente.
  • Lire le bit RCSTA(OERR) qui indique s'il y a eu un bourrage (overrun). C'est possible si l'utilisateur n'a pas été assez rapide pour lire les données reçues. Là encore, dans une vraie application (on ne le fera pas aujourd'hui), il faut prévenir l'utilisateur grâce à un bit dans un registre USTATUS. Pour régler le problème de bourrage RCSTA(OERR), il faut éteindre et rallumer le récepteur et mettant RCSTA(CREN) à 0 puis à 1. Les données en cours de réception sont perdues. Il va falloir le faire aujourd'hui, car si par un malheureux hasard, il y avait bourrage et que RCSTA(OERR) passe à 1, le récepteur serait bloqué.

Travaux pratiques

L'usage de minicom va permettre de communiquer avec le micro-contrôleur.

minicom

experience n°1 : écriture d'un caractère

• ajouter une séquence d'initialisation de l'émetteur rs232, émission à 9600 bauds, sur 8 bits.
• envoyer dans le programme principal un caractère quelconque, mais affichable, à chaque appui du bouton poussoir.

experience n°2 : loop-back d'un caractère

• modifier la séquence d'initialisation pour démarrer le récepteur en demandant à être interrompu à chaque réception.
• ajouter l'ISR_RC et faire un loop-back, c.-à-d. renvoyer tout ce qui est reçu.
• laisser le programme principal tel qu'il est dans boutonit.
• Essayer de faire une mise en majuscule ou minuscule des caractères reçus.

experience n°3 : affichage LCD

• ajouter le code nécessaire pour que le caractère envoyé sur TX soit aussi écrit sur le LCD. Pour ce faire vous utiliserez le code disponible dans
  ~encadr/micro/examples/lcd

experience n°4 : la calculatrice

• On va faire simple. Modifier l'ISR_RC, de manière à ce que le pic réalise une calculatrice postfixe sur des nombres à 1 chiffre de 0 à 9. Pour faire 1 + 1, on envoie 11+, et le pic renvoie 2.
• Si vous voulez progresser dans la programmation assembleur, passer à une calculatrice octet sur des nombres à 1 ou 2 chiffres les nombres seront séparés d'un espace : 1<espace>31<espace>+, le pic rend 32.