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

[kenous9]

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

[jowo]

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

[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

[kenous9]

Je n'ai pas utiliser le logiciel HyperTerminal. Par contre, j'ai bien vérifié le fonctionnement de mon boitier. Comme vous l'avez remarqué,je reçois plus de donnée que d'appel de la fonction serialEvent(SerialPortEvent ev). Alors connaissant parfaitement mon protocole de communication de mon boitier, j'ai finté. C'est à dire qu'à chaque fois que je rentre dans ma fonction d'interruption, j'effectue une lecture multiple afin de vider le buffer. Le résultat est bon mais je n'effectue pas une lecture caractère par caractère car je lis un groupe de donnée à chaque appel de la fonction d'interruption. De plus, cela suppose que les intervalles des appels de ma fonction d'interruption soit constante pour ne pas avoir un stockage trop important de donner dans le buffer d'entrée.

[jowo]

Ta finte n'en est pas une

En effet, c'est ainsi qu'il faut coder pour lire les données du port sériel.

Je crois que tu confonds interruption et événement. Avec l'API JavaComm, tu ne reçois pas d'interruption mais un événement (un message).

Pourquoi désires-tu lire caractère par caractère?
Car en lisant la description de ton protocole, je ne vois pas la nécessité d'effectuer une telle opération.


Pour finir
Borland: Java Communication API

[kenous9]

Mon désir de lire caractère par caractère peut s'expliquer essentiellement par le fait que j'ai plus souvent fait des programmes pour microcontroleur ou DSP(où dans mon esprit la gestion des interruptions=performance) que de programme pour PC.
Je te remercie pour ces informations car jusqu'à présent je pensais que ce n'était pas normal de ne pas pouvoir lire caractère par caractère. Par conséquent, je vais donc modifier mon programme pour m'adapter au mode de fonctionnement de l'API.
Pour finir, j'aimerais savoir si l'API permet de gérer des ports série virtuel,si oui? Combien?

merci par avance

[jowo]

Je comprends mieux pourquoi tu désirais lire caractère par caractère

Ce qui concerne les ports virtuels, je ne suis pas 100% sûr de ma réponse, je ne vois aucun problème. L'OS propose les ports virtuels comme les ports "normaux" COM1, COM2.

L'API peut gérer autant de ports que le système propose. Il y aura probablement un problème de performance si ton programme doit en gérer une centaine.

[kenous9]

Je te remercie encore pour toutes ces informations précieuses.