mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Probleme mit FT232 & Bray Terminal


Autor: Benedikt (Gast)
Datum:

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

Autor: thkais (Gast)
Datum:

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

Autor: Benedikt (Gast)
Datum:

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

Autor: Willi Walter (Gast)
Datum:

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

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Benedikt (Gast)
Datum:

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

Autor: Tobi (Gast)
Datum:

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

Autor: Tobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nachtrag:
könnte so ein fehler dadurch entstehen, dass die write timeouts der
schnitstelle sehr klein gesetzt werden, so dass zeichen verloren gehen?

Autor: Benedikt (Gast)
Datum:

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

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vermutung: Problem mit Dateiendeerkennung. Kannst Du Binärdateien
senden, die Nullen (Hex 0x00) enthalten?

Autor: Benedikt (Gast)
Datum:

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

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
0x1A ist Ctrl-Z. Das ist das beliebte EOF-Zeichen.

Autor: Benedikt (Gast)
Datum:

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

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist schon klar.
War ein Hinweis an Tobi (den Autor des Terminalprogrammes), daß er
seine Dateieenderkennung überarbeiten sollte.

Autor: Tobi (Gast)
Datum:

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

Autor: Benedikt (Gast)
Datum:

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

Autor: Stefan Kleinwort (Gast)
Datum:

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

Autor: Tobi (Gast)
Datum:

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

Autor: Rufus T. Firefly (Gast)
Datum:

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

Autor: Tobi (Gast)
Datum:

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

Autor: Benedikt (Gast)
Datum:

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

Autor: Rufus T. Firefly (Gast)
Datum:

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

Autor: Tobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja, da wird der standarddateiauswahldialog des os aufgerufen

Autor: Rufus T. Firefly (Gast)
Datum:

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

Autor: Benedikt (Gast)
Datum:

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

Autor: Tobi (Gast)
Datum:

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

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Super, Danke.
Emailadresse: benedikt83 ät gmx punkt net

Autor: Tobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gut, werde ich dir irgendwann heute abend schicken!

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es hat leider nichts gebracht.
Ist aber auch nicht so schlimm, solange 230kBaud und mehr richtig
funktioniert...

Autor: Tobi (Gast)
Datum:

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

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Blockade beim Datei senden ist zwar unschön, aber die gibt es auch
beim Bray Terminal...

Autor: Tobi (Gast)
Datum:

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

Autor: Benedikt (Gast)
Datum:

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

Autor: Tobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So eine Funktion hatte ich auch schon angedacht. Werd ich einbauen!

Autor: Manuel (Gast)
Datum:

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

Autor: Tobi (Gast)
Datum:

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

@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

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Programm funktioniert mit dem FT232 jetzt einwandfrei !
Auch die File Send Funktion ist spitze !

Wirklich super das Programm...

Autor: Benedikt (Gast)
Datum:

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

Autor: Tobi (Gast)
Datum:

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

Autor: Tobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich zerleg natürlich nicht den Code sondern die zu sendenden Daten

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein Fehler kommt nicht, die Übertragung läuft einwandfrei.
Nur ist sie eben etwas langsam.

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.