ich habe gelesen, dass man USB einfach mit einem Pull-Up-Wiederstand direkt an einem FPGA betreiben kann. Das geht wirklich nur für Fullspeed? Dient der Pull-Up-Wiederstand für die USB Erkennung(Plug and Play)? Ist es möglich mit einem USB PHY(z.B. FTDI) zu kommunizieren ohne die entsprechende Treibe zu instalieren? Praktisch wie eine Bridge(USB->RS232->RS232->USB). vielen Danke. Hua
@hua >ich habe gelesen, dass man USB einfach mit einem Pull-Up-Wiederstand >direkt an einem FPGA betreiben kann. Das geht wirklich nur für Fullspeed? Dient der Pull-Up-Wiederstand für die USB Erkennung(Plug and Play)? Ja das geht nur mit Low-Speed (1.5 Mbit/s) und Full-Speed(12 Mbit/s). Für High-Speed (480 Mbit/s) braucht man spezielle PHYs. Der Pull-Up ist für die Signalisierung der Geschwindigkeit (LOW/FULL/HIGH Speed). Das Plug & Play macht die Software. >Ist es möglich mit einem USB PHY(z.B. FTDI) zu kommunizieren ohne die >entsprechende Treibe zu instalieren? Praktisch wie eine >Bridge(USB->RS232->RS232->USB). Ohne Treiber wird das nix. MfG Falk
Danke erst mal für deine Helfe. Kann das so funktionieren? PC <-> (USB-PHY) <-> FPGA <-> (USB-PHY) <-> (USB-Gräte) Der FPGA konfiguriert nur die USB-PHY und leitet die Daten durch. Würde der PC den USB-PHY oder das USB-Gerät als USB Device erkennen?
Könnte so funktionieren, wenn man einen Optokoppler zwischen den USB datenleitungen schaltet und die Kommunikation damit auslesen?
Die Geschichte mit dem "USB direkt am FPGA" ist ein ziemlicher Hack. Für Low-Speed-Devices (1.5 MBit/s) kann man das machen, bei Full-Speed (12 MBit/s) kann es je nach Host-Controller, Device und Kabel auch schiefgehen. Die USB-Spezifikation beschreibt sehr genau die (analogen) Signalformen, z.B. die Flankensteilheit etc. Außerdem ist der Bus bidirektional und nutzt sowohl differentielle als auch nicht-differentielle Übertragung. Das alles bekommt man mit einem 1:1-Anschluss an das FPGA nicht sauber hin. Mit einem externen USB-PHY bist Du auch bei Full-Speed auf der sicheren Seite. Wenn es Dir ums Sniffen an einem vorhandenen Gerät geht, könntest Du die vorgeschlagene Host--PHY--FPGA--PHY--Device Variante nehmen. Wenn es mehr ein Hack werden soll/darf, geht auch FPGA direkt an den USB-Leitungen und alles mit kurzen Leitungslängen (!) machen. Das Problem bei letzterer Lösung ist, dass Du bei den bidirektionalen Übertragungen nicht weißt, ob gerade Host oder Device sendet. Da das aber aus den Inhalten der übertragenen Pakete ersichtlich sein sollte, kannst Du auch erstmal alles mit dem FPGA speichern und später am PC "in Ruhe" auswerten. Die "Luxus-Lösung" wäre vielleicht, mit dem FPGA und 2 PHYs einen USB-Hub zu implementieren, der dem Host gegenüber 2 Ports meldet. An einem hängt dann transparent das zu sniffende Device, am anderen kann man den Puffer des FPGAs bequem auslesen. :-) Jetzt hab' ich einen halben Roman geschrieben, und noch gar nicht gefragt, was das am Ende eingelicht werden soll. Wenn es "nur" darum geht, ein USB-Device Protokoll-mäßig zu untersuchen, reicht vielleicht auch ein Software-USB-Sniffer wie Snoopy (Windows) oder eine der Sniff-Lösungen für Linux. Gruß, Till.
Hallo Till, Danke für deine Helfe. Bei mir ist der Host kein PC und erkannt der Host auch keinen Hub, deswegen kann man nicht einfach softwaremässig realisieren. benötigt einer host eine Treibe für den USB-PHY unbedingt? oder wenn es so wie "Host--PHY--FPGA--PHY--USB-Stick" ist und der Host hat keine Treibe, würde der USB-Stick vom Host erkannt? Wie ist mit meine andere Lösung(Optokoppler)? Lg, Xincheng
Vielleicht erläuterst Du mal lieber was Du machen möchtest. Der Host muss in jedem Fall seinen Teil des Protokolls unterstützen wie das Device auch. Wenn ein Teilnehmer das Protokoll nicht beherscht wird das nix, egal ob die Protokollengine nun ganz in Hardware, in Hardware + Firmware oder ganz in Software (und Pegelwandlern) realisiert wird. Noch was zum Sniffen: Die Lösung PC <-> (USB-PHY) <-> FPGA <-> (USB-PHY) <-> (USB-Gräte) klingt zwar gut, ist allerdings nicht wirklich praktikabel wenn man sich die zeitbedingungenen ansieht recht anspruchsvoll zu implementieren. Und nun im FPGA noch einen USB-Hub zu implementieren halte ich für die Einrichtung einer ganz neuen überflüssigen Baustelle. Für normale Entwicklungsaufgaben im gehobenen Amateur/Semiprofi Bereich sollte ein Softwaresniffer völlig ausreichend sein. Ausnahme vielleicht FPGA-implementationen wo man auch noch die Bitschicht und die Timingparameter überprüfen muss.
Also, ich muss die komunikation zwischen ein Host(kein PC, zB. USB-Anschuluss von einem Oszilator(nur als ein Beispiel)) und Device(zB. USB Stick) erkennen, auch die Geschwindigkeit ausmessen.
In diesem Fall scheiden Software-Sniffer wohl aus. Die Timing-Probleme bei der Doppel-PHY-Lösung sehe ich nicht so ganz. Allerdings hast Du (Hua/Xincheng) uns auch immernoch nicht so ganz verraten, was Du denn nun genau brauchst. Protokoll-Analyse ist bei einem USB-Stick unsinnig, weil das "USB Mass Storage Protocol" dokumentiert und bei usb.org einsehar ist. Was meinst Du in diesem Zusammenhang mit "Geschwindigkeit"? Gruß, Till.
Hallo Till, OK, noch mal die genaue Info. Ich muss so zwischen 8 USB-Sticks umschalten und gleichzeitig mit hören, ob die Erkennung des USB-Sticks erfolgreich ist, oder nicht. Das ganze muss automatisiert werden. Darum möchte ich gerne auch das Protokoll auslesen und analysieren. Gibt so was wie „USB-Interface“(kein Einfluss in die normale dataleitungen), aber der nicht vom Host als Host erkannt wurde? Einfach die Data-Busspannung messen und ins RS232 oder was auch immer umwandeln. lg, Xincheng
Hallo! Automatisiertes Umschalten zwischen 8 USB-Sticks? Warum das? Wenn die Größe eines Sticks nicht ausreicht -> größeren kaufen oder USB-Festplatte nehmen. Wenn verschiedene Sticks dran sollen, tut's eventuell auch eine mechanische USB-Umschaltbox. Elektronisch läßt sich das natürlich auch machen, getreu der Devise "machbar ist alles". Die Frage ist nur, wieviel Aufwand Du betreiben willst. Ein normaler USB-PHY scheidet beim Anzapfen der USB-Leitungen wohl aus, weil der PHY als Endpunkt der Leitung gedacht & entworfen ist. Also kannst Du nur (mit kurzen Verbindungen) die USB-Datenleitungen an Eingänge Deines FPGA legen. Ob die Fehlerrate auf dem Bus dadurch steigt, siehst Du spätestens bei der USB-Protokollauswertung im FPGA. Ein anderes Problem wäre die Umschaltung zwischen den verschiedenen Sticks. Vielleicht kann man analoge Multiplexer dafür verwenden. Das Ganze ist und bleibt aber ein Hack, im produktiven Betrieb (oder gar als verkauftes Produkt) möchte ich mir sowas lieber nicht vorstellen. Eine sauberere (aber technisch wesentlich aufwändigere) Lösung hatte ich ja schon vorgeschlagen: einen USB-Hub im FPGA. Wahlweise mit 9 PHYs (einmal zum Host und acht Mal zu den Devices) oder 2 PHYs und einem externen Umschalter. Vorteil: die USB-Leitungen werden nicht angezapft, und der Hub kann dem Host plug/unplug-Events "sauber" melden. Zudem muss der USB-Traffic der Devices zwangsweise durch den Hub und kann bequem mitgesnifft werden. Allerdings erfordert diese Lösung die Implementierung eines kompletten Hubs + Sniffer + Umschaltlogik, was sicher nicht trivial ist. Deshalb: such lieber nach einer anderen Lösung für Dein Problem. Gruß, Till.
Hallo Till, erst mal vielen Dank! Ich sehe auch nur eine mögliche Lösung für High Speed: PHY-USB-PHY. Ich habe aber noch eine bisschen Unklarheit, und zwar wenn ich die Lösung PHY-FPGA-PHY nehmen und zwischen HOST und USB-Device einschalten, welche Device werde vom Host erkannt? PHY oder USB-Device? Ich habe nämlich schon nach so einem PHY gesucht, aber leider hat alle PHY eine UMTI Interface (Eingentliche Endpoint). Ich darf ja kein HUB dazwischen einschalten, weil mein Host kein HUB erkennen kann (keine entsprechende Treibe Vorhand oder so was). Noch einfacher gesagt, ich brauche eine Lösung, die gar keine Einfluss in die ursprüngliche Kommunikation. Lg, Xincheng
Hallo! Ok, wenn wir über High-Speed-USB reden, kannst Du das Anzapfen der Leitungen vergessen. Das Dein Zielgerät keine Hubs unterstützt hab' ich glatt überlesen. Es bleiben also wirklich nur zwei PHYs mit dem FPGA dazwischen übrig. Ein 1:1-Durchschalten der Leitungen wird nicht klappen, dafür sind die PHYs auch nicht gedacht. Doch selbst, wenn Du dafür eine Lösung findest, dürfte der entstehende Jitter und die Latenz ausserhalb dessen liegen, was der USB-Standard zulässt. Vielleicht kannst Du einen "Proxy" bauen, der ganze USB-Frames puffert und weiterleitet. Mach Dich mal im USB-Standard schlau, wieviel Reaktionszeit für ein High-Speed-Device vorgeschrieben ist. Bei Full-Speed-Devices können IIRC zwischen dem Request des Hosts und der Antwort des Devices mehrere Millisekunden vergehen. Wenn das auch nicht geht, wäre sogar ein Proxy auf Ebene des "USB Mass Storage"-Protokolls denkbar. Spätestens auf dieser Ebene sollten die Delays des Proxys keine Rolle mehr spielen. Mir scheint aber, dass Du bei USB nicht so sehr sattelfest bist. Ein einzelner PHY wird natürlich überhaupt nicht vom Host "erkannt". Er koppelt lediglich den Bus (physikalisch) an Dein logisches Gerät (FPGA) an. Was Du uns immernoch nicht verraten hast: warum willst Du die USB-Sticks überhaupt umschalten? Gruß, Till.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.