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?
Was passiert denn, wenn man die Prozesspriorität von Putty im Taskmanager hochstellt? Grüße, Peter
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.
Wie würde der Kopierbefehl übrigens beendet?
- 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!
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.