Дополнительные возможности ОС

Разработка BSP для новой модификации платы

Пакет поддержки платы (BSP) является общим названием для всего кода, специфического для оборудования платы. Он состоит обычно из следующих компонентов:

Процесс создания BSP включает следующие задачи:

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

Разработка начального загрузчика для нового устройства

Начальный загрузчик является утилитой, которая является неотъемлемой частью процесса разработки устройства OEM. Начальный загрузчик предназначен для размещения образа времени выполнения в памяти, и переходе затем к процедуре запуска ОС.

Последовательность начального запуска CE показана на рисунке 10.2 и имеет следующие операции:

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

Использование начального загрузчика во время процесса разработки пакета поддержки платы (BSP) экономит время. Можно быстро загрузить новый образ времени выполнения в целевое устройство, используя начальный загрузки, а не пересылку образа времени выполнения вручную на целевое устройство, используя программатор флэш-памяти или совместимый с IEEE 1149.1 порт тестового доступа и технологию периферийного сканирования.

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

Хотя каждый начальный загрузчик отличается выполняемыми задачами, и способом их выполнения, наиболее общий начальный загрузчик загружает образ времени выполнения через Ethernet в RAM на целевом устройстве. Несколько примеров имеется в документации ОС и примерах кода.

Модификация адаптации уровня OEM

Уровень адаптации (OAL) Производителя оригинального оборудования (OEM) операционной системы создается для изоляции и минимизации изменений операционной системы необходимых для переноса ОС на каждую новую аппаратную платформу. Как видно на рисунке 10.3, OAL содержит самый нижний уровень процедур, которые взаимодействуют непосредственно с оборудованием системы.

Ядро использует процедуры OAL для общения с оборудованием. Транспортный Уровень Интерфейса Ядра (Kernel Interface Transport Layer - KITL) используется системой разработки для коммуникации с целевым устройством. Уровень адаптации OEM (OAL) является уровнем кода, который логически располагается между ядром CE и оборудованием целевого устройства. Физически OAL соединяется с библиотеками ядра для создания исполняемого файла ядра.

Средства коммуникации OAL между операционной системой (ОС) и целевым устройством включают код для обработки прерываний, таймеров, управления питанием, абстрагирования шины, базового кода управлением В/В (IOCTL), и т.д.

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

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

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

Инфраструктура процессора и аппаратной платформы, предоставляемая OAL производственного качества, позволяет разработать минимальное базовое ядро CE, образ Tiny Kernel, за счет небольших усилий по разработке.

OAL производственного качества предоставляет следующие усовершенствования относительно предыдущей модели OAL:

В CE можно клонировать существующий BSP. Однако каталог BSP ..\WINCE600\Platform\<Название аппаратной платформы > содержит файлы минимального кода, и они являются в основном конфигурационными файлами. Большая часть файлов кода BSP находится в каталоге ..\WINCE600\ Platform\Common и не должна модифицироваться, если только реализация аппаратной платформы не отличается существенно от реализации CE. Мы теперь ссылаемся на программные компоненты, как на библиотеки.

Библиотеки OAL являются совокупностью функциональных, статических библиотек, которые можно собирать по модульному принципу для создания OAL или начального загрузчика. Отдельные библиотеки соответствуют множеству API, общему для всех архитектур ЦП. Аппаратная библиотека организована и реализована согласованным образом, в соответствии с аппаратной архитектурой, номером компонента, и функциональным уровнем, чтобы помочь определить уровень требуемой аппаратной поддержки, и для создания самодокументированной структуры каталогов.

OAL производственного качества позволяет использовать согласованное оборудование на семействе процессоров. Для выполнения этого аппаратная библиотека реализует базовые функции для OAL, которые взаимодействуют на уровне микросхемы. Операции на уровне платы, такие как маршрутизация IRQ или взаимодействия связующей логики, остаются в каталоге ..\WINCE600\Platform\<Hardware Platform Name>, но они упрощаются и абстрагируются на всех архитектурах, где возможно.

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

Рисунок 10.4 показывает, как OAL, начальный загрузчик, драйверы, и конфигурационные файлы образа времени выполнения взаимосвязаны с BSP и стандартной платой разработки (SDB) или аппаратной платформой.

Аппаратные инструменты отладки для встроенных систем

При первоначальном создании новой встроенной компьютерной платы, часто используются специальные внешние аппаратные инструменты отладки. Они включают такие устройства, как внутрисхемные эмуляторы (ICE), датчики in-target (ITP), и логические анализаторы специального назначения, соединенные с контактами отладки или трассировки оборудования, выходящими из процессора. На процессорах первого поколения можно было выполнить трассировку потока выполнения инструкций, используя логический анализатор, соединенный с шиной между процессором и памятью. Но более новые процессоры сильно конвейеризированы и содержат кэш инструкций, делая такой подход не слишком полезным для подробной отладочной информации. Некоторые небольшие системы на кристалле (SoC) микроконтроллеров используют только память на кристалле, поэтому в этом случае шина памяти процессора является внутренней для микросхемы.

Программные точки прерывания не будут работать на коде, выполняющемся из ROM (т.е., PC BIOS или ROM Bootloader), так как специальные инструкции call/jump, необходимые для реализации программных точек прерывания невозможно записать в ROM. В ответ на эти проблемы на многих процессорах были разработаны специальные процессорные контакты порта отладки/трассировки.

Для поддержки оборудования портов отладки/трассировки процессора обычно требуется один дополнительный контакт или гнездо процессора на встроенной компьютерной плате. Это может требовать некоторых начальных рассмотрений разработки PCB для поддержки отладки. На многих процессорах с картриджами с большим количеством выводов, такими как BGA, может быть невозможно получить доступ к нужным контактам, без этого специального отладочного контакта или гнезда.

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

Помните, что при первоначальной настройке новой платы, программные инструменты отладки не будут работать, пока не работают OAL, начальный BSP, и ОС. Поэтому эти аппаратные инструменты отладки являются очень полезными для начальных этапов отладки на новой плате.

К сожалению, модули ICE, модули ITD, или инструменты адаптера порта отладки процессора для логических анализаторов могут стоить несколько тысяч долларов, и для каждого нового типа процессора требуется новое устройство. Аппаратный инструмент отладки ARM показан на рисунке 10.5, а аппаратный инструмент отладки X86 показан на рисунке 10.6. Также только несколько LED на плате, соединенной с портом GPIO, могут быть очень удобны, чтобы получить представление о том, какой выполняется код, вставляя код для вывода на LED в критически важных точках.

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

Перенос нового образа ОС на eBox для автономной начальной загрузки

В окончательной версии встроенного устройства ОС и все встроенные приложения будут автоматически автономно загружаться, используя локальную копию кода. Этот код обычно хранится во флэш-памяти устройства. Чтобы загрузить новую ОС на eBox, используя локальную копию вместо загрузки каждый раз через сетевое соединение, используйте один из следующих методов:

Можно скопировать NK.BIN с флэш-устройства USB, флэш-карты CF, или используйте Target _remote tools _file viewer, если устройство соединено с VS 2005. Вариант экспорта удаленного файла является немного медленным, так как требует около 5 минут. Нужно будет перезагрузить eBox и выйти в DOS во время приглашения загрузки и исправить имя файла, удаляя дополнительные символы ~1, которые появятся в имени файла NK.BIN на внутреннем флэш-устройстве. После копирования нового NK.BIN, используйте вариант загрузки 1, чтобы загрузить новый локальный образ NK.BIN с внутреннего флэш-устройства.

Можно также при желании отредактировать начальное меню вариантов загрузки eBox, чтобы изменить разрешение вывода и даже исключить необходимость выбора варианта загрузки. Отредактируйте файлы DOS config.sys и autoexec.bat на внутреннем флэш-устройстве, чтобы сделать какие-то изменения. DOS в eBox содержит программу EDIT. LoadCEPC имеет несколько аргументов командной строки для задания начального разрешения дисплея и IP-адреса, который вы можете при желании изменить. Прочтите внимательно файлы config.sys и autoexec.bat.

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

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

В сборке выпуска для ОС, которая все еще не соединена с настольным ПК во время выполнения отладки, не забудьте снять флажок параметра сборки Enable KITL в окне свойств проекта. Если настольный компьютер не присоединен, то при активированном KITL будет делаться попытка коммуникации с настольным ПК. Она, в конечном счете, прервется, но процесс реально замедляет целевую систему. Подпроект Autolaunch будет полезен для автоматического запуска приложений во время начальной загрузки (см. Приложение А).

Инструменты для тестирования

В системе производственного качества будет требоваться обширное тестирование на финальной сборке ОС перед выпуском нового продукта. Windows Embedded CE 6.0 Test Kit (CETK) является инструментом, который можно использовать для тестирования драйверов устройств, которые были разработаны для операционной системы CE. Архитектура CETK показана на рисунке 10.7. CETK содержит совокупность тестов командной строки в графическом интерфейсе пользователя. Инструменты тестирования в CETK поддерживают процессоры (CPU) и аппаратные платформы, которые поддерживает CE.

CETK предоставляет несколько комплектов тестирования. Каждый из них содержит комбинацию тестов CETK. Некоторые тесты CETK присутствуют в нескольких комплектах тестов, а некоторые имеют различные командные строки в каждом комплекте тестирования. Комплект тестирования выполняет тесты определенной категории устройств на основе CE. Название комплекта тестирования указывает категорию целевых устройств, которые тестирует комплект, например, базовые устройства на основе CE, или Pocket PC и Smart-телефоны на основе Windows Mobile™.

Инструмент CETK состоит из показанного на рисунке 10.8 серверного приложения, которое выполняется на рабочей станции разработки, и клиентского программного обеспечения, которое выполняется на каждом целевом устройстве, которое соединяется с CETK. CETK использует тестовую программу Tux, процессор регистрации Kato, загрузчик драйверов устройств, и технологии расширения Tux для создания и выполнения вариантов тестов.

Инструмент Application Verifier, показанный на рисунке 10.9, оценивает стабильность приложения и распознает обычные ошибки программирования. Этот инструмент может обнаружить и указать утечки памяти, обрабатывать утечки (такие как критические разделы и DLL), и утечки в объектах интерфейса графических устройств (GDI). Этот инструмент может также распознавать некоторые формы повреждения кучи.

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

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

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

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

Инструмент CE Stress, показанный на рисунке 10.10, включает клиент/серверную оснастку и совокупность модулей тестирования. Оснастка выполняет модули тестирования в случайной последовательности в цикле в течение произвольного периода времени.

Модули тестирования выполняют функциональное тестирование. Каждый модуль тестирования выполняет ряд тестов на функциональной части операционной системы (ОС). Тесты могут включать простые вызовы интерфейса прикладного программирования (API) или могут моделировать более сложные сценарии.

Кодирование с учетом требований безопасности

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

Краткий список из 10 самых важных правил для кодирования программ C\C++ с учетом требований безопасности обычно включает следующее:

CE содержит версию инструмента статического анализа кода PREFast. Чтобы активировать инструмент анализа кода, выберите подпроект, сделайте щелчок правой кнопкой мыши, выберите свойства, и выберите вкладку C\C++. Найдите строку настроек code analysis и измените ее с настройки по умолчанию no на yes. После следующей операции сборки генерируется отчет с дополнительными предупреждениями. Инструмент анализа кода может выявить переполнение буферов, семантические проблемы в использовании HRESULT, потенциальные и реальные проблемы использования памяти, и неправильное использование операторов. Кроме того, он выявляет многие объекты, которые могут быть просто опечатками, но проявляются в коде как несовпадение форматов, неподходящее преобразование типов, и т.д.

CE включает также библиотеку времени выполнения C с улучшенной безопасностью и поддерживает использование безопасных строковых функций. Библиотека времени выполнения С (C Runtime Library - CRT) была расширена, чтобы включить безопасные версии функций, которые создают угрозы безопасности. Более старые, небезопасные версии этих функций теперь исключены, а их использование ведет к предупреждениям во время компиляции. Во многих случаях безопасные строковые функции позволяют безопасно выполнять строковые операции с расширенными множествами символов и с Unicode.

Лицензирование и проблемы интеллектуальной собственности для встроенных систем

При разработке реального продукта вопросы интеллектуальной собственности (ИС) и лицензирования необходимо разрешить на начальном этапе процесса проектирования. Юридические соглашения могут быть достаточно сложными и требовать значительного времени для выработки. Большинство поставщиков ОС запрашивают несколько тысяч долларов за инструменты разработки, и затем часто требуют лицензионные отчисления за каждое устройство. Несколько поставщиков ОС требуют существенную единовременную плату.

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

Текущая коммерческие отчисления за CE 6.0 составляет около US $1000 для инструментов разработки (включая Visual Studio) и от US $3 до US $16 за устройство. Стоимость варьируется в зависимости от уровня предоставляемого исходного кода и приложений, лицензированных для OEM.

Как показано на рисунке 10.11, существует специальный инструмент для определения типа лицензии по файлу ядра NK.BIN. В Platform Builder этот инструмент доступен через Tools _Platform Builder 6.0 Run-time License Assessment Tool. Этот инструмент будет полезен также для перечисления свойств, представленных в сгенерированном ранее файле ядра NK.BIN.

Дополнительная информация

Контрольные упражнения