contrôle activex MSCOMM32.ocx

[Yves]

Réponse de l'auteur :

- Il pense qu'on peut envoyer un caractère nul avec \0.

- il va voir ce qu'il peut faire pour le handshaking, il est d'accord qu'il n'y en a pas. Mais comme il n'a pas vraiment le temps de bosser sur ses extensions actuellement, je ne sais pas ce que "je vais voir ce que je peux faire" peut vouloir dire en terme de délais. [img]/epicentre/images/%%GRAEMLIN_URL%%/wink.gif[/img]

- Start Monitoring ne sert pas à grand-chose, par contre Stop Monitoring permet de fermer le port.

[dampat]

Bonsoir,

Merci pour la réponse. Comme je ne suis pas de ceux qui attendent qu'on fasse le boulot à leur place, j'ai commencé à programmer une extension pour le port série. La programmation C et c++ sous Windows est difficile.
J'arrive à envoyer des données (ça c'est facile). Le problème, c'est pour la réception.
J'ai une question de novice en la matière qui concerne mon souci:
les routines des conditions sont-elles exécutées lorsque HandleRunObject de l'objet reprend la main, c'est-à-dire toutes les 20ms ?
Je persévère, je vais bien finir par y arriver.

[Yves]

Les routines des conditions sont exécutées effectivement une fois par boucle, donc ça dépend du frame rate sélectionné par l'utilisateur dans les propriétés de l'application. Par défaut c'est 50 ou 60 frames par seconde, donc 20 ou 16 ms par frame, mais ça peut être 1 seconde par frame si l'utilisateur met 1 comme valeur.

Si tu veux qu'une fonction soit appelée plus rapidement, il faut utiliser un timer par exemple avec la fonction timeSetEvent (mais on ne peut pas descendre en-dessous de 10 ms je pense).

Autre solution, tu peux créer un autre thread qui tourne en parallèle :

DWORD dwThreadID;
hThread = (HANDLE)_beginthreadex(NULL, 0, &MyFunction, (LPVOID)(LPCSTR)"", 0, &dwThreadID);

Le souci avec le multi-thread c'est la synchronisation avec le thread principal, donc c'est un peu délicat à programmer mais c'est probablement la meilleure solution dans ton cas.

[dampat]

Bonjour,

C'est ce que j'avais commencé à faire. J'ai quelques soucis pour l'instant au delà des 2-3 premiers caractères reçus.
Peut-être que j'ouvre plusieurs threads en cascade sans le vouloir.
Je vais debugger, j'espère que ça ira pas trop durement.
Merci pour l'aide, en tout cas.

[dampat]

Bonjour,
j'ai commencé à débugger. Et là je ne comprends pas trop, lorsque je teste la communication avec le débuggeur, la réception de données fonctionne correctement, mais lorsque je lance l'application normalement, de temps en temps la réception est bonne, et la plupart du temps je ne reçois qu'un bout des données.
Peut-être que mon thread de réception est interrompu par autre chose. Si c'est le cas, est-ce-que l'utilisation de PauseRunObject au moment de la lecture du Buffer par exemple pourrait permettre de bien recevoir les données (thread ininterrompu jusqu'à nouvel ordre) ou est-ce-que ce phénomène vient d'autre chose ?

[Eagle4]

peut etre que tes threads ne sont pas bien synchronisé et que si on lui laisse le temps (comme en cas de debuggage) ton thread de reception s'execute bien, et que sinon, il va trop vite, et les autres threads, important, ne s'execute qu'àprès...

[Yves]

PauseRunObject ne peut pas servir à ça, elle est appelée par le runtime lorsque l'utilisateur met le jeu en pause (ou lorsque le programme met le jeu en pause avant d'afficher une boîte de dialogue modale).

Peut-être devrais-tu lancer le thread avec une priorité élevée? (je crois que le coefficient de priorité d'un thread normal est 9, celui des threads plus élevés étant en général de 15, il doit y avoir des constantes Windows pour ça).

[dampat]

Bonjour,
J'ai essayé d'ajouter un Critical Section au moment de la réception et de l'expression de récupération des données reçues pour résoudre deux problèmes: la réception des données incomplètes et le plantage de l'application lorsque deux objets textes accèdent aux données reçues, à la même ressource donc. Je ne comprends pas, normalement, EnterCriticalSection et Leave CriticalSection devrait empêcher que cela ne se produise, non ?
Je vais voir pour la priorisation des threads. Y a-t-il un moyen plus approprié ou que j'aurait oublié pour la synchronisation des threads: CEvent ou autre chose ?

[Yves]

Pour bloquer l'accès à une routine on peut aussi utiliser un Mutex mais les critical sections sont bien aussi.

Le plantage se produit où exactement? Que dit le débuggeur?

[dampat]

Bonsoir,
j'ai résolu le problème d'accès de 2 objets texte au buffer de réception. Par contre j'ai toujours des pertes de données. J'ai certainement un problème de synchronisation car les 2 objets textes n'affichent pas la même chose.
Je vais remettre tout ça à plat et voir ce que ça donne. Je ne suis pas non plus un foudre de guerre en synchronisation de threads.