Version imprimable
pour ce qui est du time out, c'est pas gagné.
par contre avec le ci dessou la reception c'est amélioré
:?Citation:
if(! com.WaitCommEvent(EvtMask))
{
Sleep(1000);
}
cela dit les 2 derniers bits sont une fois sur deux faux et je n'aime pas trop ce genre de méthode, c'est limite remplacer un jouint usagé par un chewing-gum...
:)
c'est pas terrible tout ça !
tu devrais reflechir a la gestion de flux ....
:D
je suis d'accord sur le principe, mais le problème est que le matériel que je test à été conçu pour que seulement RX et TX soit utiliser...je vais voir ce que je peux faire pour ça...Citation:
Envoyé par farscape
Pour ce qui est du récepteur:
il reçoit une trame
fait la commande qui lui est demander
envoi une trame pour dire ce qu'il a fait
Il ne prévient pas ou ne demande pas à émettre.
salut,
Alors dans ce mode de fonctionnement:
tu dois envoyer une trame attendre la reponse avant d'envoyer une autre trame.
si il n'y a que Rx/Tx c'est classique d'une gestion de flux par Xon/Xoff.
mais bon vu les debits en question ça ne devrait pas causer de probleme.(du moins coté windows)
le probleme se situe plus dans la synchro entre l'emission reception.
:D
savez vous comment on utilise les tempon FIFO de Windows
idée:
lorsque des données sont envoyer sur le port COM, il devrait se mettre dans le tampon et généré une interuption.
si je détecte cette interuption je devrait pouvoir lire le contenu du tampon et récupérer le trame.
reste savoir comment utilisé le tampon et récupérer l'interuption.
au fait ça marche...
:lol:
désoler de ne pas avoir prévenu plus tot mais ça m'était sorti de l'esprit.
:roll:
pour résoudre mon problème j'ai fait ma propre class "SerialCom" afin de savoir ce que je fait...
les classes toutes faite c'est sympa, mais faut mieux sans inspirer plutot que de les réutiliser sans savoire le role de chaque methodes et attributs.
alors merci :D