Hallo, gibt es ein Tool, mit dem man wirklich schnelle serielle Kommunikation mitloggen kann? Gemeint sind Baudraten größer 2MBaud.
Serial schrieb: > Gemeint sind Baudraten größer 2MBaud. Süß... Nimm ein LogicAnalyzer deiner Wahl und exportiere die Daten als Exel-File. Sollte selbst ein einfacher Saleae locker schaffen.
Serial schrieb: > Hallo, > > gibt es ein Tool, mit dem man wirklich schnelle serielle Kommunikation > mitloggen kann? > > Gemeint sind Baudraten größer 2MBaud. Was für eine serielle Schnittstelle genau? (SPI, I2C, SATA, HDMI, ...?)
Ein PC mit USB/Seriell-Adapter kann i.d.R. auch 3MBaud. Allerdings keine krummen ...
Nun, ja, wenn du ein UART hast, das das kann ... Allenfalls ein 16 oder 32 bit controller, der mit irgendwas oberhalb 20MHz laeuft. Alternativ mit einem FPGA. Ein UART ist nicht allzu schwierig in einem FPGA. Auf alle Faelle gibt es RS485 Treiber, die 25MBit koennen.
:
Bearbeitet durch User
Also HTERM kommt da irgendwie nicht hinterher... oder möglicherweise ganz andere Fehlerquelle, der FTDI Chip liefert nicht schnell genug.
Serial schrieb: > oder möglicherweise > ganz andere Fehlerquelle, der FTDI Chip liefert nicht schnell genug Du kennst doch Deine Baudrate (welche??) und hast zugriff aufs Equipment. Falls möglich, nimm doch einfach mal 1Mbit oder so. Vielleicht sind ja auch Pegelprobleme. Nimm also 2 USB/Seriell-Adapter und lass den einen senden den anderen empfangen und schaue, ob PC-SW / Chips OK sind. .
> Also HTERM kommt da irgendwie nicht hinterher
Das kann ich mir gut vorstellen.
Ich würde unter Linux versuchen, mit einem copy Befehl (oder dd) direkt
vom seriellem Port in eine Datei zu kopieren.
Beim Testen/Debuggen benutze ich aber normalerweise geringe Baudraten
(vorzugsweise maximal 9600). Erst wenn alles klappt, stelle ich dann auf
höhere Baudraten um. Leider hat man nicht immer die freie Wahl.
USB UART Kommunikation auf einem bereits etwas betagten Windows System in eine Datei zu loggen, ist mit vielen Terminal Programmen (ich benutze dafür gerne putty mit der Log All To File Option) erfahrungsgemäß bis 6MBaud kein Problem. Sollte dein USB/Seriell Wandler einen der einfacheren Chips wie den FT232R besitzen, bist du jedoch auf 3MBaud maximal limitiert, wobei 1, 2 und 3 MBaud nur noch in vollen MBaud Schritten zu wählen sind - deine 2.4MBaud würden damit also nicht funktionieren. Du bekommst normalerweise keine Fehlermeldung, wenn du sie trotzdem wählst, der Chip arbeitet einfach mit der nächstniedrigeren. Das größere Problem ist, dass du die 2, 3, oder bis zu 6MBaud nicht willkürlich in den Rechner fließen lassen kannst, dein RX Buffer würde zwischen den 1ms Frames überlaufen. Du brauchst also entweder eine geeignete Flusskontrolle, oder musst sicherstellen, dass die durchschnittliche Netto Senderate ~2MBit/s nicht überschreitet. Es hilft, die Framerate des USB Seriell Wandler im Gerätemamager auf 1ms zu stellen (Standard häufig 64ms), die Paketgröße maximal zu wählen, und falls du immer noch Probleme haben solltest, das entsprechende Log Programm wie puTTY auf einen CPU Kern zu locken.
Zitronen F. schrieb: > Nun, ja, wenn du ein UART hast, das das kann ... > Allenfalls ein 16 oder 32 bit controller Was soll die Verarbeitungsbreite von mehreren Byte bei einem Byte-orentierten Übertragungsverfahren deiner Meinung nach an Vorteilen bringen? Also warum soll es 16- oder gar 32Bit Controller sein, wenn es nur (üblicherweise) maximal 8Bit breite Daten zu verarbeiten gilt? OK, es gibt auch noch dieses seltenst verwendete Frameformat mit 9 Datenbits, dafür könnte eine höhere Verarbeitungsbreite eventuell schon vorteilhaft sein...
Auch wenn die Baudrate bei 2.4MBit liegt muss man ja nicht MByte ueberteragen, sondern kann mal mit 32 Byte probieren. Das kann HTerm dann auch. Weshalb ich einen 16 oder 32 Bitter vorschlage .. weil die mit MHz klotzen koennen. Ein AVR auch mit 20MHz geclockt kann keine 2.4MBit am UART. Auch wenn er's koennte sollen die Daten ja auch noch irgendwo hin, und das reicht dann nicht mehr.
:
Bearbeitet durch User
c-hater schrieb: > Was soll die Verarbeitungsbreite von mehreren Byte bei einem > Byte-orentierten Übertragungsverfahren deiner Meinung nach an Vorteilen > bringen? Angenommen, der beteiligte µC soll Daten zwischenspeichern, so ist die Chance, daß er mehr Speicher ansteuern kann, bei 32-Bit-µCs eher gegeben als bei 8-Bit-µCs. Bei einem Protokollanalysator oder auch nur -Mithörer erscheint mir das Konzept eines ausreichend großen Aufzeichnungspuffers nicht vollends verwegen. Dazu kommt, daß bei 2.4 MBaud immerhin 240 kByte/sec durchrauschen, was bei einer einfachen UART eine Interruptrate von 240 kHz zur Folge hat, und die zu bedienen ist, wenn auch noch etwas anderes sinnvolles erledigt werden soll, mit einem 8-Bitter, der nur mit ein paar MHz getaktet wird, auch nicht ganz trivial. Bei -beispielsweisen- 24 MHz Takt stehen nur 100 Taktzyklen pro empfangenen Zeichen zur Verfügung.
mir ist die Aufgabe noch nicht klar. Der TO will doch einen Datenstrom per PC mitlesen. Das geht bei "glatten" Baudraten von 1 oder 2 MBaud doch problemlos mit jedem USB-Umsetzer. Wenn er 2.45MBaud hat, wird das der USB-Umsetzer vermutlich nicht können. Dann braucht er vielleicht einen Wandler von 2.45MBaud auf 3MBaud. Das könnte ein 8-Bitter mit 2 Uarts und entsprechendem Quartz machen (also wenn es da gemeinsame Teier gibt), links höhren, rechts rauspusten. Kein Zwischenspeichern. Solang raus schneller ist, als rein.
Notfalls implementiert man sich seinen eigenen USB-Seriell-Wandler. z.B. die UART's der STM32 sind von der Baudrate her recht flexibel (freier Prescaler). Natives USB, viel Speicher und Leistung haben diese Controller auch. Als Ausgangspunkt: https://github.com/Erlkoenig90/f1usb/tree/vcp
Ich war auch schon kurz davor, das Beispielprogramm von Niklas vorzuschlagen, da ich es bereits ein paar mal als UART-Schnüffler verwendet habe. Allerdings habe ich keine Ahnung, wie es mit so hohen Baudraten performt. Immerhin hat der STM32 reichlich RAM, damit kann man schon üppige Puffer einrichten. Hier ist es als Projekt für die System Workbench und das BluePill Board. Das Atollic TrueStudio kann dieses Projekt importieren: http://stefanfrings.de/stm32/usb_test2.zip
Stefanus F. schrieb: > Allerdings habe ich keine Ahnung, wie es mit so hohen > Baudraten performt. Hab's nicht ausführlich getestet, aber solange der PC die Daten schnell genug abholt sollte es klappen. Je größer die Datenrate, desto effizienter wird es, da dann größere Pakete gesendet werden. Stefanus F. schrieb: > da ich es bereits ein paar mal als UART-Schnüffler > verwendet habe. Ach, sag doch was, mich freut es zu erfahren wenn jemand meine Sachen nutzen kann :)
3 kurze Anmerkungen dazu - HTERM hat ein Problem mit hohen Datenraten, einfach mal was anderes testen - USB-Wandler von SiLabs können ganz gut hohe Datenraten, wenn die gewünschte Rate nicht dabei ist kann man mit Baudrate Aliasing arbeiten. Da gibt es ein Tool von SiLabs. FTFI soll das auch können. - Bitte kein USB Wandler von Prolific. Die haben zwar den gesamten Markt aufgrund ihres günstigen Chipsatzes geflutet, sind aber auch die „Hauptschuldigen“ an dem generell schlechten Ruf von USB Seriell Wandlern.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.