Устройство неправильно определено как последовательная мышь

Question

Я работаю над устройством, которое связывается с ПК через (виртуальный) последовательный порт.Проблема в том, что данные, которые мы периодически отправляем, неправильно идентифицируются Windows как мышь мыши, после чего загружается драйвер «Microsoft Serial Ballpoint», и указатель мыши начинает прыгать по экрану и случайным образом щелкать по объектам.

Немного Googling показывает, что это старая и общеизвестная проблема с последовательными устройствами, где обычным обходным путем является небольшой взлом реестра, чтобы отключить нарушающий драйвер.Однако от наших пользователей этого требуют многие, и я бы предпочел, чтобы наше приложение не связывалось с реестром пользователей.Особенно, если это исправление зависит от версии Windows, и пользователь вполне может использовать мышь для шины.

Вместо этого я хотел бы избежать проблемы, изменив наш протокол, чтобы не отправлять какие-либо данные, которые могут получить насошибочно идентифицирован как мышь.Единственная проблема в том, что я не совсем уверен, какие шаблоны следует избегать.Судя по всему, протокол Microsoft Mouse состоит из пакетов из четырех байтов, в которых установлен старший бит MSB, а три последних ясны.

Достаточно ли будет посылать только 7-битный ASCII?Есть ли другие устройства, о которых мне нужно беспокоиться, если их обнаружат?

Answer 1

Я только что столкнулся с этой проблемой сам на Windows 7 Professional x64, и решение, которое мне помогло, - это зайти в реестр и отредактировать следующее значение:

Location: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\sermouse  
Key: Start  
Value: 3

Изменить Value на 4и это прекратит возникновение этой проблемы.

Вот список всех допустимых значений Start :

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.

---

Команда reg edit будет выглядеть следующим образом:

REG ADD "HKLM\SYSTEM\CurrentControlSet\Services\sermouse" /V Start /T REG_DWORD /F /D 4

Затем необходимо перезагрузить компьютер, который теперь должен запускаться правильно, а не пытаться обнаружить последовательную мышь.

удачи.

Answer 2

Оказывается, что обнаружение мыши в Windows обычно обрабатывается драйвером фильтра serenum.sys.Этот драйвер реализует поддержку устаревших последовательных мышей наряду с serial plug-and-play .Microsoft даже предоставила исходный код в качестве образца WDK .

. При обнаружении порты переключаются в режим 1200-7-N-1, утверждая DTR + RTS, на который ответожидается в течение 200 мс, с парой повторных попыток в случае сбоя.К сожалению, для устаревшей мыши для идентификации достаточно одного M или B символа.

В нашем случае протокол был переработан, чтобы избежать этих символов, и теперь, похоже, больше не ошибается.

Однако мы использовали виртуальный последовательный порт USB, и для традиционного последовательного порта этот подход может быть несколько сложным, поскольку все, что отправляется с другой скоростью передачи, может выглядеть как шум линии.В этом случае я полагаю, что самый простой обходной путь, как уже было предложено, возможно, состоит в том, чтобы избежать любых нежелательных передач.

В качестве альтернативы с последовательными управляющими сигналами, фактически подключенными или перехваченными устройством USB CDC, обрабатывающимDTR или RTS сигналы и удержание на выходе.На самом деле реализация протокола plug-and-play была бы еще более изящным вариантом.Предположительно, существуют дешевые кабели RS232 без полного набора управляющих сигналов, хотя такой подход все еще может потерпеть неудачу.

Answer 3

Я также столкнулся с этой проблемой, исправил ее, отключив «последовательный перечислитель» в дополнительных свойствах драйвера FTDI (свойства COM-портов в диспетчере устройств). Это описано в http://www.ftdichip.com/Support/Documents/AppNotes/AN_107_AdvancedDriverOptions_AN_000073.pdf.

Answer 4

Я сам столкнулся с этой ошибкой Windows. Вот мое собственное исследование по теме:

Microsoft признает эту ошибку: http://support.microsoft.com/kb/819036 Начните с загрузки их инструмента и посмотрите, решит ли он проблему.

• Скачайте и установите их программу.
• Запустите его из командной строки из C: \ program \ Microsoft comdisable \
• Запись comdisable /list при выполнении программы.
• Будут показаны все порты на компьютере.
• Запись comdisable /disable COMx, где x - номер порта.
• Сделайте это для всех портов на компьютере.
• Reboot.

Надеемся, это будет универсальное решение.

В качестве альтернативы, вы можете взломать boot.ini, но я не верю, что это работает в Vista / Win 7. У меня есть некоторые заметки о приложениях от Cisco, описывающие, как это сделать. Если вышеуказанное не решит вашу проблему, пожалуйста, дайте мне знать.

Answer 5

В моей среде разработки я просто отключил Microsoft Serial Mouse из диспетчера устройств.

Кажется, это решает проблему моей проблемы. Прежде чем сделать это, микросхема CH340G, которую я использовал в своей конструкции, использовалась для пятикратного понижения DTR до инициации соединения, для эффективной перезагрузки моей платы на базе Arduino и превращения ее в бесполезную.

Answer 6

У меня была эта проблема с 2010 года, когда к компьютеру подключены головки серийного масштаба. Преобразователь USB в последовательный или нет .. Я использую CP2102 устройства SILABS onkly или подобное. Я обошел его, просто разрешив драйверу установить, а затем в диспетчере устройств найдите драйвер шариковой ручки под мышью / HIDA и затем просто ОТКЛЮЧИТ драйвер , НЕ УДАЛЯЙТЕ, просто отключите его. Затем, когда вы перезагружаетесь даже с установленным драйвером, кажется, что Windows игнорирует компорт как последовательную мышь и использует данные из ввода. Вы также обнаружите, что если драйвер шариковой ручки активен, то этот COM-порт используется и иногда возвращает COM-порт, недоступный ... надеюсь, это поможет кому-то там :) Tx Ben

Answer 7

Если у вас есть «истинный» последовательный порт или USB-ключ (RS-232, RS-485, это не имеет значения), эту проблему можно обойти, сначала открыв соответствующий последовательный порт с помощью терминала, или с любым приложением, которое вы хотите контролировать, и только затем подключать устройство. Ради себя, вы также должны обратить внимание на удаление устройства перед разрывом соединения.

С FTDI-чипами, припаянными на самом устройстве, вы обанкротились. Мне потребовалось несколько раундов, чтобы объяснить руководству, что устройство, обменивающееся данными самостоятельно, в паре с микросхемой FTDI, припаянной на печатной плате, в сочетании с компьютерами Windows, скорее всего, не будет удобен для пользователей, независимо от того, как выглядит гладкий разъем USB. на шкафу ... (К счастью, все эти условия встречаются довольно редко и необычно)

Answer 8

Может быть, это поможет: У нас была такая же проблема с FTDI FT232RL. Мы обнаружили, что это была аппаратная проблема нашей печатной платы.

FTDI-Datasheet говорит о # RESET-Pin: Активный низкий сброс сброса. Это может использоваться внешним устройством для сброса FT232R. Если не требуется, его можно оставить не подключенным или поднять на VCC.

RESET-Pin не требовался в нашем приложении, поэтому мы подключили его к Vcc через 1k Pull-Up. Казалось, что подтягивание # RESET-Pin вызвало неопределенный запуск FT232RL, по крайней мере, каждый второй конвертер, который мы подключали к USB-разъему, вызвал последовательный шарик в диспетчере устройств. Мы удалили подтягивающий резистор на # RESET-Pin, при этом # RESET-Pin не подключен. С тех пор каждый интерфейс работал правильно и больше не создавал последовательные шарики в диспетчере устройств Windows.