j'ai écrit un logiciel où je dois lire 2 ports de communication, un pour
un GPS et un pour un AIS.
Le GPS transmet à 4800 bauds. Il émet approx. 300 caractères par seconde.
Ma première question : est-ce préférable de déclencher un ComEvReceive à
chaque caractère reçu en placant 0 dans le RThresold, ou bien de placer
un nombre comme 100, 200 ou 300 dans le RThresold.
J'ai aussi un timer pour procéder le data du GPS. Je l'ai placé à 1
seconde. C'est-à-dire qu'à chaque seconde je "processe" le GPS data que
j'ai placé dans un double buffer à chaque ComEvReceive. Est-ce que cette
seconde est OK? Devrais procéder le data plus souvent ?
Le 2e port reçoit du data d'un AIS, un appareil qui transmet à 38400
bauds des phrases de texte encapsuléees en 6 bits. Selon le traffic
maritime, il peut transmettre jusqu'à 2500 caractères par seconde.
Même question ici que pour le port GPS ; utiliser le RThresold pour
déclencher un ComEvReceive ou y aller à chaque caractère. Aussi, est-ce
préférable de processer le data plusieurs fois par seconde, ou une fois
par seconde est suffisante.
Actuellement, mes Thresold sont à 0. Mes timers à 1 seconde. Lorsqu'il
y a beaucoup de traffic maritime, donc d'émissions de data par les
navires, mes buffers semblent "jammer". J'affiche l'heure locale à
chaque seconde et celle -ci s'update seulement au 5, 10 ou même 15
secondes parfois.
Est-ce qu'un DoEvents dans les routines de data processing arrangerait
les choses ? Le CPU a d'autres choses à faire pendant ses "temps libre";
afficher les navires sur une carte vectorielle en temps réel, leur cap,
vitesse, position, etc..
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Jean-marc
"Jacquelin Hardy" a écrit dans le message de news:
Bonjour groupe,
Hello,
j'ai écrit un logiciel où je dois lire 2 ports de communication, un pour un GPS et un pour un AIS. Le GPS transmet à 4800 bauds. Il émet approx. 300 caractères par seconde.
Ma première question : est-ce préférable de déclencher un ComEvReceive à chaque caractère reçu en placant 0 dans le RThresold, ou bien de placer un nombre comme 100, 200 ou 300 dans le RThresold.
Personellement, j'aime bien RThreshold à 0, et je gère "à la main" ce qui arrive.
J'ai aussi un timer pour procéder le data du GPS. Je l'ai placé à 1 seconde. C'est-à-dire qu'à chaque seconde je "processe" le GPS data que j'ai placé dans un double buffer à chaque ComEvReceive. Est-ce que cette seconde est OK? Devrais procéder le data plus souvent ?
Une seconde est plus que suffisante, En une seconde, un navire ou autre objet sur l'eau ne vas pas faire plus d'une dizaine de mètre. Compte tenu de l'imprécision du GPS, pour moi une seconde est plus q'assez.
Le 2e port reçoit du data d'un AIS, un appareil qui transmet à 38400 bauds des phrases de texte encapsuléees en 6 bits. Selon le traffic maritime, il peut transmettre jusqu'à 2500 caractères par seconde.
Même question ici que pour le port GPS ; utiliser le RThresold pour déclencher un ComEvReceive ou y aller à chaque caractère.
Idem, je laisserais à 0 et j'appelerais une procédure perso quand j'ai une trame complète.
Aussi, est-ce préférable de processer le data plusieurs fois par seconde, ou une fois par seconde est suffisante.
Ca dépend de ce que tu fais avec ces données. Même sans savoir exactement ce que fait ton appli, je dirais qu'une fois par seconde est un bon rythme.
Actuellement, mes Thresold sont à 0. Mes timers à 1 seconde. Lorsqu'il y a beaucoup de traffic maritime, donc d'émissions de data par les navires, mes buffers semblent "jammer". J'affiche l'heure locale à chaque seconde et celle -ci s'update seulement au 5, 10 ou même 15 secondes parfois.
Est-ce qu'un DoEvents dans les routines de data processing arrangerait les choses ?
Oui, un DoEvents arrangera très bien les choses!
Le CPU a d'autres choses à faire pendant ses "temps libre"; afficher les navires sur une carte vectorielle en temps réel, leur cap, vitesse, position, etc..
Une question quand même: si tu mets RThreshold à 0, tu controles en temps réel (caractère par caractère) ce que tu reçois. Je suppose que tu peux savoir à tout moment (lors de la réception d'un caractère) si tu as reçu une trame d'information complète? Si oui, pourquoi un Timer? Ne serait il pas plus efficace de processer de manière systèmatique dès que tu as un jeu de données complet? Ceci s'applique à GPS et à AIS.
Un truc du genre:
Sub Comm_evReceive
stocke nouveau caractère dans buffer Est ce caractère de fin de trame? Si oui Call Process_data (Buffer) Fin si End Sub
Evidemment, cela suppose que tu peux savoir, lors de la réception d'un caractère, que tu as assez d'info (ce que j'ai appelé une trame) pour faire un processing intelligent.
Sur les GPS que j'employais, il y a avait des caractères spéciaux qui signalaient le début et la fin d'émission d'une "trame" d'info.
Une autre solution avec un autre matériel était de mesurer la taille de la trame car un jeu de donnée (une trame d'info) avait toujours la même taille.
"Jacquelin Hardy" <jachardy@videotron.ca> a écrit dans le message de news:
uoCC81bLHHA.1248@TK2MSFTNGP03.phx.gbl...
Bonjour groupe,
Hello,
j'ai écrit un logiciel où je dois lire 2 ports de communication, un pour
un GPS et un pour un AIS.
Le GPS transmet à 4800 bauds. Il émet approx. 300 caractères par seconde.
Ma première question : est-ce préférable de déclencher un ComEvReceive à
chaque caractère reçu en placant 0 dans le RThresold, ou bien de placer un
nombre comme 100, 200 ou 300 dans le RThresold.
Personellement, j'aime bien RThreshold à 0, et je gère "à la main" ce qui
arrive.
J'ai aussi un timer pour procéder le data du GPS. Je l'ai placé à 1
seconde. C'est-à-dire qu'à chaque seconde je "processe" le GPS data que
j'ai placé dans un double buffer à chaque ComEvReceive. Est-ce que cette
seconde est OK? Devrais procéder le data plus souvent ?
Une seconde est plus que suffisante, En une seconde, un navire ou autre
objet sur l'eau ne vas pas faire plus d'une dizaine de mètre. Compte tenu
de l'imprécision du GPS, pour moi une seconde est plus q'assez.
Le 2e port reçoit du data d'un AIS, un appareil qui transmet à 38400 bauds
des phrases de texte encapsuléees en 6 bits. Selon le traffic maritime, il
peut transmettre jusqu'à 2500 caractères par seconde.
Même question ici que pour le port GPS ; utiliser le RThresold pour
déclencher un ComEvReceive ou y aller à chaque caractère.
Idem, je laisserais à 0 et j'appelerais une procédure perso quand
j'ai une trame complète.
Aussi, est-ce préférable de processer le data plusieurs fois par seconde,
ou une fois par seconde est suffisante.
Ca dépend de ce que tu fais avec ces données. Même sans savoir exactement
ce que fait ton appli, je dirais qu'une fois par seconde est un bon rythme.
Actuellement, mes Thresold sont à 0. Mes timers à 1 seconde. Lorsqu'il y a
beaucoup de traffic maritime, donc d'émissions de data par les navires,
mes buffers semblent "jammer". J'affiche l'heure locale à chaque seconde
et celle -ci s'update seulement au 5, 10 ou même 15 secondes parfois.
Est-ce qu'un DoEvents dans les routines de data processing arrangerait les
choses ?
Oui, un DoEvents arrangera très bien les choses!
Le CPU a d'autres choses à faire pendant ses "temps libre"; afficher les
navires sur une carte vectorielle en temps réel, leur cap, vitesse,
position, etc..
Une question quand même: si tu mets RThreshold à 0, tu controles en temps
réel (caractère par caractère) ce que tu reçois. Je suppose que tu peux
savoir à tout moment (lors de la réception d'un caractère) si tu as reçu
une trame d'information complète? Si oui, pourquoi un Timer? Ne serait il
pas plus efficace de processer de manière systèmatique dès que tu as un
jeu de données complet? Ceci s'applique à GPS et à AIS.
Un truc du genre:
Sub Comm_evReceive
stocke nouveau caractère dans buffer
Est ce caractère de fin de trame?
Si oui
Call Process_data (Buffer)
Fin si
End Sub
Evidemment, cela suppose que tu peux savoir, lors de la
réception d'un caractère, que tu as assez d'info (ce que j'ai
appelé une trame) pour faire un processing intelligent.
Sur les GPS que j'employais, il y a avait des caractères spéciaux
qui signalaient le début et la fin d'émission d'une "trame" d'info.
Une autre solution avec un autre matériel était de mesurer la taille
de la trame car un jeu de donnée (une trame d'info) avait toujours la
même taille.
"Jacquelin Hardy" a écrit dans le message de news:
Bonjour groupe,
Hello,
j'ai écrit un logiciel où je dois lire 2 ports de communication, un pour un GPS et un pour un AIS. Le GPS transmet à 4800 bauds. Il émet approx. 300 caractères par seconde.
Ma première question : est-ce préférable de déclencher un ComEvReceive à chaque caractère reçu en placant 0 dans le RThresold, ou bien de placer un nombre comme 100, 200 ou 300 dans le RThresold.
Personellement, j'aime bien RThreshold à 0, et je gère "à la main" ce qui arrive.
J'ai aussi un timer pour procéder le data du GPS. Je l'ai placé à 1 seconde. C'est-à-dire qu'à chaque seconde je "processe" le GPS data que j'ai placé dans un double buffer à chaque ComEvReceive. Est-ce que cette seconde est OK? Devrais procéder le data plus souvent ?
Une seconde est plus que suffisante, En une seconde, un navire ou autre objet sur l'eau ne vas pas faire plus d'une dizaine de mètre. Compte tenu de l'imprécision du GPS, pour moi une seconde est plus q'assez.
Le 2e port reçoit du data d'un AIS, un appareil qui transmet à 38400 bauds des phrases de texte encapsuléees en 6 bits. Selon le traffic maritime, il peut transmettre jusqu'à 2500 caractères par seconde.
Même question ici que pour le port GPS ; utiliser le RThresold pour déclencher un ComEvReceive ou y aller à chaque caractère.
Idem, je laisserais à 0 et j'appelerais une procédure perso quand j'ai une trame complète.
Aussi, est-ce préférable de processer le data plusieurs fois par seconde, ou une fois par seconde est suffisante.
Ca dépend de ce que tu fais avec ces données. Même sans savoir exactement ce que fait ton appli, je dirais qu'une fois par seconde est un bon rythme.
Actuellement, mes Thresold sont à 0. Mes timers à 1 seconde. Lorsqu'il y a beaucoup de traffic maritime, donc d'émissions de data par les navires, mes buffers semblent "jammer". J'affiche l'heure locale à chaque seconde et celle -ci s'update seulement au 5, 10 ou même 15 secondes parfois.
Est-ce qu'un DoEvents dans les routines de data processing arrangerait les choses ?
Oui, un DoEvents arrangera très bien les choses!
Le CPU a d'autres choses à faire pendant ses "temps libre"; afficher les navires sur une carte vectorielle en temps réel, leur cap, vitesse, position, etc..
Une question quand même: si tu mets RThreshold à 0, tu controles en temps réel (caractère par caractère) ce que tu reçois. Je suppose que tu peux savoir à tout moment (lors de la réception d'un caractère) si tu as reçu une trame d'information complète? Si oui, pourquoi un Timer? Ne serait il pas plus efficace de processer de manière systèmatique dès que tu as un jeu de données complet? Ceci s'applique à GPS et à AIS.
Un truc du genre:
Sub Comm_evReceive
stocke nouveau caractère dans buffer Est ce caractère de fin de trame? Si oui Call Process_data (Buffer) Fin si End Sub
Evidemment, cela suppose que tu peux savoir, lors de la réception d'un caractère, que tu as assez d'info (ce que j'ai appelé une trame) pour faire un processing intelligent.
Sur les GPS que j'employais, il y a avait des caractères spéciaux qui signalaient le début et la fin d'émission d'une "trame" d'info.
Une autre solution avec un autre matériel était de mesurer la taille de la trame car un jeu de donnée (une trame d'info) avait toujours la même taille.
"Jacquelin Hardy" a écrit dans le message de news:
Bonjour groupe,
Hello,
j'ai écrit un logiciel où je dois lire 2 ports de communication, un pour un GPS et un pour un AIS. Le GPS transmet à 4800 bauds. Il émet approx. 300 caractères par seconde.
Ma première question : est-ce préférable de déclencher un ComEvReceive à chaque caractère reçu en placant 0 dans le RThresold, ou bien de placer un nombre comme 100, 200 ou 300 dans le RThresold.
Personellement, j'aime bien RThreshold à 0, et je gère "à la main" ce qui arrive.
J'ai aussi un timer pour procéder le data du GPS. Je l'ai placé à 1 seconde. C'est-à-dire qu'à chaque seconde je "processe" le GPS data que j'ai placé dans un double buffer à chaque ComEvReceive. Est-ce que cette seconde est OK? Devrais procéder le data plus souvent ?
Une seconde est plus que suffisante, En une seconde, un navire ou autre objet sur l'eau ne vas pas faire plus d'une dizaine de mètre. Compte tenu de l'imprécision du GPS, pour moi une seconde est plus q'assez.
Le 2e port reçoit du data d'un AIS, un appareil qui transmet à 38400 bauds des phrases de texte encapsuléees en 6 bits. Selon le traffic maritime, il peut transmettre jusqu'à 2500 caractères par seconde.
Même question ici que pour le port GPS ; utiliser le RThresold pour déclencher un ComEvReceive ou y aller à chaque caractère.
Idem, je laisserais à 0 et j'appelerais une procédure perso quand j'ai une trame complète.
Aussi, est-ce préférable de processer le data plusieurs fois par seconde, ou une fois par seconde est suffisante.
Ca dépend de ce que tu fais avec ces données. Même sans savoir exactement ce que fait ton appli, je dirais qu'une fois par seconde est un bon rythme.
Actuellement, mes Thresold sont à 0. Mes timers à 1 seconde. Lorsqu'il y a beaucoup de traffic maritime, donc d'émissions de data par les navires, mes buffers semblent "jammer". J'affiche l'heure locale à chaque seconde et celle -ci s'update seulement au 5, 10 ou même 15 secondes parfois.
Est-ce qu'un DoEvents dans les routines de data processing arrangerait les choses ?
Oui, un DoEvents arrangera très bien les choses!
Le CPU a d'autres choses à faire pendant ses "temps libre"; afficher les navires sur une carte vectorielle en temps réel, leur cap, vitesse, position, etc..
Une question quand même: si tu mets RThreshold à 0, tu controles en temps réel (caractère par caractère) ce que tu reçois. Je suppose que tu peux savoir à tout moment (lors de la réception d'un caractère) si tu as reçu une trame d'information complète? Si oui, pourquoi un Timer? Ne serait il pas plus efficace de processer de manière systèmatique dès que tu as un jeu de données complet? Ceci s'applique à GPS et à AIS.
Un truc du genre:
Sub Comm_evReceive
stocke nouveau caractère dans buffer Est ce caractère de fin de trame? Si oui Call Process_data (Buffer) Fin si End Sub
Evidemment, cela suppose que tu peux savoir, lors de la réception d'un caractère, que tu as assez d'info (ce que j'ai appelé une trame) pour faire un processing intelligent.
Sur les GPS que j'employais, il y a avait des caractères spéciaux qui signalaient le début et la fin d'émission d'une "trame" d'info.
Une autre solution avec un autre matériel était de mesurer la taille de la trame car un jeu de donnée (une trame d'info) avait toujours la même taille.
Jean-Marc,
je te remercie bien pour tes réponses.
Jacquelin
Jean-marc a écrit :
"Jacquelin Hardy" <jachardy@videotron.ca> a écrit dans le message de news:
uoCC81bLHHA.1248@TK2MSFTNGP03.phx.gbl...
Bonjour groupe,
Hello,
j'ai écrit un logiciel où je dois lire 2 ports de communication, un pour
un GPS et un pour un AIS.
Le GPS transmet à 4800 bauds. Il émet approx. 300 caractères par seconde.
Ma première question : est-ce préférable de déclencher un ComEvReceive à
chaque caractère reçu en placant 0 dans le RThresold, ou bien de placer un
nombre comme 100, 200 ou 300 dans le RThresold.
Personellement, j'aime bien RThreshold à 0, et je gère "à la main" ce qui
arrive.
J'ai aussi un timer pour procéder le data du GPS. Je l'ai placé à 1
seconde. C'est-à-dire qu'à chaque seconde je "processe" le GPS data que
j'ai placé dans un double buffer à chaque ComEvReceive. Est-ce que cette
seconde est OK? Devrais procéder le data plus souvent ?
Une seconde est plus que suffisante, En une seconde, un navire ou autre
objet sur l'eau ne vas pas faire plus d'une dizaine de mètre. Compte tenu
de l'imprécision du GPS, pour moi une seconde est plus q'assez.
Le 2e port reçoit du data d'un AIS, un appareil qui transmet à 38400 bauds
des phrases de texte encapsuléees en 6 bits. Selon le traffic maritime, il
peut transmettre jusqu'à 2500 caractères par seconde.
Même question ici que pour le port GPS ; utiliser le RThresold pour
déclencher un ComEvReceive ou y aller à chaque caractère.
Idem, je laisserais à 0 et j'appelerais une procédure perso quand
j'ai une trame complète.
Aussi, est-ce préférable de processer le data plusieurs fois par seconde,
ou une fois par seconde est suffisante.
Ca dépend de ce que tu fais avec ces données. Même sans savoir exactement
ce que fait ton appli, je dirais qu'une fois par seconde est un bon rythme.
Actuellement, mes Thresold sont à 0. Mes timers à 1 seconde. Lorsqu'il y a
beaucoup de traffic maritime, donc d'émissions de data par les navires,
mes buffers semblent "jammer". J'affiche l'heure locale à chaque seconde
et celle -ci s'update seulement au 5, 10 ou même 15 secondes parfois.
Est-ce qu'un DoEvents dans les routines de data processing arrangerait les
choses ?
Oui, un DoEvents arrangera très bien les choses!
Le CPU a d'autres choses à faire pendant ses "temps libre"; afficher les
navires sur une carte vectorielle en temps réel, leur cap, vitesse,
position, etc..
Une question quand même: si tu mets RThreshold à 0, tu controles en temps
réel (caractère par caractère) ce que tu reçois. Je suppose que tu peux
savoir à tout moment (lors de la réception d'un caractère) si tu as reçu
une trame d'information complète? Si oui, pourquoi un Timer? Ne serait il
pas plus efficace de processer de manière systèmatique dès que tu as un
jeu de données complet? Ceci s'applique à GPS et à AIS.
Un truc du genre:
Sub Comm_evReceive
stocke nouveau caractère dans buffer
Est ce caractère de fin de trame?
Si oui
Call Process_data (Buffer)
Fin si
End Sub
Evidemment, cela suppose que tu peux savoir, lors de la
réception d'un caractère, que tu as assez d'info (ce que j'ai
appelé une trame) pour faire un processing intelligent.
Sur les GPS que j'employais, il y a avait des caractères spéciaux
qui signalaient le début et la fin d'émission d'une "trame" d'info.
Une autre solution avec un autre matériel était de mesurer la taille
de la trame car un jeu de donnée (une trame d'info) avait toujours la
même taille.
"Jacquelin Hardy" a écrit dans le message de news:
Bonjour groupe,
Hello,
j'ai écrit un logiciel où je dois lire 2 ports de communication, un pour un GPS et un pour un AIS. Le GPS transmet à 4800 bauds. Il émet approx. 300 caractères par seconde.
Ma première question : est-ce préférable de déclencher un ComEvReceive à chaque caractère reçu en placant 0 dans le RThresold, ou bien de placer un nombre comme 100, 200 ou 300 dans le RThresold.
Personellement, j'aime bien RThreshold à 0, et je gère "à la main" ce qui arrive.
J'ai aussi un timer pour procéder le data du GPS. Je l'ai placé à 1 seconde. C'est-à-dire qu'à chaque seconde je "processe" le GPS data que j'ai placé dans un double buffer à chaque ComEvReceive. Est-ce que cette seconde est OK? Devrais procéder le data plus souvent ?
Une seconde est plus que suffisante, En une seconde, un navire ou autre objet sur l'eau ne vas pas faire plus d'une dizaine de mètre. Compte tenu de l'imprécision du GPS, pour moi une seconde est plus q'assez.
Le 2e port reçoit du data d'un AIS, un appareil qui transmet à 38400 bauds des phrases de texte encapsuléees en 6 bits. Selon le traffic maritime, il peut transmettre jusqu'à 2500 caractères par seconde.
Même question ici que pour le port GPS ; utiliser le RThresold pour déclencher un ComEvReceive ou y aller à chaque caractère.
Idem, je laisserais à 0 et j'appelerais une procédure perso quand j'ai une trame complète.
Aussi, est-ce préférable de processer le data plusieurs fois par seconde, ou une fois par seconde est suffisante.
Ca dépend de ce que tu fais avec ces données. Même sans savoir exactement ce que fait ton appli, je dirais qu'une fois par seconde est un bon rythme.
Actuellement, mes Thresold sont à 0. Mes timers à 1 seconde. Lorsqu'il y a beaucoup de traffic maritime, donc d'émissions de data par les navires, mes buffers semblent "jammer". J'affiche l'heure locale à chaque seconde et celle -ci s'update seulement au 5, 10 ou même 15 secondes parfois.
Est-ce qu'un DoEvents dans les routines de data processing arrangerait les choses ?
Oui, un DoEvents arrangera très bien les choses!
Le CPU a d'autres choses à faire pendant ses "temps libre"; afficher les navires sur une carte vectorielle en temps réel, leur cap, vitesse, position, etc..
Une question quand même: si tu mets RThreshold à 0, tu controles en temps réel (caractère par caractère) ce que tu reçois. Je suppose que tu peux savoir à tout moment (lors de la réception d'un caractère) si tu as reçu une trame d'information complète? Si oui, pourquoi un Timer? Ne serait il pas plus efficace de processer de manière systèmatique dès que tu as un jeu de données complet? Ceci s'applique à GPS et à AIS.
Un truc du genre:
Sub Comm_evReceive
stocke nouveau caractère dans buffer Est ce caractère de fin de trame? Si oui Call Process_data (Buffer) Fin si End Sub
Evidemment, cela suppose que tu peux savoir, lors de la réception d'un caractère, que tu as assez d'info (ce que j'ai appelé une trame) pour faire un processing intelligent.
Sur les GPS que j'employais, il y a avait des caractères spéciaux qui signalaient le début et la fin d'émission d'une "trame" d'info.
Une autre solution avec un autre matériel était de mesurer la taille de la trame car un jeu de donnée (une trame d'info) avait toujours la même taille.
