Linux, ports série et pb de synchronisation (pour experts)

Linux, ports série et pb de synchronisation (pour experts) - C++ - Programmation

Marsh Posté le 24-03-2003 à 16:48:55    

Salut,
 
Je developpe actuellement une application sur une carte PC104 ( PC embarqué, compatible x86) avec linux d installé dessus. Or sur cette carte il n y a que 2 ports serie (comme la plupart des PC) . J ai donc rajouté une carte d 'extension avec 2 ports supplémentaires.
 
Sachant que jai besoin de 3 ports série, j ai donc 3 Threads auxiliaires  tournant sur chacun des ports. Le pb est que j'ai un pb de synchro. Explication :
 
Sur le port ttyS0 j ai un cable relié à un bus CAN (avec une interface CAN-RS232) qui dialogue dans les 2 sens.
 
Sur le port ttyS1, j ai un controleur série de dalle tactile , le driver dialogue dans les 2 sens pour la config (au demarrage de X) mais sinon ne fait que lire ce qu il y a sur le port.
 
Sur le port ttyS2 , je suis relié a une carte controleur d ecran TFT , je ne fait qu envoyer des trames (j ignore la reception meme si il y a des trames recues).
 
 
Le pb est que : si j envoie une trame dans ttyS2 , elle n est envoyée que 5 sec(ou carrement ignorée!!) apres SAUF si entre temps je recois ou j emets quelque chose dans ttyS0 (apparemment il y a une relation maitre-esclave entre port 0 et 2 , mais aussi port 1 et 3)
 
si j'inverse ttyS2 et ttyS3, cette fois ci ca ne fonctionne plus et ca fait planter le driver de la dalle tactile (toujours pb relation port 1 / port 3)
 
si par contre je debranche ttyS1 (la dalle tactile) et que je configure mon envoi vers le controleur dalle TFT sur le port ttyS1 (il ne reste plus que ttyS0 et ttyS1) ca marche nickel , c est instantané et pas de plantage
 
J ai evidemment loggué mes envois : ca marque bien que le write a été fait (sans retour d erreur) mais il est "vraiment envoyé" seulement 5 sec apres .
 
Je pense donc que les ports ttyS0/ttyS2 et ttyS1/ttyS3 sont dépendant l'un de l autre (relation maitre / esclave commme je le disais) mais je ne comprends pas trop la reaction.
 
Est ce que j ai quelque chose a configurer sur le port (genre un fcntl) ???
 
 
Ou alors c peine perdue, on ne peut pas utiliser 4 ports en meme temps ? (dans ce cas, faut me dire l interet d avoir 4 ports :-/ )
 
 
Merci de vos reponses

Reply

Marsh Posté le 24-03-2003 à 16:48:55   

Reply

Marsh Posté le 25-03-2003 à 09:33:22    

Salut,
je pense que tes données sont bufferisées en écriture, c'est-à-dire que lorsque tu les envoie, elles sont simplement recopiées dans un buffer. Elles sont envoyées 'pour de vrai' un peu plus tard, par exemple après un timeout.
 
Un petit flush devrait te permettre de forcer leur envoi.
 
J'ai pas d'info plus précises sous la main, mais tu trouveras peut-etre des trucs intéressants sur ce site:
 
http://www.linuxdevices.com/articles/AT5727959130.html
 
Bon courage !

Reply

Marsh Posté le 25-03-2003 à 09:53:21    

La piste la plus probable est celle du flush
 
Une autre piste à "creuser" est l'allocation des réssources I/O, IRQ, etc. Si tes ports partagent dynamiquement ces ressources, certaines tâches peuvent être considerer comme prioritaires; ou encore, un thread qui veut écrire le truc A mais ne peut pas car les ressurces sont occupées, plutard, tu lui démande écrire le truc B et il s'execute, c'est-à-dire que le truc A n'a pas été fait ...

Reply

Marsh Posté le 25-03-2003 à 11:10:16    

et comment on fait un flush sur un port ? il me semblait que l action d un write vidait automatiquement les buffers ????
 
 
en tout cas merci de vos reponses :)

Reply

Marsh Posté le 25-03-2003 à 11:20:39    

FFLUSH(3)                 Manuel du programmeur Linux                FFLUSH(3)
 
NOM
       fflush - Vider les buffers d'un flux.
 
SYNOPSIS
       #include <stdio.h>
 
       int fflush (FILE *flux);
 
DESCRIPTION
       La  fonction  fflush force l'écriture de toutes les données se trouvant
       dans les buffers de l'espace utilisateur, et  met  à  jour  le  flux  à
       travers  la  fonction sous-jacente d'écriture. Le statut d'ouverture du
       flux n'est pas affecté.
 
       Si l'argument flux est NULL, fflush vide tous les flux en sortie.
 
VALEUR RENVOYÉE
       Si elle réussit intégralement, cette fonctions renvoie 0.  Sinon,  elle
       renvoie EOF, et la variable errno contient le code d'erreur.
 
ERREURS
       EBADF  flux n'est pas ouvert, ou du moins pas en écriture.
 
       La  fonction  fflush  peut  aussi  échouer,  et  positionner dans errno
       n'importe quelles erreurs spécifiées dans la routine write(2).
 
NOTES
       Remarquez que fflush ne vide  que  les  buffers  fournis  par  la  bib-
       liothèque  C dans l'espace utilisateur.  Pour s'assurer que les données
       sont écrites physiquement sur le disque, il faut vider les  buffers  du
       noyau à l'aide par exemple de sync(2) ou fsync(2).
 
CONFORMITÉ
       La fonction fflush est conforme à ANSI X3.159-1989 (``ANSI C'').
 
VOIR AUSSI
       write(2), fclose(3), fopen(3), fsync(2), sync(2), write(2), setbuf(3)
 
TRADUCTION
       Christophe Blaess, 1997.
 
BSD                              30 Août 2000                        FFLUSH(3)

Reply

Marsh Posté le 25-03-2003 à 13:21:14    

:(
 
 
j utilise les fonctions de bas niveau, autrement dit je fais un write sur un descripteur de fichier et non sur un flux ...  
 
bon c pas grave, de toute facon je ne pense pas que le pb soit la car d ecrire sur le 3eme perturbe parfois le port maitre associé.
 
 

Reply

Marsh Posté le 25-03-2003 à 13:50:44    

FERROR(3)                 Manuel du programmeur Linux                FERROR(3)
 
NOM
       ferror,  clearerr, feof, fileno - Vérifier et réinitialiser les statuts
       d'un flux.
 
SYNOPSIS
       #include <stdio.h>
 
       void clearerr (FILE *stream);
       int feof (FILE *stream);
       int ferror (FILE *stream);
       int fileno (FILE *stream);
 
DESCRIPTION
       La fonction clearerr efface les  indicateurs  d'erreur  et  de  fin  de
       fichier concernant le flux pointé par stream.
 
       La  fonction  feof  teste  l'indicateur de fin de fichier concernant le
       flux pointé par stream, et renvoie une valeur non nulle si cet  indica-
       teur  est  actif.  L'indicateur  de  fin de fichier ne peut être réini-
       tialisé que par la fonction clearerr.
 
       La fonction ferror  teste  l'indicateur  d'erreur  concernant  le  flux
       pointé par stream, et envoie une valeur non nulle si cet indicateur est
       actif. L'indicateur d'erreur ne peut être réinitialisé que par la fonc-
       tion clearerr.
 
       La  fonction  fileno renvoie le descripteur de fichier, de type entier,
       correspondant au flux stream.
 
ERREURS
       Ces fonctions ne devraient pas échouer, et ne positionnent donc pas  la
       variable errno.
 
CONFORMITÉ
       Les  fonctions  clearerr,  feof, et ferror sont conformes à X3.159-1989
       (``ANSI C'').
 
VOIR AUSSI
       open(2), stdio(3).
 
TRADUCTION
       Christophe Blaess, 1997.
 
BSD                             23 Octobre 1996                      FERROR(3)

Reply

Marsh Posté le 25-03-2003 à 13:55:51    

xilebo a écrit :

:(
bon c pas grave, de toute facon je ne pense pas que le pb soit la car d ecrire sur le 3eme perturbe parfois le port maitre associé.


IRQ et I/O
 
EDIT: il y a beaucoup de choses qui accedent aux fichiers et autres ressources?


Message édité par western le 25-03-2003 à 13:57:13
Reply

Marsh Posté le 25-03-2003 à 16:26:46    

dans mon appli je n'ecris que sur le port  
/dev/ttyS0 (mon bus CAN)
/dev/ttyS3 (la carte controleur TFT)
 
je n ecris jamais sur /dev/ttyS1 ( c pas a moi de le faire, c au driver)
 
 
Or si j ecris dans /dev/ttyS3 ca me perturbe /dev/ttyS1 et le driver me dit qu il y a des pertes de synchros(en gros des caracteres inutiles)
 
donc a mon avis c pas un pb de flush mais de dependance de port.... :(

Reply

Marsh Posté le 25-03-2003 à 16:44:11    

xilebo a écrit :

dans mon appli je n'ecris que sur le port  
/dev/ttyS0 (mon bus CAN)
/dev/ttyS3 (la carte controleur TFT)
 
je n ecris jamais sur /dev/ttyS1 ( c pas a moi de le faire, c au driver)
 
 
Or si j ecris dans /dev/ttyS3 ca me perturbe /dev/ttyS1 et le driver me dit qu il y a des pertes de synchros(en gros des caracteres inutiles)
 
donc a mon avis c pas un pb de flush mais de dependance de port.... :(


Quelle confiance as-tu dans ton driver? A priori tu écrits/lis sur 3 ports en utilisant le noyau pour le premier et le dernier, et driver spécifique pour le seconde, et c'est ce dernier qui te dit qu'il y a pertes de données, c'est-à-dire que le noyau gére mal tes ports!  
Certes, tu peux essayer de regarder de côté de noyau pour savoir s'il y a une option spécifique à activer pour que ton drive se taise mais j'en doute que tu en trouves à moins que le driver a besoin d'un mode spécifique (synchrone/asynchrone) mais il faut commencer par vérifier la config' hardware ...

Reply

Marsh Posté le 25-03-2003 à 16:44:11   

Reply

Marsh Posté le 25-03-2003 à 21:38:23    

j ai le source du driver (driver ecrit par le constructeur de la dalle tactile que j utilise http://www.elotouch.com) et je ne vois pas d erreur dedans.
 
 
et je precise si j inverse /dev/ttyS3 avec /dev/ttyS2 , mon /dev/ttyS0 n'est pas "perturbé" ... par contre si j envoie des donnees dans /dev/ttyS2, ca met 5 sec SAUF si je lis ou j ecris dans /dev/ttyS0. C est vraiment bizarre
 
 
Et le pb , c que je ne peux pas mettre mes ports ttyS2 et ttyS3 sur d autres IRQ car c une carte additionnelle qui se configure par jumper et j ai peu de choix pour les IRQ (chui vert par contre le port paralle ne me sert , ca me bouffe un IRQ et je peux pas l enlever)
 
 
 :bounce:

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed