lecture du port serie

Bonjour à tous,

J'ai fait le programme suivant pour envoyer une ligne de commande au port serie , puis récupérer la réponse. mais malheureusement, je n'arrive pas à récupérer l'information.

Code:

---

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

#include <stdio.h> #include <opencv/highgui.h> #include <fcntl.h> int main() { int _platine; int entete; _platine = open("/dev/ttyS0", O_RDWR | O_NOCTTY | O_NDELAY); if(_platine <0) { perror("Erreur d'ouverture du port serie"); exit(-1); } else { write(_platine,"VLIM\r",5); read(_platine, &entete, sizeof(entete)-1); printf ("VLIM = %d", entete); } }

---

Je récupère toujour la valeur 0, normalement je dois récuperer la valeur 2500.

Il te faudrait un peu plus de gestion d'erreur pour nous aiguiller.

• Essaie de tester le retour des write et read. Comme ça tu vérifies que l'écriture a bien marché, et que tu lis bien le bon nombre d'octets.
• Pourquoi lis-tu 3 octets ?
• Tu reçois bien un int ? Pas un short ? Essaie de faire un read de char par char en affichant le résultat en hexa : "%.02X"
• Oublie pas ton \n à la fin de ton printf
• Oublie pas le close à la fin
• Où as-tu réglé ton baudrate ? Ton termios est déjà configuré ?

Un truc du genre :

Code:

---

1 2 3 4 5 6 7 8

int ret; unsigned char c; while (1) { ret = read(_platine, &c, 1); printf("read (%d) : %.02X\n", ret, c); }

---

meme avis que le modérateur ci-dessus.

Après pour le read = 0, je pense que le problème vient de l option O_NDELAY lorsque tu récupères le file descriptor, le read est alors non-bloquant. En conséquence lorsque tu fais une lecture, read t indique qu il n a rien dans son buffer UART car ton périphérique ne t as pas encore répondu.

Meilleures salutations.

Si tu essayes de lire ce que tu viens d'écrire, il me semble que ce n'est pas possible. Si j'ai bonne mémoire, j'ai lu un sujet sur Developpez où le PO voulait faire ça et quelqu'un avait répondu que écrire sur le port série donne un signal au fil TX et que le lire lit le signal du fil RX. S'ils ne sont pas reliés, il n'y a pas de raison que le signal de sortie boucle sur l'entrée.

Enfin j'ai trouver la solution: il me fallait déclarer buffer (entete) en tant que tableau et rajouter la fonction :

Code:

---

1 2 3

char buffer[255]; /* Input buffer */ fcntl(fd, F_SETFL, 0);

---

donc mon programme final est (peut être ça va servir d'autres personnes) :

Code:

---

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

#include <iostream> #include <stdio.h> /* Standard input/output definitions */ #include <fcntl.h> /* File control definitions */ using namespace std; int main(void) { char buffer[255]; /* Input buffer */ int fd = open("/dev/ttyS0", O_RDWR | O_NOCTTY | O_NDELAY); if (fd == -1) { perror("open_port: Unable to open /dev/ttyS0 - "); return 1; } else { fcntl(fd, F_SETFL, 0); write(fd, "VLIM\r",5); read(fd, buffer, sizeof(buffer) - 1); cout << buffer << endl; close(fd); } return (0); }

---

Ravi que ça fonctionne.

Néanmoins, je suis curieux. Je ne comprends pas trop ce qu'apporte l'appel à fcntl qui va si je ne m'abuse paramétrer ton file descriptor à 0 (O_RDONLY). En faisant ça tu écrases complètement ta configuration. Généralement, fcntl et F_SETFL est plutôt utilisé avec F_GETFL pour ne pas perdre ta configuration initiale.

Bref, dans la mesure où tu es en O_RDWR et O_NDELAY (=O_NONBLOCK) j'ai du mal à comprendre en quoi l'appel à fcntl corrige le problème.

Je me mettrais bien dans les mêmes conditions pour tester, mais je n'ai pas le même contexte. Si quelqu'un a une explication, je suis preneur.

Quoi qu'il en soit, ssssa1983 si tu peux le faire, je te conseille vivement de gérer tous les cas d'erreurs. Ça n'en sera que mieux pour les potentielles prochaines erreurs.