Bug in Hyperterminal

[Patrick W. (wieland)]

Hallo Forum!

Ich habe ein merkwürdiges Verhalten bei Hyperterminal festgestellt und 
wollte mal wissen, ob der Fehler nur bei mir auftritt, oder ob der auch 
bei anderen Windows-Installationen auftritt: Ich habe hier einen AVR der 
über den UART mit meinem PC kommuniziert. Unter Linux schicke ich Daten 
per "echo 'daten' > /dev/ttyS0" und lausche mit "cat /dev/ttyS0". 
Funktioniert auch alles ganz normal. Dann hab ich mal den 
Mikrocontroller an eine Windows-2000-Maschine gehängt und Daten per 
Hyperterminal geschickt. Folgende Feststellung: Von den 8 Bits, die für 
einen Buchstaben in ASCII-Kodierung nötig sind, werden nur die unteren 7 
Bits stets korrekt übermittelt. Das höchste Bit, welches für die errsten 
128 Zeichen des ASCII-Standards logischerweise "0" ist, wird von 
Hyperterminal jedoch rein zufällig mal als "0" oder "1" gesendet. Wenn 
ich vom AVR eines der oberen 128 ASCII-Zeichen sende, dann wird die "1" 
im höchsten Bit von Hyperterminal einfach ignoriert (beziehungsweise auf 
"0" umgeändert). Das "komische" Verhalten beim Senden hört aber sofort 
auf, sobald man einmal das ASCII-Zeichen "0" (also den "Buchstaben 
Null") gesendet hat.

Spinnt nur meine Windoofs-Kiste oder sieht das bei euch auch so aus? 
Oder ist es vielleicht gar kein Bug sondern ein Feature? g

[Rainer (Gast)]

Schon mal einen Blick auf die ASCII-KOnfiguration der Verbindung 
geworfen? Ist hier was falsches eingestellt, wird Hyperterminal schon 
mal recht eigenwillig! Gruß Rainer

[yalu (Gast)]

Sind auf beiden Seiten die Parameter für die Datenwortlänge und die
Parität gleich eingestellt? Ist zwar banal, aber immer wieder Grund
für Überaschungen. Gerade die "Zufälligkeit" des obersten Bits riecht
stark danach, dass da ein Paritätsbit anstelle des Datenbits gesendet
wird.

Und der AVR hat natürlich einen Quarz als Takt? Mit dem internen
RC-Oszillator ist die korrekte Datenübertragung Glücksache. Eine
ungenaue Bitrate erklärt Übertragungsfehler in den obersten Bits
ebenfalls. Aber auch das ist eigentlich banal und mittlerweile hier im
Forum meterbreit getreten.

Sonst habe ich im Moment keine Idee.

[Patrick W. (wieland)]

Hi,
also der USART am AVR funktioniert tadelos, mit den üblichen 
Randbedingungen: Fusebits zur Verwendung von externer Taktquelle, 
Quarzoszillator, Pegelwandler Max232ACPE mit entsprechenden Kapazitäten, 
geschirmte Leitung, Einstellungen im Baudratenregisten nach Datenblatt, 
beide Stationen mit 8N1 ohne Handshake, Abfrage von UDRE (resp. RXC) 
bevor gesendet (resp. empfangen) wird, Tin und Rout am Mäxchen zu 
Testzwecken kurzgeschlossen. Ich glaub' ich hab nichts vergessen. g An 
Hyperterminal habe ich keine Einstellungen geändert, ausser natürlich 
dem üblichen "8N1/Handshake-Kram".
Naja, was solls. Derartige Macken kennt man ja von Windows, aber ich 
hatte nicht vor hier einen Flamewar zu starten.

[Dietmar E (Gast)]

Keinerlei Probleme hier mit Windows und HyperTerminal, Bug erscheint mir 
unwahrscheinlich (Windows-Urgestein). HyperTerminal verwendet eigene 
Port-Einstellungen, also COM-Port nicht im Windows-Gerätemanager 
einstellen, sondern in HyperTermninal: Datei->Eigenschaften-Menü, dann 
unter "COM1" den "Konfigurieren"-Knopf anklicken: 8N1, 
Flusssteuerung="Keine". Dialog schliessen. Im HyperTerminal-Fenster 
<RETURN> drücken und die Verbindung sollte stehen.

[Peter (Gast)]

=> Einstellungen prüfen, (Baudrate, 8 DatenBit)
=> Mit dem Oszilloskop das Signal prüfen,
   insbesondere die exakte Baudrate.

Ich hatte auch schon PCs, bei denen gewisse Baudraten bis zu 3..4 % 
neben dem konfigurierten Wert lagen