Probleme mit USB/Serial convertern

A

Alexander Peter

Guest
Hallo,

ist zwar etwas OT hier, vielleicht hat aber der ein oder andere von Euch da
auch schon seine leidvollen Erfahrungen sammeln dürfen.

Hatte das alles schon mal bei den "Kollegen von nebenan" in
'microsoft.public.de.vc' drin, war aber bisher noch nicht so ergiebig :-(

Ich habe eine "Altlast" (Windows MFC Applikation) übernommen, die
vornehmlich unter Windows 2000 und Windows XP nicht 100%ig will.

Wir haben für eines unserer Produkte die Möglichkeit einer RS232
Fernsteuerbarkeit. Bisher unter Windows 98 und NT bei eingebauter
Schnittstelle (fast) keinerlei Probleme. Unter 2000 und XP (pro oder home)
im wesentlichen auch nicht. Wenn es Probleme gibt/gab, waren
die auf der jeweiligen Installation hausgemacht.

Aufgrund immer weniger eingebauter COM Ports speziell bei Laptops gingen
jetzt einige Kunden dazu über USB/seriell Wandler
einzusetzen. Eine andere Lösung die ich hier schon erfolgreich getestet
habe sind EtherNet/Serial Wandler (z.B. Moxa NPort).

Jetzt kommt das Ominöse:
Auf all meinen Testsystemen die mindestens eine eingebaute serielle
Schnittstelle haben habe ich keinerlei Probleme. Kommunikation
steht. Auch per USB/Seriell oder Ethernet/Seriell völlig stressfrei.

Nur die PCs/Laptops die keine eingebaute serielle Schnittstelle haben
machen Ärger:

+ Gegenüber wird nicht erkannt
+ bei grösseren Datentransfers kann es zum Abbruch der Kommunikation kommen

Habt ihr irgendeine Idee nach was ich suchen sollte/kann?

Ein paar Fakten/Daten:

+ MFC Applikation
+ serielle Übertragung mit 38.4kBaud
+ 5 Draht Übertragung RxD/TxD/GND, DTR ist Remotereset, CTS ist
Gegenübererkennung

Ausserdem verhält sich die Anwendung im Remote Debug etwas unterschiedlich
auf den einzelnen Plattformen?

Any ideas?

Alexander
 
Nur die PCs/Laptops die keine eingebaute serielle Schnittstelle haben
machen Ärger:

+ Gegenüber wird nicht erkannt
+ bei grösseren Datentransfers kann es zum Abbruch der Kommunikation
kommen


Hallo Alexander,
bei uns gibt es ähnliche Probleme. Wir vermuten stark, dass es aufgrund des
begrenzten Receive-FIFOs der USB/RS232 Adapter zu Überläufen kommt
(RTS-Leitung sollte eigentlich beachtet werden). .
Falls der Datentransfer voneinander abhängig ist (ein Byte wird gesendet,
ein Byte wird geantwortet etc.) muss man die USB-Timeslots berücksichtigen,
wenn es schlecht läuft, kann die Antwort erst 2-3 ms später da sein. Damit
bricht die Datenrate brutal ein gegenüber einer nicht-USB-Lösung.
Weiterhin scheinen die Treiber einiger Karten noch nicht ganz zu Ende
programmiert zu sein.

Lösungen:
- Beachtung der RTS-Leitung
- Baudrate verringern
- kleine Pakete einzeln quittieren (ziemlich geringer Durchsatz)
- Am besten: die nicht ganz billigen PCMCIA-RS232 - Adapter verwenden

Viele Grüße
Rainer
 
Am Fri, 23 Jul 2004 08:22:41 +0200 schrieb Rainer Harthaus:

Nur die PCs/Laptops die keine eingebaute serielle Schnittstelle haben
machen Ärger:

+ Gegenüber wird nicht erkannt
+ bei grösseren Datentransfers kann es zum Abbruch der Kommunikation
kommen


Hallo Alexander,
bei uns gibt es ähnliche Probleme. Wir vermuten stark, dass es aufgrund des
begrenzten Receive-FIFOs der USB/RS232 Adapter zu Überläufen kommt
(RTS-Leitung sollte eigentlich beachtet werden). .
Falls der Datentransfer voneinander abhängig ist (ein Byte wird gesendet,
ein Byte wird geantwortet etc.) muss man die USB-Timeslots berücksichtigen,
wenn es schlecht läuft, kann die Antwort erst 2-3 ms später da sein. Damit
bricht die Datenrate brutal ein gegenüber einer nicht-USB-Lösung.
Weiterhin scheinen die Treiber einiger Karten noch nicht ganz zu Ende
programmiert zu sein.

Lösungen:
- Beachtung der RTS-Leitung
- Baudrate verringern
- kleine Pakete einzeln quittieren (ziemlich geringer Durchsatz)
- Am besten: die nicht ganz billigen PCMCIA-RS232 - Adapter verwenden
Hallo Rainer,

das Seltsame ist halt, dass unsere Anwendung mit derselben Hardware (also
USB/seriell converter) an PCs *mit* eigenem COM funktioniert?! Also kann's
an der Hardware selbst ja nicht liegen :-( Der Fehler muss also irgendwo an
der anderen integration des Treibers oder "wasweissichs" innerhalb Windows
liegen, oder?

Alexander
 
Hallo

ich weiss nicht, ob das heutzutage noch ein Problem ist. ich hatte mal
das Problem, dass die Interruptzuweisung von COM1 nicht verträglich
war (frag mich nicht mehr warum) Wenn man auf COM2 gewechselt hatte
gings, Com 3 schon wieder nicht mehr. Daher vermutete ich den
gemeinsamen IRQ von COM1 und COM3. Wie dem auch sei... COM2 ging dann
gut
Einfach probieren, wenn man bei dem Treiber vorgeben kann, welchen
COM-Port er nehmen soll...

MArtin
 
Alexander Peter schrieb:

Jetzt kommt das Ominöse:
Auf all meinen Testsystemen die mindestens eine eingebaute serielle
Schnittstelle haben habe ich keinerlei Probleme. Kommunikation
steht. Auch per USB/Seriell oder Ethernet/Seriell völlig stressfrei.
Man müsste wissen, ob da wirklich ohne Adapter KEINERLEI COM Port im
System ist. Meistens sind es doch welche, nämlich für IrDA oder das
Modem. Ich weiß, daß es bei USB-Seriell Wandlern mal Probleme mit der
Installation gabe, weil einige Notebooks keinerlei COM Subsystem o.ä.
innstalliert hatten. Denen fehle irgendeine Treiberebene oder so. Ich
habe das Dokument noch irgendwo liegen.

Ganz glauben kann ich das nicht, Ihr solltet mal versuchen, bei den
problematischen Systemen die USB-Seriell Wandler auszutauschen. Ich weiß
z.B., daß die Keyspan Adapter relativ weitgehend konfigurierbar sind
z.B. was Buffergrößen und verschiedene andere Parameter angeht. Das geht
bei anderen Adaptern nicht.


- Carsten



--
Audio Visual Systems fon: +49 (0)2234 601886
Carsten Kurz fax: +49 (0)2234 601887
Von-Werth-Straße 111 email: audiovisual@t-online.de
50259 Pulheim / Germany WGS84:N50°57'50.2" E06°47'28.5"
 
In article <zv92m92ym0qf$.ybs7smnzovtt.dlg@40tude.net>,
Alexander Peter <apeter@musicandsales.com> writes:

|> das Seltsame ist halt, dass unsere Anwendung mit derselben Hardware (also
|> USB/seriell converter) an PCs *mit* eigenem COM funktioniert?! Also kann's
|> an der Hardware selbst ja nicht liegen :-( Der Fehler muss also irgendwo an
|> der anderen integration des Treibers oder "wasweissichs" innerhalb Windows
|> liegen, oder?

Das liegt wohl weniger an der Unterscheidung mit/ohne Legacy-Com, sondern an
einem anderen USB-Hostcontroller. Intel/AMD/Nvidia/Opti sind gut, VIA schlecht,
SiS besch... Leider ist VIA stark verbreitet, die haben aber selbst mit USB1.1
immer noch ziemliche Probleme. Es scheint unglaublich schwer zu sein, die 12Mbit
stabil über den PCI zu bekommen...

--
Georg Acher, acher@in.tum.de
http://wwwbode.in.tum.de/~acher
"Oh no, not again !" The bowl of petunias
 
Georg Acher schrieb:

Das liegt wohl weniger an der Unterscheidung mit/ohne Legacy-Com, sondern an
einem anderen USB-Hostcontroller. Intel/AMD/Nvidia/Opti sind gut, VIA schlecht,
SiS besch... Leider ist VIA stark verbreitet, die haben aber selbst mit USB1.1
immer noch ziemliche Probleme. Es scheint unglaublich schwer zu sein, die 12Mbit
stabil über den PCI zu bekommen...
Das wäre in der Tat auch eine Möglichkeit. Ich weiß, daß einige USB
HostController prinzipiell Ärger in low-latency Audio Systemen machen,
während andere problemlos sind.

Das erklärt zwar nicht direkt, daß die Probleme auch mit dem Ethernet
Converter autreten, aber dafür ist die Anzahl der problematischen
Systeme vermutlich einfach noch nicht statistisch relevant.

- Carsten
 
Carsten Kurz <audiovisual@t-online.de> :

z.B., daß die Keyspan Adapter relativ weitgehend konfigurierbar sind
z.B. was Buffergrößen und verschiedene andere Parameter angeht. Das geht
bei anderen Adaptern nicht.
Die Erfahrung mit verschieden guten Treibern der einzelnen Hersteller
hab ich auch schon gemacht. "Normaler" Betrieb lief eigentlich immer
störungsfrei, aber wehe, die Steuerleitungen (RTS etc) wurden als
digital IOs verwendet, am besten auch noch zeitkritisch.
Bei mir hat sich der Keyspan auch positiv hervorgetan.

Und das Treiberfeature, alle übertragenen Daten mitzuschreiben ist
sowieso Gold wert.
 

Welcome to EDABoard.com

Sponsor

Back
Top