Bonjour.
Je voudrais espionner un bus I2C en le reliant sur le port série.
Je n'ai pas de problème avec les connections électroniques, ni avec la technologie I2C.
Mais j'ai besoin d'un programme rapide ( donc assembleur ) pour réagir en direct aux changements d'état des entrées du port série.
J'envisage d'utiliser MASM pour l'assembleur et Visual Basic, pour le traitement à postériori des données.
Il faudrait modifier le vecteur d'interruption du port série, et que le nouveau programme d'in terruption stocke en direct les données reçues dans un buffer.
Visual Basic, lui, à travers une DLL, viendrait lire ce buffer.
Mais j'ai un problème avec la "vision globale" du système ...
Est-ce qu'on peut changer un vecteur d'interruption dans une fonction de DLL ? ( Pour changer un vecteur, on doit être en mode réel ? Alors que Windows tourne en mode protégé, non ? )
Je suis, à vrai dire, un peu perdu entre les différents modes du processeur, et des directives .model de l'assembleur ...
Si je pense pouvoir m'en sortir pour les "détails" de telle ou telle fonction à créer, quelqu'un a t-il une idée de "l'organigramme global" de ce qu'il y a à faire ?
Merci et meilleurs voeux.
    
 

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

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 

Salut FFred10
Il 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.

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