Меню

Cdc abstract control model acm как установить

Cdc abstract control model acm как установить

Драйвера устройств обычно скрываются в менеджере устройств как только устройство отключится или подаст команду на скрытие (несмотря на то, что они по прежнему установлены в системе). Очень часто «одноименные» драйвера конфликтуют из-за несоответствия версий и пр.

Методика очистки списка не используемых устройств: (Уже многими опробовано и даёт хорошие результаты когда ничего уже не помогает «увидеть» работоспособное «устройство».
0. Отключите от компьютера все внешние USB-устройства.
1. Создайте переменную окружения с именем DEVMGR_SHOW_NONPRESENT_DEVICES со значением равным 1.
Для этого: 1.1. Щелкните правой кнопкой на значке «Мой компьютер» (My Computer) и выберите пункт «Свойства» (Properties).
1.2. В открывшемся диалоговом окне перейдите к вкладке «Дополнительно» (Advanced) и нажмите на кнопку «Переменные среды» (Environment Variables).
1.3. На расположенной в верхней части диалогового окна панели «Переменные среды» нажмите на кнопку «Создать» (New).
1.4. В поле «Имя переменной» наберите (лучше скопируйте отсюда) DEVMGR_SHOW_NONPRESENT_DEVICES, а в поле «Значение переменной» введите 1.
1.5. Два раза подряд нажмите на кнопку «OK».)

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

2. Вызовите менеджер/диспетчер устройств:
3. Щелкните правой кнопкой на значке «Мой компьютер» (My Computer), выберите пункт «Свойства» (Properties) и перейдите к вкладке «Оборудование» (Manage).
4. Нажмите на кнопку «Диспетчер устройств» (Device Manager), раскройте меню «Вид» (View) и выберите команду «Показать скрытые устройства» (Show Hidden Devices).

5.4 Раздел «Контроллеры универсальной последовательной шины USB»: Здесь можно удалить все СКРЫТЫЕ (серенькие) устройства: «Ваше устройство» Device USB Driver, Запоминающее устройство для USB, Неизвестное устройство и другие.
5.5 Перезагрузите компьютер.

6. После всех этих удалений попробуйте заново подключить «ваше устройство». Он должен обнаружиться как новое устройство и Windows установит к нему драйвера или вы их установите сами ( на некоторых устройствах нужно устанавливать драйвера без подключения по USB, т.е. подключать после установки драйвера).
6.1 Перезагрузите компьютер.
Обычно такая процедура устраняет все проблемы в конфликтных драйверах «вашего устройства».

7. спасибо за предоставленную информацию Alex_1959, :yes2:

Обычно решение проблемы, прямо или косвенно, отражено в шапке.

Источник

Cdc abstract control model acm как установить

Thesycon USB CDC/ACM драйвер предоставляет эмуляцию последовательного порта для операционных систем Windows (версий 8.1, 8, 7, Vista, XP), путем реализации протокола эмуляции последовательного канала связи поверх USB. Драйвер представляет Win32-совместимый COM-порт, и дополнительно некоторые уникальные возможности, такие как поддержка Plug&Play-совместимого процесса энумерации. Это позволяет избежать путаницы с нумерацией COM-портов и повышает удобство использования.

Драйвер работает с устройствами, которые совместимы со стандартом Communication Device Class (CDC), подкласс Abstract Control Model (ACM). Однако драйвер поддерживает 3 различные типа протоколов USB, подробнее описанные ниже.

[Поддерживаемые протоколы USB]

Сокращенный протокол CDC/ACM. Этот режим использует только интерфейс данных CDC (конечные точки bulk in + bulk out). Управляющий интерфейс (конечная точка interrupt in) не требуется. Устройство должно поддерживать запросы, специфические для класса CDC (CDC class-specific requests), чтобы оно все еще могло поддерживать настройку скорости передачи (baud rate settings) и обработку сигналов управления / состояния последовательного канала связи (serial control/status lines). Этот режим полезен, если количество доступных конечных точек ограничено имеющимися аппаратными возможностями.

Протокол Bulk-only. Устройство реализует только интерфейс данных (конечные точки bulk in + bulk out). Устройство не предоставляет дополнительного интерфейса управления, и ему не нужно реализовывать обработку каких бы то ни было запросов на конечной точке EP0. Поскольку режим bulk-передач предоставляет механизм управления потоком данных (flow control), то нет необходимости в поддержке сигналов управления / состояния последовательного канала связи (serial control/status lines). Достоинство протокола bulk-only в том, что усилия по реализации поддержки протокола USB урезаны до минимума.

[Функциональные возможности драйвера класса USB CDC/ACM]

Поддержка USB. Со стороны USB поддерживается полная функциональность. Драйвер оптимизирован на максимальную эффективность. Драйвер USBIO поддерживает USB 3.0, USB 2.0 и USB 1.1. Это подразумевает поддержку USB-режимов скоростей передачи low speed, full speed и high speed.

Читайте также:  Как установить на рабочий стол часы на redmi

Операционная система. Драйвер USBIO поддерживает все текущие системы Windows 32 bit и 64 bit.

Virtual COM Port. Драйвер предоставляет операционной системе виртуальный COM-порт, который совместим с API виртуального последовательного порта Win32 (serial port API). COM-порт может использоваться стандартными программами Windows, такими как HyperTerminal. Он может быть сконфигурирован либо как последовательный порт, либо как модемное устройство (используя драйвер unimodem). Имя COM-порта назначается автоматически.

Plug&Play. Поддерживаются оповещения по добавлению / удалению, и совместимая с Plug&Play энумерация и метод идентификации портов, который не основан на именах COM-портов.

Power Management. Драйвер поддерживает модель управления энергопотреблением Windows.

Статический COM-порт. Опционально виртуальный COM может поддерживать поведение статического COM-порта для поддержки старых приложений. Т. е. приложение может удерживать COM-порт открытым, даже когда соответствующее USB-устройство извлечено из системы, и продолжить обмен данными после того, как устройство подключено снова.

Прим. переводчика: ИМХО это самая важная функция, потому что стандартный драйвер USB CDC, встроенный в Windows, требует не только переподключения к открытому порту, но часто даже перезапуска программы.

Multiple USB Interfaces. Драйвер поддерживает 2 и большее количество COM-портов для многоинтерфейсных (Multi-Interface) устройств.

Несколько устройств USB. Одновременно драйвер может работать с несколькими устройствами USB.

Кастомизация. Драйвер класса USB CDC/ACM позволяет адаптации, специфические для вендора и продукта (VID и PID).

Сертификация WHQL. Драйвер удовлетворяет стандарту Windows Driver Model (WDM) и может быть сертифицирован организацией Windows Hardware Quality Labs (WHQL) для операционных систем Windows 8.1 (32 bit и 64 bit), Windows 8 (32 bit и 64 bit), Windows 7 (32 bit и 64 bit), Windows Vista (32 bit и 64 bit) и Windows XP (32 bit и 64 bit).

Стеки для встраиваемых устройств (Embedded USB Stacks). В дополнение к драйверу устройства Thesycon предоставляется Embedded USB Device Stack [3] (библиотека подпрограмм для устройства USB) и Embedded USB Host Stack [4] (библиотека подпрограмм для хоста USB), доступная для некоторых микроконтроллеров. Вместе с этими комплектами разработчика Thesycon предоставляет быструю и эффективную по цене поддержку разработки firmware и драйвера устройства для USB-устройств класса CDC/ACM.

В таблице перечислена поддержка различных версий операционных систем Windows.

Поддерживаемые операционные системы 32 бита 64 бита
Windows 8.1 ДА ДА
Windows 8 ДА ДА
Windows 7 ДА ДА
Windows Vista ДА ДА
Windows XP ДА ДА
Windows Embedded 8 Standard ДА ДА
Windows Embedded Standard 7 (WES7) ДА ДА
Windows Embedded Enterprise ДА ДА
Windows Embegged POSReady ДА
Windows Embedded Server ДА ДА
Windows XP Embedded ДА
Windows Server 2012 R2 ДА
Windows Server 2012 ДА
Windows Home Server 2011 ДА
Windows Server 2008 R2 ДА
Windows Server 2008 ДА ДА
Windows Server 2003 ДА ДА
Windows Home Server ДА

Thesycon также предоставляет драйверы класса ACM для Windows CE и Windows Mobile [5].

[Простая установка]

Используя Thesycon PnP Driver Installer, можно очень просто создать специальный помощник (setup wizard), который будет поддерживать установку драйвера, удаление и обновление драйвера самым комфортным и надежным способом. Дополнительную информацию по поводу PnP Driver Installer см по ссылке [2].

[Бесплатная демо-версия]

Чтобы получить free demo, нужно заполнить контактную форму на сайте thesycon.de [1]. Демо-версия имеет ограничение по времени использования, но в остальном поддерживается полный функционал. После того, как устройство подключено, драйвер может использоваться 4 часа, затем драйвер запретит сам себя, и компьютер должен быть перезагружен, чтобы demo можно было использовать снова. Пакет demo включает в себя сам драйвер и документацию.

[Идентификаторы производителя и продукта (USB Vendor ID, Product ID)]

Для каждой модели устройства USB требуется наличие официального идентификатора вендора (USB vendor ID, VID). Vendor ID должны быть уникальными, и они назначаются по специальному запросу организацией USB Implementers Forum (www.usb.org). При регистрации идентификаторов взимается плата.

Читайте также:  Как установить вай фай на ноутбуке если его нет

Компания Thesycon владеет USB vendor ID, и может предоставить подмножество своих идентификаторов продукта (product ID, PID) для производителей устройства USB. Для производителей, которые купили лицензию на программное обеспечение USB компании Thesycon, услуга на предоставление пары VID/PID будет предоставлена бесплатно.

Источник

Как мы преодолевали передачу данных по USB

С чего все началось

Итак, в нашем замечательном приборе Беркут-ММТ (на базе PXA320 и GNU/Linux) есть не менее замечательный модуль OTDR (на базе STM32 и NutOS), представляющий собой импульсный оптический рефлектометр. Эта связка работает следующим образом: пользователь нажимает на экране на различные элементы UI, в приборе происходит немножечко магии, и желания пользователя трансформируются в команды вида «duration 300», которые уходят в измерительный модуль. Конкретно эта команда выставляет длительность измерений в 300 секунд. Модуль к прибору подключен по USB, для передачи команд поверх USB поднят CDC-ACM.

Кратенько — CDC-ACM позволяет эмулировать последовательный порт через USB. Так что для верхнего уровня наш измерительный модуль в системе доступен как /dev/ttyACM0. CDC-ACM служит для передачи команд в модуль или чтения текущих настроек/состояния модуля. Для передачи самой рефлектограммы служил USB Bulk интерфейс, который все свое время посвящал только одному — передаче данных рефлектограммы из модуля в прибор, как бинарного потока данных. В какой-то момент мы заметили, что рефлектограмма приходит к нам не полностью. Так мы открыли для себя, что USB может терять данные.

Схематично это выглядело так:

b5-cardifaced — это демон, который принимает команды по D-Bus и отправляет их в карту через CDC-ACM интерфейс. Результат выполнения посылает обратно по D-BUS.

usbgather — небольшая программка, которая работает на базе libusb и занимается тем, что выгребает из модуля рефлектограмму через USB Bulk и выдает ее на stdout.

Костыли и велосипеды

Сели мы и подумали — нам нужно понимать вся ли рефлектограмма к нам пришла для возможности пропуска неполных рефлектограмм. Стали мы придумывать различные хитрые заголовки, контрольные суммы и тд. Потом поняли что изобретаем ТСР. И тогда было принято волевое решение вместо USB Bulk завести TCP/IP поверх CDC-EEM. Почему CDC-EEM? Потому что CDC-EEM позволяет наиболее просто использовать USB как транспорт для передачи сетевого трафика. На самом приборе поддержка CDC-ECM в ядре есть, а модулях мы используем NutOS в качестве операционной системы и поддержка CDC-EEM и TCP/IP стек в NutOS был.

Фикс длинною в жизнь 3 месяца

Казалось бы — ни что не предвещало беды. Подняли CDC-EEM, настроили IP адреса. Ping? Есть ping! Ура. Изменили механизм передачи данных с USB Bulk на передачу данных через TCP-сокет. Вот-вот должно было наступить счастье, но тут внезапно при тестировании сеть упала с криками в dmesg о своей непростой жизни, наших кривых руках и вставшей колом очереди на отправку для нашего сетевого интерфейса. Примерно так:

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

Корень зла

Все вышеперечисленное усугублялось сообщениями в dmesg о неизвестных link cmd. Добавили побольше дебага и узнали, что нам на USB host приходит ответ на echo request, который мы не посылали.

Когда ничего не работает — настает время читать документацию. Вот и мы раздобыли доку по CDC-EEM, да не откуда-нибудь, а прямо с usb.org. Оказывается первый EEM-пакет это не только кучка данных, но еще и EEM-заголовок, в котором содержится тип пакета (управление или данные) и длина данных. И да, у CDC-EEM есть свой echo request/echo response.

Но наше счастье было бы не полным, если бы не еще одна деталь — при приеме служебных пакетов модуль зависал. Наглухо. Вместе с CDC-ACM.

Читайте также:  Как по английскому будет установить

У нас в модуле USB было настроено так, что передача шла пакетами по 64 байта. Соответственно один Ethernet пакет бился на N пакетов по 64 и передавался через USB. Вот так:

После весьма продолжительного изучения ситуации мы пришли к выводу, что происходит вот что: мы теряем часть EEM-пакета (да, USB не гарантирует доставку). Но мы прочитали из заголовка длину и опираемся на нее. Соответственно мы из следующего пакета вычитываем N потерянных байт, а следующие данные воспринимаем как начало нового EEM-пакета и интерпретируем первые 2 байта как заголовок. А там может оказаться все что угодно. Вплоть до взведенного в 1 бита, который указывает что это служебный пакет. В совсем плохих случаях мы ловим такие данные, которые при интерпретации как EEM-заголовок дают нам Echo Response огромной длины. Гораздо большей, чем наша оперативная память. Так мы поняли что наша реализация usbnet в NutOS требует серьезных доработок.

Больше проверок хороших и разных

В процессе ковыряния usbnet в NutOS было выяснено, что текущий вариант вообще не готов к приему служебных пакетов. От слова совсем. Мы сделали новый вариант, который стал способен корректно обрабатывать служебные пакеты, а именно: мы смотрели тип пакета, ибо на echo по стандарту мы ответить обязаны; проверяли длину — если она больше MTU — то мы явно словили мусор. Еще нашли странность в функции, запускающей передачу данных по endpoint’у: мы проверяли — не занят ли сейчас нулевой endpoint, и если занят — просто выходили и все. Вызывающий эту функцию всегда считал что передача данных запущена, а часто получалось что нет. В итоге мы теряли данные, причем в обе стороны.

Были войны с ТСР-сокетом — иногда данные не передавались и мы не видели почему. Не знаю что руководило разработчиками NutOS, но множество функций, имеющих возвращаемый тип int в любой непонятной ситуации возвращали «-1». Некоторые из них записывали реальный код ошибки в информацию о сокете, некоторые нет. Так что пришлось позаниматься протаскиванием кодов возврата с самых низов, вроде функции отправки данных с сетевухи, до самых верхов — функций типа NutTcpDeviceWrite?(). После этого мы смогли видеть где случился затык.

Потом были всякие допиливания и донастройки таймаутов в сокете, добавки статических записей в ARP-таблицы на модуле и на самом приборе: в нашей сети всего 2 устройства: прибор и модуль, нет смысла в устаревании записей в ARP-таблице.

Итоги

В нашей карте теперь есть маленький ТСР сервер, который служит для передачи данных из карты в прибор. Перед началом измерений в карте запускается TCP сервер и карта начинает ждать входящих подключений. После того, как клиент подключится к ТСР серверу, карта начинает измерения и через TCP сервер отправляет результаты в прибор.

Теперь схематично работа прибора с модулем выглядит примерно так:

Действующие лица:
b5-cardifaced — тот же что и раньше — транслирует команды из D-Bus в карту и отсылает результат обратно в D-Bus;
nc — собственно netcat, читает данные рефлектограммы из сокета и отдает их на stdout для дальнейшей обработки.

После всех этих приключений у нас теперь сетевой рефлектометр. Сетевой, правда, не на все 100% — управление происходит через CDC-ACM, а сбор данных из модуля — по TCP/IP через CDC-EEM. У нас все равно есть небольшая потеря данных, но за счет использования TCP/IP на выходе мы всегда получаем полную рефлектограмму. Мы узнали много нового о USB в целом и CDC-EEM в частности и USB я стал любить чуть меньше, чем раньше.

Нагрузочный тест показал, наш модуль на базе STM32F103 может прокачать 220 килобайт данных в секунду по TCP/IP over CDC-EEM, при том что модуль в это время занимается полезной работой и USB у нас работает без использования DMA.

Источник