cp2102 treiber problem, maus gefriert ein

[markus bütler (Gast)]

Guten Tag

Ich habe ein Print entwickelt der via CP2102 mit dem Computer 
kommunizieren soll. Der Baustein wurde wie im Datenblatt beschrieben 
beschaltet. Er wird von der "Board-Spannung" betrieben.
Im Anhang ist die Beschaltung zu sehen.

Ich habe den aktuellen Treiber und einen älteren Probiert, bei beiden 
das selbe Problem. Wenn ich den Print über USB an den Computer 
anschliesse, gefriert die Maus ein, bis ich ihn wieder ausstecke. Das 
selbe passiert auch auf einem anderen PC.

Die Ratschläge von 
http://www.logview.info/cms/Installation-428-Version.phtml habe ich auch 
schon probiert.

Kennt jemand das Problem?


Gruss

[markus bütler (Gast)]

Hat dieses Problem noch niemand gehabt?

[Stimmt S. (stimmts)]

Der Beitrag ist zwar schon etwas älter, aber falls noch jemand das 
gleich Problem hat oder hierrauf stößt:

Ich hab das bei Stackoverflow gefunden:
http://stackoverflow.com/questions/9226082/device-misdetected-as-serial-mouse

und das hat geholfen:
Location: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\sermouse
Key: Start
Value: 3
Change Value to 4, which is Disabled and it will stop this problem 
occurring.

Das ganze ist wohl ein Bug auf Seiten Windows. CP2102 wird fälschlich 
als "serial ballpoint" erkannt.

Grüße, Stimmts.

[Rufus Τ. F. (rufus)]

David M. schrieb:
> Das ganze ist wohl ein Bug auf Seiten Windows.

Nein. Wird eine serielle Schnittstelle erkannt, und reagiert das an der 
seriellen Schnittstelle angeschlossene Gerät auf eine bestimmte Art 
und Weise, wird --dank Plug&Play-- der zugehörige Devicetreiber geladen. 
Das ist entweder ein Maus- oder Modemtreiber.

Abhilfe ist entweder das Unterdrücken des seriellen Plug&Play oder aber 
ein eindeutig vom Verhalten einer Maus/eines Modems unterscheidbares 
Verhalten des angeschlossenen Geräts.

Hier eine Beschreibung des Protokolls:

It turns out that mouse detection in Windows is normally 
handled by the serenum.sys filter driver.
This driver implements support for legacy serial mice
along with serial plug-and-play. 
Microsoft has even provided the sourcecode as a WDK sample.

During detection the ports switches to 1200-7-N-1 mode
while asserting DTR+RTS to which a response is expected
within 200 ms, with a couple of retries in case of failure.

Unfortunately for a legacy mouse a single M or B character
suffices as identification.

In our case the protocol was reworked to avoid these
characters and now appears not to be misidentified anymore.

However we were using a virtual USB serial port and for 
a traditional serial port this approach may be somewhat 
difficult as anything sent at a different baud rate is 
liable to look like line noise. 
(...)

Alternatively with the serial control signals actually 
hooked up, or intercepted by a USB CDC device, processing 
the DTR or RTS signals and holding off on output.

Also:
Windows aktiviert DTR+RTS und erwartet binnen 200 msec ein einzelnes 
Byte, das ein "B" oder "M" sein kann. Das wird mehrfach wiederholt.

[Stimmt S. (stimmts)]

Danke für die Erklärung.

Rufus Τ. Firefly schrieb:
> Abhilfe ist entweder das Unterdrücken des seriellen Plug&Play oder aber
> ein eindeutig vom Verhalten einer Maus/eines Modems unterscheidbares
> Verhalten des angeschlossenen Geräts.

was genau bewirkt dann die Änderung des Registry-Eintrages? Deaktiviert 
sie das Plug'n'Play?

[Michael L. (michaelx)]

David M. schrieb:
> Danke für die Erklärung.
>
> Rufus Τ. Firefly schrieb:
>> Abhilfe ist entweder das Unterdrücken des seriellen Plug&Play oder aber
>> ein eindeutig vom Verhalten einer Maus/eines Modems unterscheidbares
>> Verhalten des angeschlossenen Geräts.
>
> was genau bewirkt dann die Änderung des Registry-Eintrages? Deaktiviert
> sie das Plug'n'Play?

Was bewirken diese komischen Kringel (auch Buchstaben genannt), die 
immer so lustig in kleinen Grüppchen aufgereiht sind? Deaktivieren die 
das selbstständige Denken?

SCNR

[Stimmt S. (stimmts)]

@michaelx
Wo fehlt hier das selbstständige Denken?
Ich kenn mich mit dem Windows-USB-Krempel nicht gut aus,
ich möchte es verstehen und sicherstellen, dass ich nicht wegen dieser 
Registry-Änderung später auf die merkwürdigsten unlösbaren Fehler stoße.

[bluppdidupp (Gast)]

Die Registry-Geschichte von oben setzt den Startmodus des 
"sermouse"-Treiberdienstes auf Deaktiviert (4). Dadurch das der 
sermouse-Treiber nach Windows-Neustart dann nicht mehr geladen wird, 
führt er dann auch die Suche nach seriellen Mäusen an COM-Ports nicht 
mehr durch.

Es gibt sogar eine ältere Doku zur Erkennung von Geräten an COM-Ports:
http://www.codon.org.uk/~mjg59/pnpcom.rtf

Das Einfachste ist, wenn das Gerät einfach schweigt und erst anfängt 
Daten zu senden, nachdem man ihm selbst irgendein "kannst jetzt 
senden"-Kennzeichen gesendet hat. Dann sieht die Windows PNP-Erkennung 
erst gar nichts was sie "falsch" interpretieren könnte ;D

Bei ftdi-Chips kann man den PNP-Kram auch per .inf deaktivieren:
http://www.ftdichip.com/Support/Documents/AppNotes/AN_107_AdvancedDriverOptions_AN_000073.pdf 
(Unter "6.6.2 Serial Enumerator")
Die Zeile mit "UpperFilters" müsste in der *.inf weggelassen werden, das 
dürfte bei anderen Herstellern vermutlich genauso aussehen.
Wobei ich nicht weiß welche Nebenwirkungen das womöglich hat (abgesehen 
von der Treibersignatur-Problematik)

[Stimmt S. (stimmts)]

Hab grad herausgefunden, dass man den sermouse-plug'n'play-kram auch im 
Gerätemanager deaktivieren kann ohne die Registry direkt zu 
verändern(unter "Mäuse und andere Zeigegeräte").
Das ist allerdings etwas schwierig wenn dabei die Maus spinnt und alles 
mögliche anklickt :D

[Michael L. (michaelx)]

David M. schrieb:
> @michaelx
> ...

Sorry. Ich kenne mich mit den Interna auch nicht wirklich aus, muss mich 
bei jedem Scheiß ert mal reindenken. Aber meinem Verständnis nach war 
die Antwort bereits ausführlich gegeben.