Пакет драйверов windows stmicroelectronics что это

Обновлено: 30.06.2024

Микроконтроллеры 1986ВЕ1Т, 1986ВЕ3Т, 1986ВЕ9х и 1901ВЦ1Т имеют контроллер USB-интерфейса, реализующий функции контроллера ведомого устройства (Device) и ведущего устройства (Host). В составе библиотеки SPL приведён пример для ведомого устройства (Device) под названием "VCOM_Echo", который позволяет использовать МК в качестве CDC USB устройства (Класс Коммуникационного Устройства), настроенного как виртуальный COM-порт. Чтобы ПК определял МК именно как устройство, подключенное по COM-порту, необходимо установить специальный драйвер. Ссылка на скачивание драйвера доступна в конце статьи.

В данной статье рассмотрена пошаговая установка драйвера Virtual COM порт в ОС Windows 7.

Установка драйвера

Для установки драйвера виртуального COM-порта необходимо иметь права администратора!

Загружаем в МК проект "VCOM_Echo" и подключаем отладочную плату к ПК с помощью кабеля USB A-B. На ПК открываем "Диспетчер устройств Windows", его можно найти в поиске меню "Пуск". Если драйвер не установлен, то после подключения МК по USB в диспетчере устройств появится "Неизвестное устройство". Открываем "свойства" нового устройства, как показано на рисунке 1.

Рисунок 1 - Диспетчер устройств Windows: неизвестное устройство Если МК определился в группе "Контроллеры USB" и отображается как "Unknown Device", вероятно был нарушен протокол обмена по USB, и проблему следует искать в ПО МК.

В открывшемся окне "Свойства. " выбираем пункт "Изменить параметры" (рисунок 2), при этом возможно потребуется ввести пароль администратора.

В новом окне выбираем пункт "Обновить драйвер", как показано на рисунке 3.

Здесь необходимо выбрать "поиск драйверов на компьютере" (рисунок 4).

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

Рисунок 5 - Окно "Обновление драйверов": выбор директории с драйвером

В процессе установки Windows может вывести предупреждение, в котором необходимо выбрать пункт "Всё равно установить этот драйвер", как показано на рисунке 6.

Рисунок 6 - Окно с предупреждением при установке драйвера

После установки драйвера в диспетчере устройств во вкладке "Порты(COM и LPT)" должно появиться новое устройство "Milandr USB RS-232 Emulation Driver" (рисунок 7).

Рисунок 7 - Диспетчер устройств Windows: новое COM-устройство

Если установить всё-таки не получается, то

Можно попробовать запустить операционную систему Windows в безопасном режиме или режиме с отключенной обязательной проверкой подписи драйверов.

Для Windows 7 при запуске компьютера необходимо быстро нажимать клавишу F8, после чего появится окно аналогично тому, что представлено на рисунке 8. После этого выбрать либо безопасный режим, либо режим с отключенной обязательной проверкой подписи драйверов и попробовать установить драйвер снова.

Рисунок 8 - Дополнительные варианты загрузки Windows 7

Для Windows 8 и 10 есть несколько способов перейти в аналогичное Windows 7 меню выбора режима загрузки, но самый простой заключается в том, чтобы нажать кнопку "Перезагрузка" вместе с зажатой кнопкой Shift прямо в меню "Пуск" (рисунок 9).

Рисунок 9 - Алгоритм попадания в первоначальный загрузчик Windows

После перезагрузки всплывёт полностью синий экран с различными вариантами загрузки операционной системы, необходимо перейти в меню "Поиск и устранение неисправностей" > "Дополнительный параметры" > "Параметры загрузки". После этого всплывёт окно с выбором режима загрузки операционной системы, как на рисунке 10.

Рисунок 10 - Меню выбора режимов загрузки Windows 8 (10)

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

Если при подключении платы Iskra JS или Iskra JS Mini к ПК в диспетчере устройств не появилось новых устройств, вероятней всего микроконтроллер управляющей платформы не прошит. Рассмотрим вариант прошивки для пользователей операционной системы Windows и MAC OS .

Для Windows

Подготовка софта

Скачайте и установите на компьютер программу для прошивки микроконтроллеров STM32.

Наеобходимо устанавливать программу прямо на диск C:/. Если в пути до этой программы будут кириллические символы или пробелы, то программа будет работать с ошибкой.

Переключите управляющую платформу в DFU-режим. Для этого необходимо соединить пин BOOT0 с пином 3V3 .

Не снимайте с платы Iskra JS джампер выбора питания, иначе на плату не поступит питание. Если у вас набор Йодо, возьмите временно джампер с платы Troyka Slot Shield

Подключите плату к компьютеру и посмотрите как определяется платформа:

Установка драйвера для STM32 в DFU-режиме

для 32-х битных систем: C:\Program Files\STMicroelectronics\Software\DfuSe

Всё получилось. Теперь можно продолжить «обновлять прошивку в DFU-режиме»

Обновление прошивки

Скачайте прошивку в зависимости от вашей управляющей платформы: Распакуйте ZIP-архив. Распаковывать его лучше всего в корень диска C. Если в пути до архива будут русские буквы или пробелы, то программа работать не будет.

Это значит всё получилось. Жмём «Quit», снимаем перемычку с BOOT0 и перезагружаем плату.

Далее запускайте Espruino Web IDE и попробуйте помигать светодиодом.

Для MAC OS

Подготовка софта

Переключите управляющую платформу в DFU-режим. Для этого необходимо соединить пин BOOT0 с пином 3V3 .

Скачайте менеджер пакетов «Homebrew». Для этого выполните команду: Далее установите утилиту dfu-util из менеджера пакетов «Homebrew». Для этого вбейте команду в терминал:

Запомните значения в квадратных скобках. В нашем случае это «[0483:df11]»

Сегодняшняя статья будет посвящена реализации виртуального COM-порта для микроконтроллеров STM32. Эта тема уже поднималась на нашем сайте (STM32 и USB), но в отличие от всех предыдущих экспериментов сегодня мы будем производить все настройки при помощи STM32CubeMx. Собственно, переходим к делу 🙂

Итак, начинаем с действий, ставших привычными! Создаем новый проект в STM32CubeMx, настраиваем его и выбираем микроконтроллер, для которого мы будем генерировать проект. Я буду использовать отладочную плату STM32F4-Discovery и, соответственно, контроллер STM32F407VG.

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

Первым делом включим поддержку USB в нашем проекте в STM32CubeMx. Во вкладке Pinout ищем пункт USB_OTG_FS:

Кроме того, задействуем внешний тактовый генератор (8 МГц), установленный на плате:

Видим, что Cube отметил все занятые выводы микроконтроллера:

Осталось выбрать режим работы USB для нашего устройства:

На этом первый этап настроек проекта закончен, переходим в окно настроек тактирования (вкладка Clock Configuration). Здесь нам надо настроить использование внешнего генератора (8 МГц), а также все необходимые предделители частоты для всех шин микроконтроллера. Поскольку этому уже была посвящена целая статья (вот она), сейчас останавливаться на этом мы не будем и перейдем дальше 🙂 Приведу только финальные настройки тактирования:

Двигаемся дальше и переходим на вкладку Configuration, где мы можем получить доступ к многочисленным настройкам непосредственно USB. Для начала заходим в настройки USB_FS, там нам нужно включить использование Vbus (вывод PA9 микроконтроллера):

Здесь мы больше ничего пока менять не будем. Переходим к настройкам USB_DEVICE. В открывшемся окне мы видим идентификаторы VID и PID, используемые устройством, а также достаточно большое количество разных параметров USB. Не буду перечислять их все, их и так видно в окне Cube. Менять мы тут ничего не будем, хотя давайте просто ради тестирования зададим в качестве PRODUCT_STRING какое-нибудь наше название:

В принципе на этом все, можно смело переходить к генерации проекта и исходного кода.

Если мы зайдем в свойства устройства, то можем увидеть там значения VID и PID, которые были установлены в настройках STM32CubeMx, а кроме того измененную нами строку PRODUCT_STRING:

Никаких сомнений в правильной работе сгенерированного проекта не остается 🙂 Но это только часть задачи, которую мы сами себе поставили. Нам нужно реализовать отправку данных. А необходимые для этого функции находятся в файле usbd_cdc_if.c:

Итак, давайте в основном цикле нашей программы будем раз в секунду отправлять 8 тестовых байт. Кстати для реализации временных задержек в HAL_Driver есть функция HAL_Delay(). В качестве аргумента мы должны передавать количество миллисекунд. В общем, получаем такой код:

Теперь остается только прошить контроллер, открыть терминал и убедиться, что данные принимаются верно. Так и поступим:

Все работает отлично, как и планировалось!

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

пакеты драйверов можно добавить в образ Windows до, во время или после развертывания образа. при планировании добавления пакетов драйверов в развертывание Windows важно понимать, как добавляются пакеты драйверов к образу, как ранжирование драйверов влияет на развертывание, а также требования к цифровой подписи для пакетов драйверов.

Добавление пакетов драйверов

пакеты драйверов можно добавить в образ Windows:

добавление пакетов драйверов перед развертыванием в автономном образе Windows с помощью DISM

автономное обслуживание происходит при изменении Windows образа полностью вне сети без загрузки операционной системы. вы можете добавлять, удалять и перечислять пакеты драйверов в автономном Windows образе с помощью программы командной строки DISM. DISM устанавливается с Windows и также распространяется в комплекте средств для развертывания и оценки Windows (Windows ADK). Дополнительные сведения о DISM см. в статье Технический справочник по обслуживанию образов развертывания и управления ими для Windows.

При добавлении пакета драйверов в образ в автономном режиме он помещается в промежуточный режим или отражается в образе:

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

Пакеты драйверов, которые не являются критическими для загрузки , являются промежуточными. Другими словами, они добавляются в хранилище драйверов. после запуска Windows PnP обнаруживает устройство и устанавливает соответствующий пакет драйверов из хранилища драйверов.

команды DISM можно использовать для добавления или удаления пакетов драйверов на подключенном или примененном Windows или среда предустановки Windows (Windows PE).

вы не можете использовать DISM для удаления пакетов драйверов папки "входящие" (пакеты драйверов, установленные на Windows по умолчанию), за исключением некоторых сетевых драйверов. Его можно использовать только для удаления пакетов драйверов сторонних производителей или поставщиков из списка.

если вы хотите добавить пакеты драйверов, критические для загрузки, в Windows PE, используйте этап настройки windowsPE , чтобы отразить пакеты драйверов перед загрузкой образа PE Windows. разница между добавлением пакетов драйверов, критических для загрузки, во время этапа настройки windowspe и добавлением их во время этапа настройки windowspe заключается в том, что во время этапа настройки для использования Windows PE будут отражены пакеты драйверов, критически важные для загрузки. во время этапа настройки offlineServicing пакеты драйверов помещаются в хранилище драйверов на Windowsном образе.

ниже перечислены методы добавления пакетов драйверов с помощью программа установки Windows.

дополнительные сведения об этих и других этапах настройки см. в разделе программа установки Windows конфигурации.

при использовании служб Windows deployment Services для развертывания в Windows server можно добавить пакеты драйверов на сервер и настроить их для развертывания на клиентах в рамках сетевой установки. Эта функция настраивается путем создания группы драйверов на сервере, добавления в нее пакетов, а затем добавления фильтров для определения того, какие клиенты будут устанавливать эти пакеты драйверов. можно настроить установку пакетов драйверов на основе оборудования клиента (например, производителя или поставщика BIOS) и выпуска образа Windows, выбранного во время установки. Можно также настроить, будут ли клиенты устанавливать все пакеты в группе драйверов или только пакеты драйверов, соответствующие установленному оборудованию на клиенте. дополнительные сведения о реализации этой функции см. в документации по службам развертывания Windows.

Ниже перечислены методы добавления пакетов драйверов в работающую операционную систему.

Использование средства PnPUtil для добавления или удаления пакетов драйверов PnP. Дополнительные сведения см. в статье Использование средства PnPUtil в командной строке для установки Самонастраивающийся устройства.

Пакеты драйверов для режима S

пакеты драйверов в режиме Windows S должны соответствовать определенным требованиям. ознакомьтесь с требованиями к драйверу Windows 10 s , чтобы узнать о типах пакетов драйверов, которые можно добавить в Windows в режиме S.

Управление папками драйверов

При добавлении нескольких пакетов драйверов следует создать отдельные папки в исходном расположении для каждого пакета драйверов или категории пакетов драйверов. Это гарантирует отсутствие конфликтов при добавлении пакетов драйверов с одинаковыми именами файлов. После установки пакета драйверов в операционной системе он переименовывается в * файл OEM. INF, чтобы гарантировать уникальность имен файлов в операционной системе. Например, промежуточные драйверы с именами MyDriver1. INF и MyDriver2. inf могут быть переименованы в oem0. INF и OEM1. INF после их установки.

Основные сведения о ранжировании драйверов

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

диспетчер Windows PnP ранжирует эти свойства пакета драйверов в порядке важности.

Сертификат для подписи маркера

Соответствие ИД PnP

Например, если пакет драйвера имеет более подходящий идентификатор PnP, но не подписан, приоритет имеет подписанный пакет драйверов с совместимым ИДЕНТИФИКАТОРом. Более старый пакет драйверов может использовать более новый пакет драйверов, если более старый пакет драйверов имеет более высокий приоритет, совпадающий с ИДЕНТИФИКАТОРом PnP или подписью.

дополнительные сведения о ранжировании пакетов драйверов см. в статье Windows ранжирования драйверов.

Основные сведения о требованиях к цифровой подписи

Подписанные пакеты драйверов являются ключевой функцией безопасности в Windows. Пакеты драйверов, установленные на компьютерах на базе процессоров x64, должны иметь цифровую подпись. Хотя это не обязательно, рекомендуется убедиться, что пакеты драйверов подписаны, прежде чем устанавливать их на компьютеры на базе x86.

Все двоичные файлы драйверов, критические для загрузки, должны содержать внедренные подписи. Например, в режиме ядра .sys файлы, критически важные для доступа к загрузочному диску.

Двоичный файл драйвера можно подписать двумя способами:

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

Пакеты драйверов PnP с цифровой подписью содержат файл каталога (CAT) с цифровой подписью. Файл каталога содержит хэш всех файлов в INF-файле пакета драйверов для установки. Подписанный файл каталога — это все, что необходимо для правильной установки большинства пакетов драйверов PnP.

Один из этих источников может подписывать пакеты драйверов:

Windows лаборатория по качеству оборудования (WHQL), которая гарантирует, что пакеты драйверов должны быть определены для программы сертификации Windows оборудования. WHQL создает каталог подписанных пакетов драйверов. Для двоичных файлов драйверов, критических для загрузки, следует добавить внедренные подписи вместо того, чтобы полагаться на каталог. Встроенные подписи в двоичных файлах драйверов, критических для загрузки, оптимизируют производительность загрузки операционной системы, устраняя необходимость в поиске соответствующего файла каталога, когда загрузчик операционной системы проверяет подпись драйвера.

Центр сертификации (ЦС) с помощью сертификата издателя программного обеспечения (SPC). Для двоичных файлов драйверов ядра, критически важных для загрузки и x64, корпорация Майкрософт предоставляет дополнительный сертификат, который можно использовать для перекрестной подписи двоичных файлов драйвера. Двоичные файлы драйверов, не являющиеся критическими для загрузки, не должны быть подписаны корпорацией Майкрософт или внедренными. вы можете использовать Windows процесс подписи кода в режиме ядра, если вам нужна гибкость для самостоятельного подписывания двоичных файлов драйвера. Сведения о цифровых подписях для модулей ядра в системах на базе x64 см. в руководстве по драйверам 64-разрядной версии.

Для тестирования можно также использовать тестовые сертификаты.

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

Ниже приведены основные способы создания таких сертификатов подписи тестирования.

Разработчики могут создавать собственные самозаверяющие сертификаты.

ЦС может выдавать сертификаты.

В обоих вариантах сертификаты подписи тестов должны быть четко идентифицированы в соответствии с проверкой. Например, слово «test» можно включать в имя субъекта сертификата, а в сертификат могут включаться дополнительные юридические заявления об отказе. Производственные сертификаты, выданные коммерческими центрами сертификации, должны быть зарезервированы только для подписывания общедоступных бета-версий и бесплатных окончательных выпусков программного обеспечения и внутреннего бизнес-программного обеспечения.

при добавлении пакетов драйверов, подписанных тестами, в Windows следует учитывать следующие моменты.

Необходимо установить тестовые сертификаты в работающей операционной системе. Их нельзя установить в автономном режиме.

Сертификат центра сертификации, выдавшего тестовый сертификат, должен быть вставлен в хранилище сертификатов доверенных корневых центров сертификации.

Примечание
Если тестовый сертификат является самозаверяющим, например с помощью средства создания сертификатов (MakeCert), то тестовый сертификат должен быть вставлен в хранилище сертификатов доверенных корневых центров сертификации.

Тестовый сертификат, используемый для подписи пакета драйверов, должен быть вставлен в хранилище сертификатов "Доверенные издатели".

необходимо добавить тестовые сертификаты в оперативный режим (в загруженный экземпляр образа Windows), прежде чем можно будет использовать программу командной строки для обслуживания образов развертывания и управления ими (DISM) для добавления пакетов драйверов, подписанных с помощью тестовой подписи, в автономный режим.

DISM проверяет сертификаты WHQL только для пакетов драйверов, критических для загрузки. Но параметр командной строки DISM может переопределить это поведение. Дополнительные сведения см. в разделе параметры Command-Line обслуживания драйвера DISM.

чтобы установить и проверить пакеты драйверов, подписанные с помощью тестовой подписи, в 64-разрядных операционных системах, задайте конфигурацию загрузки Windows в тестовом режиме с помощью средства BCDedit на конечном компьютере. Тестовый режим проверяет, что образ драйвера подписан, но для проверки пути сертификата не требуется, чтобы издатель был настроен в качестве доверенного корневого центра сертификации. Чтобы правильно обработать пакет драйвера в логике установки и ранжирования драйвера PnP, тестовый сертификат должен храниться в хранилище доверенных сертификатов образа операционной системы. Сведения о тестовом режиме во время разработки см. в разделе рекомендации по драйверам 64-bit.

[! Внимание! *] Если на компьютере с архитектурой x64 установлен неподписанный или недопустимый критически важный для загрузки пакет драйверов, компьютер не будет загружаться. Неподписанный или недопустимый критически важный для загрузки пакет драйверов приведет к ошибке. Необходимо удалить пакет драйверов из образа. При выполнении обновления убедитесь, что неподписанные пакеты драйверов и связанные с ними приложения, службы или устройства удалены или обновлены с подписанным пакетом драйверов.

Если вы не включите режим тестирования с помощью BCDedit, и у вас установлен пакет драйверов, подписанный тестом, компьютер не будет загружаться. При использовании DISM для удаления пакета драйверов все экземпляры отраженного пакета драйверов могут не быть удалены. Поэтому рекомендуется не развертывать образы с установленными пакетами драйверов, подписанными тестами.

Дополнительные ресурсы

Эти веб-сайты содержат дополнительные сведения о требованиях к пакету драйверов:

Дополнительные сведения о развертывании пакетов драйверов PnP см. в разделе требования к подписывания установки устройства PnP.

дополнительные сведения о цифровых подписях и разработке пакетов драйверов см. на соответствующей странице на центральном веб-сайте Windows Hardware для разработчиков .

Читайте также: