Hallo zusammen,
hat jemand von euch Erfahrung ob es möglich ist USB-Daten über eine
UTMI-Baustein zu erfassen, anschließen die parallelen RX bzw. TX Daten
per WLAN oder Ethernet zu übertragen und dann wieder per UTMI-Baustein
wieder zurück zu USB übermitteln. Selbstverständlich mit Unterstützung
von FPGAs.
Die ganze Betrachtung ist unabhängig des Timing, es geht nur um die
Frage ob dies möglich ist, Daten so über mehr als 5m zu übertragen.
SAKI schrieb:> hat jemand von euch Erfahrung ob es möglich ist USB-Daten über eine> UTMI-Baustein zu erfassen, anschließen die parallelen RX bzw. TX Daten> per WLAN oder Ethernet zu übertragen und dann wieder per UTMI-Baustein> wieder zurück zu USB übermitteln. Selbstverständlich mit Unterstützung> von FPGAs.> Die ganze Betrachtung ist unabhängig des Timing, es geht nur um die> Frage ob dies möglich ist, Daten so über mehr als 5m zu übertragen.
Genau das Timing ist es, das Euch da in die Suppe spucken wird. Die
5m-Begrenzung bei USB 2 wird nicht dadurch verursacht, dass die Signale
nach 5m zu schwach sind, sondern es sind die Signallaufzeiten auf dem
bidirektionalen Adernpaar.
Dieses Problem löst man normalerweise mit Device Servern. Ein USB Device
Server ist ein kleiner Rechner, der als USB-Host arbeitet und seine
Befehle per LAN/WLAN vom PC bekommt. Auf dem PC ist ein Treiber, der dem
Betriebssystem eine virtuelle USB-Karte bereitstellt und die Aufrufe an
den Device Server weiterleitet. Da das über LAN geschieht, gibt es dort
keine Längenbegrenzung. Der steuernde PC kann also weit entfernt stehen,
nur der Device Server mit seiner physikalischen USB-Verbindung muss in
der Nähe stehen.
Was auch möglich ist: eine USB-Brücke, die auf Protokollebene arbeitet.
Nehmen wir an, Du willst einen Drucker fernsteuern. Dann brauchst Du
eine Kiste, die für den PC wie ein Drucker aussieht, und eine Kiste, die
für den Drucker wie ein PC aussieht. Was dann zwischen den beiden Kisten
transportiert wird, sind dann nicht die Low-Level Signale, sondern die
Anwendungs-Daten, also Druckdaten, Druckerstatus etc. Das ist nämlich im
Gegensatz zu den physikalischen USB-Signalen nicht zeitkritisch.
fchk
Frank K. schrieb:> Was auch möglich ist: eine USB-Brücke, die auf Protokollebene arbeitet.> Nehmen wir an, Du willst einen Drucker fernsteuern. Dann brauchst Du> eine Kiste, die für den PC wie ein Drucker aussieht, und eine Kiste, die> für den Drucker wie ein PC aussieht. Was dann zwischen den beiden Kisten> transportiert wird, sind dann nicht die Low-Level Signale, sondern die> Anwendungs-Daten, also Druckdaten, Druckerstatus etc. Das ist nämlich im> Gegensatz zu den physikalischen USB-Signalen nicht zeitkritisch.
Frank vielen Dank!
Genau hierum geht es, ob ich dies gelöst bekomme ohne eine "Kiste" als
Device und die andere als erneuten Host zu konfigurieren?
Das wäre meine Worst-Case Lösung.
Im Idealfall hätte ich gerne die Kommunikation von Host (PC) zu Device
(Tastatur) per Gigabit-Ethernet getunnelt ohne ein Weiteres Device und
Host einzusetzen.
PC (Host) <-> FPGA (Device) <-> Ethernet (Datenübertragung) <-> FPGA
(Host) <-> Tastatur (Device)
Grüße
Wir benutzen sowas im industriellen Umfeld von Icron. Das funktioniert
einwandfrei über Glasfaser oder CAT Kabel. Je nachdem was man überträgt
und wie weit ist es aber etwas langsamer als direkt angeschlossen.
Bei USB 3 ist es auch bei 100m Glasfaser noch genau so schnell, da dort
ja eh TX und RX getrennt sind und nix umgesetzt werden muss.
Die haben das mittlerweile auch für LAN, also nicht zwingend als
Direktverbindung.
Es gibt entsprechende Hardware zu kaufen, jedoch entspricht keine meiner
Anforderung.
Grund hier für ist ein spezielles Ethernet Protokoll an welches nun die
USB-Daten mit angebunden werden sollen.
Grundsätzlich: Finger weg von solchem Unsinn.
Das USB Protokoll erlaubt es nicht das Signal zu tunneln, schlicht
aufgrund des Timings. Alles was in der Art auf dem Markt ist, ist eine
Krücke, die nur mit Glück in bestimmten Konfigurationen funktioniert.
Es gibt "USB Server" die sind quasi ausgelagerte Host-Controller, bei
denen der Host-Controller nicht auf dem Motherboard im lokalen Bus
sitzt, sondern am Ethernet. Bei denen gibt es die Timingprobleme nicht.
SAKI schrieb:> Die ganze Betrachtung ist unabhängig des Timing, es geht nur um die> Frage ob dies möglich ist, Daten so über mehr als 5m zu übertragen.
Ja klar. Aber das wird kompliziert, jedenfalls dann, wenn es universell
sein soll.
> PC (Host) <-> FPGA (Device) <-> Ethernet (Datenübertragung) <-> FPGA
(Host) <-> Tastatur (Device)
Also eins ist sicher: die FPGAs sind über. Was der erste macht, kann auf
dem PC in Software geschehen, was der zweite machen muß, ist für eine
unverselle Anwendung so komplex, dass der Job auf einem entsprechend
potenten µC viel besser aufgehoben ist.
Und was dann designmäßig insgesamt rauskommt, ist das, was man für
relativ kleines Geld fix und fertig als USB-Device-Server kaufen kann.
Ich würde Silex empfehlen, wenn's wirklich zumindest einigermaßen
universell werden soll. Ein dämliches USB-HID kann aber auch die
billigere Konkurrenz ganz sicher.
Fakt ist: bis du mit einem FPGA so weit bist, wie selbst der billigste
Silex-Konkurrent, hast du so viel Geld verbrannt, dass du dir so
ungefähr 1000..10000 8Port-Silex dafür hättest kaufen können...
SAKI schrieb:> Grund hier für ist ein spezielles Ethernet Protokoll an welches nun die> USB-Daten mit angebunden werden sollen.
Ethercat? Sercos? Profibus? Oder was ganz geheimes?
fchk
SAKI schrieb:> Die ganze Betrachtung ist unabhängig des Timing, es geht nur um die> Frage ob dies möglich ist, Daten so über mehr als 5m zu übertragen.
Timing ist aber extrem wichtig bei USB. Denn ein Gerät muss derart
schnell auf den USB Host antworten dass die Lichtgeschwindigkeit die
mögliche Länge ernsthaft begrenzt.
Außerhalb dieser Grenze kann es IMHO keine universelle "Verlängerung"
geben.
Glücklicherweise sind da auch die Verzögerungen von 5 Hub Chips mit
einberechnet, so dass man schon deutlich länger kommen kann - etwa mit
optischen Kabeln.
Lange Verlängerungen müssten also USB auf beiden Enden "terminieren",
wass dann aber nur für bestimmte Geräteklassen funktionieren kann.
Hey,
euch allen vielen Dank für die Meinungen, Denkanstöße und Unterstützung.
Ich werde Eure Kommentare im Forum mit in meine weitere Entscheidung
nehmen.
Somit ist der Thread für mich geschlossen.
Danke und schöne Grüße
c-hater schrieb:> Ich würde Silex empfehlen
Mit SEH habe ich bessere Erfahrungen gemacht, was Langzeitstabilität
angeht. Bei Silex war ab und zu ein Tritt nötig, d.h. Aus/Ein.
(prx) A. K. schrieb:> Mit SEH habe ich bessere Erfahrungen gemacht, was Langzeitstabilität> angeht. Bei Silex war ab und zu ein Tritt nötig, d.h. Aus/Ein.
Nunja, wir benutzen den Kram praktisch nur, um "USB-Lizenz-Dongles"
(also das allseits beliebte Kopierschutz-Gedöhns) für VMs bereit zu
stellen. Zumindest hier gab es niemals die Notwendigkeit für
irgendwelche "Tritte".
Und immerhin sind es insgesamt sieben verschiedene Anwendungen, für die
wir uns mit solchem Scheiß rumschlagen müssen. Diese Lizenz-Scheiße
nervt selbst dann noch mehr als genug, wenn die Dongles problemlos
funktionieren...