Interception d'événements sur port série
ffred10
Messages postés
4
Date d'inscription
mardi 1 mars 2005
Statut
Membre
Dernière intervention
18 juillet 2008
-
18 janv. 2007 à 00:45
Guilou34 Messages postés 142 Date d'inscription mercredi 5 avril 2006 Statut Membre Dernière intervention 29 janvier 2016 - 31 janv. 2007 à 14:48
Guilou34 Messages postés 142 Date d'inscription mercredi 5 avril 2006 Statut Membre Dernière intervention 29 janvier 2016 - 31 janv. 2007 à 14:48
3 réponses
Guilou34
Messages postés
142
Date d'inscription
mercredi 5 avril 2006
Statut
Membre
Dernière intervention
29 janvier 2016
1
24 janv. 2007 à 18:35
24 janv. 2007 à 18:35
Pouquoi utiliser le port série alors qu'avec le port parallèle il suffit d'aller sur :http://www.vbfrance.com/codes/PORT-PARALLELE-BUS-I2C-AVEC-PCF8574A-24C32-PCF8591_36774.aspx
D'autant plus qu'il me parait difficile de synchroniser le bus I2C avec une liaison série asynchrone sans parler des niveaux logiques (+12, -12 pour le port série).
Amicalement
D'autant plus qu'il me parait difficile de synchroniser le bus I2C avec une liaison série asynchrone sans parler des niveaux logiques (+12, -12 pour le port série).
Amicalement
ffred10
Messages postés
4
Date d'inscription
mardi 1 mars 2005
Statut
Membre
Dernière intervention
18 juillet 2008
29 janv. 2007 à 01:05
29 janv. 2007 à 01:05
Merci Guilou34
Je vais tout de même analyser la source que tu me proposes, cela va peut être m'aider.
Pourquoi utiliser le port série ? Parce que la station I2C est relativement éloignée du PC. Et j'ai utilisé un convertiseur de niveau MAX232. Je n'ai pas fait d'essai à haute vitesse, mais électroniquement cela fonctionne très bien puisque je peux, via le port série de mon PC, et un simple programme en VB, envoyer des ordres sur le bus I2C distant.
Mais les choses se corsent car plutôt que de m'en servir comme maitre sur le bus, je voudrais faire passer mon PC à l'état d'esclave, donc le PC ne contrôle plus le timing.
Là, VB n'est plus assez rapide, et surtout ne réagit pas en direct aux changements d'états des broches du port série, mais selon la file d'attente des interruptions.
Bien qu'un peu compliqué cela doit être possible et je continue de chercher, mais il serait aussi possible de programmer un petit microcontrôleur placé à coté du PC ( ou au niveau de la station distante ) pour faire l'interface du bus et dialoguer avec le PC selon la norme de la liaison asynchrone standard du port série ...
Amicalement
Je vais tout de même analyser la source que tu me proposes, cela va peut être m'aider.
Pourquoi utiliser le port série ? Parce que la station I2C est relativement éloignée du PC. Et j'ai utilisé un convertiseur de niveau MAX232. Je n'ai pas fait d'essai à haute vitesse, mais électroniquement cela fonctionne très bien puisque je peux, via le port série de mon PC, et un simple programme en VB, envoyer des ordres sur le bus I2C distant.
Mais les choses se corsent car plutôt que de m'en servir comme maitre sur le bus, je voudrais faire passer mon PC à l'état d'esclave, donc le PC ne contrôle plus le timing.
Là, VB n'est plus assez rapide, et surtout ne réagit pas en direct aux changements d'états des broches du port série, mais selon la file d'attente des interruptions.
Bien qu'un peu compliqué cela doit être possible et je continue de chercher, mais il serait aussi possible de programmer un petit microcontrôleur placé à coté du PC ( ou au niveau de la station distante ) pour faire l'interface du bus et dialoguer avec le PC selon la norme de la liaison asynchrone standard du port série ...
Amicalement
Guilou34
Messages postés
142
Date d'inscription
mercredi 5 avril 2006
Statut
Membre
Dernière intervention
29 janvier 2016
1
31 janv. 2007 à 14:48
31 janv. 2007 à 14:48
Salut FFred10Il ne faut pas perdre de vue que la liaison série RS232 est gérée par un circuit spécialisé (UART) et qu’elle est basée, à ce niveau, sur le protocole « Test And Transfert ». C’est à cette fonction que sont destinés les signaux DTR, DSR, RTS et CTS . En établissant certains pontages dans les fiches du câble utilisé, on peut forcer ces signaux à l’état Vrai (Null Modem ) mais cela ne dispense nullement de l’obligation d’utiliser un protocole surtout si un des système est multitâche. <?xml:namespace prefix o ns "urn:schemas-microsoft-com:office:office" /??>
Plusieurs méthodes sont envisageables, la plus simple est la méthode de l’écho : tout octet reçu doit être immédiatement renvoyé ; la vitesse est divisée par deux mais un contrôle de la ligne elle-même est constamment effectué.
Une méthode utilisée dans l’industrie consiste, pour le contrôleur, à envoyé l’octet 255 suivi du ou des octets définissant la commande à exécuter et d’attendre l’octet d’acquittement ACK (=6 en ASCII). Pour le contrôlé, l’algorithme est simple : chaque octet reçu est incrémenté et s’il passe à zéro l’octet suivant est pris comme commande et l’octet ACK est envoyé suivi éventuellement d’un second signalant que la commande a été effectuée avec succès.
Le fait que la méthode du « Null Modem » est prévue et fonctionne parfaitement dans un réseau Windows , mais aussi dans des programmes commerciaux de transfert de fichiers, montre bien qu'elle est réalisable.
Mais en utilisant le port parallèle, les choses sont plus simples puisqu’on peut suivre le standard I2C. D'ailleurs la discution du modèle décrit par Rylryl le confirme. Le fait que ce port soit en TTL est aisément surmonté , comme tu le signales, avec in MAX232.
Amicalement
Plusieurs méthodes sont envisageables, la plus simple est la méthode de l’écho : tout octet reçu doit être immédiatement renvoyé ; la vitesse est divisée par deux mais un contrôle de la ligne elle-même est constamment effectué.
Une méthode utilisée dans l’industrie consiste, pour le contrôleur, à envoyé l’octet 255 suivi du ou des octets définissant la commande à exécuter et d’attendre l’octet d’acquittement ACK (=6 en ASCII). Pour le contrôlé, l’algorithme est simple : chaque octet reçu est incrémenté et s’il passe à zéro l’octet suivant est pris comme commande et l’octet ACK est envoyé suivi éventuellement d’un second signalant que la commande a été effectuée avec succès.
Le fait que la méthode du « Null Modem » est prévue et fonctionne parfaitement dans un réseau Windows , mais aussi dans des programmes commerciaux de transfert de fichiers, montre bien qu'elle est réalisable.
Mais en utilisant le port parallèle, les choses sont plus simples puisqu’on peut suivre le standard I2C. D'ailleurs la discution du modèle décrit par Rylryl le confirme. Le fait que ce port soit en TTL est aisément surmonté , comme tu le signales, avec in MAX232.
Amicalement