Le meilleur moyen de d�bugguer votre code est d'installer une autre machine sous Linux et de connecter les deux ordinateurs par un c�ble null-modem. Utilisez miniterm (disponible dans le Linux programmers guide -- ftp://sunsite.unc.edu/pub/Linux/docs/LDP/programmers-guide/lpg-0.4.tar.gz -- dans le r�pertoire des exemples) pour transmettre des caract�res � votre machine Linux. Miniterm est tr�s simple � compiler et transmettra toute entr�e clavier directement sur le port s�rie. Vous n'avez qu'� adapter la commande #define MODEMDEVICE "/dev/ttyS0" � vos besoins. Mettez ttyS0 pour COM1, ttyS1 for COM2, etc... Il est essentiel, pour les tests, que tous les caract�res soient transmis bruts (sans traitements) au travers de la ligne s�rie. Pour tester votre connexion, d�marrez miniterm sur les deux ordinateurs et taper au clavier. Les caract�res �crit sur un ordinateur devraient appara�tre sur l'autre ordinateur, et vice versa. L'entr�e clavier sera �galement recopi�e sur l'�cran de l'ordinateur local.
Pour fabriquer un c�ble null-modem, pour devez croiser les lignes TxD (transmit) et RxD (receive). Pour une description du c�ble, r�f�rez vous � la section 7 du Serial-HOWTO.
Il est �galement possible de faire cet essai avec uniquement un seul ordinateur, si vous disposez de deux ports s�rie. Vous pouvez lancez deux miniterms sur deux consoles virtuelles. Si vous lib�rez un port s�rie en d�connectant la souris, n'oubliez pas de rediriger /dev/mouse si ce fichier existe. Si vous utilisez une carte s�rie � ports multiples, soyez s�r de la configurer correctement. La mienne n'�tait pas correctement configur�e, et tout fonctionnait correctement lorsque je testais sur mon ordinateur. Lorsque je l'ai connect� � un autre, le port a commenc� � perdre des caract�res. L'ex�cution de deux programmes sur un seul ordinateur n'est pas totalement asynchrone.
Les p�riph�riques /dev/ttyS* sont destin�s � connecter les terminaux � votre machine Linux, et sont configur�s pour cet usage apr�s le d�marrage. Vous devez vous en souvenir lorsque vous programmez la communication avec un p�riph�rique autre. Par exemple, les ports sont configur�s pour afficher les caract�res envoy�s vers lui-m�me, ce qui normalement doit �tre chang� pour la transmission de donn�es.
Tous les param�tres peuvent �tre facilement configur� depuis un programme. La configuration est stock�e dans une structure de type struct termios, qui est d�finie dans <asm/termbits.h> :
#define NCCS 19
struct termios {
tcflag_t c_iflag; /* Modes d'entr�e */
tcflag_t c_oflag; /* Modes de sortie */
tcflag_t c_cflag; /* Modes de contr�le */
tcflag_t c_lflag; /* Modes locaux */
cc_t c_line; /* Discipline de ligne */
cc_t c_cc[NCCS]; /* Caract�res de contr�le */
};
Ce fichier inclus �galement la d�finition des constantes. Tous les modes d'entr�e dans c_iflag prennent en charge le traitement de l'entr�e, ce qui signifie que les caract�res envoy�s depuis le p�riph�rique peuvent �tre trait�s avant d'�tre lu par read. De la m�me fa�on, c_oflags se chargent du traitement en sortie. c_cflag contient les param�tres du port, comme la vitesse, le nombre de bits par caract�re, les bits d'arr�t, etc... Les modes locaux, stock�s dans c_lflag d�terminent si les caract�res sont imprim�s, si des signaux sont envoy�s � votre programme, etc... Enfin, le tableau c_cc d�finit les caract�res de contr�le pour la fin de fichier, le caract�re stop, etc... Les valeurs par d�faut pour les caract�res de contr�le sont d�finies dans <asm/termios.h>. Les modes possibles sont d�crits dans la page de manuel de termios(3). La structure termios contient un champ c_line (discipline de ligne), qui n'est pas utilis� sur les syst�mes conformes � POSIX.
Voici trois fa�ons de lire sur les p�riph�riques s�rie. Le moyen appropri� doit �tre choisi pour chaque application. Lorsque cela est possible, ne lisez pas les cha�nes caract�re par caract�re. Lorsque j'utilisais ce moyen, je perdais des caract�res, alors qu'un read sur la cha�ne compl�te ne donnait aucune erreur.
C'est le mode de fonctionnement normal pour les terminaux, mais peut �galement �tre utilis� pour communiquer avec d'autres p�riph�riques. Toutes les entr�es sont trait�es lignes par lignes, ce qui signifie qu'un read ne renverra qu'une ligne compl�te. Une ligne est termin�e par d�faut avec un caract�re NL (ACII LF), une fin de fichier, ou un caract�re de fin de ligne. Un CR (le caract�re de fin de ligne par d�faut de DOS et Windows) ne terminera pas une ligne, avec les param�tres par d�faut.
L'entr�e canonique peut �galement prendre en charge le caract�re erase, d'effacement de mot, et de r�affichage, la traduction de CR vers NL, etc...
L'entr�e non canonique va prendre en charge un nombre fix� de caract�re par lecture, et autorise l'utilisation d'un compteur de temps pour les caract�res. Ce mode doit �tre utilis� si votre application lira toujours un nombre fix� de caract�res, ou si le p�riph�rique connect� envoit les caract�res par paquet.
Les deux modes ci-dessus peut �tre utilis� en mode synchrone ou asynchrone. Le mode synchrone est le mode par d�faut, pour lequel un appel � read sera bloquant, jusqu'� ce que la lecture soit satisfaite. En mode asynchrone, un appel � read retournera imm�diatement et lancera un signal au programme appelant en fin de transfert. Ce signal peut �tre re�u par un gestionnaire de signal.
Cela ne constitue pas un mode d'entr�e diff�rent, mais peut s'av�rer �tre utile, si vous prenez en charge des p�riph�riques multiples. Dans mon application, je traitais l'entr�e depuis une socket TCP/IP et depuis une connexion s�rie sur un autre ordinateur quasiment en m�me temps. L'exemple de programme donn� plus loin attendra des caract�res en entr�e depuis deux sources. Si des donn�es sur l'une des sources deviennent disponibles, elles seront trait�es, et le programme attendra de nouvelles donn�es.
L'approche pr�sent�e plus loin semble plut�t complexe, mais il est important que vous vous rappeliez que Linux est un syst�me multi-t�che. L'appel syst�me select ne charge pas le processeur lorsqu'il attend des donn�es, alors que le fait de faire une boucle jusqu'� ce que des caract�res deviennent disponibles ralentirait les autres processus.
Hosting by: Hurra Communications GmbH
Generated: 2007-01-26 18:01:16