Petit guide de programmation des ports d'entrées / sorties sous Linux

Copyright © 1995-2000 Riku Saikkonen.

Copyright © 2002-2006 Jean-François Prévost, Guillaume Lelarge et Jean-Philippe Guérard pour la version française.

Sauf mention du contraire, les Guides pratiques Linux sont la propriété de leurs auteurs respectifs. Les Guides pratiques Linux peuvent être copiés ou diffusés, en partie ou en intégralité, sous tout format qu'il soit physique ou électronique, tant que ce texte d'information sur les droits d'utilisation est conservé dans toutes les copies. Les diffusions commerciales de ce document sont permises et encouragées ; cependant, l'auteur souhaiterait être tenu au courant de telles diffusions.

Toute traduction, œuvre dérivée ou compilation incluant un Guide pratique Linux doit être diffusée en respectant les conditions de ce texte d'information sur les droits d'utilisation. Autrement dit, vous n'avez pas le droit de créer des œuvres dérivées d'un Guide pratique et d'imposer des restrictions supplémentaires à sa diffusion. Des exceptions à ces règles peuvent être accordées dans certains cas ; contactez (en anglais) le coordinateur des Guides pratiques Linux à l'adresse ci-dessous.

En résumé, nous souhaitons encourager la dissémination de ces informations au travers le plus grand nombre de circuits possibles. Cependant, nous souhaitons conserver nos droits d'auteurs sur ces Guides pratiques et nous souhaitons être informé de tout projet de diffusion des Guides pratiques.

Pour toute question, envoyez un courrier électronique, en anglais, à Tim Bynum, coordinateur des Guides pratiques Linux, à l'adresse <tjbynum CHEZ metalab POINT unc POINT edu>.

Unless otherwise stated, Linux HOWTO documents are copyrighted by their respective authors. Linux HOWTO documents may be reproduced and distributed in whole or in part, in any medium physical or electronic, as long as this copyright notice is retained on all copies. Commercial redistribution is allowed and encouraged; however, the author would like to be notified of any such distributions.

All translations, derivative works, or aggregate works incorporating any Linux HOWTO documents must be covered under this copyright notice. That is, you may not produce a derivative work from a HOWTO and impose additional restrictions on its distribution. Exceptions to these rules may be granted under certain conditions; please contact the Linux HOWTO coordinator at the address given below.

In short, we wish to promote dissemination of this information through as many channels as possible. However, we do wish to retain copyright on the HOWTO documents, and would like to be notified of any plans to redistribute the HOWTOs.

If you have questions, please contact Tim Bynum, the Linux HOWTO coordinator, at <tjbynum AT metalab DOT unc DOT edu> via email.

Si vous avez des remarques ou des corrections, n'hésitez pas à m'écrire en anglais à l'adresse <Riku POINT Saikkonen CHEZ hut POINT fi> …

N'hésitez pas à faire parvenir vos commentaires et suggestions concernant l'adaptation française de ce document au projet Traduc.org à l'adresse : <commentaires CHEZ traduc POINT org>.

Les routines pour accéder aux ports d'entrées / sorties sont situées dans le fichier d'en-tête /usr/include/asm/io.h (ou linux/include/asm-i386/io.h dans les sources du noyau Linux). Ces routines sont des macros, il suffit donc de déclarer #include <asm/io.h>; dans votre code source sans avoir besoin de bibliothèques additionnelles.

À cause d'une limitation de gcc (présente dans toutes les versions que je connais, egcs y compris) vous devez compiler le code source qui fait appel à ces routines avec le drapeau d'optimisation (gcc -O1 ou plus), ou alternativement en déclarant #define extern static avant la ligne #include <asm/io.h> (n'oubliez pas de rajouter ensuite #undef extern).

Pour le débogage, vous pouvez compiler avec les drapeaux suivants (tout du moins avec les versions les plus récentes de gcc) : gcc -g -O. Il faut savoir que l'optimisation engendre un comportement parfois bizarre de la part du débogueur. Si cela vous pose un réel problème, vous pouvez toujours utiliser les routines d'accès aux ports d'entrées / sorties dans un fichier source séparé, et ne compiler que ce fichier avec le drapeau d'optimisation activé.

Un autre moyen d'accéder aux ports d'entrées / sorties est d'ouvrir en lecture ou en écriture le périphérique /dev/port (un périphérique en mode caractère, numéro majeur 1, mineur 4) au moyen de la fonction open(). Notons que les fonctions en f*() de la bibliothèque stdio font appel à des tampons mémoires internes, il vaut donc mieux les éviter. Il suffit ensuite, comme dans le cas d'un fichier, de se positionner sur l'octet approprié au moyen de la fonction lseek() (l'octet 0 du fichier équivaut au port 0x00, l'octet 1 au port 0x01, et cætera) et d'en lire (read()) ou écrire (write()) un octet ou un mot.

Il est évident que l'application doit avoir la permission d'accéder au périphérique /dev/port pour que cette méthode fonctionne. Cette façon de faire reste certainement plus lente que la première, mais elle ne nécessite ni optimisation lors de la compilation ni appel à ioperm(). L'accès aux privilèges de super-utilisateur n'est pas impératif non plus, si vous donnez les permissions adéquates à un utilisateur ou un groupe pour accéder à /dev/port (cela reste tout de même une très mauvaise idée du point de vue de la sécurité du système, puisqu'il devient possible de porter atteinte au système, peut-être même d'obtenir le statut de root en utilisant /dev/port pour accéder directement aux disques durs, cartes réseaux, et cætera).

Il n'est pas possible d'utiliser les fonctions select(2) ou poll(2) pour lire /dev/port puisque l'électronique du système n'a pas la possibilité d'avertir le microprocesseur qu'une valeur a changé sur un port d'entrée.

Avant toutes choses, il est important de préciser l'impossibilité de garantir un contrôle précis des temps d'exécution de processus en mode utilisateur du fait de la nature multitâche du noyau Linux. Votre processus peut être mis en sommeil à n'importe quel moment pour une durée allant de 10 millisecondes à quelques secondes (sur un système dont la charge est très importante). Malgré tout, pour la plupart des applications utilisant les ports d'entrées / sorties, cela n'est pas très important. Si vous voulez minimiser cet inconvénient, vous pouvez donner à votre processus une priorité plus haute (reportez-vous à la page de manuel de nice(2)) ou faire appel à l'ordonnancement temps-réel (voir ci-après).

Si vous souhaitez obtenir une précision de temporisation plus élevée que celle qu'offre les processus en mode utilisateur usuels, sachez qu'il existe des possibilités de support « temps-réel » en mode utilisateur. Les noyaux Linux de la série 2.x permettent de travailler en quasi temps-réel. Pour les détails, reportez-vous à la page de manuel de sched_setscheduler(2). Il existe également des versions spéciales du noyau offrant un vrai ordonnancement temps-réel.

	    extern __inline__ unsigned long long int rdtsc()
	    {
	    unsigned long long int x;
	    __asm__ volatile (".byte 0x0f, 0x31" : "=A" (x));
	    return x;
	    }
	  

Pour des durées de la précision d'une seconde, il est certainement plus simple d'utiliser la fonction time(). Pour obtenir plus de précision, gettimeofday() a une précision d'environ une microseconde (mais rappelez-vous de l'ordonnancement déjà évoqué précédemment). Pour les Pentium, le fragment de code rdtsc ci-dessus est précis au cycle d'horloge près.

Si vous souhaitez que votre processus reçoive un signal après un certain laps de temps, utilisez setitimer() ou alarm(). Voyez les pages de manuel de ces fonctions pour plus de détails.

L'adresse de base du port parallèle (appelée BASE ci-dessous) est 0x3bc pour /dev/lp0, 0x378 pour /dev/lp1 et 0x278 pour /dev/lp2. Si vous souhaitez piloter un matériel fonctionnant comme une imprimante classique, voyez le Printing-HOWTO.

En plus du mode standard d'écriture-seule décrit ci-dessous, il existe un mode « étendu » bidirectionnel sur la plupart des ports parallèles. Pour des informations à ce sujet ainsi que sur les récents modes ECP / EPP (et le standard IEEE 1284 en général), voici deux adresses : http://www.fapo.com/ et http://www.beyondlogic.org/. Rappelez-vous cependant que puisque vous ne pouvez pas utiliser les requêtes d'interruptions (IRQ) ou l'accès DMA dans un programme en mode utilisateur, vous serez certainement obligé d'écrire un pilote pour le noyau afin d'exploiter les modes ECP / EPP. Il me semble que quelqu'un est déjà en train de développer un tel pilote, mais je n'en sais pas plus à ce sujet.

Le port BASE+0 (port de données) contrôle les signaux de données du port (respectivement D0 à D7 pour les bits 0 à 7; états : 0 = bas (0V), 1 = haut (5V)). Une écriture sur ce port positionne l'état des broches correspondantes. La lecture retourne la dernière valeur écrite en mode standard ou étendu, sinon les données présentes sur les broches connectées à un autre périphérique en mode de lecture étendue.

Le port BASE+1 (port d'état) est en lecture seule et retourne l'état des signaux d'entrée suivants :

Le port BASE+2 (port de contrôle) est en écriture seule (une lecture sur celui-ci retourne la dernière valeur écrite) et contrôle les signaux d'état suivants :

Brochage (d'un connecteur femelle sub-D 25 sur le port) (e = entrée, s = sortie) :

 1(e/s) -STROBE,   2(e/s) D0,          3(e/s) D1,          4(e/s) D2, 
 5(e/s) D3,        6(e/s) D4,          7(e/s) D5,          8(e/s) D6, 
 9(e/s) D7,       10(e) ACK,          11(e) -BUSY,        12(e) PE, 
13(e) SLCT,       14(s) -AUTO_FD_XT,  15(e) ERROR,        16(s) INIT,     
17(s) -SLCT_IN,   18-25 masse

Les spécifications données par IBM indiquent que les broches 1, 14, 16 et 17 (les sorties de contrôle) sont de type collecteur ouvert ramené à 5,0 V au moyen d'une résistance de 4,7 kohm (intensité de fuite de 20 mA, de source 0,55 mA, état haut de sortie 5,0 V moins tension de pull-up). Le reste des broches ont une intensité de fuite de 24 mA, de source de 15 mA et leur voltage à l'état haut est au minimum de 2,4 V. L'état bas pour toutes les broches est au maximum de 0,5 V. Les ports parallèles d'autres types que celui d'IBM peuvent s'écarter de ce standard. Pour plus d'informations à ce sujet, voyez l'adresse : http://www.hut.fi/Misc/Electronics/circuits/lptpower.html.

Avertissement

Faites très attention aux masses ! J'ai déjà grillé à plusieurs reprises des ports parallèles en les connectant alors que l'ordinateur était sous tension. Utiliser un port parallèle non intégré à la carte mère peut s'avérer une bonne solution pour éviter de trop grands désagréments. Vous pouvez obtenir un second port parallèle pour votre machine au moyen d'une carte multi-entrées / sorties à petit prix. Il vous suffit de désactiver les ports dont vous n'avez pas besoin, puis de configurer le port parallèle de la carte sur une adresse libre. Vous n'avez pas besoin de vous préoccuper de l'IRQ du port parallèle si vous n'y faites pas appel.

Le port de manette de jeu est accessible aux adresses 0x200-0x207. Si vous souhaitez contrôler une manette de jeu ordinaire, vous serez probablement mieux servi en utilisant les pilotes distribués avec le noyau.

Brochage (pour un connecteur sub-D 15 femelle) :

Les broches fournissant une tension de +5 V semblent souvent être connectées directement sur l'alimentation de la carte mère, ce qui peut leur permettre d'obtenir pas mal de puissance, en fonction de la carte mère, du bloc d'alimentation et du port de manette de jeu.

Les entrées numériques sont utilisées pour les boutons des deux manettes de jeu (manette A et manette B, avec deux boutons chacune) que vous pouvez connecter au port. Ces entrées devraient être de niveau TTL classique, ainsi vous pouvez lire directement leurs valeurs sur le port d'état (voir plus bas). Une véritable manette de jeu retourne un état bas (0 V) lorsque le bouton est pressé et un état haut dans l'autre cas (une tension de 5 V des broches de d'alimentation au travers d'une résistance de 1 kohm).

Les pseudo entrées analogiques mesurent en réalité la résistance. Le port de manette de jeu comporte un quadruple monostable (une puce de type NE558) connecté aux quatre entrées. Pour chaque entrée, il y a une résistance de 2,2 kohm entre la broche d'entrée et la sortie du monostable, et un condensateur de 0,01 µF entre la sortie du monostable et la masse. Une véritable de manette de jeu a un potentiomètre pour chaque axe (X et Y), connecté entre le +5 V et la broche d'entrée appropriée (AX ou AY pour la manette A, ou BX ou BY pour la manette B).

Lorsqu'il est activé, le monostable initialise ses lignes de sortie à un état haut (5 V) et attend que chaque condensateur de temporisation atteigne une tension de 3,3 V avant de mettre la sortie correspondante à un état bas. La durée de l'état haut de la sortie du temporisateur est proportionnelle à la résistance du potentiomètre de la manette de jeu (en clair, la position du manche de la manette de jeu de l'axe approprié) comme expliqué ci-dessous :

où R est la résistance en ohm, du potentiomètre et t la durée de l'état haut de la sortie, en microsecondes.

Pour effectuer une lecture sur les entrées analogiques, vous devez tout d'abord activer le monostable (au moyen d'une écriture sur le port, voir plus bas), puis scruter l'état des quatre axes au moyen de lectures répétées jusqu'à la transition à un état bas, permettant ainsi de mesurer la durée de l'état haut. Cette scrutation est très gourmande en temps machine. De plus, sur un système multitâche non temps-réel tel que Linux (en mode utilisateur normal) le résultat n'est pas très précis, du fait de l'impossibilité de scruter le port constamment (à moins d'utiliser un pilote noyau et de désactiver la gestion des interruptions pendant la scrutation, mais sachez que vous consommerez encore plus de temps machine). Si vous savez à l'avance que le signal va mettre un certain temps (plusieurs dizaines de millisecondes) avant de basculer, vous pouvez faire appel à usleep() avant de procéder à la scrutation afin de laisser un peu de temps machine aux autres processus.

Le seul port d'entrées / sorties auquel vous avez besoin d'accéder est le port 0x201 (les autres ports se comportent de façon identique ou ne réagissent pas). Toute écriture sur ce port, peu importe la valeur envoyée, active le temporisateur. Une lecture retourne l'état des signaux d'entrée :

Si le périphérique avec lequel vous communiquez est à peu près compatible avec le standard RS-232, vous devriez être en mesure d'utiliser pour cela le port série. Le pilote série du noyau Linux devrait suffire pour la plupart des applications (vous ne devriez pas avoir à programmer le port directement, de plus vous devriez probablement écrire un pilote pour le noyau si vous souhaitiez le faire), il est en effet très polyvalent et l'usage de débits non-standards ne devrait pas poser de problèmes particuliers.

Voyez la page de manuel de termios(3), le code source du pilote (linux/drivers/char/serial.c) ainsi que la page http://www.easysw.com/~mike/serial/ pour plus d'informations sur la programmation des ports séries des systèmes Unix.

La traduction française de ce document a été réalisée par Jean-François Prévost <prevost CHEZ 2cse TIRET group POINT com>.

La relecture de ce document a été réalisée par Guillaume Lelarge <gleu CHEZ wanadoo POINT fr> et Jean-Philippe Guérard <fevrier CHEZ tigreraye POINT org>.