Как добавить драйвер в образ wince

Обновлено: 20.11.2024

Microsoft Windows CE — это модульная и масштабируемая операционная система, которая поддерживает различные устройства. В этой статье представлена модель драйверов устройств Windows CE, которая уникальна для всего семейства Windows.

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

Встроенные — это те устройства, которые интегрированы в платформу. Устройства, попадающие в эту категорию, включают дисплей, сенсорную панель, аудиосистему, последовательный порт, принтер, клавиатуру, светодиод, аккумулятор и гнездо для платы ПК. Разработка соответствующих драйверов происходит во время разработки самой платформы (производителем оборудования), и драйверы интегрируются в окончательный образ CE, который хранится в ПЗУ или флэш-памяти.

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

Модель водителя

Windows CE поддерживает четыре типа драйверов: собственный, потоковый интерфейс, USB и NDIS. Каждый тип описан в следующих параграфах. Важно отметить, что эта модель драйвера уникальна для CE; Драйверы Windows 9x/NT/2000 не поддерживаются. Кроме того, драйверы CE реализованы в виде статических библиотек (файлы .lib) или библиотек с динамической компоновкой (файлы .dll).

Родные драйверы

Windows CE предназначена для прямого использования встроенных устройств. Эти устройства управляются собственными драйверами, тесно связанными с основными компонентами Windows CE. Например, модуль подсистемы графики, окон и событий (GWES) вызывает определенные функции в драйвере устройства отображения для рендеринга изображений во время выполнения. Как и следовало ожидать, эти функции отличаются от тех, которые требуются в драйвере батареи. Следовательно, каждый родной драйвер должен соответствовать определенному четко определенному интерфейсу, называемому интерфейсом драйвера устройства (DDI). Эти интерфейсы объясняются более подробно позже. Достаточно сказать, что OEM-производители не могут изменить ни один из этих интерфейсов и что собственные драйверы должны полностью их поддерживать.

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

Драйверы потокового интерфейса

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

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

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

Чтобы их было легко идентифицировать, драйверы потокового интерфейса следуют уникальному соглашению об именах файлов, которое состоит из трехбуквенного префикса (например, CAM для камеры или BCR для считывателя штрих-кода), цифры, которая идентифицирует конкретное устройство, когда несколько доступны экземпляры и двоеточие. Допустимые имена: COM1:, COM2:, BCR1: и т. д. Трехбуквенный префикс может быть любой комбинацией прописных букв, но он должен быть уникальным для данной платформы. файловая система обращается к конкретному драйверу.

В отличие от собственных драйверов, все драйверы потокового интерфейса имеют общий интерфейс, состоящий из 10 функций или точек входа в каждом драйвере. Эти функции, описанные в Таблице 1, очень похожи на функции файлового API, которые используются приложениями. Для данного драйвера каждая функция должна начинаться с префикса драйвера, который показан как «xxx» в таблице 1.

Таблица 1 Интерфейс потока
Функция	Вызывается, когда
xxx_Init	Драйвер загружен
xxx_DeInit	Драйвер выгружен
xxx_PowerOn	Питание включено (восстановлено)
xxx_PowerOff	Питание выключено (режим ожидания)
xxx_Open	Приложение открывает драйвер
xxx_Close	Приложение закрывает драйвер
xxx_Read	Приложение считывает данные, зависящие от устройства
xxx_Write	Приложение записывает данные, зависящие от устройства
xxx_Seek	Приложение устанавливает маркер файла
xxx_IOControl	Приложение выдает команду, зависящую от драйвера

В листинге 1 приложение обращается к драйверу последовательного интерфейса (COM1:), открывая его с помощью CreateFile() , что приводит к вызову COM_Open() в драйвере последовательного порта. (CreateFile() сочетает в себе возможность создавать и открывать файлы. Вызов OpenFile() отсутствует.) Драйвер возвращает дескриптор, который затем используется с обычными файловыми функциями Win32, такими как WriteFile() и ReadFile() , соответственно обработанными. функциями драйвера COM_Write() и COM_Read(). Затем вызывается CloseHandle(), чтобы закрыть дескриптор. Затем вызывается COM_Close() драйвера для освобождения внутренних ресурсов.

Независимый поставщик оборудования может адаптировать эти функции к возможностям устройства. Например, в драйвере камеры функция xxx_Read() может возвращать данные полного изображения, тогда как функция xxx_Seek() может позиционировать маркер файла в начале определенного изображения. Функция xxx_IOControl() обычно используется для реализации операций, которые не подходят для других функций. Документация по драйверу становится крайне важной, поскольку позволяет разработчикам понять, как использовать драйвер при написании приложений, обращающихся к устройству.

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

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

Драйверы USB

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

Windows CE поддерживает только хост-сторону спецификации USB. Это означает, что любое USB-совместимое устройство может быть подключено к платформе CE, но CE-устройство не может работать как USB-устройство для другого компьютера. CE поддерживает полную спецификацию USB на стороне хоста, включая различные методы передачи данных: управление, изохронный, управляемый прерываниями и массовый.

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

Драйверы NDIS

Спецификация интерфейса сетевых драйверов (NDIS) связывает сетевые драйверы с:

Стеки протоколов (TCP/IP и IrDA)
Сетевые адаптеры (например, адаптер Ethernet)

В CE поддерживается только часть исходной спецификации, NDIS 4.0 для NT. В результате драйверы минипорта поддерживаются, а монолитные и полные драйверы — нет. К счастью, драйверы минипорта в значительной степени совместимы по исходному коду с драйверами для NT.

Microsoft предоставляет различные образцы драйверов NDIS и рекомендует портировать существующий драйвер NT, если он доступен, а не создавать его с нуля. Для разработки драйверов NDIS лучше всего обращаться к документации, содержащейся в наборе драйверов устройств Windows NT (DDK), поскольку в документации DDK для CE процесс написания драйверов мини-порта NDIS подробно не обсуждается.

Реализация драйвера устройства

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

Обработка прерываний

Прерывания обрабатываются в Windows CE особым образом, как показано на рис. 1. Обработчик событий ядра первым перехватывает возбужденное прерывание. Прерывание, а также прерывания с более низким приоритетом отключены, но все другие прерывания с более высоким приоритетом остаются разрешенными (при условии, что базовая архитектура поддерживает вложенные прерывания на основе их приоритетов). Затем вызывается соответствующая процедура обслуживания прерываний (ISR).

ISR находится на уровне адаптации OEM (OAL) — наборе низкоуровневых функций, написанных OEM-производителями, которые находятся между ядром и оборудованием (а не в каком-либо драйвере). Единственной целью ISR является возврат логического идентификатора обработчику службы прерываний (ISH) в ядре, но он может реализовать больше функций, если производительность является проблемой. Поскольку Windows CE 3.0 поддерживает вложенные прерывания, ISR могут быть прерваны и должны быть соответствующим образом закодированы. Например, ISR, которые реализуют критический код, который не может быть вытеснен, должны временно отключать все прерывания. Однако это следует делать только для выполнения нескольких инструкций, поскольку отключение прерываний с более высоким приоритетом может помешать работе системы в реальном времени (подробнее об этом позже).

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

Подпрограммы обслуживания прерываний (ISR) устанавливаются в OEMInit(). Разработчики могут назначить один обработчик для каждого прерывания или один обработчик для нескольких прерываний. В листинге 2 показаны части обработки прерываний последовательной связи на платформе x86. В этом примере линии запроса на прерывание (IRQ) сопоставляются с логическими идентификаторами через таблицу с именем MapIntr2Sysintr[] . При вызове ISR он получает номер IRQ и возвращает соответствующий логический идентификатор. Код адаптирован из образцов CEPC OAL Platform Builder 3.0. В листинге 3 показаны части IST драйвера последовательной связи для платформы x86. Код адаптирован из образцов Platform Builder 3.0 CEPC. При инициализации (COM_Init()) объект события (pSerialHead->hSerialEvent) связывается с логическим идентификатором (тот же, что используется ISR в листинге 2), и запускается IST (IST()). Этот поток ожидает установки объекта события ядром (когда ISR возвращает соответствующий идентификатор прерывания), а затем обрабатывает прерывание. Как только прерывание обработано, поток вызывает Interrupt-Done(), чтобы сообщить ядру о завершении обработки прерывания.

Архитектура драйвера

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

Многоуровневый драйвер основан на фрагменте кода, который можно повторно использовать на разных платформах для упрощения и сокращения времени разработки. Этот код, предоставленный Microsoft, называется драйвером модульного устройства (MDD) и реализует основные функции драйвера. Он не обращается к оборудованию напрямую, а полагается на другой фрагмент кода, который зависит от оборудования и называется драйвером, зависящим от платформы (PDD). При переносе многоуровневого драйвера с одной платформы на другую необходимо переписывать только PDD, а не весь драйвер. Между MDD и PDD существует интерфейс (в зависимости от драйвера). Он называется интерфейсом поставщика услуг драйверов устройств (DDSPI). Этот интерфейс определяет функции в PDD, которые вызываются MDD во время выполнения.

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

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

Большинство драйверов для встроенных устройств имеют многоуровневую архитектуру, поскольку корпорация Майкрософт предоставляет для них многоуровневые образцы. Тем не менее OEM-производитель может повторно внедрить эти драйверы, чтобы они лучше подходили для его устройств. Например, OEM может изменить MDD, а также DDSPI, если это имеет смысл. Единственным недостатком является то, что модифицированный MDD может быть не таким переносимым, как исходный (конечно, это может не быть проблемой), и могут потребоваться изменения в PDD.

Microsoft предоставляет средство разработки драйверов под названием Platform Builder. Фактически, Platform Builder позволяет создавать, загружать и отлаживать полные образы Windows CE (включая драйверы устройств) для различных процессоров. Он объединяет редактор, кросс-компиляторы для всех поддерживаемых процессоров, компоновщик, встроенный отладчик, загрузчик изображений и набор дополнительных инструментов.

Новым в Platform Builder версии 3.0 является добавление возможностей отладки оборудования, которые позволяют обходить загрузчики во время разработки (позволяя выполнить этап разработки драйвера устройства раньше) и отлаживать код инициализации системы и ISR в OAL.

Platform Builder предоставляет множество образцов драйверов (некоторые для каждого из четырех типов драйверов), предназначенных как для ПК, так и для универсальных платформ, соответственно называемых CEPC и ODO. Он также включает в себя набор для тестирования драйверов устройств (DDTK) для расширенного тестирования собственных драйверов.

Соображения в реальном времени

Windows CE v. 3.0 претерпела значительные изменения, чтобы стать системой реального времени. Драйверы устройств не защищены от этих изменений и могут фактически снизить производительность в реальном времени, если они не реализованы должным образом.

Как упоминалось ранее, вложенные прерывания поддерживаются на основе их приоритетов. Обратите внимание, что некоторые архитектуры не поддерживают вложенные прерывания по своим приоритетам (x86 является одним из них), поэтому эта концепция не всегда применима. Если это так, ISR должны быть написаны соответствующим образом. Например, критические секции могут потребовать отключения всех прерываний. Это еще более верно, если для соображений производительности прерывание обрабатывается непосредственно в ISR, а не в IST. В таком случае отключение прерываний напрямую влияет на задержку системных прерываний и может ухудшить общую производительность системы, если она не будет тщательно настроена. быть приемлемым в некоторых случаях. В версии 3.0 у водителей есть до 256 приоритетов на выбор, чтобы обеспечить своевременную работу.

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

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

Нет никаких сомнений в том, что разработка драйверов для Windows CE 3.0 намного проще, чем для предыдущих версий, благодаря усовершенствованным инструментам разработки и многочисленным доступным примерам реализации драйверов. И все большее число OEM-производителей предоставляют драйверы Windows CE 3.0 для своих устройств.

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

Жан-Луи Гаро (BSCS, MSEE) — технический директор компании Annasoft Systems.С 1997 года он занимается разработкой устройств Windows CE, от адаптации платформы до разработки приложений. Он также является автором книги Windows CE с нуля (Annabooks, 1999). Свяжитесь с ним по .

Окончание срока службы Windows CE стало серьезной проблемой для пользователей этой операционной системы с тех пор, как Microsoft объявила о ее прекращении. В этой статье мы собираемся пролить свет на эту тему, объяснив, что это на самом деле означает и какие последствия это может иметь для вас, если ваш продукт все еще работает на WinCE. В связи с широким использованием этой ОС в медицинских устройствах, хотелось бы более конкретно поговорить об окончании срока службы Windows CE как части медицинского программного обеспечения. Вы получите краткий обзор вариантов миграции и контрольный список шагов, которые необходимо предпринять для успешного перехода с этого устаревшего программного обеспечения.

Что такое Windows CE?

Возможно, вы знакомы с Windows CE, если когда-либо имели дело с портативным устройством или встроенной системой. WinCE является лидером среди портативных устройств уже более двадцати лет.

Первая версия этой операционной системы, выпущенная Microsoft в 1996 году, была предшественницей мобильной ОС. Он был предназначен для небольших, легких устройств с небольшим объемом памяти и монохромным экраном с разрешением 480*240 пикселей. Подобно Windows 95, CE была специально разработана для встраиваемых систем.

Изначально Windows CE была операционной системой общего назначения. Но очень скоро выяснилось, что множество устройств, потенциально способных работать с WinCE, имеют большой спрос на обработку в реальном времени. Таким образом, следующая версия, то есть Windows CE версии 2.0, уже содержала в своем ядре планировщик реального времени.

Со временем Microsoft выпустила новые версии, добавив дополнительные функции и изменив название ОС на Windows Embedded CE и, наконец, на Windows Embedded Compact. С расширением функциональности и сферы применения Windows CE нашла применение в автомобильной промышленности, телекоммуникациях, бытовой электронике, промышленных решениях и здравоохранении.

История версий Windows CE

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

Последняя версия WinCE — Windows Embedded Compact 2013 представляет собой 32-разрядную многозадачную многопоточную операционную систему реального времени, которая предлагает своим пользователям ряд возможностей по разумной цене. Он предоставляет широкий спектр платформ и достаточное количество компонентов для создания собственных образов ОС с необходимой аппаратной функциональностью.

Windows CE для медицинских устройств

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

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

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

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

Windows CE — хороший выбор, если подключение к сети Wi-Fi является важной функцией вашего медицинского устройства. CE поддерживает WPA и WPA2, что делает соединения Wi-Fi безопасными. С помощью CE вы можете настроить приемопередатчик Wi-Fi в соответствии с потребностями вашего устройства, кроме того, имеется хороший выбор драйверов для различных приемопередатчиков Wi-Fi.

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

Что случилось с Windows CE?

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

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

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

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

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

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

GuruCE предлагает глубокие технические знания об операционных системах Windows Embedded. Консультанты GuruCE являются одними из лучших в области разработки, обучения и консультирования для Windows Embedded BSP и драйверов. Они помогают клиентам преодолеть крутую кривую обучения и значительно сократить время выхода их продуктов на рынок. Четко определенные процедуры разработки гарантируют полностью протестированный и работающий продукт в рамках запланированных затрат и времени.

Добро пожаловать!

Добро пожаловать на сайт GuruCE — экспертов по встраиваемым технологиям!

GuruCE предлагает услуги по обучению, консультированию и разработке для Microsoft Windows CE/Embedded Compact и Microsoft Windows 10 IoT Core. У нас есть большой опыт работы с ARM (iMX, PXA, TI и т. д.), MIPS (AU1x00 и т. д.) и x86. Для этих архитектур мы реализовали драйверы для USB, аудио, видео, сети, PCI, DSP, FPGA, файловых систем и т. д.

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

Если у вас есть какие-либо вопросы, не стесняйтесь обращаться к нам!

GuruCE iMX6 BSP версии 2391

После многих недель тщательного тестирования GuruCE iMX6 BSP версии 2391 готов! В этом выпуске добавлено несколько замечательных новых функций, таких как High Assurance Boot и 100%-ный переход без мерцания от заставки загрузчика к рабочему столу CE или вашему приложению, новые драйверы для дисплеев, сенсорных контроллеров и RTC, а также множество улучшений и исправлений кода.

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

Картинка стоит миллиона слов, так что представьте, на что способно видео.

Для этого выпуска мы создали видео, показывающее, как легко работать с нашим BSP и сколько функций уже включено в него "из коробки":

Содержание видео

00:18 - SetWINCERoot
00:52 - Установка BSP
01:12 - Структура BSP
02:10 - Дизайн ОС Сборка конфигураций
03:30 - Каталог BSP
06:30 — Изменить плату и выбрать каталог.
07:58 – Заголовочный файл для конкретной платы.
09:28 – Уменьшение размера образа ядра.
11:27 – Каталог для конкретного процессора. items
11:48 — Настройка реестра на основе куста и TexFAT
12:05 — Включение и настройка High Assurance Boot
12:20 — Генерация сертификатов и ключей HAB
14:15 - Создание дизайна ОС для создания загрузчика и образов ядра с подписью HAB
14:32 - Создание загрузчика для NXP Manufacturing Tool
15:00 - Настройка NXP Manufacturing Tool
16:25 - Перепрошивка загрузчика на SPI NOR Flash с помощью Visual Studio
16:57 - Остановка служб подключения устройств Windows Mobile для обеспечения загрузки и отладки через последовательный порт USB
17:30 - Использование CEWriter для прошивки загрузчика, ядра и заставок на SD-карту
18:5 8 - Настройка загрузчика
19:13 ---- Настройка основного дисплея
19:23 ---- Настройка дополнительного дисплея
19:29 ---- Настройка дублирование основного дисплея на дополнительный дисплей
19:35 ---- Настройка Ethernet
19:48 - Проверка HAB и прожигание предохранителей
21:31 - Загрузка рабочего стола CE на Плата Nitrogen6X
22:08 - Pocket CMD через UART (CLI, интерфейс командной строки)
22:15 - Включенные утилиты
23:18 - CE Remote Desktop
23:52 - Переключение между WEC7 и WEC2013
24:28 — Tiny OS Design (маленькая безголовая конфигурация)
24 :45 – ШАБЛОН драйвера качества продукции, SDK и код приложения
25 :50 – Настройка загрузчика для загрузка и отладка KITL через USB Serial
26:56 – Установка точек останова в исходном коде драйвера
27:12 – Подготовка Visual Studio к отладке и разработке драйвера
27:48 – Проверка переменных во время выполнения
28:18 - Выгрузка, модификация, пересборка и загрузка драйверов во время выполнения e, без пересборки и скачивания всего образа ядра

Наше обещание

Мы продолжим улучшать наш iMX6 BSP, добавлять новые функции и будем поддерживать наших клиентов в течение многих лет, по крайней мере, до даты окончания расширенной поддержки Microsoft 10 октября 2023 г.

Несмотря на то, что GuruCE i.MX6 BSP уже является наиболее производительным, 100% стабильным OAL и наиболее многофункциональным i.MX6 BSP на рынке сегодня, всегда есть что улучшить или исправить, а также реализовать новые функции.< /p>

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

Эти указания по применению помогут вам выполнить шаги, необходимые для создания собственного образа Windows Embedded CE 6. Эта статья относится к BSP для Trizeps VI.

Подготовка

Прежде всего вам необходимо установить Microsoft Platform Builder для Windows Embedded CE 6.0:

Если во время установки вас спросят, для каких платформ, вы должны выбрать ARMV4I и XScale. Если у вас уже есть установка, вы можете добавить эти платформы, запустив программу установки Platform-Builder. Перед использованием последней версии Trizeps-BSP обновите Platform-Builder с помощью загрузки Windows Embedded CE.
Установите BSP Keith&Koep для Trizeps VI.

Создание нового проекта

Выберите пакеты поддержки плат, с которыми вы хотите использовать этот проект; то есть вы можете добавить TR4CONXS, чтобы добавить поддержку Trizeps4-BSP. Поскольку в этом примере используется Trizeps6, выберите TR6CONXS.

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

Изменить проект

После того как мастер проектирования ОС создаст новое рабочее пространство, вы можете внести в него некоторые изменения. NEWCOL Слева вы видите представление элементов каталога. Если это окно не отображается, используйте Вид –> Другие окна –> Представление элементов каталога, чтобы добавить его. Это представление покажет, какие элементы каталога включены в ваш образ Windows Embedded CE.

Чтобы добавить элемент, установите флажок. Давайте добавим несколько драйверов:

Теперь выберите тип образа, который вы хотите построить:
Тип: nk.nb0 (RAM): Создайте образ, который не сохраняется во флэш-память. Это весьма полезно, если вы хотите напрямую загрузить образ через Platform-Builder в оперативную память и начать отладку. Его также можно использовать для запуска образов с SD-карты. Эта конфигурация использует реестр на основе ОЗУ и сравнима с режимом, использовавшимся в более ранних продуктах Trizeps.
Тип: xip.bin (ROM, BinFS): Создайте образ, который хранится на отдельном flash-разделе. Он использует реестр на основе Hive, а флэш-диск монтируется как корневая файловая система. Это приводит к тому, что все изменения остаются постоянными (как в настольных операционных системах). Примечание. При использовании этой конфигурации вы должны установить: Project→ ProjectName Properties..→ Configuration Properties→ General→ Target name for debugger: xip.bin . Обязательно измените это для обеих конфигураций сборки: TR6CONXS ARMV4I Debug и TR6CONXS ARMV4I Release.

После добавления драйверов можно заметить, что на Trizeps SDMMC стоят два креста. Если вы хотите узнать, почему они были исключены, щелкните элемент правой кнопкой мыши и выберите «Причины исключения элемента».
В этом случае вам нужно только добавить SD-карту.

Если вы хотите использовать ActiveSync, вы должны включить USB Function Clients –> последовательный компонент.
Вы также можете добавить драйвер класса USB Storage Class, чтобы можно было подключать USB-накопители.

Создать проект

Если вы считаете, что закончили со своими изменениями, вызовите Build -> Build Solution .

Через несколько минут сборка должна завершиться следующим образом:

Если вы выбрали Тип: nk.nb0 (ОЗУ), используйте nk.nb0;
Если вы выбрали Тип: xip.bin (ROM,BinFS), используйте xip.bin;
для загрузки.

Загрузить в Trizeps VI

После того, как вы создали образ, вы можете приступить к его загрузке в свой Trizeps-модуль. Взгляните на документацию загрузчика для получения дополнительной информации о том, как это сделать. Все используемые здесь команды также можно поместить в autoboot.bat на SD-карту.

nk.nb0 (ОЗУ)

Запуск с SD-карты:

Первая строка загрузки nanddisk запустит скрипт, который обычно инициализирует ваш дисплей.
boot mmc nk.nb0 загружает образ в оперативную память и запускает его.
Возможно, вы захотите вызвать epsm, чтобы стереть содержимое flashdisk.

Загрузить через Platform-Builder:

Подробнее см. в разделе Использование Eboot.

xip.bin (ROM, BinFS)

Запуск с SD-карты:

Первая строка загрузки nanddisk запустит скрипт, который обычно инициализирует ваш дисплей.
boot mmc xip.nb0 сохраняет образ для прошивки.
ereg запускается с чистым реестром при следующей загрузке.
fb запустит сохраненное изображение.
Возможно, вы захотите вызвать epsm, чтобы стереть содержимое flashdisk.

Скачать

Файлы cookie helfen bei der Bereitstellung von Inhalten. Durch die Nutzung dieser Seiten erklären Sie sich damit einverstanden, dass Cookies auf Ihrem Rechner gespeichert werden. OK Больше информации

Seiten-Werkzeuge

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