usb-schnittstelle protokollieren

Hallo, ich habe ein Problem und hoffe, dass hier jemand ist, der sich damit auskennt und mir helfen kann:
Meine Aufgabe ist folgende: Eine Hardware soll erstellt werden, mit der man die Datenübertragung an einer USB-Schnittstelle protokollieren und auslesen kann, allerdings ohne Mikrocontroller. Mich in Mikrocontroller einzuarbeiten würde eh viel zu lange dauern. Ich soll einen FTDI-chip zum Abgreifen der Daten verwenden. Ich hab mich mal ein bisschen darüber informiert (habe vorher noch nie mit sowas gearbeitet) und bin auf den FT232R gestoßen. Kann mir jemand sagen, ob der dafür geeignet ist.
Wäre nett, wenn mir jemand antworten würde. Würde mich auch über weitere Tipps von euch freuen.

Nach meinen ersten Versuchen mit USB würde ich sagen
ohne Mikrocontroller wird es wahrscheinlich nicht gehen.
Der Bus ist eigentlich aus Hardwaresicht nämlich kein
Bus sondern ein Stern. Die Daten werden bei Full Speed
(12MBit) als differentielle Signale übertragen.
Zudem wird noch über Widerstände die Geschwindigkeit
des Geräts und dessen Präsenz detektiert.
Da kann man nicht einfach einen zweiten Baustein parallel
schalten.

Für den Anfang und um zu sehen wie Komplex der
USB-Bus ist, würde ich dir empfehlen die Seite von
http://www.beyondlogic.org/
zu studieren.
Im besonderen "USB in a Nutshell - Making sense of the USB
standard" und "USB Protocol Analysers".

GeoBot

Das ist ja genau mein Problem. Ich habe mich schon über die Datenübertragung an der USB-Schnittstelle informiert und weiß, dass man die Daten nicht so einfach abgreifen kann, da sich jedes Gerät, dass man an den Bus hängt, zuerst irgendwie identifizieren muss und eine Adresse zugeteilt bekommt. Könntest du mir sonst irgendeinen Tipp geben wie man so etwas realisieren könnte? Ich bin dankbar für jeden Tipp, den ich bekomme. Im notfall probiere ich es halt mit nem Mikrocontroller, hab halt nur noch nie damit gearbeitet.
Vielen Dank trotzdem für deine Antwort!

Die zündende Idee habe ich da auch noch nicht ge-
habt! Aber man kann ja mal darüber philosophieren,
und schauen ob etwas herauskommt.

Angenommen wir wollen die Kommunikation nur
"mithören", dann brauchen wir einen "Baustein"
den wir an die beiden Leitungen eines Differenzsignals
hängen, der dabei die Datenübertragung nicht stört
und uns das Signal vom Bus entkoppelt zur Verfügung
stellt.

Möglicherweise tut es ein breitbandiger OP mit
JFET-Eingängen? Daran dann einen Schmitttrigger.

Da die dann die beiden Bitströme einem mit
12 MBit/s seriell entgegenkommen ist die Frage
wie bekomme ich die in einen Rechner?
Mit RS232 ist da nix.
Ich denke auch ein Parallelport wird da noch zu
langsam sein. Oder können die 1,5MByte/s?
Und das geht auch nur wenn man einen
Seriell-Parallel-Wandler findet der da schnell genug
ist.

Bliebe noch Ethernet - USB HighSpeed - oder eine
PCI-Karte.

Gibt man sich mit Ausschnitten aus der Kommunikation
zufrieden, kann man den in einem großen FIFO
zwischenspeichern und langsam in den Rechner einlesen.

Den Rohdatenstrom mit dem ganzen Protokolloverhead
muss man dann "nur" noch filtern um an die Daten zu
kommen. Dazu musst du dann aber die verschiedenen
Protokolle beherrschen.

Also nichts was man mal so zwischen durch machen kann.

GeoBot

Das hört sich ja ziemlich kompliziert an.
Ich hab auch schon daran gedacht, einfach zwei Spulen jeweils um die invertierte und die nichtinvertierte Daten-Leitung zu wickeln und durch die darin induzierten Spannungen die Informationen abzugreifen. Das Problem ist nur, dass man dann eben nie weiß, von wo das Signal gerade kommt, wegen der bidirektionalen Übertragung.
Die Verarbeitung der Daten ist dann auch nochmal ein Problem. Ich habe gelesen, dass sie NRZI-Verschlüsselt sind und ich weiß nicht, wie man soetwas rückgängig macht. Ich habe für das Projekt eigentlich zwei wochen Zeit, denke aber nicht dass ich das noch in der Zeit schaffen werde.

Hallo!

Dier Idee vom GeoBot scheint mir am einfachsten zu sein, da man die Signale vom USB-Leitungen, ohne ein Gerät anzumelden (so wie mit einem Oszilloskop), "beobachten" kann. Man müsste nur noch eine Hardware bauen, die sich am USB-Port eines PCs anmeldet und die Daten einlesen lässt. Vielleicht könnte man dafür sogar ein fertiges USB-Oszilloskop adaptieren ?

Edit: in deinem erstem Beitrag ist nur angegeben, dass die Daten protokoliert und nicht analisiert werden sollen.

MfG

In meiner Aufgabenstellung steht nur, dass ich die Daten protokollieren soll, egal in welcher Form. Ich soll dann ne Anleitung dazu schreiben, wie man sie wieder mithilfe eines Programmes umformen kann. Mit C oder C++ zum Beispiel. Das mit dem OP hört sich wirklich nicht schlecht an. Meinst du einer aus der TL06_Serie würde funktionieren? Und reicht die Betriebsspannung, die ich über das USB-Kabel bekomme aus um den OP zu versorgen?

Fürs protokolieren eines USB-Busses mit 12 MHz rechteckigen Impulsen sollte der OP die Bandbreite um 120 MHz haben, es wird also mit "normalen" OPs nicht gehen. Wenn du einen breitbändigen rail-to-reil OP (z.B. MAX 4012, 4108, 4113, 4224 vom Reichelt) nimmst, dann würde die +5V von USB reichen.

MfG

Hab mir mal die Datenblätter der von dir genannten OP`s angeschaut. Jetzt hätte ich nochmal ne Frage. Ich hab schonmal vor längerer Zeit mit OP`s ein paar kleinere Schaltungen aufgebaut. Ich weiß noch, dass man immer eine + und eine -Spannung anlegen musste. Beim USB-Anschluss hat man aber doch als Versorgungsspannung 5 V gegen Masse. Geht das dann? Und was mir auch noch aufgefallen ist, die OP`s brauchen 12V supply voltage. Da reichen doch die 5V gar nicht vom USB.

Die + und - Spannungen sind nur für nicht rail-to-rail OPs notwendig. Die von mir o.g. OPs arbeiten schon ab 3,3 V (erste Seite des Datenblatts). :)

Bist du dir im klaren darüber das das ein Projekt mit mindestens 2 mannjahren aufwand ist ?
Weiterhin scheint dein Auftraggeber keinen blassen chimmer von USB zu haben denn der "Tipp" mit dem FTDI ist ziemlich daneben. Du musst den physischen Datenverkehr mithören, daraus die Daten extrahieren die an die verschiedenen Endpunkte gegangen sind, daraus kannst du dann zumindest die Enumeration des gerätes mitlesen und bekommst raus was für descriptoren es hat. Ab da kannst du so gut wie nichts mehr machen. Denn alles hängt von der Firmware des Gerätes und dem Treiber auf dem Rechner ab.

Erschwehrend hinzu kommt das einfache PC Tools wie SnoopyPro schon alles machen was du bis dahin mühsamst in mehreren Monaten zusammengebastelt hast.

Ja, bin mir darüber im klaren, ich erwarte auch nicht, dass ich es in den zwei Wochen, die ich jetzt noch dafür habe, komplett zum laufen bekomme. Das mit den Mannjahren könnte man jetzt als diskriminierung verstehen!
Zu PICture: Erstmal danke für deine ganzen Tipps. Ich habe mir jetzt mal den von dir empfohlenen IC MAX4012 bestellt. Meinst du ich soll noch einen Schmitt trigger dahinter schalten, so wie GeoBot es geraten hat. Der dient ja eigentlich nur dazu das Signal auf eindeutige Werte zu bekommen. Aber wenn der OP schnell genung ist, braucht man das doch nicht, oder?

Zitat:

---

Zitat von **julia85**

Das mit den Mannjahren könnte man jetzt als diskriminierung verstehen!

---

Da muss ich grad mal offtopic was einwerfen: Es wäre mir neu, dass der feststehende Begriff "Mannjahr" in irgendeiner Weise gegendert wird. Das Wörterbuch sagt dazu auch: "Ein Mannjahr bezeichnet gewöhnlich die Arbeitsleistung, die eine Person während eines Jahres (im Schnitt 220 Arbeitstage) leistet." Und das Wort Person bezeichnet in der Regel beide Geschlechter ;)

hallo,

wäre so ein sniffer nicht am einfachsten?


http://benoit.papillault.free.fr/usbsnoop/doc.php.en


gruss

Hallo!

Bei jeder Entwicklung macht man zuerst das minimalste, sonst dauert es fast ewig. Wenn das abgegriffene Signal vom USB-Bus nicht genug gut für weitere Verarbeitung seien sollte, könnte man immer noch dazwischen einen Schmitt-Trigger einschleifen. Ich hoffe, dass du es anfangst auf einer Lochrasterplatine aufbauen würdest und erst am Ende eventuell eine Platine ätztst. Ich habe selber mit diesen OPs noch nichts gemacht, aber etwas enliches wurde schon lange diskutiert. Ich vermute, dass die Eingangsimpedanz des OPs zu niedrig wäre, siehe dazu:

https://www.roboternetz.de/phpBB2/viewtopic.php?t=44240

MfG