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.