|
|
|
Bonjour,
Je cherche à faire communiquer entre eux deux PC via leurs ports USB (un peu comme l'ancien "LapLink" le permettait via les ports RS232, à l'âge d'or) J'ai un compilateur C pour développer du Dos/Windows sur PC, mais ne sais pas (encore) gérer les ports USB autrement qu'en relation avec un périphérique. Si vous avez des exemples (en C) je suis preneur. Il y a quelques années j'avais développé en C une carte (à PIC 18F2455 qui a un port USB) et un soft Windows pour communiquer via USB entre cette carte et un PC. Si je colle deux uC cul à cul avec un bus // entre eux, j'aurai deux ports USB, un connecté à chaque PC. Mais je préfèrerais me passer de hard et faire communiquer les deux PC sans autre intermédiaire qu'un câble USB/USB. |
|
|
|
Jean-Christophe <my.addr> wrote:
> Je cherche à faire communiquer entre eux deux PC > via leurs ports USB (un peu comme l'ancien "LapLink" > le permettait via les ports RS232, à l'âge d'or) Pour info: je ne prétends pas être un expert de l'USB, en particulier actuel, mais la problématique m'intéresse. Encore faut-il qu'au moins un des ports USB soit `inversible': je m'explique: un port USB est un `host' (ou initiateur), et un périphérique est une `target' (ou cible). Tous les chips ne sont pas inversibles: typiquement certains sur des téléphones ou des raspberry pi le sont, mais je ne suis pas sûr que ceux installés sur les PC le soient. Et ensuite, il faudrait bien évidemment le logiciel qui va avec. Il se pourrait qu'un chip compatible `USB on the go' soit inversible. Alternative: utilisation d'un câble Host-to-Host, qui émule deux targets tête-bêche. Ces câbles semblent utiliser un peu votre solution, peut-être de manière plus efficace: > Il y a quelques années j'avais développé en C une carte > (à PIC 18F2455 qui a un port USB) et un soft Windows > pour communiquer via USB entre cette carte et un PC. > Si je colle deux uC cul à cul avec un bus // entre eux, > j'aurai deux ports USB, un connecté à chaque PC. Ca, oui, ça marcherait (toutefois, bien souvent les target USB sur des systèmes embarqués sont utilisés en émulation série: il y a un port série classique p.ex. à 19'200 bit/s entre le microcontrôleur et le chip USB, c'est donc assez lent). Voir le mode USB FIR ou SIR, de mémoire. > Mais je préfèrerais me passer de hard et faire communiquer > les deux PC sans autre intermédiaire qu'un câble USB/USB. Sous Linux, un pilote réseau USB host-to-host a été développé il y a déjà un moment. [..] Ce document est intéressant car il donne plein de pistes sur le câblage nécessaire, les types de chips, etc. Il peut être apparemment utilisé également pour des échanges directs sur USB, même si, finalement, il me semblerait plus simple de mettre deux dongles USB-vers-ethernet et un câble ethernet entre eux et de configurer le réseau comme d'habitude! |
|
|
Merci pour ces informations, Marc.
Je vais digérer tout ça. Pour les softs j'avais développé en C, d'un côté la carte à PIC18F2455 et de l'autre une app Windows. Je ne vois pas ce que tu veux dire par "inversible", via l'USB je pouvais communiquer dans les deux sens, que ce soit à l'initiative du PC ou de la carte. Merci encore. [..] |
|
|
On 2018-08-05, Marc SCHAEFER <schaefer> wrote:
>> Je cherche à faire communiquer entre eux deux PC >> via leurs ports USB (un peu comme l'ancien "LapLink" >> le permettait via les ports RS232, à l'âge d'or) > Pour info: je ne prétends pas être un expert > de l'USB, en particulier actuel, mais la problématique > m'intéresse. Vous savez qu'Ethernet a été inventé ? |
|
|
Stephane <st> wrote:
> Vous savez qu'Ethernet a été inventé ? Oui, d'où ma suggestion en fin d'article que vous n'avez pas lue. Même sur les sujets techniques, vos contributions n'ont aucun intérêt. |
|
|
Jean-Christophe <my.addr> wrote:
> Merci pour ces informations, Marc. > "inversible", via l'USB je pouvais communiquer dans les deux sens, > que ce soit à l'initiative du PC ou de la carte. Sur ce point, je dois avouer que mes connaissances sont faibles. J'étais resté sur une version d'USB où les chips `target' étaient différents des chips `initiateurs'. Toutefois, il se peut bien qu'avec On The Go, et même avant, avec les chips pour systèmes embarqués, cette problématique ne se pose plus. J'exprimais mon doute ainsi: > Tous les chips ne sont pas inversibles: typiquement > certains sur des téléphones ou des raspberry pi > le sont, mais je ne suis pas sûr que ceux installés > sur les PC le soient. Maintenant si ça marche .. parfait. |
|
|
> "Stephane" :
> Vous savez qu'Ethernet a été inventé ? Ce n'est pas le sujet évoqué, ni la question posée. Relisez mieux mon post précédent. Merci pour votre contribution. |
|
|
Jean-Christophe <my.addr> wrote:
> Pour les softs j'avais développé en C, d'un côté la carte à PIC18F2455 > et de l'autre une app Windows. Je ne vois pas ce que tu veux dire par > "inversible", via l'USB je pouvais communiquer dans les deux sens, > que ce soit à l'initiative du PC ou de la carte. Complément: une façon assez classique de faire cela est de déclarer le type de périphérique USB de la carte PIC18F2455 comme un port série target. Dans ce cas, le host (ici Microsoft) va régulièrement `poller' le port série virtuel, ce qui donne l'illusion que les échanges se font, "initiés" par les deux côtés, indifféremment. En résumé, l'API de haut niveau te permettra d'écrire et de lire sur ton port série virtuel et les couches bassent se chargent de la scrutation (polling). Je *suppose* que c'est ce qui se passait: sinon, ton ordinateur et ta carte supportent le standard OTG, voir plus bas, ce qui est de plus en plus supporté. Ton chip semble le supporter d'ailleurs. En fait, le bus USB *classique* est `maître-esclave', avec un arbitre centralisé (chaque port USB sur le host). Le maître est toujours l'initiateur des commandes et la cible (target) y répond. Lorsque des périphériques (target) veulent régulièrement envoyer des données, le maître (initiateur, host) va régulièrement les interroger. Il y a même une configuration pour spécifier le temps d'interrogation pour les transferts réguliers == isochrones. Le grand avantage d'avoir construit un tel "bus" `maître-esclave' est l'absence de collision. En SCSI interface parallèle, tout périphérique pouvait être initiateur et target, en particulier avec la notion de reconnexion. Le bus avait été conçu pour résoudre les collisions par CSMA/CR (on écoute un peu, si rien ne se passe, on met la ligne correspondant à son ID à 1, et celui qui a le plus grand ID gagne): collision resolution avec potentiel de famine. Pour bien comprendre la différence entre `initiateur' (host) et `cible' (target, périphérique), le plus simple est de considérer ma tablette Samsung: - elle peut être vue comme un périphérique série (pour utiliser évt. son modem interne) ou comme un périphérique bloc (pour monter son filesystem), ou comme un périphérique MTP (pour échanger des fichiers) par un host -> elle est une target - elle peut être vue comme un initiateur (host) si on y branche un clavier USB (qui lui est une target) Dans ce cas, face à un host, le port USB de la tablette devient une target, et face à une target un host: le chip est `inversible' (il peut aussi p.ex. fournir de l'alimentation électrique, ce qu'une cible ne fait pas normalement). Mais il y a encore mieux: le standard OTG (on the go) permet à une cible sur un bus USB avec un autre host de communiquer avec lui et de lui proposer une inversion; la cible peut alors communiquer avec une autre cible en tant qu'initiateur directement (que cette cible supporte ou non OTG). Exemple d'application: copier un disque sur un autre sans ordinateur intermédiaire [..] En théorie cela permettrait aussi d'éviter le polling, ressemblant un peu à la `reconnexion SCSI envers le host', mais je n'ai rien vu à ce sujet. NB: la terminologie target/initiator que j'utilise vient de SCSI, je crois que USB appelle cela plutôt Host et Device, mais le principe est similaire. |
|
Fuseau horaire GMT +2. Il est actuellement 16h39. | Privacy Policy
|