Архитектура встраиваемой ОС реального времени – CE 6.0

Приложения пользователя

Верхний уровень на рисунке 6.2 состоит из выполняющихся на устройстве приложений пользователя. Приложения пользователя обычно разрабатываются на C/C++ или C#. Windows CE поддерживает подмножество системных вызовов API Win32 настольной системы Windows. Это означает, что разработанные для CE приложения можно перекомпилировать для выполнения на настольной Windows, но обратное будет неверно. CE поддерживает пару тысяч вызовов API, а самая последняя настольная ОС имеет около двадцати тысяч. Вызовы API добавляются только по мере необходимости, чтобы разработать небольшое, но достаточное подмножество Win32 API. Это помогло сократить размер ядра CE. Стандартный GUI и интерфейс пользователя имеют внешний вид, похожий на настольную ОС Windows.

В дополнение к Win32 система CE предоставляет поддержку для нескольких интерфейсов программирования Microsoft, включая COM, ActiveX, MFC, и ATL. Объектная модель компонентов (COM) компании Microsoft предлагает стандарт создания компонентов, которые можно повторно использовать и объединять в более крупные системы. COM определяет двоичные объекты, которые можно запрашивать во время выполнения. Модель COM является независимой от языка. Элемент управления ActiveX является специальным типом объекта COM, используемым для расширяемых элементов управления. Элемент управления ActiveX обычно предоставляет интерфейс пользователя и предоставляет свойства, методы, и события.

Microsoft Foundation Classes (MFC) является библиотекой классов для разработки приложений Windows на C++. Она имеет в основном такие же функциональные возможности, как и Win32 API, но в инфраструктуре объектно-ориентированного приложения. Active Template Library (ATL) является библиотекой шаблонов C++, созданной для разработки элементов управления ActiveX и других компонентов COM.

Можно разрабатывать приложения, которые выполняются на устройстве на основе CE вместе с разработкой ядерной ОС в качестве подпроекта, или приложения можно разрабатывать на основе импортированного Пакета разработки программного обеспечения (SDK). Разработчики приложений, использующие SDK, могут работать на уровне интерфейса прикладного программирования (API) и не должны понимать низкоуровневые детали ОС и разработки драйверов для нового устройства. В любом случае приложения разрабатываются с помощью Visual Studio 2005 IDE. Разработка приложений и примеры кода будут рассмотрены подробнее в главе 8.

Все приложения на основе CE состоят из процесса и одного или нескольких потоков:

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

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

Библиотека codedll.dll автоматически связывается с каждым приложением для предоставления поддержки для базовых API. Некоторым API будет требоваться соединение приложения с дополнительными библиотеками DLL. Проверьте оперативную справочную информацию о конкретном API, чтобы узнать, не требуются ли дополнительные DLL.

.NET Compact Framework обеспечивает поддержку для выполняющихся в CE приложений C# и Visual Basic.

Вызовы системного API

Прикладные программы используют вызовы системного API для использования служб и средств ОС. Системный вызов является функцией, которая располагается в другом процессе, и о которой уведомляет NK.exe. Ядро затем вызывает подходящий серверный процесс для обработки системного вызова.

Как видно на рисунке 6.3, когда приложение CE 6.0 делает системный вызов API

Затем ядро CE

Наконец, требуемая служба

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

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

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

Ядро

Ядро, которое представлено модулем NK.exe (New Kernel), является основой операционной системы CE (ОС). Ядро предоставляет базовые функции ОС для любого устройства на основе CE. Эти функции включают управление процессами, потоками, и памятью. Ядро также предоставляет некоторые функции управления файлами. Службы ядра позволяют приложениям использовать эти базовые функции. Рисунок 6.4 показывает общую структуру, выделяя ядро в качестве канала для остальной части базовой ОС.

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

Ядро CE использует страничную систему виртуальной памяти для управления и распределения памяти программ. Система виртуальной памяти предоставляет непрерывные блоки памяти страницами по 4096 байтов в областях по 64 Кбайтов, так чтобы приложениям не нужно было управлять реальным распределением памяти. Для требований памяти менее 64 Кбайтов приложение может использовать локальную кучу, предоставляемую всем приложениям CE, и создавать отдельные кучи. Ядро также распределяет память в стеке для каждого нового процесса или потока. Используйте функции памяти из ядра для распределения и освобождения виртуальной памяти, использования памяти в локальной куче, создания отдельных куч, и распределения памяти из стека. Код программы может использовать неиспользуемую память из статического блока данных, который выделяется для загрузки приложения. Процессы также могут использовать отображенные в память объекты для общего доступа к данным.

Архитектура памяти

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

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

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

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

В CE, когда инициализируется процесс, ОС отображает следующие DLL и компоненты памяти:

Библиотеки DLL и разделы чтения/записи ROM DLL загружаются, начиная с вершины адресного пространства. Библиотеки DLL управляются загрузчиком, который загружает все DLL по одному и тому же адресу для каждого процесса. Стек, куча, и исполняемый файл (.exe) создаются и отображаются с нижней части адресного пространства. Нижние 64 Кбайта памяти всегда остаются свободными.

Для CE 6.0 процесс ядра располагается в верхних 2 Гбайтах из 4 Гбайтов (32 бит) виртуального пространства памяти, а нижние 2 Гбайта являются уникальными для каждого процесса. Существует ограничение примерно в 32000 процессов, в связи с количеством указателей, которые можно создать. Практическое ограничение числа процессов определяется объемом имеющейся физической памяти.

Так как доступ к виртуальной памяти транслируется в аппаратный доступ через устройство управления памятью (MMU), то код виртуальной памяти зависит от ЦП.

Центральные процессоры ARM и x86 используют аппаратные таблицы страниц, так что содержимое виртуальной памяти доступно непосредственно оборудованию, в то время как другие ЦП используют программный буфер опережающей выборки при передачах (TLB) miss handler, где содержимое виртуальной памяти необходимо заполнить, чтобы TLB действовал.

Рисунок 6.5 показывает внутреннее отображение адресного пространства виртуальной памяти для процесса пользователя.

Проектные задачи управления виртуальной памятью в CE 6.0 включают:

Рисунок 6.6 показывает внутреннее отображение адресного пространства виртуальной памяти. Таблица 6.1 показывает карту виртуальной памяти CE 6.0, и описывает каждую область более подробно.

Пользователи могут вызывать функции ВП только на той памяти, которую они распределили с помощью VirtualAlloc, они не могут выполнять операции ВП на ВП в пространстве пользователя, распределенном ядром, таком как стеки, отображенные в память представления файлов, и данные/код DLL.

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

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

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

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

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

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

Базовые службы операционной системы (OS)

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

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

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

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

Файловые системы

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

Так как управляемые FSD файловые системы являются предпочтительным типом файловой системы, CE включает драйверы файловой системы (FSD - File System Drivers) для ряда файловых систем. Кроме того, разработчики встраиваемых систем могут создавать и регистрировать собственные файловые системы.

Независимо от типа памяти, все файловые системы доступны через интерфейс программирования приложений (API) файловой системы Microsoft Win32.

Драйверы зарегистрированной файловой системы включают Release-Directory File System (RELFSD), Object Store (RAM) File System, и ROM File System.

Хранилище объектов в Windows Embedded CE предоставляет постоянное хранилище для приложений и связанных с ними данных, даже когда основной источник питания недоступен, при условии, что имеется резервный источник питания. Одна или несколько микросхем памяти, которые обычно являются микросхемами энергонезависимой RAM, составляют физическое хранилище объектов.

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

Операционная система использует хранилище объектов для выполнения следующих задач:

Файловая система и реестр будут рассмотрены более подробно. Таблица 6.2 описывает объекты файловых систем и каталога управления хранилищем, которые можно выбирать для ОС при использовании инструмента Platform Builder (Сборщик платформы) для генерации нового ядра.

Внутренняя файловая система в целевом устройстве управляет доступом к RAM. Файловая система может также обеспечить хранение файлов в хранилище объектов, которое находится в RAM. Имеется два варианта внутренней файловой системы: файловая система RAM и ROM, и файловая система только ROM. Они обладают различными свойствами, и нужно будет выбрать правильный вариант для целевого устройства. Обе файловые системы предоставляют возможность подключения дополнительных внешних файловых систем, таких как FAT (таблица распределения файлов).

Файловая система RAM и ROM предоставляет хранение файлов в хранилище объектов, а также доступ к ROM. Хранилище объектов является корнем (root) файловой системы, и все данные ниже корня хранятся в хранилище объектов, с исключением для внешних файловых систем, которые подключаются как каталоги ниже корня. Данные в ROM доступны через каталог Windows. Файловая система RAM и ROM наиболее полезна на целевых устройствах, которые обеспечивают постоянное питание RAM, так как хранилище объектов будет потеряно, если RAM не обновляется.

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

Графика, работа с окнами, и подсистема событий (GWES)

CE объединяет библиотеки интерфейса прикладного программирования (API) Win32, интерфейса пользователя (UI), и интерфейса графических устройств (GDI) в модуль графики, работы с окнами и подсистемы событий GWES (Graphics, Windowing, and Events Subsystem). GWES является интерфейсом между пользователем, приложением, и операционной системой (ОС).

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

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

Процессы и потоки

Все приложения в CE состоят из процесса и одного или нескольких потоков:

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

Для задания уровней приоритета CE использует функции CeSetThreadPriority и CeGetThreadPriority. Функция CeSetThreadPriority задает приоритет для указанного потока. Функция CeGetThreadPriority возвращает 0 (ноль) как самый высокий приоритет, и 255, как самый низкий приоритет.

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

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

Каждый поток совместно использует все ресурсы процесса, включая его адресное пространство. Каждый поток имеет стек. Редактор связей задает размер стека для всех потоков, которые создаются в процессе ( /STACK ). Отдельный поток может иметь свой собственный размер стека, вызывая CreateThread и используя параметр STACK_SIZE_PARAM_IS_ A_RESERVATION.

Поток содержит также состояние регистров ЦП, называемое контекстом, и запись в списке выполнения системного планировщика.

Можно использовать функцию GetThreadContext для извлечения контекста определенного потока, и функцию SetThreadContext для задания контекста определенного потока.

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

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

Потоки могут быть в одном из следующих состояний:

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

Многозадачность и планирование

Планирование является важным вопросом в любой ОСРВ. Во время планирование ядро поддерживает список приоритетов каждого потока в операционной системе (ОС). Каждый процесс может содержать несколько потоков, и каждый поток является траекторией выполнения. Система планирования управляет порядком в котором эти различные траектории выполнения выстраиваются, и позволяет траекториям взаимодействовать друг с другом предсказуемым образом.

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

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

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

Поток выполняется пока:

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

В CE 6.0 по умолчанию используется квант времени 100 мс. Квант времени можно задавать между 1 и 100 мс. Планировщик выполняет задание с самым высоким приоритетом. Задачи с одинаковым приоритетом будут выполняться циклически друг за другом. Никакого алгоритма старения в планировщике не используется, поэтому возможна ситуация зависания (потоки или процессы с низким приоритетом, которые никогда не выполняются). Пользователям необходимо тщательно проектировать прикладные программы и благоразумно задавать уровни приоритетов, чтобы избежать зависания.

Уровни приоритета

CE предлагает 256 уровней приоритета, при этом нулевой обладает наивысшим приоритетом, а 255 является самым низким приоритетом. Многие более высокие уровни приоритета (с 247 и до нуля) присваиваются приложениям реального времени, драйверам, и системным процессам.

Чтобы помешать случайному приложению снизить производительность системы, OEM может ограничить использование всех уровней приоритета между 247 и нулем только определенными OEM приложениями. Используйте CeSetThreadPriority и SetThreadPriority для задания потоку уровня приоритета. Используйте CeGetThreadPriority и GetThreadPriority для извлечения уровня приоритета потока. Система уровней приоритета имеет четыре диапазона, показанные в таблице 6.3.

Инверсия приоритета

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

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

Так как требуется неограниченный объем времени для освобождения инверсированного потока и это находится вне контроля ядра, то OEM теряет управление над планированием процесса. Чтобы гарантировать производительность реального времени, OEM должен гарантировать, что условие инверсии приоритета не возникает.

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

Предположим, что приложение имеет три потока:

Поток 1 и поток 2 находятся в спящем режиме или блокированы в начале примера. Затем выполняется поток 3 и входит в критический раздел. В этот момент поток 2 начинает выполнение, вытесняя поток 3, так как поток 2 имеет более высокий приоритет. Поэтому поток 3 продолжает владеть критическим разделом.

Позже начинает выполнение поток 1, вытесняя поток 2. Поток 1 пытается войти в тот критический раздел, которым владеет поток 3, но так как им владеет другой поток, поток 1 блокируется, ожидая критический раздел.

В этом месте начнет выполняться поток 2, так как он имеет более высокий приоритет, чем поток 3, а поток 1 не выполняется. Поток 3 никогда не освободит критический раздел, который ожидает поток 1, так как поток 2 будет продолжать выполняться. Поэтому поток с самым высоким приоритетом в системе, поток 1, становится блокированным, ожидая выполнения потоков с более низкими приоритетами.

Чтобы разрешить проблему с потоками CE допускает наследование приоритета на глубину одного уровня. В предыдущем примере, когда поток 1 блокируется, так как он ждет завершения потока 3, CE повышает приоритет потока 3. Когда приоритет потока 3 повышается, он выполняется и, в конечном счете, освобождает общий ресурс для потока 1.

После освобождения потоком 3 общего ресурса, CE восстанавливает исходный приоритет потока 3, и затем выполняется поток 1.

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

Производительность в реальном времени

Производительность в реальном времени определяется для операционной системы CE следующим образом:

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

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

Следующий список показывает возможности ядра, которые поддерживает CE, как ОСРВ:

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

Время ответа, показанное в таблице 6.4, было измерено и опубликовано для CE 5.0, а время для CE 6.0, как утверждается, будет таким же или немного лучше. Тестовая система включала следующие оборудование и программное обеспечение:

Время в таблице 6.4 примерно в 10 раз быстрее, чем у Linux, согласно недавнему исследованию . Как видно на рисунке 6.10, эти времена цикла ответа на несколько порядков величины быстрее, чем можно обычно видеть у настольной ОС общего назначения Windows, и вполне укладывается в диапазон времени ответа строго определенную ОС реального времени.

Примитивы синхронизации

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

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

Мьютексы являются, как подразумевает название (MutEx - Mutual Exclusion), объектами взаимного исключения, и похожи на критические разделы. Принципиальное различие состоит в том, что мьютексы являются настоящими объектами ядра ОС с указателем, и могут именоваться для использования между процессами. Поэтому важно закрывать указатель на мьютекс когда он больше не требуется, чтобы предотвратить утечку ресурсов ядра. Мьютексы создают больше накладных расходов, чем критические разделы, потому что требуют обращения к ядру.

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

Объекты событий обычно используются для указания, что что-то произошло, в противоположность синхронизации доступа к общедоступному ресурсу. Начальное состояние объекта события определяется параметром InitialState. Используйте функцию SetEvent для задания состояния объекта события для сигнализации. Используйте функцию ResetEvent для сброса состояния объекта события в несигнализируемое. Когда сигнализируется состояние сброшенного вручную объекта события, оно остается сигнализирующим, пока не будет явно сброшено в несигнализируемое с помощью функции ResetEvent. Любое число ожидающих потоков, или потоков, которые в дальнейшем начинают операции ожидания для указанного объекта событий, могут освобождаться во время сигнализации состояния объекта. Когда сигнализируется состояние автоматически сброшенного объекта событий, он остается сигнализирующим, пока не будет освобожден одиночный ожидающий поток; система затем автоматически сбрасывает состояние в несигнализируемое. Если ожидающих потоков нет, то состояние объекта событий остается сигнализирующим. События могут быть также пульсирующими, что всегда будет сбрасывать объект событий снова в несигнализируемое состояние.

Состояние сброшенного вручную объекта событий, сигнализируемое функцией SetEvent,остается сигнализируемым, пока не будет явно задано как несигнализируемое состояние функцией ResetEvent. Все ожидающие потоки, или потоки, которые впоследствии начинают операции ожидания для указанного объекта событий, вызывая функции ожидания, будут освобождаться, пока сигнализируется состояние объекта. Состояние автоматически сбрасываемого объекта события, сигнализируемое функцией SetEvent, будет оставаться заданным, пока не будет освобожден одиночный ожидающий поток, когда он перейдет в несигнализируемый. Сбрасываемые вручную объекты событий, сигнализирующие функцией PulseEvent, освободят все ожидающие потоки и немедленно вернутся в несигнализирующее состояние. Автоматически сбрасываемый объект события, сигнализирующий функцией PulseEvent, освободит максимум один ожидающий поток, и немедленно переходит в несигнализирующий. Если ожидающих потоков нет, событие все равно перейдет в несигнализирующее, ничего не освобождая. Используйте функцию CloseHandle для закрытия указателя. Система закрывает указатель автоматически, когда процесс завершается. Объект события разрушается, когда будет закрыт его последний указатель.

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

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

Когда возникает событие, поток снова можно использовать при планировании времени ЦП. После планирования поток продолжает выполнение. Поток теперь синхронизовал свое выполнение с возникновением события.

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

Так как несколько процессов могут иметь указатели на один и тот же объект события или мьютекс, эти объекты можно использовать для выполнения межпроцессной синхронизации. Процесс, который создает объект, может использовать указатель, возвращаемый функцией CreateEvent или CreateMutex. Другие процессы могут открывать указатель на объект, используя имя объекта в другом вызове функций CreateEvent или CreateMutex. Именованные объекты предоставляют процессам способ совместного использования указателей объектов. После того как процесс создает именованное событие или объект мьютекса, другие процессы могут использовать это имя для вызова соответствующей функции, CreateEvent или CreateMutex, чтобы открыть указатель на этот объект.

Межпроцессная коммуникация

CE поддерживает для межпроцессной коммуникации модели общей памяти и передачи сообщений. Существует много ситуаций, где имеет место использование общей памяти. Наиболее распространенным является передача буфера между процессами пользователя, драйверами и серверами. Приложения пользователя также могут совместно использовать память. В CE функции CeRemoteHeapCreate и CeRemoteHeapTranslatePointer позволяют создавать кучу, которая доступна только ядру или серверу в режиме пользователя и клиенту, где сервер может выделять, освобождать, читать и писать, в то время как клиент может читать и писать, но не может исказить метаданные кучи. Отображенные в память файлы позволяют нескольким процессам общаться, используя объект файла в качестве нижележащей среды коммуникации. Файл может быть реальным или с поддержкой в памяти, а отображение обеспечивает доступ к данным с помощью обычных указателей. Операционная система заботится о том, чтобы все процессы видели одинаковые данные.

Для отображенных в память указателей в CE используйте функции CeOpenCallerBuffer, CeCloseCallerBuffer, CeAllocAsynchronousBuffer, и CeFreeAsynchronousBuffer. Используйте ReadProcessMemory вместе с WriteProcessMemory. Соедините парой указатель с идентификатором процесса и передавайте их вместе. Используйте функции VirtualAllocEx, VirtualCopyEx, и VirtualAllocCopyEx для задания альтернативных точек входа в память для процессов. Эти механизмы обычно реализуются драйверами или серверами процесса режима пользователя/ядра. CeOpenxxx/CeClosexxx на самом деле реализуются с помощью Read/WriteProcessMemory. Они являются вспомогательными функциями, используемыми обычно драйверами или серверами режима ядра/пользователя для доступа к буферу памяти клиентского процесса. Read/WriteProcessMemory могут использоваться любым процессом, но требуют указатель на целевой процесс. Функции VirtualAlloc/CopyEx также требуют указатель на целевой процесс. Функцию VirtualCopyEx можно вызывать только из режима ядра.

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

Сообщение WM_COPYDATA посылается, когда приложение передает данные другому приложению. Сообщение WM_SYSCOPYDATA посылается, когда компонент системы передает данные другому компоненту системы.

Message Queuing (MSMQ) является совершенно другим типом системы обмена сообщениями, которая используется для высокоуровневой коммуникации между устройствами в сети. MSMQ не используется для межпроцессной коммуникации на одном устройстве.

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

Приложения реального времени используют прерывания для своевременного ответа на внешние события. Для этого CE разбивает обработку прерывания на два шага: процедуру обработки прерывания (ISR - Interrupt Service Routine) и поток обработки прерывания (IST - interrupt service thread). ISR выполняется сразу, IST может затратить некоторое время, которое необходима для выполнения работы. Каждый запрос прерывания (IRQ - Interrupt Request) ассоциируется с ISR. ISR может отвечать нескольким источникам IRQ.

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

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

Обслуживание IRQ в Windows Embedded CE 6.0 начинается с ядра, которое перехватывает все исключения, а затем определяет соответствующее действие. В случае IRQ ядро перехватывает IRQ, сохраняет регистры, поддерживаемые для ISR, и вызывает определенную вами ISR. Примерами аппаратных IRQ могут быть изменение состояния последовательного порта COM, или нажатие кнопки на считывателе штрих-кода. ISR располагается в OAL.

Процедура обработки прерывания (ISR) является кодом, который обрабатывает запросы прерываний (IRQ) на целевом устройстве. ISR является центральной частью OAL и отвечает за определение источника прерывания, маскирование его, и возврат уникального идентификатора в ядро Windows Embedded CE 6.0 для указания, какой драйвер должен использоваться для обработки события. Когда в ISR добавляется поддержка для других источников прерывания, имеются другие процедуры поддержки прерываний, которые нужно будет реализовать для отображения аппаратных прерываний в уникальные идентификаторы - отображения IRQ в SYSINTR, активация и деактивация прерываний, и т.д. Используя код OAL система CE ассоциирует каждый IRQ с ISR. Когда происходит прерывание, обработчик исключений ядра вызывает зарегистрированную процедуру ISR для этого прерывания. Используя функцию HookInterrupt в OAL, можно зарегистрировать только один одну ISR для каждой линии IRQ. Однако можно ассоциировать ISR с одним или несколькими идентификаторами прерываний. Когда ISR возвращает управление в ядро, ядро проверяет возвращаемый идентификатор прерывания и задает связанное с ним событие. Соответствующий поток IST в драйвере устройства зависит от события и освобождается для обработки события, когда становится потоком с самым высоким приоритетом в системе. Для управления ISR необходимо реализовать функции управления ISR, которые позволяют ядру начать, обслужить и завершить обработку прерывания.

Поток обслуживания прерывания (IST) является потоком, который выполняет большую часть обработки прерывания. ОС активирует IST, когда ОС имеет прерывание для обработки. Иначе IST будет неактивным. Драйвер устройства или OAL может связать идентификатор прерывания с событием, создавая IST и вызывая функцию InterruptInitialize. IST затем ожидает событие. IST вызывает функции в аппаратном, зависящем от платформы, слое драйвера, чтобы прочитать или записать в целевое устройство. Чтобы ОС активировала IST, IST должен связать объект события с идентификатором прерывания. Используйте функцию CreateEvent для создания объекта события.

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

Рисунок 6.11 показывает действия, вовлеченные в обработку прерывания в CE:

Одним из наиболее важных аспектов производительности ядра в реальном времени является возможность обслуживать IRQ в течение строго определенного периода времени.

Задержка прерывания относится, прежде всего, к задержкам программной обработки прерываний; то есть, количеству времени, которое проходит с момента, когда внешнее прерывание приходит в процессор и до момента, когда начинается обработка прерывания. Если подкачка страниц не происходит, время задержки прерываний в CE ограничено для потоков, заблокированных в памяти. Это делает возможным тестировать задержки худшего случая - общее время до запуска ISR и запуска IST. Общее количество времени, пока прерывание не будет обработано, можно затем определить вычисляя время, необходимое в ISR и IST.

Задержка для ISR включает время, которое требуется ядру для направления на регистры сохранения обработчика ISR (стандартное), и т.д., и время, в течение которого прерывания выключены (переменное). Задержка ISR является интервалом времени, который начинается, когда IRQ задается в ЦП, и заканчивается, когда начинает выполняться ISR. Начало ISR, которое измеряется, можно вычислить на основе текущего состояния других прерываний в системе. Если выполняется прерывание, вычисление начала новой процедуры ISR, которое будет замеряться, должно учитывать два фактора: число прерываний с более высоким приоритетом, которые произойдут после рассматриваемого прерывания, и время, затраченное на выполнение ISR.

Чтобы предотвратить потерю и задержку высокоприоритетных прерываний, ядро CE использует вложенные прерывания. Вложенные прерывания позволяют запросам прерываний (IRQ) с более высоким приоритетом вытеснять IRQ с более низким приоритетом. Вложенные прерывания допускаются в соединении с Real-Time Priority System (Система приоритетов реального времени). ISR с более высоким приоритетом могут вытеснять ISR с более низким приоритетом. Ядро управляет деталями сохранения состояния ISR, когда происходит прерывание с более высоким приоритетом, и восстановлением его после завершения ISR с высоким приоритетом. В большинстве случаев вытесненная ISR не обнаруживает, что была вытеснена. Уровень вложения прерываний ограничен только тем, что может поддерживать аппаратная платформа.

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

Драйверы устройств

Драйвер устройства является программой, которая абстрагирует функции физического или виртуального устройства. Драйвер устройства управляет работой этих устройств. Примерами физических устройств являются сетевые адаптеры, таймеры, и универсальные асинхронные приемо-передатчики (UART). Примером виртуального устройства является файловая система. Реализация драйвера устройства позволяет предоставить функции этого устройства приложениям и другим частям операционной системы. При разработке драйвера устройств используйте возможности базовых служб предоставляемых ОС. Где только возможно, должна использоваться библиотека функций CEDDK для низкоуровневых операций в драйверах устройств.

Многие драйверы устройств CE реализуют потоковый интерфейс. Точками входа базового потокового интерфейса являются XXX_Open, XXX_Close, XXX_Read, и XXX_Write. Сетевые адаптеры, адаптеры дисплея, устройства мыши, клавиатуры, и другие устройства специального назначения не используют потоковый интерфейс. Эти устройства используют интерфейс, который соответствует функциям устройства. Различные процессы будут загружать различные драйверы устройств. Хотя драйверы устройств CE являются привилегированными модулями, они не должны выполняться в режиме ядра.

Большинство драйверов устройств CE состоят из зависимого от платформы драйвера (PDD) и драйвера устройства модели (MDD). Монолитный драйвер объединяет все PDD и MDD в один драйвер. Многоуровневый драйвер не объединяет их.

MDD имеет следующие характеристики:

PDD имеют следующие характеристики:

Следующий список содержит вопросы для рассмотрения при выборе между реализацией многоуровневого драйвера или монолитного драйвера:

В CE 6.0 предоставляются образцы исходного кода для ряда драйверов и предоставляется широкий ассортимент обычно используемых драйверов устройств. Более подробная информация о разработке драйверов устройств будет представлена в лекции 9.

Менеджер устройств загружает все драйверы в пространство ядра как драйверы режима ядра, если только в реестре не задан флаг DEVFLAGS_LOAD_AS_USERPROC. Драйверы режима ядра предоставляют лучшую производительность, так как они могут вызывать API ядра непосредственно используя версию ядра coredll, называемую k.coredll.dll. Драйверы ядра могут синхронно обращаться к буферам пользователя очень быстро, так как память пользователя доступно непосредственно. Драйверы режима ядра должны быть надежными, так как они имеют неограниченный доступ к памяти. Ошибка в драйвере режима ядра может испортить память ядра, вызывая отказ системы.

Драйверы режима пользователя

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

Инфраструктура драйвера режима пользователя делится на два физических компонента. Первым компонентом является Рефлектор драйвера режима пользователя (User Mode Driver Reflector), который располагается в менеджере устройства. Вторым компонентом является Хост драйвера режима пользователя (User Mode Driver Host), который является приложением режима пользователя, которое запускается и управляется Рефлектором драйвера режима пользователя. С точки зрения пользователя рефлектор заставляет драйверы режима пользователя работать, как если бы они были драйверами режима ядра.

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

Процесс использования Драйвера режима пользователя начинаются с приложения пользователя или с драйвера шины предка. Приложения пользователей и драйверы шины предка могут загружать Драйверы режима пользователя, вызывая функции ActivateDevice или ActivateDeviceEx. Приложения пользователя и драйверы шины предка могут выгрузить Драйверы режима пользователя, вызывая функцию DeactivateDevice. После загрузки любое приложение пользователя или драйвер могут обратиться к Драйверу режима пользователя, вызывая указатель устройства.

Если драйвер является Драйвером режима пользователя, обращение к ActivateDevice или ActivateDeviceEx приведет к тому, что менеджер устройств вызовет также функцию Рефлектора драйвера режима пользователя. Драйвер распознается как Драйвер режима пользователя, когда значение FLAGS задано как DEVFLAGS_LOAD_ AS_USERPROC (0x10) в ключе устройства в реестре.

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

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

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

Реестр

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

Структура реестра CE аналогична реестру настольных версий Windows. Реестр содержит множество поддеревьев данных. Каждое поддерево состоит из ветвей, называемых ключами, и каждый ключ может содержать подключи и/или записи. Записи хранятся как пары имя/значения. В основании каждого поддерева находится корень, который определяется с помощью хорошо-известного константного значения, или HKEY.

Таблица 6.5 показывает корневые константы, поддерживаемые в CE, и краткое описание каждой:

Базовый фрагмент данных, который хранится в реестре, называется значением. Значение может быть различного типа, включая строку или двоичное значение. Каждое значение имеет имя и соответствующий фрагмент данных. Например, устройство которое выполняет программное обеспечение CE Handheld PC, Professional Edition, использует имя значения Wrap to Window в ключе HKEY_LOCAL_MACHINE\Software\Microsoft\Pocket Word\Settings для хранения целочисленного фрагмента данных для версии Pocket Word.

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

CE поддерживает два типа реестров, на основе RAM и на основе улья (hive). По умолчанию CE 6.0 реализует реестр на основе улья. Тип реестра невидим для приложений, но изменяет сохраняемость, последовательность загрузки, скорость, и использование памяти на используемом устройстве. Выбор типа реестра и настроек реестра влияет также на поведение профилей пользователей. Предоставляется специальная утилита, называемая Regedit, для редактирования реестра в Platform Builder. Platform Builder генерирует начальные записи реестра для используемого устройства вместе с кодом образа ОС.

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

Реестр на основе RAM

Реестр на основе RAM хранит все данные реестра в хранилище объектов. Это эффективно в терминах скорости и размера в устройствах, которые имеют RAM с питанием от батареи. Устройства, которые не поддерживают питание RAM во время выключения, должны копировать реестр во время выключения и восстанавливать реестр при включении питания. Реестр на основе RAM предназначен для использования в устройствах, которые часто используют теплую загрузку, но редко или никогда холодную загрузку.

Реестр на основе улья

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

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

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

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

Менеджер устройств

Менеджер устройств (Device Manager) загружается ядром, он выполняется непрерывно, и управляет загруженными драйверами устройств и их интерфейсами. Когда загружается Менеджер устройств, он загружает также Менеджер ресурсов (Resource Manager) В/В для чтения списка доступных ресурсов из реестра.

Менеджер устройств отслеживает интерфейсы, предоставляемые драйверами, и поддерживает поиск драйверов на основе глобально уникального идентификатора (GUID). Интерфейс IClass может связать интерфейс GUID с унаследованным именем драйвера, его именем $device, или его именем $bus. Например, COM1:, $device\com1, или $bus\pci_0_3_0.

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

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

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

Менеджер устройств ищет ключ реестра HKEY_LOCAL_MACHINE\Drivers\RootKey, чтобы определить ключ для начала обработки загрузки драйвера. Значением по умолчанию для RootKey является Drivers, но оно обычно задается как Drivers\BuiltIn. Менеджер устройств вызывает ActivateDeviceEx для загрузки драйвера, определенного значением подключа Dll, находящегося в ключе, определенном значением RootKey.

Значение подключа Dll по умолчанию будет BusEnum.dll, называемое также перечислителем шины. Загрузка BusEnum.dll вызывает загрузку всех драйверов устройств. Устройство, загруженное функцией ActivateDeviceEx, может прочитать его указатель активации из его ключа реестра Active.

Менеджер устройства связывает имя шины с драйверами. Неименованные устройства также могут иметь имя шины, так как даже если приложения могут не иметь доступа к драйверу, драйвер может быть доступен другим драйверам или системным объектам, таким как Менеджер питания. Имя шины может иметь ACL отличный от обычного имени устройства.

Драйверы могут программным путем объявлять интерфейсы, вызывая DMAdvertiseInterface. Функция DMAdvertiseInterface позволяет драйверам добавить дополнительные GUID для поиска в их соответствующих списках. DMAdvertiseInterface предоставляет библиотека Devmgr.dll, которая также реализует большую часть функций Менеджера устройств. Так как только Менеджер устройств может загрузить Devmgr.dll, только драйверы устройств могут вызывать DMAdvertiseInterface. Если драйвер устройства не объявляет о недоступности своих интерфейсов, когда драйвер выгружается, Менеджер устройств автоматически очищает уведомление объявления интерфейса.

Компоненты менеджера устройств

Менеджер устройств состоит из Device.exe и Devmgr.dll. Device.exe содержит библиотеку Devmgr.dll, которая реализует базовые функции Менеджера устройств. Так как Менеджер устройств состоит из двух отдельных модулей, драйверы устройств могут соединяться непосредственно с Менеджером устройств и вызывать определенные функции, такие как DMAdvertiseInterface, не создавая накладных расходов системного вызова. Таблица 6.6 показывает компоненты Менеджера устройств.

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

Менеджер ресурсов В/В

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

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

OAL и реестр обычно предварительно распределяют ресурсы пространства В/В и IRQ, которые запрашивают драйверы шины. Однако Менеджер ресурсов В/В не ограничен управлением пространствами В/В и IRQ. Определенное множество доступных ресурсов может включать все, что вы определяете. Драйверы шины, такие как драйвер шины PCI, ресурсы запроса пространства В/В и IRQ у Менеджера ресурсов В/В, когда он загружает драйверы устройств для устройств, которые находит. То же самое справедливо для драйвера шины PC Card и ресурсов В/В, требуемых драйверам клиентов PC Card. Драйвер шины PC Card освобождает ресурсы, когда пользователи удаляют PC Card из системы.

Каждая аппаратная платформа имеет уникальные IRQ и доступное пространство В/В. IRQ для встроенных и фиксированных устройств должны отображаться в идентификаторы прерываний ( SYSINTR ) в OAL. IRQ для встроенных и фиксированных устройств должны исключаться из доступных ресурсов. IRQ используемые с шиной PCI обычно являются совместно используемыми.

IRQ и ресурсы пространства В/В являются предопределенными. Ключи реестра HKEY_LOCAL_MACHINE\Drivers\Resources\IRQ и ключи реестра HKEY_LOCAL_MACHINE\Drivers\Resources\IO предоставляют начальное состояние Менеджера ресурсов В/В.

Загрузчик

Загрузчик CE отвечает за загрузку модулей, которые состоят, как из исполнимых файлов, так и динамически подключаемых библиотек (DLL), в виртуальную память, так что они могут выполняться операционной системой. Каждый модуль может иметь несколько связанных с ним флагов в конфигурационном файле Config.bib.

Для каждого модуля можно задать следующие свойства:

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

Управление питанием

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

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

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

Таблица 6.7 описывает переходы между состояниями для CE - в зависимости от используемого устройства.

Используя Менеджер питания устройства получают уведомления об изменении состояния питания как управляющие коды В/В (IOCTL). Так как IOCTL выполняются в контексте потока, разработчики драйвера имеют значительно большую гибкость в том, как они реализуют изменение состояния питания. Использование IOCTL для управления питанием позволяет также разделить состояние питания устройства и общее состояние питания ОС. Поэтому некоторые устройства можно выключить во время работы ОС, а другие можно оставить включенными, когда большая часть ОС приостановлена.

Кроме управления питанием устройства Менеджер питания уведомляет приложения о связанных с питанием событиях. Например, Менеджер питания информирует заинтересованные приложения, когда ОС восстанавливается из приостановленного состояния.

Менеджер питания реализован как динамически подключаемая библиотека (DLL), называемая Pm.dll, которая компонуется непосредственно с Device.exe. Device.exe вызывает точки входа в Pm.dll, когда вызываются прикладные интерфейсы программирования управления питанием. Исходный код для Pm.dll предоставляется вместе с Microsoft Platform Builder 4.0 и более поздними версиями, и OEM могут модифицировать его для своего устройства на основе CE.

Менеджер питания действует как посредник между устройствами, приложениями, и определяет состояния питания ОС. Он реализует следующее множество правил коммуникации между тремя этими частями:

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

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

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

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

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

Менеджер питания предоставляет также следующие возможности:

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

Менеджер питания управляет состояниями питания устройства в контексте состояний питания системы, которые определены OEM.

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

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

Средства безопасности ОС

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

Доступны следующие технологии обеспечения улучшенной безопасности в устройствах и приложения:

Сетевые свойства ОС

Сетевые свойства и поддержка сети являются критически важным компонентом любой современной операционной системы. CE предоставляет ряд сетевых служб и свойств. CE предоставляет поддержку для приложений на основе Интернет. Поддерживаются следующие сетевые свойства:

Операционная система CE реализует пакет протоколов TCP/IP (Transmission Control Protocol/Internet Protocol). ОС включает стандартный стек TCP/IP, позволяющий устройствам на основе CE участвовать как одноранговые узлы сети и серверы в локальных (LAN) и удаленных сетях.

CE поддерживает следующие стандартные характеристики:

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

Поддержка предоставляется, как для IPv4, так и для IPv6. Таблица 6.8 суммирует предоставляемые службы TCP/IP.

Архитектура пакета протоколов CE TCP/IP показана на рисунке 6.16.

Сборка системы ОС и Platform Builder

В CE используется специальный инструмент для генерации индивидуального ядра операционной системы, называемый Platform Builder, который показан на рисунке 6.17. В CE 6.0 он выполняется в Visual Studio 2005 с SP1. В Platform Builder разработчик выбирает различные свойства ОС и необходимые драйверы устройств из объектов каталога (слева на рисунке 6.17), используя мышь для выбора необходимых объектов. Затем пользователь выбирает Build из меню верхнего уровня для сборки нового ядра ОС, используя выбранные свойства ОС. Новую ОС можно затем выполнить и отладить на эмуляторе ARM или можно быстро загрузить в требуемое устройство, соединенное с ПК с помощью сети, USB, или последовательных соединений.

Терминология Platform Builder

Существует большое число уникальных терминов, используемых в Platform Builder. Использование Platform Builder и различных меню будет легче, когда вы поймете следующую терминологию:

Объект каталога: Любой объект, который можно выбрать из Catalog Items View.

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

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

Образ времени выполнения: Программное обеспечение для развертывания на целевом устройстве, или то же самое программное обеспечение, выполняющееся на целевом устройстве. Образ времени выполнения содержит ОС и связанное с ней программное обеспечение.

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

Каталог: Контейнер выбираемых индивидуально объектов функций CE.

Компонент: Наименьшая единица функциональности, которую можно добавить в конструкцию ОС.

Конфигурация: Выборка объектов каталога и выборка определенных возможностей.

Аппаратная платформа: Архитектура оборудования для выполнения ОС CE и связанного оборудования.

Модуль: EXE или DLL, которые являются частью ОС CE.

Подпроект: Механизм отслеживания совокупности файлов, которые можно использовать для проектирования и добавления функций в ОС CE. Проекты ОС могут содержать несколько подпроектов.

Целевое устройство, устройство на основе CE: Экземпляр аппаратной архитектуры или экземпляр объединенной аппаратной и программной архитектуры.

Проект: Контейнер для всех файлов, связанных с конструкцией ОС.

Сборка образа времени выполнения

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

С каждой конструкцией ОС Platform Builder по умолчанию предоставляет конфигурацию с именем Debug и конфигурацию с именем Release. Вы можете выбрать одну конфигурацию. Конфигурация определяет параметры сборки конструкции ОС. Можно модифицировать параметры сборки для каждой конфигурации. Для каждой конструкции ОС только одна конфигурация может быть активна в данный момент времени. Вариант Debug выводит больше отладочных сообщений, но также требует примерно на 40% больше памяти и дополнительного времени для загрузки, так как выводится много отладочных сообщений. После сборки конструкции ОС можно затем создать образ времени выполнения. Образ времени выполнения содержит ОС и связанное программное обеспечения для развертывания на целевом устройстве.

Затем разработчик собирает для устройства новый образ модифицированной ОС. В Platform Builder, когда вы выбираете сборку образа времени выполнения на основе конструкции операционной системы, система сборки, показанная на рисунке 6.19, выполняет следующие последовательные фазы:

Система сборки выполняет следующие задачи во время этих фаз:

Целевые устройства могут включать множество устройств, включая ARM Device Emulator, или CEPC (ПК выполняющий CE), или оборудование реальной системы, используя любой из поддерживаемых процессоров. Новый образ ОС можно быстро загрузить в любое из этих целевых устройств для дополнительной отладки и тестирования.

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

Конфигурационные файлы системы сборки

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

На основе этой информации инструмент Build собирает исходный код в каталоге и указанных подкаталогах. Таблица 6.9 показывает типы конфигурационных файлов исходного кода

Инструмент Build обходит дерево каталогов в поиске файлов dirs, а затем файлов sources. Файлы Dirs определяют файлы sources, которые содержат:

Когда инструмент Build находит файл sources в текущем каталоге, он вызывает инструмент Nmake (Nmake.exe), который делает одно из следующего:

Инструмент Make Binary Image (Makeimg.exe) вызывает ряд приложений и пакетных файлов, которые используют конфигурационные файлы образа для создания образа времени выполнения. Таблица 6.10 показывает типы конфигурационных файлов образа времени выполнения.

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

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

Файл сборщика двоичного образа (.bib) определяет, какие модули и файлы включаются в образ времени выполнения. Makeimg.exe использует файлы .bib для определения, как загружать модули и файлы в память целевого устройства.

Файл Platform.bib определяет

Файл Config.bib содержит разделы MEMORY и CONFIG для образа времени выполнения. Раздел MEMORY файла Config.bib определяет таблицу памяти для образа времени выполнения, определяя имя, адрес, размер, и тип областей MEMORY в образе времени выполнения.

При обновлении Platform.bib или Project.bib для включения файла определите следующие объекты:

Используйте параметры Address и Size в таблице памяти для определения раздела памяти, предназначенного для RAM, а также для ROM. Параметр Address определяет адрес, где начинается раздел RAM. Вместе параметры Address и Size указывают адрес, где заканчивается раздел RAM.

Раздел MODULES файлов *.bib определяет, какие модули на основе CE включены в образ времени выполнения, и как они загружаются в таблицу памяти, созданную в разделе MEMORY файла Config.bib. Он модифицируется для добавления файлов *.dll и подпроектов в образ ОС.

Этот раздел может содержать до 2000 модулей, которые состоят из двух-частной комбинации исходного кода и данных. Следующий пример показывает столбцовый формат, используемый записью раздела MODULES в файле *.bib:

Параметр name определяет имя входа раздела MODULES, как он появляется в таблице памяти. Обычно запись Name совпадает с именем файла, указанным Path.

Параметр path определяет полный путь доступа к файлу, как определено в разделе MODULES, который Romimage.exe включает в образ времени выполнения. Обычно имя файла Path совпадает с Name записи раздела MODULES.

Параметр Memory block определяет раздел RAMIMAGE области памяти в которую Romimage.exe загружает объектный модуль. Romimage.exe помещает объектные модули в указанное место памяти в том порядке, в котором они появляются в разделе MEMORY. Это место памяти соответствует разделу MEMORY, определенному в файле Config.bib. Существует только один RAMIMAGE на образ времени выполнения. Имя, которое используется для определения раздела MEMORY должно совпадать с именем, определенным в файле Config.bib.

Параметр section override определяет тип записи раздела, как ее интерпретирует Romimage.exe, и может быть задан как MODLES или FILES. Когда этот параметр добавлен в запись, Romimage.exe игнорирует раздел, в котором находится запись, и интерпретирует запись как члена указанного раздела. Это является необязательным.

Параметр type определяет тип файла, и может быть комбинацией следующих символов:

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

Несколько сайтов сообщества пользователей и новостных групп обсуждают различные темы и проблемы связанные с Windows Embedded CE: