Serielle Schnittstelle am Laptop

Computer: Hardware Drucker, Monitore & Zubehör
1

Hallo www-Experten.
Ich hoffe, damit bin ich im richtigen Board.

Ich habe bei meinem PC einen USB to Seriell Converter und die Datenübertragung funktioniert normal.
Wenn ich bei einem Laptop den selben Converter verwende und mit dem selben Programm eine Übertragung starte, dann funktionierts nicht mehr richtig. Habe das bereits mit mehreren Laptops ausprobiert: 1x HP und 2 verschiedene Gericom. Habe es auch schon mit mehreren Desktop-PCs probiert und da hat es immer funktioniert.

Betriebssystem war immer Windows XP. ich verwende ein von mir geschriebenes Programm zur Übertragung. Beim PC benötigt die Übertragung ca. 1 Minute (und wird dann vom Peripheriegerät auch richtig übernommen), beim Laptop nur ca. 40 Sekunden. Ich verwende exakt die selben Einstellungen und erhalte auch die selben Signale (wurde schon überprüft, mit dem Programm portmon). Der Laptop ist einfach um 20s schneller.

Hat mal jemand von euch ein ähnliches Problem gehabt?
Was kann die Ursache sein?

mfg Andreas

2

Moien

Ich habe bei meinem PC einen USB to Seriell Converter und die
Datenübertragung funktioniert normal.
Wenn ich bei einem Laptop den selben Converter verwende und
mit dem selben Programm eine Übertragung starte, dann
funktionierts nicht mehr richtig. Habe das bereits mit
mehreren Laptops ausprobiert: 1x HP und 2 verschiedene
Gericom.

Also einem Laptop und 2 Schrotthaufen.

Ich würde auf die Spannungsversorung per USB tippen. Einige der USB-RS232 Module sind für 6V gebaut, werden aber an den 5V des USB betrieben. Funktioniert ganz gut wenn auch tatsächlich 5V am USB anliegen. Bei Laptops kann die Spannung schonmal etwas weiter in die Knie gehen und damit die kritische Grenze definitiv unterschreiten.

Hast du mal mit einem aktiven USB-Hub getestet ?

cu

3

Ich würde auf die Spannungsversorung per USB tippen. Einige
der USB-RS232 Module sind für 6V gebaut, werden aber an den 5V
des USB betrieben. Funktioniert ganz gut wenn auch tatsächlich
5V am USB anliegen. Bei Laptops kann die Spannung schonmal
etwas weiter in die Knie gehen und damit die kritische Grenze
definitiv unterschreiten.

Hast du mal mit einem aktiven USB-Hub getestet ?

cu

An der USB-Versorgung kanns nicht liegen, weil mein USB to Seriell Converter funktioniert ja einwandfrei. Ich erhalte auch am Ausgang das richtige Signal. Aber danke für den Tipp.
Allerdings dürfte bei einem Laptop (oder zumindest bei meinen Testgeräten) irgendetwas mit der Übertragunsrate nicht stimmen. Oder die Synchronisierung mit mienem Peripheriegerät haut nicht hin.

Wir haben jetzt einmal folgende Überlegung: Bei einem Gerät, die eine gewöhnliche Hardware-Schnittstelle hat, wie es bei einem Desktop-PC ja der Fall ist, wird die Übertragungsrate Hardware mäßig berechnet. (Lassen wir jetzt mal außer acht, dass ich trotzdem meinen Converter verwende)
Im Gegensatz dazu wird bei einem Laptop, der keine Hardware-Schnittstelle besitzt, die Datenrate von der Software bestimmt.
Wir hatten jetzt die Idee einen Laptop mit einer Hardware-Schnittstelle zu verwenden (konnten bis jetzt aber leider noch keinen auftreiben und das deshalb noch nicht testen).

Kann diese Überlegung irgend wer bestätigen, oder tippen wir dabei komplett im dunkeln?

mfg Andreas

4

Moien

Wir haben jetzt einmal folgende Überlegung: Bei einem Gerät,
die eine gewöhnliche Hardware-Schnittstelle hat, wie es bei
einem Desktop-PC ja der Fall ist, wird die Übertragungsrate
Hardware mäßig berechnet. (Lassen wir jetzt mal außer acht,
dass ich trotzdem meinen Converter verwende)

Lassen wir es mal nicht ausser acht: die USB-Teile machen ihren eigenen Takt. Nichts von den internen Takten kommt über USB durch. An der Baudrate auf RS-232 Seite wird es nicht liegen.

Es könnte aber was ganz banales sein: die Software ist uralt und benutzt die Zykluszeit der CPU als Referenz für busywaiting. Beim starten des Programm schaltet die CPU kurz die Arbeitsfrequnz hoch (weil ja Last da ist). Da kalibiert sich das Programm auf dia aktuelle Frequenz. Danach läuft die CPU aber im energiesparenden, frequenzreduizertem Betrieb weiter => für das Programm vergeht die Zeit plötzlich viel langsamer. Das ist allerdings ein Problem aus dem letzten Jahrtausend. Die letzte Programmiersprache die diesen Fehler fest eingebaut hatte war TurboPascal unter DOS 6.

Teste das mal aber trotzdem durch (Energieschema auf Desktop stellen, CPU-Info Programme wie NHC mitlaufen lassen, Takt im BIOS auf einen Wert festnageln).

cu

5

Es könnte aber was ganz banales sein: die Software ist uralt
und benutzt die Zykluszeit der CPU als Referenz für
busywaiting. Beim starten des Programm schaltet die CPU kurz
die Arbeitsfrequnz hoch (weil ja Last da ist). Da kalibiert
sich das Programm auf dia aktuelle Frequenz. Danach läuft die
CPU aber im energiesparenden, frequenzreduizertem Betrieb
weiter => für das Programm vergeht die Zeit plötzlich viel
langsamer. Das ist allerdings ein Problem aus dem letzten
Jahrtausend. Die letzte Programmiersprache die diesen Fehler
fest eingebaut hatte war TurboPascal unter DOS 6.

Da mein Programm eine VB6 Anwendung ist, kann ich mir das zwar nur schwer vorstellen, aber danke für den Tipp. Ich werde das testen.

mfg

6

Hallo Andreas,

Wir haben jetzt einmal folgende Überlegung: Bei einem Gerät,
die eine gewöhnliche Hardware-Schnittstelle hat, wie es bei
einem Desktop-PC ja der Fall ist, wird die Übertragungsrate
Hardware mäßig berechnet. (Lassen wir jetzt mal außer acht,
dass ich trotzdem meinen Converter verwende)
Im Gegensatz dazu wird bei einem Laptop, der keine
Hardware-Schnittstelle besitzt, die Datenrate von der Software
bestimmt.

Das stimmt so nicht.
In beiden Fällen ist irgendwo ein Quarzoszillator. Durch Teiler wird dann im UART die Baudrate erzeugt. Die Teiler werden durch die Software initialisiert, um die gewünschte Baudrate einzustellen.

Wird das bei deinem Adapter wesentlich anders gemacht, solltest du dir einen besseren besorgen !!

Wie hast du die „richtigen Signale“ überprüft ?
Die Baudrate gehört auch zu „richtig“.

Wie wird eigentlich synchronisiert ? XON/XOFF oder Hardware Handshake ?
Und mit welcher Baudrate betreibst du die Schnittstelle ?

Grundsätzlich kann es eine Verzögerung zwischen dem Empfang eines XOFF Zeichens und der Weiterleitung bis zum Treiber geben, da das Zeichen ja erst noch über USB übertragen werden muss. Bei einem UART, welches direkt im PC eingebaut ist, fällt diese Verzögerung wesentlich kleiner aus.
Der Fehler könnte auch am verwendeten Protokoll auf der V.24 Verbindung liegen oder der Puffer im Endgerät verträgt es nicht, wenn es nach dem Senden eines XOFF noch mehr Daten empfangen muss, was aber ein Implementierungfehler ist.

MfG Peter(TOO)

7

Hi Andreas,

Wenn ich bei einem Laptop den selben Converter verwende und
mit dem selben Programm eine Übertragung starte, dann
funktionierts nicht mehr richtig.

Jep, ein leidvolles Thema.

Was kann die Ursache sein?

USB arbeitet frame orientiert: http://www.oem-printer.com/ergebnis.lasso?-token=42F…

Entweder du achtest darauf, nur passende Frames zu übertragen, oder du nimmst eine PCMCIA Karte, die native RS232 zur Verfügung stellt. Die verhält sich dann wie die alte RS232.

mfg Ulrich

8

Hallo,

Du schreibst nichts über die Randbedingungen

  • Handshakes
  • baudrate
  • Timing
  • Protokoll
  • Timeouts
    usw.

Solange ich denken kann, ist es so, daß bei jeder Neuentwicklung
eines Gerätes mit der obligatorischen RS232 irgendwann mal
irgendwelche Probleme auftreten. Was es im konkreten Fall ist,
kann man nur durch Analyse herausbekommen. Dazu nutze ich
üblicherweise einen „Spion“ und einen (digitalen) Oszi.

Der Spion ist nur eine umschaltbaren Abzweig am RS232-Stecker
des Gerätes, der wahlweise die Daten des Senders (PC) und des
Empfängers (Gerät) zum Rxd-Pin einem weiteren PC/Laptop mit einem
zuverlässigen Terminalprogramm (z.B.Term90 vom alten Nortoncommander)
leitet.
Dort sieht man erstmal, was jeweils gesendet und empfangen wird.
Was man natürlich nicht sieht, ist das Timing und evtl.
Hardware-Handshake-Signale. Dazu muß ein Oszi ran.

Meist liegt das Problem im irgendwie veränderten Timing.
Da werden mal die Zeichen in kürzerem Abstand gesendet (eine kleine
Pause zwischen 2 zeichen ist immer gut, wenn es die Datenmenge
zuläßt.
Andermal sind plötzlich Pausen zu lang - Timeout kommt.
Oder Protokolle werden vom Betriebssystem oder zusatzhardware
zerhackt -> siehe Framingproblem.

Auch die exakten Bitlängen sind natürlich zu überprüfen.

Auch die bidirektionale Übertragung kann Timingprobleme bereiten.
Wenn z.B. Eine Antwort vom Gerät schon gesendet wird, während der
PC noch Daten sendet -> geht z.B. nicht mit Funkverb. (Bluetooth
oder ähnlich, weil nicht gleichzeitig nur senden und empf. können).

Andere Probleme können durch das Betriebssystem (Windows) verursacht
werden, wenn die Daten aus dem Puffer nicht schnell genug abgeholt
werden, so daß der Puffer in den Pollingpausen überläuft (war
eine Zeitlang bei Win95/98 ein Problem, weil die Hardware noch
zu langsam war).

Viele Probleme lassen sich dadurch finden und beheben, daß die
Zeichen mit genügend Absand (Pause) gesendet werden und die
Timeoutzeiten verlängert werden.
Wenn möglich sollte auch auf das gleichzeitige Senden von Daten
in beide Richtungen verzichtet werden.

Gruß Uwi

www-Experten Ich hoffe, damit bin ich im richtigen Board.

Ich habe bei meinem PC einen USB to Seriell Converter und die
Datenübertragung funktioniert normal.
Wenn ich bei einem Laptop den selben Converter verwende und
mit dem selben Programm eine Übertragung starte, dann
funktionierts nicht mehr richtig. Habe das bereits mit
mehreren Laptops ausprobiert: 1x HP und 2 verschiedene
Gericom. Habe es auch schon mit mehreren Desktop-PCs probiert
und da hat es immer funktioniert.

Betriebssystem war immer Windows XP. ich verwende ein von mir
geschriebenes Programm zur Übertragung. Beim PC benötigt die
Übertragung ca. 1 Minute (und wird dann vom Peripheriegerät
auch richtig übernommen), beim Laptop nur ca. 40 Sekunden. Ich
verwende exakt die selben Einstellungen und erhalte auch die
selben Signale (wurde schon überprüft, mit dem Programm
portmon). Der Laptop ist einfach um 20s schneller.

Hat mal jemand von euch ein ähnliches Problem gehabt?
Was kann die Ursache sein?

mfg Andreas