mehrere USB-Geraete mit CP2102 gleichzeitig betreiben

L

Lutz Schulze

Guest
Hallo,

habe eben mal an 2 verschiedenen Win-XP Rechnern getestet, zwei
USB-Chips CP2102 gleichzeitig zum laufen zu bekommen.
Leider ohne Erfolg, es wird nur immer ein Chip erkannt und als
virtueller Com-Port zur Verfügung gestellt.
Ist das eventuell prinzipiell gar nicht möglich? Habe bisher aber noch
keinen Grund finden können.

Da mir hier eine Testmöglichkeit fehlt: ist der FT232BM (FT245BL)
dafür vielleicht die bessere Wahl?

für eure Tips dankt

Lutz
--
Temperatur und mehr mit dem PC messen - auch im Netzwerk: http://www.messpc.de
jetzt neu: Ethernetbox für direkten Anschluss der Sensoren im Netzwerk
Test im IT-Administrator: http://www.messpc.de/MessPC-Testbericht-ITA.pdf
http://www.netzwerkseite.de - die Seite rund um EDV-Netzwerke
 
Hi,

habe eben mal an 2 verschiedenen Win-XP Rechnern getestet, zwei
USB-Chips CP2102 gleichzeitig zum laufen zu bekommen.
Leider ohne Erfolg, es wird nur immer ein Chip erkannt und als
virtueller Com-Port zur Verfügung gestellt.
Ist das eventuell prinzipiell gar nicht möglich? Habe bisher aber noch
keinen Grund finden können.
das kenne ich bereits von Prolific USB Chips.
Deine CP2102 haben vermutlich beide die gleiche VID und PID.
Die Treiber können sie deshalb nicht eindeutig zuweisen.

Ich hatte solche Probleme mit einem USB-Seriell Konverter
mit Prolific Chip und gleichzeitig angeschlossenem Chipdrive,
ein Chipkartenleser mit Prolific Chip. Auch hier hatten
beide die gleiche VID und PID. Es war nicht möglich beide
an einem PC zu betreiben.

Der Prolific Chip sitzt übrigends auch in vielen USB-GPS Mäusen.

Da mir hier eine Testmöglichkeit fehlt: ist der FT232BM (FT245BL)
dafür vielleicht die bessere Wahl?
Auf jeden Fall. Aber nur wenn du jeder Schaltung ein EEPROM
spendierst und UNTERSCHIEDLICHE VID und PID einprogrammierst.
Bei gleicher VID, PID hatte ich auch mit den FTDI Chips das
Problem das Win sie nicht unterscheiden konnte und sich sogar
komplett aufgehängt hat.

Viele OEMs benutzen Chips mit den Original VID, PID des
Chipherstellers. Grund: Eigene VID, PID zu registrieren
kostet Kohle. Der Kunde ist hier wieder einmal der Dumme.
Unerwartete Nebenwirkungen.

Wer kommt auch schon auf die Idee ZWEI USB-Seriell Konverter
von demselben Hersteller an seinem PC zu benutzen ? Das ist doch
unwahrscheinlich ;)

Die schöne (?) neue USB-Welt
Holger

http://www.holger-klabunde.de
 
In article <433c518e$0$26227$9b4e6d93@newsread2.arcor-online.net>,
holger klabunde <hk@holger-klabunde.de> writes:

|> Wer kommt auch schon auf die Idee ZWEI USB-Seriell Konverter
|> von demselben Hersteller an seinem PC zu benutzen ? Das ist doch
|> unwahrscheinlich ;)

Das sollte aber egal sein, wenn beide denselben Chip haben. Windows bindet die
Treiber ja nicht nur anhand VID/PID sondern auch noch mit der Port-Hierarchie.
Und über USB gibts low-level ohnehin eine eindeutige ID. Wenn sowas nicht geht,
ist es eher ein dicker Bug im Treiber...

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

holger klabunde schrieb:
Deine CP2102 haben vermutlich beide die gleiche VID und PID.
Logisch, wenn es das gleiche Geräte des selben Herstellers (Lutz) sind.
Das *muß* so sein.


Die Treiber können sie deshalb nicht eindeutig zuweisen.
Der kann sie nicht zuordnen, weil sie beide entweder keine oder aber
die selbe Seriennummer haben. Laut Spezifikation ist dieser String zwar
optional, aber die Praxis lehrt etwas anderes.

Als Abhilfe ist also einfach beiden Chips eine *eindeutige* Seriennummer
zuzuorden. Ein EEPROM muß natürlich nicht noch extra angeschlossen werden,
da der CP2102 das bereits eingebaut hat.


Da mir hier eine Testmöglichkeit fehlt: ist der FT232BM (FT245BL)
dafür vielleicht die bessere Wahl?
Der FT232 ist die schlechtere Wahl. Der ist teurer, größer und braucht
erheblich mehr an externer Beschaltung. Mit dem FT245 ist kein Vergleich
möglich, das ist etwas anderes. Das "Problem" mit der Seriennumer hast Du
aber mit beiden FTDIs ganz genau so.

BTW: Die FT232AM wurden sogar alle defekt ausgeliefert. Ohne EEPROM
funktionierten die gar nicht, da fälschlicherweise auf Anfrage eine
Seriennumer geliefert wurde, und zwar immer die selbe!


Gruß,
René
 
Hallo!

Joerg Wunsch schrieb:
Dann ist er buggy. Wenn sie in der Hierarchie des USB an zwei
verschiedenen Knoten klemmen, *können* sie nicht das gleiche Device
sein, also sollte der Treiber ihnen auch dynamisch zwei verschiedene,
vom Betriebssystem unterscheidbare Namen zuteilen. Alles andere kann
man nur als Bug ansehen.
Ja gut, das passiert auch, wenn dem Gerät keine Seriennumer zugeordnet
ist. Ich muß mich etwas entschärfen. Trotzdem gehört eine solche Nummer
in jedes Gerät, IMO. Gerade bei diesen virtuellen Ports gehen Dir sonst
schnell die Nummern aus.

Alles Andere sehe ich auch als Bug an, und zwar im Gerät! Es kann nun mal
keine zwei gleichen Geräte mit der selben Seriennumer geben. Vorausgesetzt,
ich weiß was eine Seriennummer ist und was eine solche auszeichnet. Und zur
Kennzeichnung des Produkts ist ja auch eigentlich der PID zuständig.

Gruß,
René
 
René König <rk@tbkoenig.de> schrieb:

Die Treiber können sie deshalb nicht eindeutig zuweisen.

Der kann sie nicht zuordnen, weil sie beide entweder keine oder aber
die selbe Seriennummer haben.
Dann ist er buggy. Wenn sie in der Hierarchie des USB an zwei
verschiedenen Knoten klemmen, *können* sie nicht das gleiche Device
sein, also sollte der Treiber ihnen auch dynamisch zwei verschiedene,
vom Betriebssystem unterscheidbare Namen zuteilen. Alles andere kann
man nur als Bug ansehen.

--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL

http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
 
René König <rk@tbkoenig.de> schrieb:

Ja gut, das passiert auch, wenn dem Gerät keine Seriennumer
zugeordnet ist. Ich muß mich etwas entschärfen. Trotzdem gehört eine
solche Nummer in jedes Gerät, IMO. Gerade bei diesen virtuellen
Ports gehen Dir sonst schnell die Nummern aus.
Wieso? Man muss doch die Portnummer nicht an die Seriennummer binden.
Wenn das Gerät halt keine hat, werden sie einfach dynamisch
zugewiesen, je nachdem, was gerade dranklemmt.

--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL

http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
 
Hallo!

Joerg Wunsch schrieb:
Wieso? Man muss doch die Portnummer nicht an die Seriennummer binden.
Wenn das Gerät halt keine hat, werden sie einfach dynamisch
zugewiesen, je nachdem, was gerade dranklemmt.
Jörg, daß das passiert, habe ich doch geschrieben. Ich will mich mit Dir
auch nicht streiten. Wenn Du meinst, daß Deine Geräte ohne Seriennummer
besser funktionieren, dann kannst Du sie einfach weglassen. *Meine* Geräte
haben eine Seriennumer, und zwar alle. Eben weil es, wie hier gezeigt, dann
doch immer mal wieder zu Schwierigkeiten kommt. Die Lösung der Probleme ist
so einfach, daß *mir* dabei auch kein Zacken aus der Krone fällt.

Die Seriennumer hat übrigens noch praktische Nebenwirkungen: Ich mache nicht
nur mit virtuellen COM Ports herum. Trotzdem will ich dem User die Möglichkeit
bieten, zwischen den angeschlossenen Geräten zu wählen. Eine eindeutige
Zuordnung wie z.B. COM1 gibt es nun aber nicht mehr. In solchen Momenten weiß
ich dann, daß die Seriennumer nicht Fluch, sondern Segen ist. :)


Gruß,
René
 
On Thu, 29 Sep 2005 23:31:25 +0200, René König <rk@tbkoenig.de> wrote:

Hallo!

holger klabunde schrieb:
Deine CP2102 haben vermutlich beide die gleiche VID und PID.

Logisch, wenn es das gleiche Geräte des selben Herstellers (Lutz) sind.
Das *muß* so sein.


Die Treiber können sie deshalb nicht eindeutig zuweisen.

Der kann sie nicht zuordnen, weil sie beide entweder keine oder aber
die selbe Seriennummer haben. Laut Spezifikation ist dieser String zwar
optional, aber die Praxis lehrt etwas anderes.

Als Abhilfe ist also einfach beiden Chips eine *eindeutige* Seriennummer
zuzuorden. Ein EEPROM muß natürlich nicht noch extra angeschlossen werden,
da der CP2102 das bereits eingebaut hat.
Danke für den Tip, werde mir das Manual noch einmal daraufhin ansehen
und ihm dann die nötigen Befehle verpassen.

Ich berichte dann, ob es im speziellen Fall hilft.

Lutz
--
Temperatur und mehr mit dem PC messen - auch im Netzwerk: http://www.messpc.de
jetzt neu: Ethernetbox für direkten Anschluss der Sensoren im Netzwerk
Test im IT-Administrator: http://www.messpc.de/MessPC-Testbericht-ITA.pdf
http://www.netzwerkseite.de - die Seite rund um EDV-Netzwerke
 
Am Thu, 29 Sep 2005 20:52:34 +0200 schrieb Lutz Schulze:


Da mir hier eine Testmöglichkeit fehlt: ist der FT232BM (FT245BL)
dafür vielleicht die bessere Wahl?
Jein! Ich habe hier Mehrere FTDIs schon am Bus gehabt, aber: wenn man nicht
aufpasst und die Geräte nicht über PID/VID wirklich wasserdicht definiert
sind können sich Virtual Com und direkter Treiber für die API von FTDI in
die Quere kommen.

Bei mir war dies der Fall, dass sich ein eigenes Gerät partout nur als vCOM
anmelden wollte, weil bereits ein vCOM vorher installiert war.

Da hilft dann nur Treiber deinstallieren/neuinstallieren oder eigene ID
vergeben (kann man bei FTDI bekommen)

HTH

Alexander
 
On Fri, 30 Sep 2005 13:59:58 +0200, Lutz Schulze
<lschulze@netzwerkseite.de> wrote:

Als Abhilfe ist also einfach beiden Chips eine *eindeutige* Seriennummer
zuzuorden. Ein EEPROM muß natürlich nicht noch extra angeschlossen werden,
da der CP2102 das bereits eingebaut hat.

Danke für den Tip, werde mir das Manual noch einmal daraufhin ansehen
und ihm dann die nötigen Befehle verpassen.

Ich berichte dann, ob es im speziellen Fall hilft.
Hat prima geklappt. Seriennummer geändert, jetzt laufen mehrere Geräte
gleichzeitig und werden als com5, com6 usw. durchnummeriert.
Silabs stellt dazu auch ein Tool zur Verfügung, CP210xSetIDs.exe.

Die Software befindet sich mit auf der CD (AN144)

Lutz.
--
Temperatur und mehr mit dem PC messen - auch im Netzwerk: http://www.messpc.de
jetzt neu: Ethernetbox für direkten Anschluss der Sensoren im Netzwerk
Test im IT-Administrator: http://www.messpc.de/MessPC-Testbericht-ITA.pdf
http://www.netzwerkseite.de - die Seite rund um EDV-Netzwerke
 

Welcome to EDABoard.com

Sponsor

Back
Top