|
Anzeige
|
USB Pakete interpretieren
Gast
#4802083
Hallo zusammen, Ich hab ein USB CDC Kommunikation mit einem STM32 implementiert, aber jetzt möchte ich wissen, wie kann ich diese Daten mit einem Logic Analizer dekodieren, Wie soll ich das interpretieren um die gesendete Daten zu dekodieren?
Gast
#4802087
Warum so kompliziert ? http://vusb-analyzer.sourceforge.net/ oder Wireshak
Gast
#4802111
Hallo , und danke für die schnelle Antwort, Ich hab gelesen und hab das gefunden: "To run the Virtual USB Analyzer, you must have Python and the PyGTK bindings." Hast du schon das Programm verwendet?
Gast
#4802117
Ne nur Wireshak und das auch nur mit Linux such mal nach "USB Sniffer" bei google da findest einiges. Die fehlenden libs findest im netz die sind nicht so untypisch.
Gast
#4802142
K. J. schrieb: > Ne nur Wireshak Wireshark :-) Mit der von K.J. zitierten Methode kannst Du sicherlich schon einmal einiges in Sachen USB-Debugging erschlagen. Und als Hobby-USB'ler bleibt Dir vermutlich auch gar keine andere Wahl. Wenn's ausreicht, so ist alles perfekt. Ansonsten sei Dir bewußt, dass Du mit so einem Software-Analyzer Programm nicht alles im Umfeld USB analysieren kannst. Wo Software-Analyzer an ihre Grenzen stoßen, dort kommen USB Hardware-Analyzer ins Spiel. Teledyne Le Croy ist einer der führenden Hersteller. Für einen Einsteiger-USB-Analyzer (nur USB2) bist Du dann allerdings schon einmal ganz locker flockig 800-1100 EUR los. Diese Seiten zeigt Dir die Unterschiede zwischen Hardware- und Software-Analyzern auf: http://www.totalphase.com/solutions/apps/usb-analyzer-benefits/ https://www.osr.com/nt-insider/2014-issue4/hardware-vs-software-bus-analyzers-alternatives/ Und hier einmal beispielhaft die Möglichkeiten, die Dir so ein Hardware-Analyzer bietet: http://teledynelecroy.com/protocolanalyzer/protocoloverview.aspx?seriesid=414&capid=103&mid=511#product_details Solltest Du mit USB 1.1 auskommen, so gibt's dort ab und an billige HW-Analyzer auf dem Markt und seit USB3 sollten eigentlich die 2er Analyzer auch langsam billiger werden. Aber - wie gesagt - wenn Du schön brav die STM32-Bibliotheken und Beispiele verwendest, wirst Du vermutlich gar nicht in die schauder- haften USB-Protokolluntiefen samt Maikäfer-Timings abtauchen müssen. Ich selber hab's einmal versucht - ist als Hobbyelektroniker mit Hobby-Zeitbudget kaum zu schaffen (aber es mag talentiertere Protokoll-Spezis geben ...). Viele Grüße & good luck Josef2
Gast
#4802394
Danke euch für eure nette Antworten Lalo schrieb: > Wie soll ich das interpretieren um die gesendete Daten zu dekodieren? Ich habe das mal mit Pulseview (sigrok) gemacht. Dort gab es einen USB Dekoder, der auch SOF und PID angezeigt hat. USB Pakete sind ja IIRC immer SOF-PID(-Addresse, EP, Daten optional-)-EOP aufgebaut, die zeigt Dein LA aber im 1. Screnshot korrekt an. Im Beispiel oben werden grade keine Daten übertragen (NAK Token). Zur Interpretation muss man sich leider das USB Protokoll mal angeschaut haben - das würde hier den Rahmen sprengen. Wireshark zeigt unter Windoof nicht 100%ig alles an, ich hatte mal Probleme mit USB Resets. Aber die übertragenen Daten würde man zu 100% sehen. +1 Wireshark Sobald Du die Hardware soweit hast daß sie Pakete empfängt und so antwortet daß es beim Host wieder ankommt (also zum Beispiel immer dann wenn du die vorhandene USB-Peripherie eines µC korrekt angeschlossen und konfiguriert hast die sich automatisch um sync und pid und crc kümmert und nicht etwa versuchst USB zu Fuß zu bitbangen) sollten die Informationen die Wireshark liefert ausreichen um den ganzen Rest des Protokolls zu implementieren und zu debuggen.
Gast
#4803186
Morgen, ich habe dieses Programm genutzt, und das ist was ich bekomme. Die Sache ist, dass ich möchte die Zeit messen, die mein Ding braucht um diese 100Bytes zu senden.
Angehängte Dateien:
Lalo schrieb: > Morgen, ich habe dieses Programm genutzt, und das ist was ich bekomme. Sieht doch hübsch aus ... > Die Sache ist, dass ich möchte die Zeit messen, die mein Ding braucht um > diese 100Bytes zu senden. Und das ergibt sich nicht aus der Spalte "Time" in Deinem Tool? Oder hast Du Probleme mit der Interpretation des Protokolls und kannst ggf. nicht einschätzen, wo die Übertragung Deiner 100 Bytes anfängt und wo sie aufhört? Wenn Du uns noch etwas mehr "Futter"/Infos gibst, so bekommst Du sicherlich im Gegenzug ebenfalls noch mehr Input. Viele Grüße Josef2
Gast
#4803236
Josef S. > Und das ergibt sich nicht aus der Spalte "Time" in Deinem Tool? Das mit der "Time" muss ich aber genauer schauen, weil ich nur diese Zeit messe, die als Time da vorgestellt ist. > Oder hast Du Probleme mit der Interpretation des Protokolls und kannst > ggf. nicht einschätzen, wo die Übertragung Deiner 100 Bytes anfängt > und wo sie aufhört? > > Wenn Du uns noch etwas mehr "Futter"/Infos gibst, so bekommst Du > sicherlich im Gegenzug ebenfalls noch mehr Input. Ich kenne mich nicht so gut mit dem USB Protokoll, deswegen bin auch nicht sicher, wie ich diese Daten interpretieren soll. Eigentlich will ich die Geschwindigkeit der übertragende Daten messen, deswegen sende ich von meinem Board am Computer diese String mit 100 Zeichen. Lalo schrieb: > Eigentlich will ich die Geschwindigkeit der übertragende Daten messen, > deswegen sende ich von meinem Board am Computer diese String mit 100 > Zeichen. Ein einzelnes Paket wird (bei Full Speed) mit 12 Mbit/s übertragen, aber das ignoriert den Protokoll-Oberhead. Du musst mehrere von diesen Paketen senden, und die durchschnittliche Zeit zwischen zwei Paketen berechnen.
Gast
#4803467
Ja, stimmt, aber am Anfang eines Pakets kommt immer eine andere Informationen... Deswegen passt diese Zeit nicht, mit der Zeit der übertragende Daten, die in diesem Fall 100 Bytes sind
Angehängte Dateien:
Lalo schrieb: > Die Sache ist, dass ich möchte die Zeit messen, die mein Ding braucht um > diese 100Bytes zu senden. Hatten wir dieses Thema nicht kürzlich schon mal? Lalo schrieb: > Ja, stimmt, aber am Anfang eines Pakets kommt immer eine andere > Informationen... > > Deswegen passt diese Zeit nicht, mit der Zeit der übertragende Daten, > die in diesem Fall 100 Bytes sind Ich verstehe ehrlich noch nicht ganz, was das Problem ist. Bin sicher, wir könnten Dir mehr helfen, wenn Du Dein Problem noch ausführlicher erklärst. Gruß Igel1 Beitrag "USB Transfer Speed Using CDC Protocol STM32446" Das dürfte das Ausgangsproblem sein.
Gast
#4806700
Lalo schrieb: > Ja, stimmt, aber am Anfang eines Pakets kommt immer eine andere > Informationen... > > Deswegen passt diese Zeit nicht, mit der Zeit der übertragende Daten, > die in diesem Fall 100 Bytes sind Aus deinen Zeilen wird einem nicht klar, was du EIGENTLICH bezwecken willst. Vermutlich stellst du dir vor, daß die Signale auf dem USB in irgend einer Weise mit den Signalen auf einem COM-Port vergleichbar wären. Das ist definitiv nicht der Fall, denn auf dem USB geht es anders zu. Da gibt es all die Pakete, die an EP0 gehen, also Verwaltungs-Zeug sind, es gibt den 1 ms Tick und es gibt die Datenpakete, die an die übrigen Endpoints gehen oder von selbigen abgeholt werden. Das ist übrigens eine wichtige Sache, die man erstmal verinnerlichen sollte: Als Device kann man NICHTS an den Host senden. Punkt. Man kann lediglich dem Host (per Hardware) klarmachen, daß man etwas zu Sendendes vorrätig hat. Der Host holt es sich dann nach seinem Gusto selber ab. Das ist was anderes als es selbst zu senden. Überhaupt ist man als Device nie der aktive Teil, sondern immer nur der Teil, der vom Host irgendwelche Anweisungen bekommt, die man eben auszuführen oder mit nem Stall zu beantworten hat, wenn man's nicht kann. Bei einem CDC kommt es nun drauf an, wie man sich als Device anstellt. Wenn der Host einem etwas an Nutzdaten hereinreicht, ist die Frage, wie schnell man den Empfangspuffer leer kriegt und als leer zurückmelden kann. Obendrein hängt die Geschwindigkeit davon ab, wieviele Bytes man so am Stück vom PC aus sendet und wieviele andere Devices noch über irgendwelche Hubs in Arbeit sind. Wenn es nur ein paar Bytes sind, dann ist die Übertragungsrate eben gering, weil der Verwaltungsaufwand zwischendurch so seine Zeit kostet. In umgekehrter Richtung sieht es ähnlich aus: Wenn man möglichst schnell einen gut gefüllten Sendepuffer als sendefertig markieren kann, dann geht es schnell. Wenn man jedoch nur ein paar Bytes zum Host senden will, dann geht es eben langsamer. Und wenn man in der Zeit, wo ein Sendepuffer grad übertragen wird, nicht einen Alternativ-Puffer füllt, sondern trödelt bis die Daten übertragen sind, dann wird es eben auch langsam. Also lies mal die Beschreibung des USB-Cores im Manual zu deinem STM32. Dort wirst du sehen, wie da was geht. W.S. Rufus Τ. F. schrieb: > Beitrag "USB Transfer Speed Using CDC Protocol STM32446" > > Das dürfte das Ausgangsproblem sein. Ah - alles klar. Gut, dass Du's verlinkt hast, denn nach der Lektüre möchte ich persönlich dem TO folgendes raten: Die Fragen, die Du - Lalo oder Andres oder Andy - stellst, deuten darauf hin, dass Du noch relativ neu im Umfeld MC-Programmierung bist. Das ist auch nicht schlimm, denn jeder hat einmal klein angefangen und ich selber bin ebenfalls weit von der Profi-Liga entfernt. Das Problem an der Sache: USB ist wirklich "advanced stuff". Ich habe mich vor geraumer Zeit einmal mehrere Wochen damit beschäftigt und war am Ende gerade mal mit Ach und Krach in der Lage, einen V-USB-basierten Temperaturlogger mit 2 Fühlern zu bauen. Dabei waren Teile in Assembler zu schreiben (okay - es war ein ATmega8), um die absolut zeitkritischen USB-Anforderungen zu erfüllen. Nach dieser Erfahrung würde ich jedem Anfänger davon abraten, natives USB zu nutzen - insbesondere, wenn's dann noch um Timings und zeitkritische Dinge geht. Solltest Du also Daten vom Computer in Richtung MC oder umgekehrt übertragen wollen, so prüfe, ob Dir nicht ein USB->RS232 (z.B. ein FTDI232-Modul) und ein paar USART-Routinen auf der MC-Seite genügen würden. Damit kommst Du als MC-Einsteiger wesentlich schneller zum Ziel. Wenn Deine Anforderungen allerdings nur allein USB zulassen, so helfen Dir meine guten Ratschläge natürlich nichts, in diesem Falle hilft nur lesen, lesen, lesen: - Jan Axelson hat mir mit Ihrem USB-Complete Buch einiges an Erkenntnis gebracht. Sodann fand ich folgende USB-Seiten gut: http://www.usbmadesimple.co.uk/ http://www.beyondlogic.org/usbnutshell/usb1.shtml https://de.wikipedia.org/wiki/Universal_Serial_Bus http://www.eeherald.com/section/design-guide/esmod14.html http://www.sprut.de/electronic/interfaces/usb/usb.htm https://www.tu-chemnitz.de/informatik/RA/news/stack/kompendium/vortraege_97/usb/protokol.html Viele Grüße & viel Erfolg wünscht Dir Igel1
Gast
#4810089
Noch mal , vielen Dank an alle für eure nette Antworten. Ich habe schon eine Lösung für das gefunden, und jetzt habe ich die Geschwindigkeit gemessen und komme auf ca. 8,23MByte pro Sekunde. Ich hätte zuerst alle über USB- Protokoll lesen müssen. ... Ich möchte auch euch alle mich zu entschuldigen, weil ich hier auf der Webseite mit verschiedenen Namen die gleiche Frage gestellt habe, ich wollte nur Ruckmeldungen bekommen. Lalo schrieb: > Noch mal , vielen Dank an alle für eure nette Antworten. ... wir sind stets bemüht :-) (ich hoffe, Du weißt, was diese Formulierung in deutschen Zeugnissen bedeutet ;-) > Ich habe schon eine Lösung für das gefunden, und jetzt habe ich die > Geschwindigkeit gemessen und komme auf ca. 8,23MByte pro Sekunde. Och - jetzt laß uns aber bitte nicht vor Neugierde sterben: Wie hast Du's letztendlich gemacht? Wie hast Du gemessen? > Ich hätte zuerst alle über USB- Protokoll lesen müssen. Richtig - dazu hatte ich geraten. Schön, dass Du Dir den Ratschlag zu Herzen genommen hast. Jetzt, nach Deiner Lektüre, wirst Du sicherlich verstehen, warum der Ratschlag genau so war, wie er war: Ohne ein gewisses Protokoll-Grundverständnis hast Du bei USB eigentlich keine Chance. > ... > > Ich möchte auch euch alle mich zu entschuldigen, weil ich hier auf der > Webseite mit verschiedenen Namen die gleiche Frage gestellt habe, ich > wollte nur Ruckmeldungen bekommen. Das wird hier in der Tat sehr ungern gesehen - ich empfinde so etwas auch ein bißchen als "ausnutzen" der Community (im negativen Sinne) ... Anyway - ich bin hier nicht der Blockwart und wenn Du's einsiehst, so ist ja alles in Ordnung. Wenn Du übrigens wirklich sehen willst, was auf Deinem USB-Protokoll so alles abgeht, so kann ich Dir im Nachgang noch anbieten, Dein Protokoll auf einem echten LeCroy USB-Hardware-Analyzer mitzuschneiden und Dir das Ergebnis zur Analyse zuzusenden. Wenn ich mich recht erinnere, so war die Software von LeCroy nämlich frei verfügbar und so solltest Du in der Lage sein, meinen Mitschnitt bei Dir in die LeCroy-Software einzuladen und zu analysieren. Einzige Einschränkung: Du müßtest das Programm auf ein STM32F4-Disco- Board oder auf ein 32F429IDISCOVERY umschreiben - etwas anderes habe ich hier nämlich nicht rumliegen. Aber eigentlich hast Du Deine erste Fragestellung ja inzwischen selbst gelöst und so ein Protokollmitschitt ist daher vermutlich überflüssig für Dich. Viele Grüße Igel1
Gast
#4812880
Andreas S. schrieb: > Och - jetzt laß uns aber bitte nicht vor Neugierde sterben: > Wie hast Du's letztendlich gemacht? > Wie hast Du gemessen? Ich habe die USB-Library bzw die Dokumentation von STM32F4 angeschaut und dort habe ich die folgenden Funktionen: uint32_t DCD_EP_PrepareRx( USB_OTG_CORE_HANDLE *pdev, uint8_t ep_addr, uint8_t *pbuf, uint16_t buf_len) wird die EP "ep_addr" vorbereitet um Daten zu empfangen mit einer length "buf_len", die in "*pbuf" gespeichert werden. eine callback-Funktion "usbd_cdc_DataOut" wird implementiert um das App zu informieren, dass die Daten know angekommen sind. uint32_t DCD_EP_Tx ( USB_OTG_CORE_HANDLE *pdev, uint8_t ep_addr, uint8_t *pbuf, uint32_t buf_len) setzt die "buf_len" und die Größe in Bytes im "EP_internal_Ram_Fifo" kopiert von"*pbuf" ein. Wenn der Host die Daten gelesen hat, wird der Rückruf "usbd_cdc_DataIn" ausgegeben, damit die App weiß, dass die Übertragung abgeschlossen ist. @Lalo:
Okay - das klingt doch gut und clever.
Dann hast Du die richtigen Hooks/Einklinkpunkte ja gefunden.
Gratulation zur Lösung Deines Problems!
Viele Grüße
Igel1
Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
