Version imprimable
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 .Citation:
Envoyé par Hokagge
parce que de toute façon le mode synchrone est bloquant et de mon avis sans espoirs.
:D
:'( :'(
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 ??
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.
:D
:D
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.
:arrow: programmation multithread voire avec des sections critiques ou EventsCitation:
Envoyé par Hokagge
Pas de Timer
note l'example de la faq fonctionne avec un thread de reception.
:D
Heu :oops:
moi pas tout comprendre
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.
:D
Joli code farscape, chapo,
Mais un peu trop élevé pour moi :oops: :oops:
En fait je n'arrive pas à voir si ton code utilise un buffer...
Pourrais-tu m'éclairer pleazzzz ?
Merci
Tout le code utile est là ( bravo Farscape )
le buffer utilisé est char sz[1000]Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
Il n'ait pas nécessaire de se préoccuper des fonctions , juste ouvrir le port COM avec PortOpen etc....puis appeler WaitCommeEvent
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 :pleure: :pleure: ).
Non pas de synchrone à part si tu veux bloquer ton application.Citation:
Envoyé par Hokagge
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.
:D
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.
ben alors suspend le thread de reception et dans le timer tu le reactive ...
:D
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 ?
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 ?
:D
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) ?
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 .
:D
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 ?
Bon voila, je change de fusil d'épaule, en utilisant, la fonction WaitCommEvent(),
Seulement voila:
Mon programme reste bloqué sur le WaitCommEvent(), qu'il y ai le PurgeComm ou non....Code:
2
3
Qu'en pensez vous ?
J'ai l'impression de saouler tt les monde avec mes question :triste:
je ne vois pas ce qui te permet d'affirmer ça 8O ,Citation:
Envoyé par Hokagge
sinon pour revenir à ton probleme
Pour moi il y a incohérence
Le GPS émet « au fil de l’eau » des informations apparemment non structurées
(Même pas un caractère de début ou fin de message ?)
Tu as un impératif de timer pour lire les informations (pourquoi d’ailleurs ?).
Tu dis il est important que cette récupération se fasse a un moment, et un fréquence bien précise.
Et pendant ce temps que se passe t’il pour l’émetteur ?, il continue d’émettre sans ce soucier du récepteur.
Dans ces conditions la seule solution valable que je vois c’est de réceptionner les données en permanence dans une pile de réception.
Quand le Timer se déclenche il suspend le thread de réception il lit la donnée la plus récente de la pile pour l’afficher/traiter, et il la purge et redémarre le thread.
Mais encore une fois ça reste valable si tu es capable de déterminer au moins le début ou la fin d’un message ne serait ce que par un retour chariot.
je sais pas si ca peux t'aider comme aproche .
mais quand j'ai géré un pointeur souris sur port série . je lisais octet par octet en continu avec un thread de lecture .
en general y a un octet de synchro , sur lequel je me callais pour lire le reste ( coordonnée pointeur etc.. )
comme le dit farscape , verifies qu'il n'y ait pas une valeur qui revienne régulierement en debut ou fin de trame .
Il y a un '$' a chaque début de ligne, et en fait je traite les trames qui m'intéressent; exemple de ce qu'envoie le GPS:
$GPGGA,104554.813,0000.0000,N,00000.0000,E,0,00,50.0,0.0,M,,,,0000*30
$GPGLL,0000.0000,N,00000.0000,E,104554.813,V*28
$GPRMC,104554.813,V,0000.0000,N,00000.0000,E,0.00,,060605,,*04
$GPVTG,,T,,M,0.00,N,0.0,K*7E
$GPGGA,104555.813,0000.0000,N,00000.0000,E,0,00,50.0,0.0,M,,,,0000*31
$GPGLL,0000.0000,N,00000.0000,E,104555.813,V*29
$GPGSA,A,1,,,,,,,,,,,,,50.0,50.0,50.0*05
$GPGSV,3,1,12,25,89,000,,31,81,000,,27,59,000,,03,46,000,*7D
$GPGSV,3,2,12,01,39,000,,13,37,000,,29,33,000,,11,15,000,*79
$GPGSV,3,3,12,28,-1,000,,08,-5,000,,22,-6,000,,23,-8,000,*73
$GPRMC,104555.813,V,0000.0000,N,00000.0000,E,0.00,,060605,,*05
$GPVTG,,T,,M,0.00,N,0.0,K*7E
J'aimerais bien garder mon timer, car il me pemetterait, (si jamais je trouve un moyen) de récupérer ce genre de trame a un instant 't', cet instant étant régit par, devinez quoi? bah mon timer.
Sinon comme tu le dit farscape, le gps continue d'envoyer tt le temps sans ce soucier d'un quelconque récepteur.
ben alors ma solution convient .
tu as tout ce qui faut.
reception en permanence avec le thread de reception avec stockage dans un pile de reception.
quand le timer se declenche gele le thread et lit le dernier element de la pile;
purge la pile et relance le thread.
il faudra gerer les instants critiques : timer déclenché et reception en cours..
etc..
:D
ok je m'y atèle ;)