wiki:InsiaProgSerieParallele

Sommaire

Programmation ports série et parallèle

1. Port série

Hardware

  • Protocoles matériels et topologies:
    • RS232: point à point, logique à niveaux (usage: câble court, bas débit). La norme électrique associée s'appelle EIA232 (signaux +/-12v)
    • RS422: bus avec 1 émetteur et un ou plusieurs récepteurs, logique différentielle (usage: câble long, haut débit)
  • Connectiques:
    • DB9 (courant)
    • DB25 (en cours de disparition)
    • RJ45 (consoles CISCO, etc)
  • Détail du câblage:
    • Terre
    • TX, RX (full duplex)
    • RTS, CTS, DSR, DTR, DCD, RI (control flow)
    • Câbles droits (dit "modem"): pour relier un terminal à un équipement (ex: PC vers modem)
    • Câbles croisés (dit "nullmodem", fils RX/TX croisés): pour relier deux terminaux entre eux (ex: PC vers PC).

Un câble fonctionnel minimaliste comporte 3 fils: terre, RX et TX. Les fils supplémentaires peuvent être utilisés ou non par les programmes (contrôle modem, contrôle de flux, etc).

On trouve souvent des câbles "universels" dits "en Y": à chaque extrémité ils possèdent un connecteur DB9 et DB25. Si les deux extrémités utilisent des prises femelles, il s'agit en général d'un câble nullmodem, donc croisé. Si une extrémité a une connectique mâle, et l'autre femelle, il s'agit vraisemblablement d'une rallonge ou d'un câble modem (plan droit).

Software

  • Utiliser les programmes suivants:
    • setserial, stty: configuration
    • minicom: terminal
  • Modalités d'accès
    • le groupe dialout chez Debian (adduser eleve dialout).
  • Détection/énumération
    • dmesg | grep tty
    • cat /proc/tty/driver/serial (voir aussi ioports et interrupts)
    • ls /sys/bus/*serial

Note: on utilise souvent un adapteur USB-RS232 de nos jours, celui-ci est détecté en tant que /dev/ttyUSB0...n.

Programmation

Il s'agit d'un character device: c'est un périphérique orienté flux, dans lequel on peut lire et écrire séquentiellement. A distinguer de l'autre grande catégorie de périphérique d'E/S, les block devices (écriture/lecture par blocs, accès aléatoire).

Ressources incontournables:

Lecture/écriture: source:/insia/c/rs232/serie1.c

Le périphérique étant représenté par un fichier (spécial), on utilise la bibliothèque C standard pour y accéder. Notez l'utilisation des appels bas niveau open(2), write(2) et read(2) au lieu de fopen/fread/fwrite, ceci étant expliqué plus bas.

Aucune configuration du contrôleur série n'est effectuée. Pour tester ce programme, il est recommandé de lancer Minicom juste avant, et d'espérer que celui-ci laisse le contrôleur dans un état correctement initialisé. Vous risquez de rencontrer de nombreux bugs divers et variés à ce stade, c'est normal. Explication rapide des problèmes rencontrés:

  • Pas de communication: il est très probable que vos deux terminaux ne sont pas d'accord sur le contrôle de flux (utiliser RTS/DTS, XON/XOFF, ou rien ?)
  • Caractères bizarres (comme le "y tréma"): il est probable que vos deux terminaux ne sont pas d'accord sur la vitesse de transmission, ou le nombre de bits de données, de parité et/ou de stop.
  • Réception d'un unique caractère: votre contrôleur est en mode non-canonique, voir plus loin.

Configuration du port série: source:/insia/c/rs232/serie2.c

Dans un environnement contrôlé (ex: embarqué), vous pouvez vous contenter d'exécuter le programme setserial au démarrage, puis utiliser directement le port série en lecture et écriture (y compris depuis le shell avec echo et cat). Sinon, vous devez vous assurer que votre programme effectue l'intialisation du contrôleur à chaque appel. Ceci se fait à l'aide de la structure termios et la fonction tcsetattr.

Il est important de noter que la fonction de lecture doit explicitement être activée (flag CREAD), et qu'il existe deux modes de lecture:

  • Canonique: en général utilisé pour communiquer entre un homme et une machine, c'est un mode où les données sont fournies au programme ligne par ligne. Il faut faire attention à des flags d'entrée (tel que ICRNL) pour que la notion de ligne soit celle que vous attendez (problème de convention de fin de ligne).
  • Non-canonique: réservé en communication machine-machine ou transfert de données (binaires), aucun traitement n'est effectué et les données sont transmises au programme comme et quand elles arrivent. Attention, dans ce mode il faut correctement configurer les champs c_cc[VTIME] et c_cc[VMIN]. Exemple:
    struct termios tio;
    memset(&tio, 0, sizeof(tio));
    
    tio.c_cflag = B9600 | CS8 | CREAD | CLOCAL;
    tio.c_lflag = 0; /* pas de ICANON */
    tio.c_iflag = 0: /* pas de traitement particulier des entrées */
    tio.c_oflag = 0: /* pas de traitement particulier des sorties */
    tio.c_cc[VTIME] = 0;
    tio.c.cc[VMIN] = 1; /* Lecture caractère par caractère */
    

Lecture/écriture asynchrone: source:/insia/c/rs232/serie3.c

En programmation classique (séquentielle), la fonction read(2) bloque le programme jusqu'à ce qu'elle puisse renvoyer des données ou une erreur. Ceci empêche le traitement simultanées de plusieurs entrées, voire le traitement indépendant de l'entrée et de la sortie série (RS232 est full-duplex).

La solution standard sous Unix est d'utiliser la fonction select. Celle-ci permet de désigner une liste de descripteurs de fichier, et le type d'événement attendu sur chacun d'eux. La fonction bloque alors le programme jusqu'à un des événements attendu soit détecté, ou un laps de temps maximal est écoulé. On peut réaliser toutes les boucles d'événements à partir de cette seule fonction (tant que la source d'événement peut être associée à un descripteur de fichier, ce qui est vrai dans 99% des cas sous Unix).


2. Port parallèle

Hardware

  • Protocoles matériels:
    • EPP/ECP (bidirectionnel)
  • Connectiques:
    • DB25
    • Centronics/36 (imprimante)
  • Détail du câblage:
    • Terre
    • D0-D7
    • Strobe
    • Ack, Paperout, Busy, Autofeed, Error, ...

Software

  • echo, cat
  • Modalités d'accès
    • le groupe lp chez Debian (adduser eleve lp).
  • Détection/énumération
    • dmesg | grep lp
    • ls /proc/sys/dev/parport

Programmation

  • Linux: character device
  • Consuter Documentation/parport.txt et le source d'un driver
  • /dev/lp0 et /dev/parport0
Last modified 14 years ago Last modified on Oct 14, 2006, 10:08:58 PM