Discussion :

[Hokagge]

Salut à tous,

Je voulais savoir s'il y avait un moyen de communiquer via un port série bluetooth de manière synchrone, je lu que le mode asynchrone était plus souple et plus mieux mais le problème c'est que la petite appli que je fais nécessite une réception de données sans passer par un buffer.

Merci .

[farscape]

Salut à tous,

Je voulais savoir s'il y avait un moyen de communiquer via un port série bluetooth de manière synchrone, je lu que le mode asynchrone était plus souple et plus mieux mais le problème c'est que la petite appli que je fais nécessite une réception de données sans passer par un buffer.

Merci .

pourquoi ? je ne vois en quoi ça te gene ,le buffer de communication c'est windows qui le gere pas toi .
parce que de toute façon le mode synchrone est bloquant et de mon avis sans espoirs.

[Hokagge]

:'( :'(

J'avais peur de ce genre de réponse,

En fait je doit faire une acquisition de donné d'un boitier GPS, pour l'instant chaque acquisition est régit par un timer, mais le truc c'est que dès que j'ouvre le port, "pof", windows bufferise, et ainsi à l'acquisition d'apres, la fonction de lecture récupère tout ce qu'il y ya dans le buffer, et non ce que lui envoie le boitier GPS à ce moment précis.

Au final je me retrouve avec tout ce que menvoie le gps, et non pas juste quelque trame, récupérées à un moment précis, d'une manière réglée par un timer.

Voila, donc selon toi, ca devient très dur de ne pas passer par le buffer,
mais est-ce qu'il y a toutefois un moyen ??

[farscape]

salut,
tout depend comment tu structures ta reception .
si tu connais la taille precise d'un message retourné ,ça ne devrait pas causer de probleme.

[Hokagge]

J'en sais rien, je peu juste te dire la taille d'un trame pour 1 seconde, parceque le problème est que le GPS envoie en continue sans se préocuper de ce qui se passe derriere :s.

Et il ya un petit traitement derriere également sur une ligne précise.

[mat.M]

J'en sais rien, je peu juste te dire la taille d'un trame pour 1 seconde, parceque le problème est que le GPS envoie en continue sans se préocuper de ce qui se passe derriere :s.

Et il ya un petit traitement derriere également sur une ligne précise.

programmation multithread voire avec des sections critiques ou Events
Pas de Timer

[farscape]

note l'example de la faq fonctionne avec un thread de reception.

[Hokagge]

Heu

moi pas tout comprendre

[farscape]

voir la faq:
http://c.developpez.com/faq/vc/?page...WithSerialPort
il y a un projet pour test en zip.
la reception fonctionne avec un thread.

[Hokagge]

Joli code farscape, chapo,

Mais un peu trop élevé pour moi

En fait je n'arrive pas à voir si ton code utilise un buffer...

Pourrais-tu m'éclairer pleazzzz ?

Merci

[mat.M]

Tout le code utile est là ( bravo Farscape )

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
// utilisation : consultation registres Modem Usr:
CCom com;
com.PortOpen(1,57600,'N',8,0);
com.UseRtsCts();
 
com.SetCommMask(EV_RXCHAR); // spécifie l'événement d'attente.
com.WriteBuffer("ATI7\r\n");
 
DWORD EvtMask;
com.WaitCommEvent(EvtMask);// attente réception 
char sz[1000];
com.ReadBuffer(sz,sizeof(sz));
AfxMessageBox(CString(sz,com.GetCountRead()));

le buffer utilisé est char sz[1000]
Il n'ait pas nécessaire de se préoccuper des fonctions , juste ouvrir le port COM avec PortOpen etc....puis appeler WaitCommeEvent

[Hokagge]

Donc ce code permet de traiter des infos sur le port série, mais toujours de manière asynchrone...

Bon bah je croi qu'il va falloir que je me fasse une raison, ( pas de synchrone ).

[farscape]

Donc ce code permet de traiter des infos sur le port série, mais toujours de manière asynchrone...

Bon bah je croi qu'il va falloir que je me fasse une raison, ( pas de synchrone ).

Non pas de synchrone à part si tu veux bloquer ton application.
la séquence montrée par Mat.M correspond a une utilisation séquentielle du traitement série pouvant convenir dans un programme en mode console .
La classe fonctionne aussi avec mode thread de réception.
c'est qui est implémenté dans l'exemple avec le zip.
Oubli ton timer, regarde ce qui est fait ...
de la com série j'en ai fais dans tout les sens avec toutes sortes de devices
Alors je serais étonné que ça ne fonctionne pas dans ton cas.

[Hokagge]

Le but de mon prgramme est de récupérer une trame venant du boitier GPS, et il est important que cette récupération se fasse a un moment, et un fréquence bien précise, c'est pourquoi le timer est idéale, le code qui est montré semble être visiblement un bon code, mais il ne peut pas coller avec ce que je veu faire, la seul solution était le mode synchrone, et le WaitCommEvent ne également pas coller avec mon appli.

Merci pour toutes vos réponse et a votre code, mais j'ai l'impression que je que je veu faire est impossible.

[farscape]

ben alors suspend le thread de reception et dans le timer tu le reactive ...

[Hokagge]

Mais le problème ne rique t'il pas d'être le même?

A savoir, une bufferisation des données à partir du moment ou je le suspend, jusqu'à la reprise ?

[farscape]

si tu le suspend ,pas de reception ,maintenant la question qui se pose qu'elle est la gestion de flux implementé ?
ton gps s'arrete d'emettre si le pc n'est pas pret ?

[Hokagge]

Le GPS envoie en continue a partir du moment ou il est allumé, il ne tien absolument pas compte d'un quelconque récepteur,

Mais quand tu dit que quand on le suspend, a partir du moment ou le port série (plus précisement le bluetooth) est ouvert il ne bufferise pas tt ce qu'il lui vient (il, c'est à dire le buffer d'entrer, input buffer) ?

[farscape]

il va remplir son buffer de reception windows ,quand il est plein ce qui suivra sera perdu .
avant de reactiver le thread il suffira de puger le com .

[Hokagge]

Le PurgeComm va bien vider le buffer ??

Si il est vide, comment va faire ma fonction de lecture pour récupérer quelquechose qui sera disparu ?