www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik HyperTerminal Übertragungszeiten unzulänglich: Hat mal jemand eine Idee?


Autor: Wilhelm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

wie es der Betreff schon sagt: Ich finde das Windows HyperTerminal 
unglaublich lahm. Ich habe in einem älteren 8051-er Derivat einen 
Bootloader, der den Download eines am PC compilierten Programmes über 
RS232 entgegen nimmt. Ein älteres Teil mit RAM. Das kann man nicht 
kaputt flashen. Es klappt einwandfrei. Es dauert nur extrem lange. Und 
zwar die 4,5-fache Zeit, die sich rein rechnerisch ergibt. 360 Sekunden 
für die Übertragung von 77kByte Textdaten (exakt 32kByte Rohdaten) im 
Intel-File bei 9600 Baud. Es dürften rechnerisch nur 80 Sekunden sein. 
Wo verschwendet das Terminal die Zeit?

Hat mal jemand einen Tip?

Ich möchte die Daten auch nicht rein binär ohne Redundanz laden, und 
wenn möglich auch kein aufwändiges Protokoll neu entwickeln.

Ich hab schon andere Baudratenquarze mit z.B. 57600 Baud gegenüber 9600 
Baud überlegt. Aber wenn das Terminal so lahm ist, kann ich den 
Lötkolben sicher kalt lassen.

6 Minuten für 32k Download sind einschläfernd.

Bei industriellen Eval-Boards, auch ohne USB, geht es doch auch 
erheblich schneller. Mehr als 5 Sekunden wartet man da nie.

Ich möchte jetzt keinesfalls ein ganz neues Faß in Nebensächlichkeiten 
aufmachen, sondern mit dem µC arbeiten...

Autor: usuru (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Muss es denn Hyperterminal sein? Ich nehme putty.

Autor: Michael H. (michael_h45)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hardware handshake aus?
Probierst mal mit was vernünftigem wie hterm, putty oder der guten alten 
dos-konsole: type datei.daten > com1. Vorher mit MODE parametrieren. 
Passt super ins makefile.

Wenn das nix hilft, ist der treiber mist.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Wilhelm (Gast)

>wie es der Betreff schon sagt: Ich finde das Windows HyperTerminal
>unglaublich lahm.

Naja, der Brüller ist es nicht.

>zwar die 4,5-fache Zeit, die sich rein rechnerisch ergibt. 360 Sekunden
>für die Übertragung von 77kByte Textdaten (exakt 32kByte Rohdaten) im
>Intel-File bei 9600 Baud. Es dürften rechnerisch nur 80 Sekunden sein.
>Wo verschwendet das Terminal die Zeit?

6min für 32kB? Das sind ~ 0,088kB/s bzw 91 Bytes/s. Ziemlich lahm. 9k6 
sind ~1000 Bytes/s, sprich deine 32kB sind in knapp 30s vergessen, bzw 
etwas über 60s im ASCII Format + Protokoll ala X-Modem.

>Hat mal jemand einen Tip?

Kann es sein, dass du einen USB-RS232 Adapter verwendest und dort mit 
Handshaking gearbeitet wird? Dann ist klar warum das so lahm ist. Das 
verträgt sich nur schlecht mit USB, auf grund des Timings.

>Bei industriellen Eval-Boards, auch ohne USB, geht es doch auch
>erheblich schneller. Mehr als 5 Sekunden wartet man da nie.

Aha, "auch ohne USB". Siehe oben.

usuru (Gast)
Datum: 25.09.2010 17:51

>Muss es denn Hyperterminal sein? Ich nehme putty.

Das ist bekannt für sein Datenverschlucken bei hohen Baudraten.

MfG
Falk

Autor: nmbx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schau dir mit einem Oszi mal die Übertragung an. Wenn ich es richtig in 
Erinnerung habe, dann lässt sich HyperTerminal sehr viel Zeit zwischen 
den einzelnen Bytes, es entstehen oft große Lücken.

Autor: Wilhelm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner schrieb:

>Kann es sein, dass du einen USB-RS232 Adapter verwendest
>und dort mit Handshaking gearbeitet wird? Dann ist klar
>warum das so lahm ist. Das verträgt sich nur schlecht mit
>USB, auf grund des Timings.

Also: Ich hab einen ganz alten Entwicklungs-PC, einen P3 mit 900 MHz, 
Betriebssystem Win-ME, und Handshaking am HyperTerminal ist OFF. Die 
Anwendung läuft nur über die 2 Leitungen Rx und Tx. Direkt an den 
RS232-Schnittstellen. Da ist sonst nichts weiter dran, außer das 
Verbindungskabel.

Meine Rechnung ist aber richtig. Mit 9600 Baud erreiche ich tatsächlich 
eine effektive Geschwindigkeit wie mit 2400 Baud. Und nur darum geht es 
erst mal. Den Speed des µC kann ich, wenn es sich lohnt, bis 57600 Baud 
aufstocken. Mehr gibt der MAX232 nicht her.

Ich könnte mir vorstellen, daß das HyperTerminal etwas Rechenzeit 
benötigt. Z.B. um den Bildschirminhalt zu verwalten. Vielleicht kann ich 
die Anzahl Bildschirmzeilen in der Registerkarte noch verkleinern. Und 
zwar sendet mein Bootloader die empfangenen Daten ja zurück ans 
Terminal, damit man den Download 1:1 im Terminalfenster beobachten kann. 
Wenn der µC spinnt, erscheint da ein Text wie "Intel Download Error", 
nur für mich zur Ansicht. Das ist wichtig. Der µC ist auf jeden Fall für 
den Download schnell genug, das ist kein Problem. Ich könnte da im 
Bootloader noch was abschalten, z.B. das Echo ans Terminal.

Habe aber auch ein neueres Notebook mit Vista, da kommen in Kürze 
USB-zu-RS232-Adapter dran. So weit bin ich aber noch nicht.


nmbx schrieb:

>Wenn ich es richtig in Erinnerung habe, dann lässt sich
>HyperTerminal sehr viel Zeit zwischen den einzelnen Bytes,
>es entstehen oft große Lücken.

Wie schon gesagt: Ich vermute das schon rein rechnerisch. Deshalb hab 
ich das Oszi auch gar nicht erst ausgepackt. Denn es kann nicht anders 
sein.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Wilhelm (Gast)

>Also: Ich hab einen ganz alten Entwicklungs-PC, einen P3 mit 900 MHz,
>Betriebssystem Win-ME, und Handshaking am HyperTerminal ist OFF. Die
>Anwendung läuft nur über die 2 Leitungen Rx und Tx. Direkt an den
>RS232-Schnittstellen. Da ist sonst nichts weiter dran, außer das
>Verbindungskabel.

Hmm, vielleicht ist der FIFO ausgeschaltet? Versuch mal einfach eine 
Datei "ins Blaue" zu senden, da sollte man an die theoretische Grenze 
bei 9k6 locker rankommen.

>erst mal. Den Speed des µC kann ich, wenn es sich lohnt, bis 57600 Baud
>aufstocken. Mehr gibt der MAX232 nicht her.

Der macht auch 115k2, keine Bange.

>Ich könnte mir vorstellen, daß das HyperTerminal etwas Rechenzeit
>benötigt. Z.B. um den Bildschirminhalt zu verwalten.

Kann sein. Kann auch sein dass bei Win ME, welches ja nur ein 
umgelabeltes Win 98 ist, die Taskverwaltung noch nicht so leistungsfähig 
ist wie im deutlich anders strukturieren Win2K/XP.

> Vielleicht kann ich
>die Anzahl Bildschirmzeilen in der Registerkarte noch verkleinern.

Kann man probieren, aber das wäre ja wie in tiefsten MS-DOS Zeiten :-0

> Und
>zwar sendet mein Bootloader die empfangenen Daten ja zurück ans
>Terminal, damit man den Download 1:1 im Terminalfenster beobachten kann.

Das sollte THEORETISCH die Performance wenig beeinflussen, bei 9k6. 
Probiers mal ohne Rücksenden.

>Bootloader noch was abschalten, z.B. das Echo ans Terminal.

tu das.

>>Wenn ich es richtig in Erinnerung habe, dann lässt sich
>>HyperTerminal sehr viel Zeit zwischen den einzelnen Bytes,
>>es entstehen oft große Lücken.

>Wie schon gesagt: Ich vermute das schon rein rechnerisch. Deshalb hab
>ich das Oszi auch gar nicht erst ausgepackt. Denn es kann nicht anders
>sein.

Das ist eine GANZ schlechte Einstellung zur Fehlersuche!!!
Expect the unexpected!

MFG
Falk

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Versuch doch mal BinTerm.
Gibts von www.mmvisual.de kostenlos.

Autor: Michael H. (michael_h45)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael H. schrieb:
> dos-konsole: type datei.daten > com1. Vorher mit MODE parametrieren.
> Passt super ins makefile.
>
> Wenn das nix hilft, ist der treiber mist.

Autor: Wilhelm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Erst mal Danke an alle für eure Hilfe und Anregungen!

Michael H. schrieb:

>dos-konsole: type datei.daten > com1. Vorher mit MODE
>parametrieren. Passt super ins makefile.

Ich hab so verschiedenes aus den DOS-Konventionen versucht, auch dicke 
alte DOS-Handbücher gewälzt. Den Befehl mode richtig angewendet. Aus dem 
DOS-Fenster heraus bekomme ich nur den Fehler INT24, und die Auswahl
zum Abbruch, Wiederholen, oder Ignorieren. Was zu nichts führt. Obwohl 
Handshaking und überhaupt alle Kontrolle ausgeschaltet ist. Baudrate, 
8,n,1. Habe dann noch ein paar mal versucht, im Gerätemanager den COM
zu konfigurieren. Das brachte auch nichts.

Es gibt aber was erfreuliches:

Und zwar habe ich vor ein paar Tagen den Quarz meines uralten 
Eval-Boardes getauscht. 12MHz gegen 7,372800MHz. Richtiger 
Baudratenquarz. Damit wird die Kiste zwar langsamer, macht aber 
Baudraten 115200 Baud.
Aber, der Programmdownload eines Intel-Hex-Files am Board rennt jetzt 
schnell wie die Wildsau, mit dem HyperTerminal, dieser Bootloader ist 
jetzt wirklich annehmbar.

Wenn ich mal seeeeehr sehr viel Zeit habe, implementiere ich noch was in 
XMODEM oder ZMODEM. Das macht ja das HyperTerminal richtig schnell, habe 
es getestet. Hatte im Internet noch gefunden, daß auch professionelle
Entwicklungstools und deren Bootloader damit arbeiten...

Autor: blablu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hterm !!

Autor: Michael H. (michael_h45)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nicht bei dem Rechner!

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.