Введение В Windows Embedded Ce 6.0
Данная статья будет интересна тем людям, которые неудачно прошили планшет с процессором WM8505, т.е. Не могут подобрать для него стабильно работающую прошивку с OS Android. Здесь я расскажу, как установить на свой планшет русскую версию OS Windows CE 6.0 Embedded. По одной из моих задумок, решил восстановить старенький планшет, отправленный давно на донорство. На момент восстановления в нем отсутствовали: Wi-Fi модуль, камера, сенсор, аккумулятор, микросхема GL850G (служит USB хабом) и прочая мелочь.
Чтобы как-то можно было управлять планшетом, например, стандартной мышкой, вывел пару USB гнезд по уже «накатанной», но усовершенствованной технологии, о которой я рассказывал. Привожу несколько фотографий данного процесса. Потому что на плате отсутствует микросхема GL850G, максимальное количество портов USB равняется двум. Если кому-нибудь будет интересно, как и откуда брать разводку USB в отсутствии чипа GL850G, спрашивайте, отвечу в комментариях, хотя все и так видно на фото. Итак, приведя «железо» планшета в более-менее рабочее состояние, я решил попытаться найти на него прошивку на базе Android OS, но ни одна из них, после установки не запускалась – made in china, что сказать. В результате выбор остановил на WinCE 6.0 RUS.
Загружается она в разы быстрее по сравнению с android, что для меня было огромным плюсом. Минусом стал тот факт, что драйвера на камеру найти так и не удалось. Скачать WinCE 6.0 русскую версию для планшета с процессором WM8505 можно. Устанавливается windows по знакомому сценарию. Необходимо распаковать архив и скопировать содержимое на флеш карту microCD, чтобы в корне флешки оказалась папка script. Затем вставляется данная microCD карта в планшет, он включается и начинается процесс установки, который занимает порядка пяти минут. Сложного ничего в нем нет, главное следить за надписями на экране и следовать им.
В процессе установки Windows CE 6.0 Embedded на планшет, нужно будет один раз вынуть microCD карту и принудительно перезагруситься. Вот все, что от Вас потребуется. Хочу отметить тот факт, что microCD карта памяти на 2 GB class 6 не подошла для этих целей, а на 16 GB class 4 – работала стабильно и надежно. Немаловажным является и тот факт, что в процессе установки WinCE 6.0 на планшет следует обязательно отпаять (отсоединить) камеру, т.к. Драйверов на нее в OS нет, и windows на процессе их поиска зацикливается.
Для сборки 6-й ОС не могу найти её саму (Windows Embedded CE 6.0), только обновления до релизов R2 и R3. Введние в Windows Embedded CE 6.0 Автор: Станислав Павлов, Павел Белевский Жанр: техническая литература Язык оригинала: русский Выпуск:. Некоторые порты устройств с системой Windows Embedded CE 6.0 могут принимать специфичные пакеты данных. Например, через UDP-порт 9204 некоторые устройства принимают данные в формате vCard. Для получения цельного представления о Windows Embedded CE рекомендуется также прочесть книгу «Введение в W.
Возможно, это будет касаться и модуля Wi-Fi, проверить не смог, т.к. Он у меня банально отсутствовал при установке, и проверить данный факт возможности не было.
Если на заре разработки специализированных устройств, в том числе ориентированных на системы реального времени, приходилось вести разработку с нуля, то на текущий момент большую популярность имеют системы-конструкторы. Задача разработчика, использующего средства разработки подобных систем, заключается в выборе необходимых «блоков» системы, которые в совокупности сформируют базовый функционал устройства. Таким образом, значительно сокращается цикл разработки устройств, поскольку основное внимание в процессе разработки и тестирования уделяется лишь вновь добавленным функциям. Примером одной из таких систем-конструкторов является Windows Embedded CE. Отставляя за рамками статьи описание широкого спектра возможностей и технологий, поддерживаемых Windows Embedded CE «Введение в Windows Embedded CE 6.0 R2» и «Windows Embedded CE 6.0 R2.
Практическое руководство», хотелось бы отметить следующие ключевые особенности. Завершая краткий обзор Windows Embedded CE 6.0, следует упомянуть о первоочередном моменте, который необходимо учитывать при принятии решения по разработке устройства на конкретной аппаратной платформе с использованием той или иной системы – это наличие пакета аппаратной поддержки BSP (Board Support Package). Для любой системы с поддержкой широкого спектра аппаратных платформ отчетливо видна тенденция абстрагирования компонентов системы от специфики конкретной платформы. Связующим звеном в данном случае как раз и выступает пакет аппаратной поддержки. Тема BSP заслуживает целого цикла статей, но остановимся лишь на основных моментах. В зависимости от типа устройства требуемый уровень проработки BSP может быть различным. Например, для мультимедиа-устройства, помимо базовых функций ввода-вывода, желательно иметь поддержку аппаратного декодирования аудио- и видеоконтента, плавной отрисовки интерфейса средствами OpenGL или DirectDraw, а также расширенные коммуникативные возможности, включающие поддержку Wi-Fi, Bluetooth и пр.
С другой стороны, для контроллера в системе контроля и управления технологическим процессом, в задачи которого входит формирование управляющих сигналов в соответствии с текущими входными параметрами, достаточно запустить минимально необходимый набор компонентов и обеспечить считывание и передачу сигналов по определенным шинам данных с учетом требований по работе в режиме реального времени. И если разработка BSP для контроллера может оказаться вполне посильной задачей, укладывающейся в финансовые и временные рамки проекта, то в случае богатых в функциональном плане устройств рациональнее использовать готовый пакет аппаратной поддержки, который, как правило, предоставляется на свободной или платной основе производителем аппаратной платформы или партнерами, специализирующимися на разработке BSP (Adeneo, BSquare и др). В первую очередь это планировщик с отличным от настольных систем Windows алгоритмом работы, а также архитектура подсистемы обработки прерываний. Принцип работы планировщика в многопоточной среде Windows Embedded CE достаточно прост и основывается на приоритетах. Для каждого потока (в контексте каждого процесса может быть запущено несколько потоков) задается значение приоритета: от 0 – наивысший приоритет до 255 – наименьший приоритет. По умолчанию поток имеет значение приоритета, равное 251. В соответствии со значением приоритета готовых к исполнению потоков в каждый момент времени исполняется поток с наименьшим его значением.
Этот простой принцип позволяет настроить систему для обеспечения детерминизма исполнения. Другим, не менее важным показателем систем реального времени является задержка при обработке прерываний. Обработка прерываний в Windows Embedded CE состоит, в общем случае, из двух этапов. Первый этап заключается в детектировании источника прерывания и выполняется в невытесняемом (non-preemptive) режиме работы системы. В соответствии с этим работа первого этапа может быть прервана только в случае возникновения более высокоприоритетного прерывания – другие потоки системы в этот промежуток времени не исполняются. После того как будет определен источник прерывания, система устанавливает связанное с ним событие.
Установка события служит сигналом для второй части, выполняющей непосредственную обработку и являющейся для системы обычным потоком. Таким образом, задержка при обработке прерывания состоит из двух частей. Если первая составляющая зависит исключительно от аппаратной части, ее архитектуры и производительности, то задержка до запуска потока обработки прерывания помимо характеристик аппаратной платформы определяется тем, как долго система находится в невытесняемом режиме и тем, как настроены значения приоритетов других потоков в системе. Наглядно описанная процедура обработки прерываний приведена на рис.
1, где ISR (процедура детектирования источника прерывания), IST (поток обработки прерывания), OAL (слой абстракции ядра от конкретной платформы), являются частью BSP. При использовании приведенной, классической для Windows Embedded CE, схемы обработки прерываний основным инструментом для улучшения значения задержек является настройка приоритетов потоков системы.
В случае если добиться желаемого результата данным способом не получается, то следующим шагом является сокращение времени нахождения системы в невытесняемом режиме. Эта задача решается оптимизацией кода всех ISR, задействованных при работе системы, и в крайнем случае временным отключением прерываний. Если же приведенные ранее меры не дали должного эффекта, то есть возможность отказаться от двухуровневой схемы обработки прерываний и поместить весь код по обработке в ISR. При этом следует понимать, что во время работы ISR не будут детектироваться менее приоритетные прерывания и будет приостановлено исполнение всех потоков системы.
Дополнительным поводом отказаться от обработки прерываний в ISR является тот факт, что в ISR доступен лишь ограниченный набор функций системного API. Исследования задержек будут проводиться на платформе BeagleBoard, а именно на EBVBeagle ревизии C2 (рис.
2), произведенной компанией EBV. Данная платформа отличается компактностью в сочетании с достаточно высокой производительностью – в ее основе лежит процессор TI OMAP3530 со встроенным блоком цифровой обработки данных (DSP). Проект BeagleBoard организован фактически энтузиастами и не имеет прямого отношения к производителю процессора – Texas Instruments. На текущий момент, как минимум в публичном доступе, отсутствует BSP, полностью реализующее функции платформы BeagleBoard под Windows Embedded CE 6.0. При этом есть несколько BSP для платформ, использующих аналогичный процессор.
Это BSP для отладочной платы EVM3530 и BSP для Gumstix Overo (разработанное компанией Adeneo. Отладочная плата EVM3530 поддерживается Texas Instruments и с недавних пор BSP для нее доступно по запросу на сайте TI (http://ww.ti.com). Инструкция по заполнению книги доходов расходов 15 за 2011 г. BSP предоставляется с определенными лицензионными ограничениями, в частности запрещена в том или ином виде публикация исходных кодов из его поставки. Благодаря тому что платформы используют один и тот же процессор, подавляющее количество функций – загрузчик, код инициализации платформы и некоторые драйверы – может быть использовано без доработки. При этом ввиду схемотехнических отличий в разводке плат и используемых вспомогательных микросхем необходима доработка кода инициализации DVI-выхода и USB-хост контроллера. Информация по доработке BSP EVM3530 размещена на ресурсе в теме EBVBeagle rev.
C2 раздела Discussions. Для тестирования задержек по обработке прерываний BSP EVM3530 может быть использовано без дополнительной доработки. Следующим этапом по подготовке к тестированию является сборка образа Windows Embedded CE. Преследуя исключительно цели тестирования задержек, воспользуемся минимальным образом. Для сборки минимального образа служит специальный шаблон Small Footprint Device, который выбирается в Visual Studio 2005 (рис.
3) при создании дизайна операционной системы. Данный шаблон включает минимальный набор модулей для запуска Windows Embedded CE и в случае BeagleBoard составил 540 Кбайт. В отличие от привычной многозадачной конфигурации Windows, как правило, с поддержкой менеджера окон в минимальном образе запущен только один процесс, собственно ядро, в контексте которого может исполняться формально неограниченное количество потоков (максимальное количество потоков фактически определяется возможностями аппаратной платформы). В данной конфигурации может быть полностью исключено влияние посторонних потоков на результаты измерений. Такой вариант системы отлично подходит для контроллеров, в которых не задействованы или задействованы лишь основные возможности Win32 и основная задача – это обработка сигналов на низком аппаратном уровне. В общем случае схема измерения задержек содержит генератор импульсов, 2-канальный осциллограф и исследуемую платформу Статья в MSDN «Benchmarking Real-time Determinism in Microsoft Windows CE» (На вход исследуемой платформы и один из каналов осциллографа подаются импульсы с генератора. При возникновении импульса на входе платформы генерируется прерывание, а результатом его обработки является изменение уровня сигнала на выходе, который подключен ко второму каналу осциллографа.
Таким образом, задержка при обработке прерывания может быть измерена как разница между моментами времени возникновения импульса генератора и изменения сигнала на выходе платформы. В качестве генератора импульсов воспользуемся одним из таймеров (всего в платформе доступно 12, из них 3 таймера позволяют скоммутировать выходной сигнал на контактную площадку для подключения плат расширения). Далее сигнал таймера подадим на вход порта ввода/вывода общего назначения (GPIO), настроив его на генерацию прерываний по приходу импульса. Для формирования выходного сигнала воспользуемся вторым портом ввода/вывода. Чтобы измерить обе задержки, ISR и IST, будем устанавливать высокий уровень выходного сигнала при входе в ISR и низкий – при запуске IST. Таким образом, фронт выходного импульса покажет ISR-задержку, а его длительность – IST-задержку. 4 показаны контакты платы, задействованные для реализации описанной схемы измерения.
Схема подключения приведена на рис. Перейдем к анализу результатов.
Сначала для случая, когда в системе запущен всего один поток. 6 приведен снимок экрана осциллографа, где желтым цветом (1) показан импульс на входе, а голубым (2) – на выходе платформы. В соответствии с полученными результатами тестирования аппаратная задержка – задержка до запуска ISR – составляет в среднем 5 мкс. IST-задержка – 6,5 мкс. Если же посмотреть историю показаний (рис.
7), то видно, что ISR-задержка менялась в интервале 2–8 мкс, а IST оставалась практически неизменной. Постоянное значение IST – идеальный случай, когда отсутствует влияние других потоков системы. В системах с интенсивным переключением потоков значение IST-задержки, как правило, подвержено флуктуации. Теперь рассмотрим случай, когда в системе запущено несколько потоков. При этом поток обработки прерываний имеет более высокий приоритет. Результаты второго эксперимента, включая историю показаний, приведены на рис.
Масштаб был увеличен, с тем чтобы выходной импульс полностью поместился на экране осциллографа. Значение IST-задержки изменило свой постоянный характер и увеличилось в среднем до 75 мкс. Также, судя по истории показаний, иногда задержка совпадает с результатом первого эксперимента. Очевидно, что минимальная задержка соответствует случаю, когда не происходит переключения контекста исполнения. А поскольку основное время поток обработки прерывания простаивает, ожидая установки события и позволяя исполняться другим потокам, то происходит это редко. Более подробное изучение системы с использованием профилировщика ядра показало, что причиной такого значительного увеличения задержки стала реализация одной из функций BSP, а именно то, как был реализован переменный тик системного таймера. После модификации BSP, с тем чтобы использовался постоянный тик системного таймера, который по умолчанию составляет 1 мс, картина задержек полностью нормализовалась (рис.
Введение В Windows Embedded Ce 6.0 Emulator Download
Отклонения величин обоих задержек составили доли микросекунды. Значение ISR-задержки сократилось до 1,5 мкс, а IST-задержка практически достигла результата для однопоточной задачи, составив 7,5 мкс. Обобщая полученные результаты, для приведенной конфигурации можно сделать следующие выводы. Во-первых, согласно значениям задержек по обработке прерываний, система полностью удовлетворяет требованиям для построения систем жесткого реального времени. Второй вывод: для достижения оптимальных результатов необходимо модифицировать BSP: либо отказавшись от реализации переменного тика таймера, либо выполнив ее доработку. Сравнивая с результатами независимых исследований Отчет по результатам независимого тестирования Windows Embedded CE (в данном случае были получены достаточно хорошие показатели. Например, для платформы на базе процессора Intel Pentium 200 МГц максимальное значение IST-задержки составило 20 мкс.