Forum: PC Hard- und Software Nadelöhr hohe Baudrate - Wo kann von Hardware bis Software optimiert werden?


von Nippey (Gast)


Lesenswert?

Hi,

ich arbeite gerade an einem Testgerät, welches seine Tätigkeiten per 
UART zur späteren Analyse mitloggt.
Die Plattform ist ein bestehendes Evaluation-Board mit 
RS232-Schnittstelle.

Konfiguration:
* UART mit 115200 baud
* µC <> Maxim Bustreiber <> 1m Kabel <> Onboard UART vom PC
* Putty mit der Funktion "Log all Session Output to File"

Problem:
Bei der momentanen Geschwindigkeit reichen an meinem Arbeits-PC 
Fensterwechsel aus, damit Putty sich verschluckt und Teile des 
Protokolls nicht gespeichert werden. (Hardware-FIFO ist über 
Gerätemanager auf Maximum gestellt)

Ich müsste die Baudrate auf das Vierfache anheben, damit sie den Test 
nicht ausbremst. Im Moment würde ich mich aber schon über einen stabilen 
betrieb mit 115 kBaud freuen.

Meine Fragen dazu:
Kennt ihr Programme, die möglichst effektiv 'mitschreiben'?
Noch selbst tippen zu können wäre zwecks Konfiguration des Testers ein 
nettes Feature.

Wäre ein FTDI durch die Puffer des USB-Protokolls vielleicht besser 
geeignet um die Windows-Engpässe auszubügeln?

von Peter D. (pdiener) Benutzerseite


Lesenswert?

Was passiert denn, wenn man die Prozesspriorität von Putty im 
Taskmanager hochstellt?

Grüße,

Peter

von Peter (Gast)


Lesenswert?

ich denke mal das es an putty liegt, einen aktuell pc bekommt man 
bestimmt nicht mit 115200 baud ausgelastet, wenn er spielend 100Mbit von 
der Netzwerkkarte verarbeiten kann.

Wenn du keine besonderen parameter einstellen musst kannst du es ja mal 
mit

copy COM1 > log.txt

auf der Kommandozeile testen.

von Peter (Gast)


Lesenswert?

Peter schrieb:
> copy COM1 > log.txt

ich meinte copy COM1 log.txt

von Nippey (Gast)


Lesenswert?

Die Priorität ist mir auch gerade eingefallen
spiele just im Moment damit herum.

Direkter COM-Zugriff aus der Konsole. Cool ;)
Kann ich dann auch sowas machen?

---Batchfile---
copy params.txt > COM1
copy COM1 > logfile.txt
---End Batchfile---

In der Params.txt würde dann das stehen, was ich sonst manuell eingebe 
um den Test zu konfigurieren und zu starten.
Ich hoffe nur, dass der zweite Befehl dann schnell genug an den ersten 
anschliesst oder ich muss zu Beginn des Tests ein Delay einbauen.

von Nippey (Gast)


Lesenswert?

Wie würde der Kopierbefehl übrigens beendet?

von (prx) A. K. (prx)


Lesenswert?

Vermutlich mit ^Z

von tspotz (Gast)


Lesenswert?

- Finger weg von USB-RS232 Wandlern die sind langsam (auch wenn du die 
Baudrate auf 236kBaud oder mehr einstellen kannst, einzelne Zeichen sind 
so schnell aber Zeichenblöcke/Streams werden nicht am Stück 
empfangen/gesendet)

- schon mal daran gedacht einen USB-Controller anstatt serieller 
Schnittstelle (nicht FTDI!)

- Hardwarehandshake verwenden

- eigene Software schreiben um Daten zu empfangen

- Linux anstatt Windows

- Der Aufzeichnungs-PC sollte nur dafür verwendet werden (also nicht 
meinen
  Surfen zu müßen während daten empfangen werden)

- eventuell vor dem PC ein Puffer bauen der die Daten zwischenspeichert 
und dann nach und nach an PC schickt,

just my 2cents

von Matthias N. (nippey)


Lesenswert?

An Hardwarehandshake habe ich auch schon gedacht, aber leider ist nur 
ein 2-Kanal (1xIn 1x Out) TreiberIC von Maxim verbaut.

Linux wäre ein Traum, leider habe ich nur einen (Firmen)-PC fürs loggen 
und (leider auch parallel) arbeiten.

Am ehesten könnte ich mal die Lösung in eigener Software angreifen, dann 
kann ich mir für die Konfiguration sogar ne gui bauen ;)

Mit Puffer meinst du ein Gerät, was alles auf ein Medium schreibt, 
welches ich nachher in Ruhe auslesen kann? Da über ein Gigabyte anfällt, 
müsste der im Ernstfall was aushalten ^^

von Falk B. (falk)


Lesenswert?

@  tspotz (Gast)

>- Finger weg von USB-RS232 Wandlern die sind langsam (auch wenn du die
>Baudrate auf 236kBaud oder mehr einstellen kannst, einzelne Zeichen sind
>so schnell aber Zeichenblöcke/Streams werden nicht am Stück
>empfangen/gesendet)

Ach was. Schon mal gerechnet? Schon mal FT232 & Co auf Herz und Nieren 
geprüft?

115k2 sind ~ 10kByte/s. Full Speed USB arbeitet mit 1 kHz 
Rahmenfrequenz. Sprich, pro Rahmen (1ms) müssen 10 Bytes vom FT232 
abgeholt / gesendet werden. Der hat in Empfangsrichtung einen 256 Byte 
FIFO, da kann er verdammt lange zwischenpuffern.

Putty ist schon mehrfach von Leuten als als buggy beschrieben worden, 
eine Suche im Forum/Google wird das bestätigen.

>- Hardwarehandshake verwenden

Ein Relikt aus alten Tagen. Ein gescheites Protokoll mit Datenblöcken 
und ensprechendem handshake per Software braucht sowas heute nicht mehr.

>- Der Aufzeichnungs-PC sollte nur dafür verwendet werden (also nicht
>meinen
>  Surfen zu müßen während daten empfangen werden)

Oh je, damit der 3 GHz P4 ja nicht überfordert wird ;-)

Mit gescheiter Software (tm) geht das auch so.

MFG
Falk

von Peter (Gast)


Lesenswert?

tspotz schrieb:
> - Linux anstatt Windows

so langsam ist windows nun auch nicht, damit diese paar bytes  nicht in 
Echtzeit verabeitet kann.

Ich würde sogar sagen das da sogar win311 noch ausreicht.

von Matthias N. (nippey)


Lesenswert?

Nun denn:

Ich werde erst einmal mal austesten ob ein CreateFile("COM1"... unter 
gcc
oder die serielle Klasse von Visual C# 2010 schneller (bzw schnell 
genung) ist.

Schön Blockweise in den RAM und dann in nem zweiten Thread ab auf die 
Platte. Sollte ja möglich sein ^^

Schonmal Danke für das Brainstorming mit euch ;)

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

Nippey schrieb:
> Ich müsste die Baudrate auf das Vierfache anheben, damit sie den Test
> nicht ausbremst.

Dann musst Du andere Schnittstellenhardware als die 
Onboard-Schnittstellen des PCs verwenden, denn die können nicht mit 
höheren Baudraten als eben jenen 115200 betrieben werden.

Das kann ein USB-Seriell-Wandler ohne große Probleme abwickeln, langsam 
werden die Dinger nur, wenn man kleine Pakete überträgt und auf 
Quittungen wartet. Große Datenmengen, die einfach nur empfangen werden 
müssen, sind kein Problem.

Deine Datenempfangsstörungen dürften auf das verwendete Terminalprogramm 
zurückzuführen sein, ein kontinuierlicher störungsfreier schneller 
Datenempfang war unter ernstgemeinten Windows-Versionen schon in den 
90er Jahren möglich, damals, als noch 486er verwendet wurden.

von Peter (Gast)


Lesenswert?

Matthias N. schrieb:
> Schön Blockweise in den RAM und dann in nem zweiten Thread ab auf die
> Platte. Sollte ja möglich sein

aber doch nicht wegen den paar daten, du verschwendest dabei mehr 
rechenzeit für die Threadsynchronierung als für den eigentlichen 
Prozess. Das Dateisystem hat selber ein cache es macht also kein sinn 
das write in einen anderen Thrad auszulagern. Du darst aber nicht 
jedesmal die datei öffnen und schliessen.

von Matthias N. (nippey)


Lesenswert?

Hmm, bisher hörte mein Programmier-Horizont vor der Windows API auf.
Ich denke, es kann doch nicht schaden, sich mal darüber schlau zu machen 
wo überall gecached wird ^^

Danke, jetzt habe ich endlich mal was interessanteres zu tun ^^

von Ralf (Gast)


Lesenswert?

Probier doch mal BrayTerm bzw. HTerm o.ä. aus. Dann hast du einen 
Vergleich, ob's vielleicht einfach am Terminalprogramm liegt. Oder ist 
Putty ein Muß?

Ralf

von Yalu X. (yalu) (Moderator)


Lesenswert?

Nippey schrieb:
> (Hardware-FIFO ist über Gerätemanager auf Maximum gestellt)

Das könnte das Problem sein.

Du meinst damit sicher den Schieberegler "Empfangspuffer" im Dialog
"Erweiterte Einstellungen", den man wahlweise auf 1, 4, 8, oder 14
einstellen kann.

Dieser Dialog ist MS-typisch maximal missverständlich beschriftet, um ja
den armen Benutzer nicht mit zu komplizierten Begriffen zu verwirren.

Statt "Empfangspuffer" müsste da "Unterbrechungsauslösefüllstand des
Empfangspuffers" stehen (oder einfach englisch Trigger Level). Nur
dieser kann im 16550 nämlich zwischen den vier genannten Werten
umgeschaltet werden, die FIFO-Größe selbst ist immer 16 (man kann den
FIFO nur als Ganzes deaktivieren, dafür gibt es eine zusätzliche
Checkbox).

Wenn du Probleme mit verschluckten Bytes hast, muss dieser Parameter
logischerweise nicht auf einen großen, sondern auf einen kleinen Wert
gesetzt werden. Versuch mal die Einstellung 1. Wenn das Problem damit
behoben ist, kannst du den Wert schrittweise erhöhen, um die CPU-Last
des Treibers zu verringern.

Dieser Vorschlag funktioniert natürlich nur unter der Annahme, dass die
Treiberentwickler bei MS im Gegensatz zu den GUI-Entwicklern verstanden
haben, wie der 16550 arbeitet und diese Einstellung richtig umgesetzt
haben. So ganz sicher bin ich mir da nicht, aber ein Versuch ist es
jedenfalls wert.

von Matthias N. (nippey)


Lesenswert?

An den Buffer-Einstellungen im Gerätemanager gedreht: keinen Einfluss.

Getestet mit hoher Prozesspriorität:
Putty: 15% Auslastung, geringe Fehlerrate
HTerm: Startet mit 5% Auslastung, steigt in wenigen Minuten auf 80% an 
und bleibt da, hälfte der Daten fehlt
Eigenes programm, Visual C# mit Klasse 'SerialPort': 10% Auslastung, 
doppelte fehlerrate von Putty, auch wenn die empfangenen Daten zunächst 
nur im RAM gesichert und nach Transferende gespeichert werden.

Da ich nicht den Rest meiner Zeit mit Benchmarks verbringen will, nehme 
ich die verschluckten Daten erst einmal in Kauf und nutze weiter Putty.

Danke für eure Tipps!

von Galenus ein Reisender (Gast)


Lesenswert?

Hallo Nippey,
früher gab es mal den Max232, ersetzte ihn durch einen ALD4202SB und 
vielleicht klappt es dann was du machen willst.

Bitte 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
Noch kein Account? Hier anmelden.