mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik schnelle Serielle Schnittstelle mitloggen


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Serial (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

gibt es ein Tool, mit dem man wirklich schnelle serielle Kommunikation 
mitloggen kann?

Gemeint sind Baudraten größer 2MBaud.

Autor: Lama (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Johnny B. (johnnyb)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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, ...?)

Autor: A. S. (achs)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Ein PC mit USB/Seriell-Adapter kann i.d.R. auch 3MBaud. Allerdings keine 
krummen ...

Autor: Joggel E. (jetztnicht)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Serial (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also HTERM kommt da irgendwie nicht hinterher... oder möglicherweise 
ganz andere Fehlerquelle, der FTDI Chip liefert nicht schnell genug.

Autor: A. S. (achs)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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. .

Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

: Bearbeitet durch User
Autor: Serial (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe 2,4MBaud

Autor: Ingo S. (logikneuling)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: c-hater (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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...

Autor: Joggel E. (jetztnicht)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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
Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. S. (achs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Niklas Gürtler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Autor: Niklas G. (erlkoenig) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :)

Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry der Link war falsch: http://stefanfrings.de/stm32/vcp_test.zip

Autor: Harald (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.