Ich habe mir vor einiger Zeit einen USB-RS232 Wander mit dem FT232 gebaut, da ich dachte höhere Baudraten erziehlen zu können. Aber leider ist das ganze sogar noch langsamer, als über normales RS232: Sobald ich die entsprechende COM Schnittstelle im Bray Terminal öffne, fängt der Mauszeiger an zu ruckeln. Wenn ich Daten mit 115200Baud über den FT232 sende, erreiche im im Durchschnitt nicht mehr als etwa 50000Baud, warscheinlich sogar noch etwas langsamer.
Da hast Du wohl ein Software-Problem. Evtl. öffnet das Bray-Terminal den COM-Port nicht über System-Funktionen, sondern versucht direkt über Hardware zuzugreifen, dies könnte den FTDI-Treiber durcheinanderbringen. Ich habe mit meinen selbstgebastelten Programmen solche Auswirkungen (ruckelnder Mauszeiger) nicht beobachten können.
Ich verwende insgesamt 3 verschiedene FT232 Module, zwei für LCDs, und eines als allgemeiner USB-RS232 Wandler. Bei allen drei habe ich das Problem mit dem Bray Terminal. Mit Winamp oder anderen Programmen läuft das ganze aber problemlos. Die Treiber sind auch richtig installiert (USB <-> Serial). Was gibt es denn außer dem Bray Terminal noch an guten Programmen ?
Bray ist wirklich für einige anwendungen völlig untauglich. z.B. hab ich mal versucht mein AVRISP über das Terminal anzusprechen, egal was ich eingestellt heb, es geht nicht. wobei das avrstudio ganz einfach damit kommunizieren kann. Alternativen kenn ich leider keine guten -> Selber machen ;) Ich werd mich heute mal damit beschäftigen und ein terminal selber programmieren. werds dann bereitstellen. MfG
Das Terminalprogramm von Tobi ist zwar besser (kein ruckelnder Mauszeiger), aber es hat Probleme mit dem senden von Dateien: Ich sende ein 3MB mp3, die Transmit LED leuchtet für <1s und das wars...
könntest du mir die datei für einen test zur verfügung stellen? ich hab so spontan absolut keine idee woran das liegen könnte
nachtrag: könnte so ein fehler dadurch entstehen, dass die write timeouts der schnitstelle sehr klein gesetzt werden, so dass zeichen verloren gehen?
Ich habe verschiedenste mp3 Dateien ausprobiert, auch andere Dateien. Wenn ich TXT Dateien schicke ist alles OK. Sende ich dagegen irgendwelche danderen Dateiformate (bin, mp3, pdf, bmp usw) und die Datei ist etwas größer, dann tritt dieser Fehler auf.
Vermutung: Problem mit Dateiendeerkennung. Kannst Du Binärdateien senden, die Nullen (Hex 0x00) enthalten?
Ich habe mir mal ne Datei mit den Werten 0-255 gebastelt Sobald der Wert 0x1A vorkommt, ist Ende. Der letze übertragene Wert ist 0x19.
Nur leider ist meine mp3 da noch nicht zu ende... Bevor einer nach dem Sinn fragt, wiso ich eine mp3 über RS232 an den VS1011 mp3 Dekoder schicke: Meine Festplatte ist kaputt gegangen, und da ich noch die letzen Fehler in der Softwar beheben möchte, bleibt nur das übrig.
Das ist schon klar. War ein Hinweis an Tobi (den Autor des Terminalprogrammes), daß er seine Dateieenderkennung überarbeiten sollte.
Danke für die ganzen Hinweise! Das problem war genau wie ihr vermutet hattet, dass die datei nicht im binärmodus geöffnet wird sondern als textdatei mit eof das problem ist jetzt in der v0.5.2 behoben: http://www.der-hammer.info/terminal/index.htm
Jetzt läufts einwandfrei ! Irgendwie wird alles immer noch langsamer, sobald ich den USB Com Port öffne, obwohl die CPU Auslastung niedrig bleibt. Seltsam... Jedenfalls funzt 230400Baud usw. auch. Gemessen habe ich rund 23kB/s.
Wenn es nur um reines Senden geht: dafür finde ich printfile recht gut, einfach einen Pseudo-Drucker einrichten (Universal/Text), der auf die serielle Schnittstelle ausgibt. Danach können Files per Drag-and-Drop auf den eingestellten COM-Port ausgegeben werden. Von der Geschwindigkeit habe ich noch kein Problem gehabt, 115kb gehen problemlos rüber, mehr habe ich noch nicht ausprobiert. Wenn die empfangenen Daten wichtig sind, dann taugt das natürlich nichts, für sowas sieht Tobis Programm ziemlich klasse aus. Viele Grüße, Stefan
@benedikt das verlangsamen des systems kann dann aber nur noch an den treibern des ftdi chips liegen, da das terminal keinen unterschied zwischen echten und unechten schnittstellen macht. wahrscheinlich sind da einige unschöne stellen im code
Eine höhere Belastung des Systemes kann an deaktivierten oder zu kleinen Hardwarefifos der Schnittstellenbausteine liegen. Das ist ein bisschen die Crux der seriellen Datenübertragung: Möchte man kleine Datenmengen mit knappen Reaktionszeiten übertragen, dann stören die Hardwarefifos nur, möchte man aber sehr große Datenmengen möglichst schnell übertragen, dann sind Hardwarefifos sehr wichtig. Bei traditioneller Schnittstellenhardware (also nicht USB) muss man sich nur die Interruptlast bei fifolosem Senden oder Empfangen mit 115200 Baud vorstellen - das sind etwa 10000 Interrupts/Sekunde, für jedes Zeichen einer. Eigentlich kein dramatischer Wert, aber auf einem System mit einer minimalen Zeitscheibengranularität von 1 msec (und üblicherweise 10 msec) ahnt man, daß es da zu interessanten Effekten kommen kann. Dieser Zustand wird mit den Ur-Schnittstellenbausteinen 8250 bzw. 16450 erzielt. Bereits die einfachen Fifos, die mit den Schnittstellenbausteinen aus der 16550-Reihe daherkommen, reduzieren die Interruplast auf -im Idealfall- ein 16tel des genannten Wertes, da mit einem Interrupt der komplette Fifoinhalt von 16 Bytes an den/vom PC übertragen werden kann. Neuere Ausführungen haben bedeutend größere Fifos, derzeit sind Größen von 64 oder 128 Bytes üblich. Das sieht natürlich bei USB-Schnittstellenbausteinen aufgrund der USB-Architektur ganz anders aus; der FT232 hat aber immerhin Sende- und Empfangspuffer von 128 bzw. 384 Bytes Größe. Deren Nutzung lässt sich über den Gerätemanager konfigurieren. Interessant ist bei dieser Betrachtung, ob die gleiche Systembelastung wie bei Tobis Programm und einem FT232 auch bei anderen Terminalprogrammen und einem FT232 auftritt. Das müsste mal mit dem Performance Monitor untersucht werden, auch sollten hierbei die verschiedenen Konfigurationsmöglichkeiten des FT232-Devicetreibers in Betracht gezogen werden. Die "unschönen Stellen im Code" ließen sich mit etwas Mühe und dem Einsatz eines Profilers lokalisieren. @Tobi: Was für einen Compiler setzt Du nochmal ein? Ich hab' mal mit VC6 profilen müssen, 's ist aber schon lang her.
ich benutz auch den vc6 (zumindest noch solange bis der 2005er endlich rauskommt) leider hab ich soetwas noch nie gemacht, geschweige denn auch nur die optionen dafür gefunden :)
Die CPU Auslastung liegt bei 2% (=idle) wenn ich eine Verbindung über USB öffne. Es dauert aber z.B. bis zu 5s ehe das Fenster erscheint wenn ich auf Send File klicke. Gibt es das Problem nur bei mir, oder hatten auch andere dasselbe Problem mit dem FT23 ?
"Es dauert aber z.B. bis zu 5s ehe das Fenster erscheint wenn ich auf Send File klicke." Ist das ein Dateiauswahldialog oder was für ein Fenster ist das?
Ich hab' mir zwar das Terminalprogramm selbst nicht näher angesehen, wenn aber das Öffnen eines Dateiauswahldialoges sehr lange dauert, dann hat das nichts mit der verwendeten Schnittstelle zu tun, sondern damit, daß - sehr viele Dateien im aktuellen Verzeichnis vorhanden sind - nicht existente Netzwerklaufwerke vorhanden sind Der [beep]-Explorer und leider auch der Windows-Standard-Dateiöffnen-Dialog versucht aus allen im aktuellen Verzeichnis befindlichen Dateien Iconressourcen zu extrahieren bzw. aus den damit verknüpften Programmen. Hinzukommt, daß für das Füllen der im Dateiauswahldialog oben eingeblendeten Drop-Down-Liste zur Verzeichniswahl alle potentiell existierenden Netzwerklaufwerke abgeklappert werden ... und das dauert, vor allem, wenn die damit verknüpfte Netzwerkresource momentan offline ist. Versuche mal folgendes: - aktuelles Verzeichnis mit nur wenigen Dateien verwenden - alle Netzwerkverbindungen kappen (net use * /del)
Ich würde sowas nicht schreiben, wenn es an dem Verzeichnis liegen würde. Wenn ich mein mp3 oder Download Verzeichnis öffne, dann dauert es auch im normalen Explorer >10s, das ist mir klar... Bei dem Terminal ist es aber nicht nur das, auch wenn ich auf Disconnect klicke, dauert es einige Sekunden bis was passiert. Wenn ich auf Send File gehe, dauert es eine Weile bis das Fenster erscheint, weiterhin dauert es lange wenn ich nur aus der Dateistruktur ein Verzeichnis auswähle, selbst wenn dieses leer ist. Habe ich dagegen eine normale RS232 Verbinundung über einen echten COM Port, werden alle Aktionen sofort ausgeführt, ganz ohne Wartezeiten. Ich kann mir das nur so erklären, dass das Terminal (bzw. der USB-RS232 Treiber) öfters die Statusleitungen usw. abfragt, während der normale COM Port Interruptgesteuert arbeitet.
Das könnte sein. Die Statusleitungen und der Eingangspuffer werden ca alle 10ms abgefragt. Ich kann dir zum testen mal eine Version mit längeren Poll-Intervallen erstellen und zuschicken. So könnte man gut testen, ob es daran liegt
Es hat leider nichts gebracht. Ist aber auch nicht so schlimm, solange 230kBaud und mehr richtig funktioniert...
Ok, ich hab aber auch gestern abend noch ein bisschen weiterprobiert und hab das gleiche verhalten, dass du beschrieben hast mit leicht geänderten parameter reproduzieren können. Ich hab deshalb die Routinen für den Port-Zugriff etwas abgeändert, so dass weniger Last verursacht wird. Ist in der nächsten Version eingebaut - vielleicht hilft das ja dann. Mir ist auch aufgefallen, dass beim Datei senden der Empfang blockiert ist, ist auch behoben worden.
Die Blockade beim Datei senden ist zwar unschön, aber die gibt es auch beim Bray Terminal...
Ich hab das Ganze ja angefangen, weil mir das BrayTerminal nicht gereicht hat, also will ich jetzt auch alles besser machen ;) Die Blockade ist unter bestimmten Bedingungen nicht nur unschön. Wenn in der Zeit, in der die Datei gesendet wird zuviele Daten neu ankommen gehen diese verloren. Bei mir passiert das, wenn mehr als 4096 Byte reinkommen (bei kleinerem Eingangpuffer natürlich auch eher). Die Oberfläche ist auch immer noch (absichtlich) blockiert aber jetzt können keine Daten mehr verloren gehen
Wenn du eh am verändern bist: Wäre es möglich, irgendein Statusfenster beim Datei Senden einzubauen ? Auf diesem irgendeine Anzeige die anzeigt wieviel bereits übertragen wurde (% Zahl, x Bytes von y gesamt, Balken usw.) und ein Abbrechen Button. Mich hat es beim Bray Terminal nämlich schon immer gestört, das ich das Programm gewaltsam schließen zu musste, wenn ich eine Datei nicht ganz übertragen wollte.
So eine Funktion hatte ich auch schon angedacht. Werd ich einbauen!
Tobi, Hut ab und vielen Dank! Das machst du echt klasse! Und laß dich nicht von irgendwelchen Kommentaren runterziehen, die kommen meist von Leuten die auch solche Programme entwickeln wollen, es aber nicht können und dann dem Nied freien Lauf lassen!
Danke! Werd ich ganz sicher nicht machen lassen. Bisher finde ich die Kommentare hier aber so ziemlich alle recht hilfreich. Gibt auch mal wieder was Neues, oder eher eine neue Version. http://www.mikrocontroller.net/forum/read-8-155472.html?reload=yes#166149 @benedikt: Kannst du diese Version mal mit dem FTDI Chip ausprobieren? Evtl haben die Veränderungen ja gewirkt. Ist jetzt auch wie vorgeschlagen ein Sendfile Dialog mit Abbrechen, Byte-Anzeige und Balken dabei
Das Programm funktioniert mit dem FT232 jetzt einwandfrei ! Auch die File Send Funktion ist spitze ! Wirklich super das Programm...
Falls du wieder mal etwas an dem Programm machst, könntest du mal schauen ob es irgendwo eine Engstelle bei dem File Transfer gibt ? Ich teste gerade Baudraten im Bereich 100kB-1MB mit dem FT232, und dabei ist mir aufgefallen, dass maximal 20-30kByte/s übertragen werden, egal wie hoch ich die Baudrate einstelle. Irgendwo gibt es anscheinend einen Engpass im Programm (oder es könnte auch am FT232 Treiber liegen, dass weiß icht nicht...) PS: Das Bray Terminal wird bei hohen Baudraten extrem langsam. Bei 750kBaud erreiche ich eine sagenhafte Geschwindigkeit von rund 20Bytes pro Sekunde !!!
20 byte pro Sekunde ist doch irrsinnig schnell ;) Es kommt keine Meldung unten in der Statuszeile, dass die Baudrate nicht unterstützt wird? Nur um schonmal Probleme mit dem Treiberinterface auszuschliessen. Ich werd mir den Code nochmal anschaun. Es könnte daran liegen, dass ich den Code in 100byte Happen zerlege, zwischen denen ich die Anzeige aktualisiere und Events verarbeite. Mal schaun, ob man das irgendwie per Interrupt/Callback Routinen hinbiegen kann
Ich zerleg natürlich nicht den Code sondern die zu sendenden Daten
Ein Fehler kommt nicht, die Übertragung läuft einwandfrei. Nur ist sie eben etwas langsam.
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.