Périphérique mal détecté en tant que souris série
Je travaille sur un périphérique qui communique avec un PC via un port série (virtuel). Le problème est que les données que nous envoyons sont parfois incorrectement identifiées par Windows en tant que souris bus, après quoi le pilote "Microsoft Serial Ballpoint" est chargé et le pointeur de la souris commence à sauter sur l'écran et à cliquer de manière aléatoire.
Un peu de recherche sur Google révèle qu’il s’agit d’un problème ancien et bien connu avec les périphériques série, où la solution habituelle consiste à pirater le registre pour désactiver le pilote incriminé. C’est cependant beaucoup à demander de nos utilisateurs et je préférerais que notre application ne dérange pas le registre des utilisateurs. Surtout pas lorsque le correctif dépend de la version de Windows et que l'utilisateur peut très bien utiliser une souris bus.
Au lieu de cela, j'aimerais éviter le problème en modifiant notre protocole pour ne pas envoyer de données qui pourraient nous donner une erreur d'identification de souris. Le seul problème est que je ne suis pas tout à fait sûr des modèles à éviter . Apparemment, le protocole de souris de Microsoft consiste en paquets de quatre octets où le MSB du premier est défini et celui des trois derniers est clair.
Envoyer uniquement ASCII 7 bits suffirait-il? Existe-t-il d'autres périphériques pour lesquels je dois craindre d'être détectés?
Je viens de rencontrer ce problème moi-même sur Windows 7 Professional x64, et une solution qui a fonctionné pour moi était d'aller dans le registre et d'éditer la valeur suivante:
Location: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\sermouse
Key: Start
Value: 3
Remplacez Value par 4 et le problème ne sera plus résolu.
Voici une liste de toutes les valeurs de départ valides :
0 Boot (loaded by kernel loader). Components of the driver stack for the boot (startup) volume must be loaded by the kernel loader.
1 System (loaded by I/O subsystem). Specifies that the driver is loaded at kernel initialization.
2 Automatic (loaded by Service Control Manager). Specifies that the service is loaded or started automatically.
3 Manual. Specifies that the service does not start until the user starts it manually, such as by using Device Manager.
4 Disabled. Specifies that the service should not be started.
Une commande reg edit serait la suivante:
REG ADD "HKLM\SYSTEM\CurrentControlSet\Services\sermouse" /V Start /T REG_DWORD /F /D 4
Vous devez ensuite redémarrer l'ordinateur, qui doit maintenant démarrer correctement et ne pas tenter de détecter une souris série.
bonne chance.
Il s'avère que la détection de souris dans Windows est normalement gérée par le pilote de filtre serenum.sys. Ce pilote implémente la prise en charge des souris série héritées avec série plug-and-play . Microsoft a même fourni le code source sous forme d’exemple WDK .
Pendant la détection, les ports basculent en mode 1200-7-N-1 tout en affirmant DTR + RTS à laquelle une réponse est attendue dans les 200 ms, avec quelques tentatives en cas d'échec. Malheureusement, pour une souris héritée, un seul caractère M ou B suffit pour l'identification.
Dans notre cas, le protocole a été retravaillé pour éviter ces caractères et semble désormais ne plus être mal identifié.
Cependant, nous utilisions un port série USB virtuel et pour un port série traditionnel, cette approche peut s'avérer quelque peu difficile, car tout ce qui est envoyé avec un débit en bauds différent risque de ressembler à du bruit de ligne. Dans ce cas, je suppose que la solution la plus simple consiste probablement, comme cela a déjà été suggéré, à éviter toute transmission non sollicitée.
Alternativement, avec les signaux de commande série réellement connectés ou interceptés par un périphérique USB CDC, traiter les signaux DTR ou RTS et attendre la sortie. La mise en œuvre du protocole plug-and-play serait une option encore plus efficace. Soi-disant, il existe des câbles RS232 bon marché sans un complément complet de signaux de commande, mais cette approche peut encore échouer.
J'ai rencontré ce bug Windows moi-même. Voici mes propres recherches sur le sujet:
Microsoft reconnaît ce problème: http://support.Microsoft.com/kb/819036 Commencez par télécharger leur outil et voyez s'il résout le problème.
- Téléchargez et installez leur programme.
- Exécutez-le à partir de l'invite de commande de C:\program\Microsoft comdisable \
- Écrivez
comdisable /listlors de l'exécution du programme. - Tous les ports de l'ordinateur seront affichés.
- Écrivez
comdisable /disable COMxoù x est le numéro de port. - Faites cela pour tous les ports de l'ordinateur.
- Redémarrez.
Cela devrait, espérons-le, fonctionner comme une solution universelle.
Alternativement, vous pouvez pirater le fichier boot.ini mais je ne crois pas que cela fonctionne dans Vista/Win 7. J'ai une note d'application de systèmes Cisco décrivant la procédure à suivre. Si ce qui précède ne résout pas votre problème, veuillez me le faire savoir.
J'ai également rencontré ce problème, résolu en désactivant "l'énumérateur série" dans les propriétés avancées du pilote FTDI (propriétés des ports COM dans le Gestionnaire de périphériques). Ceci est décrit dans http://www.ftdichip.com/Support/Documents/AppNotes/AN_107_AdvancedDriverOptions_AN_000073.pdf .
Si vous avez un "vrai" port série ou une clé USB (RS-232, RS-485, peu importe), ce problème peut être contourné en ouvrant d'abord le port série en question avec un terminal ou une application quelconque. voulez le surveiller avec, et seulement ensuite, brancher le périphérique. Pour votre propre intérêt, vous devez également faire attention à retirer le périphérique avant de mettre fin à la connexion.
Avec les puces FTDI soudées sur le périphérique lui-même, vous êtes cassé. Il m'a fallu quelques tours pour expliquer à la direction qu'un périphérique communiquant avec lui-même couplé avec une puce FTDI soudée lors de la réunion PCB, les ordinateurs Windows ne satisferont probablement pas la convivialité, quelle que soit la précision de l'USB la prise peut ressembler au meuble ... (heureusement, toutes ces conditions sont assez rares et inhabituelles)
Cela aide peut-être: Nous avons eu le même problème avec FTDI FT232RL.Nous avons découvert qu’il s’agissait d’un problème matériel de notre carte de circuit imprimé.
FTDI-Datasheet dit à propos de # RESET-Pin: Broche de réinitialisation active basse. Ceci peut être utilisé par un périphérique externe pour réinitialiser le FT232R. Si ce n'est pas nécessaire, il peut être laissé non connecté ou remonté vers VCC.
RESET-Pin n’était pas nécessaire dans notre application, nous l’avons donc connectée à Vcc via 1k Pull-Up . deuxième convertisseur, nous avons connecté à une prise USB a provoqué un stylo-bille série dans le gestionnaire de devive. Nous avons retiré la résistance de soulèvement à # RESET-Pin, le # RESET-Pin n'étant donc pas connecté. Depuis lors, chaque interface a fonctionné de manière probante et ne créait plus de points de bille série dans le gestionnaire de périphériques Windows.
Dans mon environnement de développement, j'ai simplement désactivé Microsoft Serial Mouse à partir du Gestionnaire de périphériques.
Cela semble résoudre le coupable de mon problème. Auparavant, la puce CH340G que j'avais utilisée dans ma conception abaissait la DTR cinq fois avant d'établir la connexion, ce qui permettait de réinitialiser ma carte Arduino et de la rendre inutile.
J'ai eu ce problème depuis 2010 avec des têtes de balance série connectées au PC. Convertisseur série ou usb ou non .. J'utilise le périphérique CP2102 ou similaire du dispositif SILABS onkly. , NE LE DÉSINSTALLEZ PAS, désactivez-le simplement. Ensuite, lorsque vous redémarrez même avec le pilote installé, Windows semble ignorer le comportement de la souris série et utilise les données de l’entrée. Vous constaterez également que si le pilote de stylo à bille est actif, COMport est utilisé et renvoie parfois un port COM inaccessible ... espérons que cela aidera quelqu'un, :) Tx Ben