Discussion :

[kenous9]

bonjour,

J'ai actuellement un boitier communiquant avec le PC par le port série qui présente les caractéristiques suivantes:
bauds=56700 kbits/s
data_bit=8
parity=none
flowcontrol=none
bitstop=1
Le protocole de communication s'énonce comme suit:
1.envoi d'une trame de 6 octets(PC -> boitier):demande d'acquisition
2.réception d'une trame de 8 octets(boitier -> PC):confirmation acquisition
3.reception en continu de trame (encadré par 2 octet de valeur connue et de 2 octets de numérotation de trame modulo 256) de 136 octets au total (vitesse de réception de 56700 kbits/s) telle que l'on ait 18 trames de 136 octets reçus par seconde.

J'ai donc utilisé le programme du paragraphe 3.2 du lien suivant:http://christophej.developpez.com/tu...java/javacomm/ que j'ai évidemment adapté en modifiant la fonction communique, en supprimant le main et les threads car j'instancie la classe à partir d'une interface graphique.
Il se trouve que si je demande l'affichage des données reçus dans la fonction d'interruption ( serialEvent(SerialPortEvent event)) et l'affichage de la taille du buffer d'entrée avec les instructions:fluxLecture.read() et serialPort.getInputStream().available(). Je constate que lorsque le buffer d'entrée atteint sa valeur limite(4096 par défaut),il se vide automatiquement provoquant une trame reçue de taille complètement farfelue couplé avec un saut de trame(50 trames sautées). Or je souhaite pourvoir faire une lecture caractère par caractère sans perdre d'information.

Pour comprendre le mécanisme, j'ai supprimé les différents affichages à l'intèrieur de la fonction d'interruption:serialEvent(SerialPortEvent event) afin de les remplacer par l' incrémentation d'une variable globale à la classe. Puis j'affiche la taille du buffer d'entrée et de la valeur de la variable globale à la sortie du programme. Je constate alors que le rapport (taille du buffer d'entrée)/(valeur de la variable globale)= 4.5. Ce qui signifie que je n'ai pas autant d'appel de la fonction serialEvent(SerialPortEvent event) que de donnée reçue.

Voici donc mes questions:
y a t'il une solution pour obtenir une lecture caractère par caractère? Si non, Est ce que la librairie payante Serialio le permet?
Peux t'on vider le buffer d'entrée sans avoir à lire toutes les données?

Merci par avance

[jowo]

Bonjour,

J'ai plusieurs questions:

- D'où provient la taille 4096bytes de t on buffer?

- Travailles-tu sans contrôle de flux (soft ou hard)?

- Ton PC, possède-t-il un carte de communication supplémentaire ou utilises-tu son port COM?

[kenous9]

Bonjour,


En ce qui concerne la taille du buffer d'entrée de 4096 bytes:
Comme je reçois plus vite les données que ce que j'arrive à les lire (1 octet lu pour 4,5 reçus) (d'où mon problème de saturation du buffer se traduisant par un vidage automatique), j'ai constaté par affichage (instruction: serialPort.getInputStream().available())que c'est la taille maximale du buffer d'entrée du port série quand on n'utilise pas l'instruction:serialPort.setInputBufferSize(int i) pour spécifier la taille du buffer d'entrée. D'ailleurs, j'ai remarqué que nous pouvons pas spécifier une taille inférieur à 4096 même en utilisant l'instruction précedemment citée. Par contre, une taille supérieur est possible mais cela ne fait que retarder dans le temps mon problème.

En ce qui concerne le contrôle de flux:
Le boitier a été conçut de façon à ce qu'il soit le plus rapide possible dans sa gamme de débit d'émission(57600 kbits/s). Par conséquent, il n'y a ni contrôle logiciel ni contrôle matériel au niveau de la liaison PC -boitier. C'est pour cela que ma fonction d'interruption est active exclusivement que sur la présence de donnée . Par contre, les trames que je reçois de manière continu (émis de manière autonome par le boitier) ont une structure particulière permettant leur traitement logiciel (ici Java).C'est à dire que mon premier octet est toujours un 2(décimal), l'octet suivant correspond à un octet de mode de configuration, puis les 2 octets suivants sont des octets de numérotation de trame modulo FF,puis j'ai un certain nombre d'octet d'information. Et enfin j'ai un octet de fin de trame:toujours le 13(décimal).

En ce qui concerne mon système de communication:
Je communique avec le boitier par le port COM1 du PC.

merci pour votre aide

[jowo]

Première vérification:

As-tu coché la case pour l'utilisation du FIFO (compatible UART 16550) de COM1 (Gestionnaire hardware)? Ce qui te permet d'avoir un tampon de 16octets.

Tu écris 57600kbit/s, ne serai-ce pas plutôt 57600bits/s?
En effet, 57600kbit/s équivalent à 57.6Mbits/s correspondant à envrion 6MB/s. Je comprends que ton COM ne puisse pas suivre une telle cadence.

Ne pas utiliser le contrôle de flux à ces vitesses, à mon opinion, est un mauvais choix.

[kenous9]

Tu as raison pour les 57600 bits/s. C'est une erreur de ma part lors de ma dactylographie.
En ce qui concerne les paramètres matérielles: l'utilisation tampon FIFO est bien activé avec

[jowo]

As-tu essayé de communiquer avec ton boîtier à l'aide du programme HyperTerminal ou une autre logiciel équivalent?

[kenous9]

tampon de réception:14
tampon d'émission:16

[kenous9]

En fait le but de mon programme est de ne plus utiliser le logiciel Max. Or il se trouve que ce logiciel écrit en C gère sans problème le port série (lecture caractère par caractère). Se peux t'il que le problème vienne des problèmes de performances de l'API Sun?
Par conséquent, j'aimerais savoir si vous avez déjà utilisé l'API Serialio(serialio.com) qui est certes payant mais qui parait-il est plus performant que l'API de Sun?

merci d'avance