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
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.
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:
1 | It turns out that mouse detection in Windows is normally |
2 | handled by the serenum.sys filter driver. |
3 | This driver implements support for legacy serial mice |
4 | along with serial plug-and-play. |
5 | Microsoft has even provided the sourcecode as a WDK sample. |
6 | |
7 | During detection the ports switches to 1200-7-N-1 mode |
8 | while asserting DTR+RTS to which a response is expected |
9 | within 200 ms, with a couple of retries in case of failure. |
10 | |
11 | Unfortunately for a legacy mouse a single M or B character |
12 | suffices as identification. |
13 | |
14 | In our case the protocol was reworked to avoid these |
15 | characters and now appears not to be misidentified anymore. |
16 | |
17 | However we were using a virtual USB serial port and for |
18 | a traditional serial port this approach may be somewhat |
19 | difficult as anything sent at a different baud rate is |
20 | liable to look like line noise. |
21 | (...) |
22 | |
23 | Alternatively with the serial control signals actually |
24 | hooked up, or intercepted by a USB CDC device, processing |
25 | 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.
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?
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
@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.
:
Bearbeitet durch User
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)
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
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.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.