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 !