USB Grundlagen Theorie Messungen Assembler ATmega

[Bernhard S. (bernhard)]

Geschätztes Forum,

in letzter Instanz soll ein kleiner Hardware USB-Sniffer entstehen,
bestückt mit einem ATmega max 20MHz.

Ob es theoretisch Überhaupt möglich ist, kann ich momentan noch nicht 
abschätzen, da sich die Impulszeiten im µs-Bereich bewegen und der AVR 
doch einige Takte benötigt, um diese zu bearbeiten und im SRAM 
abzulegen.

Im Beispiel wurde ein USB-RS232 angeschlossen, der Port ist noch 
geschlossen, also inaktiv. Nach einigen ms zeigte sich dieses OSZI-Bild 
https://www.mikrocontroller.net/attachment/557966/Pege_1us_.jpg

Wird der Port durch die PC-Software geöffnet, dann herrscht reger 
Datenverkehr.

Deutlich ist erkennbar, dass nach jeder ms der PC Daten mit dem 
USB-Stick autauscht s.Bild
https://www.mikrocontroller.net/attachment/557965/Pege_1us.jpg

Die Pegelunterschiede betragen bei D- und D+ ca. 3V, ich denke ein OPV 
könnte die Spannungdifferenz gut erkennen und ein USB-High und USB-Low 
zur Verfüung stellen.

Frage: Kennt jemand Literatur, wo die Gundlagen der USB-Übertragung gut 
beschrieben sind?

Danke

Bernhard

[Irgend W. (Firma: egal) (irgendwer)]

Du solltest erstmal erklären von welchem "USB" du redest
- https://en.wikipedia.org/wiki/USB#Signaling

Und dann für den Anfang: Jenachdem hast du dann auch verschiedenen 
Leitungscodierungen:
- https://en.wikipedia.org/wiki/Line_code

Im Forgeschrittenenmodus dann:
- https://www.usb.org/documents
- z.B.: https://www.usb.org/document-library/usb-20-specification


Du willst allen Ernstes z.B. 40 MB/s(480 MBd) bei USB 2.0 mit deiner 
20MHz Gurke aufzeichnen? Selbst USB 1.0 (Full Speed) 1 MB/s(12 MBd) ist 
damit schon arg sportlich => ca. 1,7 Prozessortakte je Symbol.

Wie stellst du denn sicher das dir nicht irgendwo eine Signalflanke 
"Übersprungen" wird? Du dürftest im Moment eher irgendwelche 
Zufallsproben aufzeichnen, aber nichts was mit den Flanken 
synchronisiert ist.

[Hinkucker (Gast)]

Anstatt für das Foto "Versuchsaufbau" fast sämtliche nicht benutzten 
Geräte einzuschalten, die weder gebraucht werden noch irgendwo 
angeschlossen sind, würde ich erstmal die Tastatur reinigen.

[m.n. (Gast)]

Ob diese Bücher noch erhältlich sind, müßtest Du überprüfen. Sie sind 
2001 erschienen.

USB 2.0, Franzis' Verlag, H.-J. Kelm,
ISBN 3-7723-7965-6

USB Handbuch für Entwickler, mitp, Jan Axelson,
ISBN 3-8266-0698-1

Vielleicht hilft Dir dieses RP2040 Projekt weiter, wenn es mit dem AVR 
(vermutlich) nicht funktionieren will: 
https://www.eevblog.com/forum/projects/usb-sniffer-using-rp2040/

[Thomas Z. (usbman)]

Bernhard S. schrieb:
> Deutlich ist erkennbar, dass nach jeder ms der PC Daten mit dem
> USB-Stick autauscht s.Bild

Das ist der SOF Transfer der kommt immer wenn das Gerät enumeriert ist. 
Die eigentlichen USB Transfers passieren zwischen diesen SOFs. Das 
bedeutet im besten Fall max etwa 17 Bulks (FSpeed, 12MBd)

Generell würde ich sagen was du vorhast ist ziemlich hoffnungslos. Da 
brauchst du schwerere Geschütze. Bedenke schon Fullspeed hat 12 MBd. 
Nicht ohne Grund wird USB üblicherweise mit einem 48 MHz Takt gesampled. 
Wenn du dann die Rohdaten hast braucht es einen NRZI Decoder und einen 
BitDestuffer. Der einfachste Teil ist das Decodieren des USB Resets und 
USB Powerdown, das wird mit Pegeln gemacht die NRZ verletzen.

Bei Highspeed kommen dann noch neben der höheren Geschwindigkeit ein 
paar zusätzliche Pakete dazu (Chirp..)

Das sowas für Lowspeed möglich ist zeigen AVR Software USB 
Implementierungen.

Für die Auswertung brauchst du also ein FPGA. Schau mal bei OpenCores da 
waren zumindest früher auch USB Cores.

[PittyJ (Gast)]

In meinen Augen ist das ein Blödsinn.
Unter USB 2.0 läuft doch kaum noch etwas. Wie will man das in Software 
dekodieren.
Und es kommen oft auch ein paar mehr Daten. Die sollen dann alle im 
ATMega gespeichert werden?

Datenrate und Volumen übersteigen die Kapazität um ein Vielfaches.

Wenn man was am PC aufzeichen möchte, dann geht of schon Wireshark. Mit 
vernüftiger Gui und Dekodierung. Schau dir das an und vergiss den 
AtMega.

[Bernhard S. (bernhard)]

@alle
Danke für Eure hilfriechen Antworten.

Dieses Beispiel-Paket, welches im 1ms Abstand übertragen wird, zeigt 
deutlich, dass ein Wattebällchen-AVR hier kaum eine Chance hat, hier 
sind "schwere Geschütze" gefragt, wie es Thomas schon anmerkte.


Im ca. 150ns Abstand liegen die einzelnen Bits an, diese bei 20MHz Takt 
(50µs) zu sampeln, zu synchronisieren und noch im SRAM bzw. in Registern 
ablegen, das ist eine echte Herausforderung.

Ev. ist eine zusätzliche Hardware hierzu erforderlich.

Hier fand ich auch interessantes zu den USB-Grundlagen, auch gut 
erklärt:
https://www.usbmadesimple.co.uk/ums_3.htm

Diese Projekt werde ich vorerst in den Sleep-Modus versetzen, bis ev. 
weitere Erkenntnisse vorliegen.

Bernhard

[c-hater (Gast)]

Bernhard S. schrieb:

> Hier fand ich auch interessantes zu den USB-Grundlagen, auch gut
> erklärt:
> https://www.usbmadesimple.co.uk/ums_3.htm

Ja, das ist sehr hilfreich zur Einarbeitung in USB. Nur alleine die 
Specs lesen ist arg trocken und sie sind auch nicht gerade mit einem 
didaktischen Aspekt gesegnet.

Andererseits: "USB made simple" allein genügt natürlich nicht. Das ist 
ja nicht ganz neu und viele Aspekte der aktuellen USB-Specs werden darin 
nicht einmal erwähnt.

Aber auch schon vieles mit dem Stand USB2.0 wird kaum angerissen. Nunja, 
man kann halt auch nicht ernsthaft erwarten, dass es jemandem gelingt, 
ein paar tausend Seiten Specs auf unter 100 Seiten einzudampfen, ohne 
dass dabei Informationen verloren gehen.

[Niklas G. (erlkoenig)]

USB auf der physischen Ebene zu sniffen bringt ja eigentlich nur was 
wenn man seine eigene Hardware entwickelt, d.h. man ist sowieso schon im 
FPGA oder ASIC Bereich, und dann kann man den Sniffer auch als FPGA oder 
ASIC bauen, also kein Grund das irgendwie in einen AVR zu quetschen...

Wenn man einfach nur ein eigenes USB Gerät auf Basis eines USB-fähigen 
Mikrocontrollers entwickeln möchte, braucht man so einen Sniffer eher 
nicht, da kann man alles auf PC-Seite analysieren (z.B. Wireshark). Hier 
hat man typischerweise eher Probleme mit dem Protokoll vom Default 
Control Endpoint und den Deskriptoren, und da hilft ein Sniffer auf 
physischer Ebene sowieso weniger, weil diese schon von der Hardware vom 
Mikrocontroller abgehandelt wird die ja hoffentlich funktioniert.

[Martin H. (horo)]

Bernhard S. schrieb:
> Frage: Kennt jemand Literatur, wo die Gundlagen der USB-Übertragung gut
> beschrieben sind?

USB in a NutShell:
https://www.beyondlogic.org/usbnutshell/usb1.shtml

Diese Dokumentation (gibt es auch als pdf im Netz) findet sich 
ausgedruckt mit vielen farbigen Anmerkungen in meinem USB-Ordner im 
Regal, das Dokument (zusammen mit midi10.pdf) habe ich vor Jahren 
verwendet, um MIDI für VUSB zu realisieren.

[PittyJ (Gast)]

Niklas G. schrieb:
> Wenn man einfach nur ein eigenes USB Gerät auf Basis eines USB-fähigen
> Mikrocontrollers entwickeln möchte, braucht man so einen Sniffer eher
> nicht, da kann man alles auf PC-Seite analysieren (z.B. Wireshark). Hier
> hat man typischerweise eher Probleme mit dem Protokoll vom Default
> Control Endpoint und den Deskriptoren, und da hilft ein Sniffer auf
> physischer Ebene sowieso weniger, weil diese schon von der Hardware vom
> Mikrocontroller abgehandelt wird die ja hoffentlich funktioniert.

Genau das habe ich gemacht. USB an einem STM32H7. Die HAL API von STM 
funktionierte auf Anhieb. Zumindest die Device-Descriptoren waren 
verfügbar.
Da analysiere ich nicht den Datenstrom per Hand, sondern nehme das 
Subsystem der CPU.
Geht bei den NXP-CPUs genauso.
Und für die eigenen Pakete habe ich dann mit Wireshark geschaut, ob 
alles so geschickt wurde, wie gedacht.

Vielleicht sollte der TE auch mit so etwas anfangen, damit er ein Gefühl 
für USB kommt. Dann merkt er selber, was ein ATMega nicht kann.

[Niklas G. (erlkoenig)]

PittyJ schrieb:
> Genau das habe ich gemacht. USB an einem STM32H7. Die HAL API von STM
> funktionierte auf Anhieb.

Selbst wenn man seinen eigenen Treiber für die Peripherie schreibt, wie 
ich es unter USB-Tutorial mit STM32 beschrieben habe, braucht man 
keinen Sniffer auf der physischen Ebene; Wireshark reicht. Teilweise ist 
nichtmal der nötig, unter einem Linux-Host sind die Kernel-Meldungen bei 
fehlerhafter Enumeration schon hilfreich.

[Bernhard S. (bernhard)]

@alle

Mehrfach wird Wireshark empfohen.

Momentan nutze ich die Version 1.12.11 unter WIN XP und Win10.

Frage: Wie kann man bei dieser Version einen USB-Port "sniffen" ?

[Niklas G. (erlkoenig)]

https://wiki.wireshark.org/CaptureSetup/USB

Es schadet sicherlich auch nicht, eine nicht-antike Version von 
Wireshark zu installieren, das kostet schließlich nichts.