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?
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.
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.
- 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
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 ^^
@ 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
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.
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 ;)
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.
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.
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 ^^
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
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.
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!
