Optimisation de l'utilisation du port COM en C++ sous linux

**mithraw** · 07/07/2009, 11h21

Salut,
J'utilise la bibliothèque Termios pour faire de la lecture écriture sur port série.
Mais j'obtiens des taux de transferts vraiment trop bas...
J'aurai aimé savoir si l'un de vous avait une idée sur comment améliorer ça...

Voilà les bouts de codes en rapport avec l'utilisation du port série :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
//ouverture et configuration du port :
 handle = open(m_comname.c_str(), O_RDWR | O_NOCTTY);
    if (handle < 0) {
      return OC_CREATE_HANDLE_ERR;
    }
    struct termios newtio;
    bzero(&newtio, sizeof (newtio));
 
    newtio.c_cflag = m_baudrate | CS8 | CLOCAL | CREAD;
    newtio.c_iflag = IGNPAR;
    newtio.c_oflag = 0;
 
    /* set input mode (non-canonical, no echo,...) */
    newtio.c_lflag = 0;
 
    newtio.c_cc[VTIME] = 1; /*0.1sec timeout between each char*/
    newtio.c_cc[VMIN] = 188; /* blocking read until 188 chars received (max length of a reading) or until timeout exceed*/
    newtio.c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP
            | INLCR | IGNCR | ICRNL | IXON);
    newtio.c_oflag &= ~OPOST;
    newtio.c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN);
    newtio.c_cflag &= ~(CSIZE | PARENB);
    newtio.c_cflag |= CS8;
 
 
    tcflush(handle, TCIOFLUSH);
    tcsetattr(handle, TCSANOW, &newtio);
 
//Lecture ecriture :
    tcflush(handle, TCIOFLUSH);
    bStatus = write(handle, pSendBuf, sendLength);
    if ((bStatus == 0) || (bStatus == -1)) {
        return TRANSMIT_ERR_WRITE;
    }
 
    bStatus = read(handle, pRecvBuf, 255);
    if (bStatus < 0) {
        return TRANSMIT_ERR_WRITE;
    }
 
    recvLength = bStatus;

Merci beaucoup d'avoir ne serait-ce que jeter un œil a mon code...
Avec cette méthode là, j'ai réussi a améliorer déjà pas mal la réactivité, mais pas encore assez pour rendre tout ça utilisable...

A++
Fabien

**3DArchi** · 07/07/2009, 12h22

Salut,
Que vaut m_baudrate ? A quoi sert newtio.c_cc[VTIME] ? Est-ce cohérent avec m_baudrate ?

**mithraw** · 07/07/2009, 12h47

m_baudrate = B9600 , c'est la variable définissant le fonctionnement d'un port com en 9600bps
newtio.c_cc[VTIME] sert de timeout, ici de timeout de réception entre chaque caractère.
extrait du man:
VMIN Nombre minimal de caractères lors d’une lecture en mode non
canonique.

VTIME Délai en dixièmes de seconde pour une lecture en mode non canonique.

Dans le mode non canonique, l’entrée est disponible tout de suite (sans
que l’utilisateur ait à taper de caractère délimiteur de ligne) et
l’édition des lignes est désactivé. La valeur des paramètre MIN
(c_cc[VMIN]) et TIME (c_cc[VTIME]) détermine les circonstances dans
lesquelles read(2) se termine ; il y a quatre cas différents :

* MIN == 0; TIME == 0 : Si des données sont disponibles, read(2)
retourne immédiatement le nombre d’octets disponibles ou le nombre
d’octets demandés (le plus petit des deux). Si aucune donnée n’est
disponible, read(2) renvoie 0.

* MIN > 0; TIME == 0 : read(2) est bloquant jusqu’à ce que MIN octets
ou le nombre d’octets demandés soient disponibles, puis renvoie le
plus petit de ces nombres.

* MIN == 0; TIME > 0 : TIME spécifie une limite de temps en dixièmes de
secondes. Le décompte du temps est démarré lors de l’appel à read(2).
read(2) retourne si au moins un octet est disponible ou si la tempo‐
risation expire. Si la temporisation expire sans qu’il n’y ait eu de
données disponibles, read(2) renvoie 0.

* MIN > 0; TIME > 0 : TIME spécifie une limite de temps en dixièmes de
secondes. Quand un premier caractère est disponible en entrée, la
temporisation est démarrée, puis remise à zéro à chaque caractère
reçu. read(2) retourne quand le nombre d’octets demandés ou MIN
octets ont été lus, ou si le délai entre deux octets est dépassé.
Comme la temporisation n’est démarrée que lors de la réception du
premier octet, au moins un octet sera lu par read(2).

**3DArchi** · 07/07/2009, 13h03

Envoyé par mithraw

m_baudrate = B9600 , c'est la variable définissant le fonctionnement d'un port com en 9600bps
newtio.c_cc[VTIME] sert de timeout, ici de timeout de réception entre chaque caractère.

Ok. Alors, tes deux équipements peuvent-ils communiquer par un taux de transfert plus important ? Il me semble qu'on peut monter jusqu'à 115.2 kbps. Existe-t-il un B115200 ?

**mithraw** · 07/07/2009, 13h12

non, ils ne peuvent pas aller plus vite... :/

**3DArchi** · 07/07/2009, 13h18

Tu as regardé du côté de la taille des buffers d'émission et de réception : sont-ils adaptés à la taille de tes trames ?

**Mac LAK** · 07/07/2009, 13h22

Je rappelle, au cas où, que 9600 bauds correspondent, en RS-232, à un taux de transfert maximal de 1,171875 ko/s... Et encore, à 8 bits de données, pas de parité, pas de bits de stop en plus. Et sans compter les octets dûs au protocole logique, hors encodage !

Donc, si tu es vers 1 ko/s de taux de transfert, c'est (hélas) tout à fait normal... Si tu es bien plus bas que ça, il faudra peut-être envisager un thread de gestion, c'est en général ainsi que je procédais pour tenir des taux et une réactivité corrects avec les liaisons série.

**mithraw** · 07/07/2009, 13h52

Merci encore pour vos réponses, c'est vraiment super sympa de m'aider!

Pour ce qui est des buffers, ils sont corrects, juste suffisant pour envoyer et recevoir les données...
Pour ce qui est des pertes, j'ai l'impression qu'ils sont due a la gestion des timeout trop large... mais je ne sais pas trop comment l'affiner... sous windows par exemple les timeouts sont en millisecondes, là c'est en dixième de seconde ... :/
Parce que quand la réponse est de 15 octets, il va attendre 100ms de plus qu'un autre octet n'arrive... hors, il doit y avoir 50% de réponses qui contiennent moins de la taille max (188 octets) ...
La fonction en question est une fonction bas niveau de mon api de lecture, il est donc difficile pour elle de déterminer ce qu'elle va recevoir ...
C'est pour ça que je pense qu'il serait mieu de voir du coté des timeout ...

**caradhras** · 07/07/2009, 14h13

Salut!

Je sais pas si ça va t'aider mais j'ai eu l'occasion de travailler sur un projet qui nécessitait l'utilisation d'un port COM sous linux. Bon c'était un projet en Ruby certes mais les quelques suggestions que je pourrais te faire sont p-e adaptables :

L'émission et la reception de données étaient gérées par un thread. Mieux encore, si mes souvenirs sont bons, la meilleure solution que nous avions trouvé était l'utilisation d'un "select" car sauf erreur, les ports COM sous linux utilisent des fichiers comme buffer (les fameux tty.... me semble-t-il) et le "select" permettait de garder un oeil sur le descripteur de fichier pour guetter toute modification (réception d'un caractère entre autre).

Ce ne sont que des pistes (que p-e quelqu'un de plus expérimenté pourrait confirmer/infirmer) qui j'espère t'aideront. Je vais essayer de retrouver la doc que j'avais fait pour ce projet voir s'il n'y a pas quelque chose d'utile pour toi dedans.

**mithraw** · 07/07/2009, 14h18

Un select ?
Ca correspond a un genre de trigger ?

**caradhras** · 07/07/2009, 14h25

C'est une fonction de synchronisation qui permet d'attendre un événement (par exemple la réception d'un caractère sur le port COM). J'avais utilisé ça pour un projet. Le select était dans une boucle while infinie (enfin... avec une condition d'arrêt quand même). Et ce while dans un thread. Ainsi, durant toute la durée de vie du thread, le select vérifie la reception de caractères. Il me semble qu'on peut lui dire d'exécuter une fonction à chaque fois qu'il sort de son état d'attente. Une fonction du genre "lecture sur le port COM".

Encore une fois, si quelqu'un pouvait confirmer ça serait top

Que je t'envois pas sur de fausses pistes.

[EDIT 1] Détail important : l'attente du select est une attente inactive
[EDIT 2]http://www.linux-kheops.com/doc/man/.../select.2.html

Optimisation de l'utilisation du port COM en C++ sous linux

C++

Discussions similaires

Partager

Partager