RS232, WinXP, Stopbit fehlt

Hi Joerg,

Auf meinem zweiten XP Rechner tritt das Problem nicht auf. Aber ein Kunde hat das gleiche Problem, aber der hat kein Oszi. Er konnte aber nachvollziehen dass der Fehler verschwindet wenn man auf Xon/Xoff umschaltet und dann wieder zurück auf "no handshake" schaltet. Genau wie bei mir.

Gruss Michael

Hallo Michael,

Das deutet allerdings schwer auf Schnittstellenfehler hin. Ich nehme mal an, es ist kein USB-RS232 Konverter in der Kette, denn bei denen gibt es schon mal Time-Outs im Millisekundenbereich.

Probiere das nochmal mit TeraTerm oder anderen nicht-MS Programmen.

Dann waere es eventuell hilfreich, zu sehen, welche Motherboards dort jeweils drin sind. Kleine Liste der verschiedenen Rechner nach dem Motto "Auf diesen geht es schief, auf jenen funktioniert alles normal".

Wenn es gar nicht weiter geht, koennte ein Post bei comp.arch.embedded helfen. Die meisten Jungs dort machen RS232, seit sie in den Windeln lagen.

Und danach einmal die Verbindung trennen und neu aufbauen. damit HT die geänderten Einstellungen auch übernimmt - Sch**teil.

Ich nehme TeraTerm, da klappt das wie es soll.

cu Michael

Michael Koch schrieb:

Das Ding wahr schon bei WinDos95 unbrauchbar.

ISt zwar von '99 ist aber mein bevorzugtes Terminalprogramm.

f=FCr

dem

so

Hatte ich vor vielen (10?) Jahren mal mit einem Win95-Rechner. Allerdings trat da das Problem nur auf, wenn man mehrmals das _gleiche_ Zeichen auf der Tastatur eingab - bei wechselnden Zeichen und bei =DCbertragung beliebiger Dateien blieb der Fehler aus. Den Workaround mit Xon/Xoff an- und ausschalten hab ich damals nicht gefunden - einfach DOS gebootet und den Kermit wieder mal h=FCpfen lassen. Dass das Echo mit der RxD/TxD-Br=FCcke unauff=E4llig bleibt w=FCrde ich damit erkl=E4ren, dass die Umschaltung 7bit/8bit bei allen in IBM- Kompatiblen (lange nicht mehr benutzt, den Ausdruck) =FCblicherweise vegetierenden SIOs nur f=FCr Rx und Tx zusammen geht.

Gru=DF, Ingo

RS232

in

an.

nn

Hallo Michael, mein bevorzugtes Terminalprogramm ist ebenfalls Teraterm. Aber zu deinem Problem. Da die Parallel-Seriell-Wandlung im UART passiert und dieser nicht defekt ist (Test mit alternativer Software), kann das Fehlen des Bits nur durch ein Fehler im Treiber passieren. Habe das mal bei einem anderen System beobachtet und gedebugt. Der Fehler tritt auf, wenn der UART-Baustein durch die Software neu konfiguriert (Steuerregister geschrieben) wird, w=E4hrend die aktuelle =DCbertragung des Wortes noch nicht beendet ist. Das =DCbertragungsende wird typisch durch ein IRQ ausgel=F6st. Schau daher mal, ob es hier (ggf. im Bios) irgendwelche Konflikte geben kann. Normalerweise sollte Hyperterm keine solchen Fehler verursachen - und tuts bei mir auch nicht.

Gru=DF, Henning

Hallo Ingo,

Allerdings trat da das Problem nur auf, wenn man mehrmals das _gleiche_ Zeichen auf der Tastatur eingab - bei wechselnden Zeichen und bei Übertragung beliebiger Dateien blieb der Fehler aus.

Du hast Recht, genau so ist es. Wenn ich abwechselnd "f" und "g" eintippe, dann wird das MSB immer korrekt gesendet. Sobald ich zweimal hintereinander das gleiche Zeichen eintippe, wird bei jedem zweiten Zeichen das MSB falsch gesendet.

Aber jetzt wo ich das weiss ist klar wie das Problem gelöst werden muss. Ich habe die Software in dem Gerät am Ende der Leitung so geändert, dass das MSB grundsätzlich ignoriert wird. Das ist in diesem Fall keine Einschränkung, weil sowieso nur ASCII Zeichen übertragen werden. Jetzt kann Hyperterminal von mir aus das MSB abhängig von der Mondphase senden oder auch nicht senden :-)

Gruss Michael

Joerg :

Was spricht eigentlich gegen ein Terminalprogramm geschrieben mit der Excel-VBA? :-)

M.

"Michael Koch" :

Au schei* Das geht solange gut, bis Saturn und Venus in Konjuktion stehen und dann Hyperterm auch mal das 7. bit anknabbert. (Find lieber den Fehler)

M.

Hallo Matthias,

Ich wuerde einen Luftsprung machen, wenn es das gaebe. MS-Works unter DOS hatte dies (ohne VBA). Damals war es kinderleicht, die Daten des Dolch Analyzers mal eben auf Works Spreadsheet zu holen und Algorithmen drueber zu schicken. Pfiffigerweise war naemlich ein Terminal Programm mit integriert. Doch den Zahn hat MS rausgerupft. Ja, ja, die guten alten Zeiten. Alles Gute hat mal ein Ende.

Nun kommt hier ein Dual Monitor PC hin und ein alter Laptop geht eventuell ins Labor. Der kann dank Win2K sehr huebsch DOS-Works 2.0 im DOS Fenster laufen lassen. Vielleicht kann ich mir wenigstens dort den ganzen API Kram ersparen ...

Auf comp.arch.embedded fragen. Das muss doch auch schon anderen Leuten passiert sein und dort sitzen die Embedded Systems Experten.

Joerg :

Im Prinzip hast Du das schon. Den Makroschnipsel dessen Link hier jemand mal gepostet hat, enthält ja alles was man braucht, um auf die Serielle zugreifen zu können, ohne jede zusätzlich DLL oder andren Kram. Fehlt nur noch das Bedieninterface (was ja am besten sowieso immer an den jeweiligen Anwendungsfall angepasst werden sollte.)

M.

Hallo Matthias,

Ja, damit ist es gegangen. Allerdings nicht 100% zuverlaessig, ab und an hakte es. Mit dieser Anleitung bin ich dann etwas weitergekommen (Methode ohne mscomm.ocx):

Frueher waren die Leute eben praktischer, auch bei MS. Da war diese Funktion schlicht und einfach Bestandteil des MS-Works Paketes. Windows sollte das Leben des Benutzers einfacher machen, doch das hat es in diesem Bereich eindeutig nicht getan. Ich brauchte als Nicht-Programmierer Stunden, um dem Laborgeraet Daten zu entlocken. 1990 brauchte ich weniger als 10 Minuten und damals hatte ich weniger Ahnung.

Das gibts auch in aktueller Fassung:

Grüße Robert