Discussion :

[arcane86]

Bonjour à tous !

J'ai pas mal regardé sur le forum, il y a beaucoup de posts sur le thème de la communication USB et j'en rajoute un , parce que je préfère savoir si il existe une solution possible à mon problème avant de me lancer.

Le problème, c'est que j'ai cru comprendre qu'on ne pouvait pas directement communiquer avec le port USB mais seulement avec l'appareil qui y est connecté.

Or pour ma part je n'ai "rien" de connecté, je veux juste envoyer des signaux électriques (qui derrière débouche sur une carte électronique toute simple).
En gros dans un premier temps juste avoir un câble USB coupé et observé les données que j'envoie à l'oscilo'.

Est-ce possible ? Avec CreateFile & co ? Avec WinUSB ? Avec le WDK ?

Désolé pour cet n-iéme post, mais bon je préfère savoir dans quoi je me lance. Merci.

[Mac LAK]

USB est un bus à part entière, qui va notamment envoyer les données par paquets formatés et non pas "directement" comme sur un port série RS-232...

Je t'encourage à aller voir à quoi ressemble "réellement" un bus USB, au moins de façon macroscopique (ex : Universal Serial Bus (français), et USB packets (anglais)).

Ta demande est équivalente à "je veux envoyer des données sur mon câble RJ-45 Ethernet, piloter directement les signaux Rx/Tx et les observer à l'oscillo"... Ce qui n'est pas possible, car ta carte Ethernet, même en "Raw Sockets", introduira toujours une capsule 802.x ainsi que les signaux CSMA/CD.

En USB, c'est pareil : tu ne pourras pas t'affranchir de la notion de paquet USB, et sans une énumération correcte, tu n'aurais de toutes façons RIEN sur ton câble coupé : le hub USB "parent" n'alimenterait même pas ton câble !! Et même si tu avais le signal, tu serais soumis au découpage temporel de l'USB quoi qu'il arrive...

Explicite mieux ton problème initial, peut-être pourra-t'on t'aider un peu mieux... Te faut-il piloter un device USB ? Générer un signal quelconque sur une ligne type TTL ?

[arcane86]

Ok, c'est un peu ce à quoi je m'attendais !

Le principe c'est de trouver un moyen de transmettre des octets (bit à bit) de données sans aucun protocole, depuis l'ordinateur vers une carte électronique (n'importe quoi, pour allumer une LED, comme pour commander un µC).

Le rôle de la carte n'est pas forcement définie, l'ordi' transmet juste des 1 et des 0 que je voudrais récupérer sur un câble en sortie (0 - 5 V par exemple, TTL pourquoi pas !).

Enfin je vais voir à passer par un PIC18F ou un FTD245, même si ça m'arange pas de mettre un "intermédiaire".

A moins que quelqu'un est une autre idée de sortie possible et simple, USB ou autre (juste un ou deux petits câbles qui sortent de l'arrière de mon PC avec des bits en farandole ! ).

[Mac LAK]

Oh, tout simplement ta sortie RS-232 ou ton port parallèle...

Au pire, il te faudra un petit circuit électronique pour adapter la tension et/ou l'ampérage en fonction de tes besoins (le truc bête, hein, les lignes du port série / parallèle directement sur un transistor ou peu s'en faut...).

RS-232 (Wikipédia) :

• Avantages :
  
  • Il suffit de régler le port et ensuite d'envoyer les octets qui seront sérialisés très très facilement :
    
    • Vitesse "au choix" entre 75 bauds et 1.000.000 bauds en fonction de ton matériel, 115.200 garanti en général.
    • 8 bits de données.
    • Pas de parité.
    • Pas de bits de stop.
    • Pas de contrôle de flux.
  • L'accès au port série se fait sans avoir besoin de driver spécifique, le code n'est "abrupt" que si l'on doit tenir des performances particulières.
    Et même dans ce cas, il y a un paquet de librairies très bien faites pour y accéder (ComPort par exemple pour Delphi/C++ Builder).
  • Un accès R/W bit à bit "TTL" est possible via les lignes CTS/RTS, la vitesse dépendant alors du programme utilisateur.
• Inconvénients :
  
  • Pas de contrôle strict sur le délai entre la demande d'envoi et le début de sérialisation sur les lignes.
  • Impossible d'envoyer moins de bits que la taille paramétrée.
  • En mode normal d'émission, il faut tenir compte de l'encodage des octets sur les lignes.
  • Limité à certaines vitesses précises.
  • Pas toujours disponible sur les PC modernes...
    Un adaptateur RS-232 sur USB résout alors le problème, il est vu comme un port COM normal et l'USB est totalement transparent.

Port parallèle (Wikipédia) :

• Avantages :
  
  • Jusqu'à 8 lignes indépendantes sans utiliser de bidouilles particulières.
  • La vitesse est définie par le programme utilisateur (dans les limites de performances du port bien sûr).
  • Plus souvent présent sur les PC modernes qu'un port RS-232.
• Inconvénients :
  
  • Demande un driver bas niveau pour être utilisé correctement (un driver générique d'accès direct aux ports I/O, en général).
  • Plus pénible à programmer qu'un port RS-232.

A toi de faire ton choix en fonction de tes besoins, donc. J'aurais tendance à te conseiller le RS-232 en utilisant CTS/RTS, d'après ce que tu décris, et donc RTS uniquement si tu ne fais qu'émettre.

[arcane86]

Merci pour ton temps !

Pour la liaison série effectivement ça serait la solution. Mais après quelques recherches j'ai vu une limitation qui ne me plait pas trop : la vitesse de transfert.

En effet le but de mon application est de permettre la transmission de données brutes depuis l'ordinateur (un fichier binaire quelconque) vers un récepteur choisi par l'utilisateur.
En gros l'utilisateur choisi les données informatiques à envoyer et gère leur traitement après, moi je me charge juste de sortir les données de l'ordinateur !
Et j'aimerai pouvoir atteindre des débits de plusieurs mégaoctets/seconde.

Existe-t-il des adaptateurs USB/série qui me permettront d'utiliser la vitesse de l'USB2.0 en faisant abstraction de tout protocole ?

Sinon je vais être obligé de me rabattre sur une carte intermédiaire assurant la transition entre USB (ou ethernet) et mes petits fils à nu !

En tous cas merci de ton aide !

[Mac LAK]

Mais après quelques recherches j'ai vu une limitation qui ne me plait pas trop : la vitesse de transfert.

Au mieux, tu auras du 1 Mbit/s avec la liaison série... N'espère pas dépasser (en gros) les 400 ko/s avec le port parallèle de toutes façons.

En gros l'utilisateur choisi les données informatiques à envoyer et gère leur traitement après, moi je me charge juste de sortir les données de l'ordinateur !

Jusque là, tout va bien, ça se fait couramment.

Et j'aimerai pouvoir atteindre des débits de plusieurs mégaoctets/seconde.

C'est là où ça se corse : pour de tels débits, difficile de se passer d'un bus normé / protocolé et de ses contrôleurs dédiés...

Existe-t-il des adaptateurs USB/série qui me permettront d'utiliser la vitesse de l'USB2.0 en faisant abstraction de tout protocole ?

Pas à ma connaissance, le problème après sur deux fils "nus" étant électrique (amortissement, parasites, phénomène d'antenne, etc.) qui t'empêcheront d'aller au delà d'approximativement 1 à 2 MBit/s...

Sinon je vais être obligé de me rabattre sur une carte intermédiaire assurant la transition entre USB (ou ethernet) et mes petits fils à nu !

Cela ne changera hélas rien du tout : la partie "nue" de tes fils ne supportera jamais de tels débits, faudrait passer en différentiel, en paire torsadée, avec des résistances de ligne et tout et tout. Ne serait-ce que côté contrôle d'erreurs (car tu AURAS des erreurs de transmission, c'est totalement inévitable), c'est déjà la cata intégrale.

Bref, faudrait refaire ce qui est déjà fait dans une carte Ethernet ou un device USB... Autant la coupler directement !

Au final, tes signaux doivent arriver dans quoi ? L'interface série d'un FPGA ? Des registres latch ? Un processeur / contrôleur ? Dans une RAM / Flash ? Et surtout, suivant quel protocole ? Quelle est la taille maximale d'un fichier à transmettre ? As-tu de réelles contraintes temporelles (= contractuelles) vis-à-vis de ton client ?

Si tu peux exprimer de façon suffisamment détaillée le besoin final réel, il devrait être possible de t'aider à choisir le meilleur protocole possible... Dans tous les cas (Ethernet ou USB), il existe des espions de bus capables de retrouver ton flux de données "brut", cet aspect n'est donc pas un problème réel en soi.

[ram-0000]

Et j'aimerai pouvoir atteindre des débits de plusieurs mégaoctets/seconde.

Avec un port série, impossible.

Le port série natif du PC, c'est 115200 bauds c'est à dire à peu près 10KO par secondes (que les puristes m'excusent)

La vistesse maxi du port USB 1.0, c'est 12MB/s, c'est à dire 1MO par seconde

La vitesse maxi du port USB 2.0, c'est 480MB/s, c'est à dire 48MO par seconde.

Ces vitesses sont des vitesses théoriques rarement atteinte dans la pratique.

Pour ton cas, si tu veux de tels débits, c'est ethernet

[Mac LAK]

Le port série natif du PC, c'est 115200 bauds c'est à dire à peu près 10KO par secondes (que les puristes m'excusent)

Il y a des évolutions du port série pour arriver à 1 Mbit/s... Toutefois, j'admets que ces ports sont plutôt rares ! 128.000 bits/s est le maximum "classique" que l'on peut trouver sur un PC.

La vistesse maxi du port USB 1.0, c'est 12MB/s, c'est à dire 1MO par seconde

USB 1.1 plutôt, l'USB 1.0 ayant été très peu répandu... A noter que pour l'USB, la bande passante est partagée par tout le monde, donc on ne peut atteindre le maximum théorique QUE si le périphérique est tout seul sur le bus et au premier étage (connecté au root hub, donc).

Pour ton cas, si tu veux de tels débits, c'est ethernet

Classiquement, Ethernet est à 10 Mbit/s minimum (sur le vieux réseau de grand-mère), 100 Mbit/s quasiment partout, et 1 Gbit/s sur les réseaux un minimum "sérieux".
On a en plus la même contrainte de partage de bande passante qu'avec l'USB, sauf qu'en plus il y a un facteur aléatoire dans le délai de transmission dû au protocole CSMA/CD intrinsèque d'Ethernet.
Le gros avantage d'Ethernet par rapport à l'USB, c'est que c'est bien plus simple et pratique d'ouvrir une socket TCP/IP pour balancer son flux de données que de faire l'équivalent en USB... Mais bon, utiliser un device USB sous Windows est loin d'être difficile, et une socket TCP/IP rajoute un overhead pas toujours négligeable sur les transmissions (encapsulation, traversée des piles TCP/IP, etc.).



Aller au delà du gigabit/s actuellement doit être considéré comme impossible avec des moyens "normaux", c'est à dire du matériel facilement accessible / approvisionnable, et à un coût raisonnable.



Dans tous les cas, rien ne sert de transmettre une donnée à fond la gamelle si, derrière, il n'y a pas moyen de stocker à la même vitesse et/ou d'avoir un buffer de taille suffisante pour accepter les transferts... D'où le fait de répondre à mes questions précédentes afin de mieux expliciter ton besoin initial.

[arcane86]

L'idée de base été de coupler un modulateur QPSK avec l'ordinateur. Mais bon la-dessus je ne suis élargie vers n'importe quel récepteur qui aurait besoin de données depuis le PC.

J'avais d'abord envisager d'utiliser la sortie VGA, mais c'est un peu le bordel avec les synchro' et tout.
Mais du coup je me suis dis que si le VGA arriver a sortir de signaux carrés (ou a peu prêt !) avec une pixel clock de plusieurs dizaines de MHz ... pourquoi pas réussir la même chose sur un autre port !

Sinon pour mes deux câbles nus, je suis ouvert à toutes propositions électroniques qui permettrait d'améliorer le débit, tant que je retrouve bien mes données brutes (pas de protocole).
La correction d'erreurs pouvant se faire en aval par l'utilisateur (si il a codé les données sur le PC avant de la transférer).

[Mac LAK]

L'idée de base été de coupler un modulateur QPSK avec l'ordinateur. Mais bon la-dessus je ne suis élargie vers n'importe quel récepteur qui aurait besoin de données depuis le PC.

Pour moi, c'est l'aspect "sans protocole" qui me gêne beaucoup. J'utilise pas mal de type de connexions différentes dans mon boulot, on véhicule énormément de données "brutes" (= non traitées / encodées par nos soins), mais toujours au travers d'une couche "connue" (Ethernet, CAN, RS-232, ...), jamais directement.

J'avais d'abord envisager d'utiliser la sortie VGA, mais c'est un peu le bordel avec les synchro' et tout.

C'est même carrément inadapté, tu ne contrôle pas réellement ce qui sort sur la prise DB15 : la carte vidéo est passée avant toi.

Mais du coup je me suis dis que si le VGA arriver a sortir de signaux carrés (ou a peu prêt !) avec une pixel clock de plusieurs dizaines de MHz ... pourquoi pas réussir la même chose sur un autre port !

Un câble VGA est hautement blindé, en paires torsadées et tout et tout... T'as qu'à voir l'épaisseur du câble pour 15 malheureux fils tout fins !!!

Sinon pour mes deux câbles nus, je suis ouvert à toutes propositions électroniques qui permettrait d'améliorer le débit, tant que je retrouve bien mes données brutes (pas de protocole).

Là, je ne peux guère t'aider, je ne suis pas électronicien.

La correction d'erreurs pouvant se faire en aval par l'utilisateur (si il a codé les données sur le PC avant de la transférer).

Tu ne comprends pas : les erreurs de transmission sont totalement inévitables, quel que soit le médium / protocole utilisé.
Si ton système de transfert fonctionne avec une validation booléenne (bien transmis / pas bien transmis), ton client final va te le jeter à la tête s'il doit refaire les téléchargement sans arrêt sans "contrôle" !
En tout cas, moi, je te renverrais dans les buts en tout cas : mon critère numéro un dans une transmission de données, c'est l'intégrité, puis la vitesse seulement après.


Dans ton cas, reste à savoir comment les données arrivent sur ton modulateur : est-ce que ces données sont prises comme des données analogiques ? Un signal discret / échantillonné ? Un protocole particulier intégré au modulateur ?

Ce sont des questions réellement importantes, qui peuvent justement t'obliger à utiliser un boîtier spécifique de transfert / sérialisation de tes données vers une prise "standard" (genre DB9) pour te relier à l'appareil désiré.

[arcane86]

Je me rends bien compte que je sors des sentiers battus et que se que j'essaie de faire n'ai pas facile voir "incorrect".

Cependant je travail en amateur et donc plusieurs solutions sont écartées, au niveau du cout, de l'approvisionnement et de la faisabilité.

Après réflexion voila où en est mon problème :

1. Mon ordinateur encode des données, à la base il s'agit d'un fichier binaire de signaux IQ suivant la norme DVB-S (mais ça pourais devenir n'importe quelles données par la suite).
2. Une carte électronique nécessite la réception de ces données et que celles-ci. C'est ici que je place ma notion (peut-être malheureuse) de "sans encodage" ; sachant qu'après je peux toujours corriger les erreurs de transmission grâce a un encodage en amont sur l'ordinateur.
   Dans le cas de base il s'agit d'un modulateur QPSK qui doit choper les signaux IQ, mais pareil, à terme j'aimerai pouvoir pluger un peu ce que je veux.
3. La transmission, le lien entre c'est deux choses. Comment passer mes données binaires de mon ordinateur à la carte électronique qui veut les recevoir bit à bit.

J'ai examiner plusieurs solution :

1. La sortie VGA, en codant chaque bit a transmettre sur un pixel (grâce a directgraphics), qui finalement ne me donner pas de si mauvais résultats (je retrouvais mes données sur les câbles RGB). Mais je n'ai aucun contrôle sur les temps de synchronisation qui "coupe" la transmission et sur la vitesse de transmission (à part changer résolution/fréquence).
2. Une sortie "contrôlable directement", RS232 en tête qui serait parfaite, mais qui est trop limité niveau débit. Dans mon exemple de modulateur j'aimerai transférer à 2Mo/s.
3. Une autre sortie, USB et RJ45 étant les plus présente, qui nécessite une carte d'interconnexion. Et là je suis en pleine recherche de ce qui se fait. Pour l'instant je trouve rien de probant (PIC18F, ENC624J600, FT2232), les sortie de ces module étant souvent "lentes" (UART, SPI, I2C ...) même si l'entrée et rapide (USB2.0 HS, 100BaseT ...).

Voila, je sors un peu du sujet de base du topic, mais bon ce genre de liaison pourrait intéresser d'autre amateurs ! (D'ailleurs faut-il déplace le topic/le renommer ?)

Dans tous les cas merci de votre aide, ça m'éclaircit les idées et m'empêche de faire trop fausse route !