Как пользоваться windows ce
Содержание
Введение
"Третья" Windows - новая операционная система Windows CE - не получила такой известности, как ее старшие сестры - Windows 98 и Windows NT, но ситуация начинает меняться. Windows CE предназначена для небольших, питающихся от батареек устройств, таких, как персональные электронные ассистенты. Несмотря на огромную разницу между этими приборами и настольными и портативными ПК, методики разработки программ для устройств Windows CE и компьютеров Windows во многом схожи. В данной статье мы расскажем о программировании для устройств Windows CE, но прежде всего попытаемся разобраться, что именно представляет собой Windows CE, чтобы провести черту между операционной системой и конкретными платформами, на которых она работает.
Windows CE - это совершенно новая версия Windows. Ее нельзя назвать обновленной или упрощенной версией Windows 98 или Windows NT. В отличие от них Windows CE с самого начала проектировалась как новая операционная система для устройств с питанием от батарей, по габаритам значительно уступающих стандартным ПК. Пользователям, вероятно, чаще приходилось слышать о Windows CE-компьютерах, таких, как ручные (hand-held, РПК) или карманные (Palm-size, КПК) ПК, чем о самой операционной системе. В ПЗУ подобных устройств, выпускаемых обычно производителями комплексного оборудования (OEM), например фирмами Hewlett Packard и Casio, занесена версия Windows CE. Поэтому пользователи избавлены от необходимости устанавливать Windows CE, она поставляется с такими приборами по умолчанию.
Интерфейс Windows CE предусматривает подмножество функций интерфейса прикладного программирования API Win32, применяемого в Windows 98 и Windows NT. Наверное, разработчики программ для Windows NT, услышав о "подмножестве", будут разочарованы, но не стоит волноваться, так как различия в API между версиями Windows для настольных ПК и Windows CE не вызовут больших проблем. Основные различия между ними сводятся к тому, что интерфейс Windows CE избавлен от избыточных функций, присутствующих в API Win32 для совместимости с предшествующими версиями Windows. Например, в версиях Windows для настольных систем имеется три или четыре способа открытия файла программными средствами. В среде Windows CE для этого существует только один способ - с помощью функции CreateFile.
Другие отличия API состоят в том, что в Windows CE не реализованы целые группы функций, которыми располагает Windows NT. Например, библиотека Winsock из состава Windows CE не содержит большинства функций WSAAsync, представленных в Windows 98 и NT. При этом функционально Windows CE отнюдь не беднее, только при программировании гнезд в среде Windows CE придется прибегать к услугам более простой Беркли-версии протокола sockets. Для Windows-программистов это означает необходимость освоения процедур применения базовых блокирующих и неблокирующих гнезд без таких полезных функций, как WSAAsync, которые в Windows 9x и NT отвечают за уведомление прикладных программ о событиях, происходящих с гнездом.
Другое важное различие между Windows CE и ее крупномасштабными родственницами состоит в том, что ее структура заранее предусматривает для OEM возможность изменения конфигурации, с тем чтобы система максимально соответствовала конкретным аппаратным платформам. Например, требования к профессиональным ручным ПК, которые представляют собой миниатюрные блокнотные ПК, работающие под управлением Windows CE, существенно отличаются от требований к ПК класса Palm-size. Поэтому Windows CE допускает разбиение на компоненты, чтобы изымать те части этой операционной системы, которые не понадобятся на целевой платформе. Подобная процедура вовсе не означает только исключение ряда DLL из состава ОС для конкретной платформы, варианты изменения конфигурации Windows CE гораздо разнообразнее. Например, API курсора, управляющий внешним видом указателя на экране, или даже компонент, отвечающий за работу с буфером обмена, вполне могут быть изъяты.
Задачу выбора компонента Windows CE решает производитель оборудования для платформ вертикального рынка или компания Microsoft для платформ горизонтального рынка. При разных сочетаниях компонентов образуются и соответствующие интерфейсы API. Следовательно, интерфейс API для РПК фирмы Casio идентичен API для РПК компании NEC, поскольку в обеих системах применяется одна и та же конфигурация Windows CE, подготовленная Microsoft для устройств класса РПК. С другой стороны, интерфейсы API устройств РПК и КПК несколько отличаются, поскольку конкретные компоненты Windows CE для этих двух платформ не совсем одинаковы. Однако не стоит придавать большое значение этим отличиям. Если не касаться специфических функций API, рассчитанных только на устройства одного класса, никаких проблем с разработкой программ для обеих платформ не будет. Всегда есть возможность предотвратить возникновение проблем, связанных со спецификой платформ, для этого достаточно явно подключить функции, ориентированные на конкретную платформу, с помощью команд LoadLibrary и GetProcAddress.
На самом деле самая серьезная проблема разработки программ, предназначенных для выполнения на обеих платформах, связана с разницей в размерах экранов, которыми оснащаются устройства этих классов. Например, вытянутый по горизонтали экран РПК (640Ч240 пиксел) требует иного расположения диалоговых окон, чем на вертикальном экране КПК (240Ч320). Разумное решение в этом случае - подготовить отдельную процедуру для работы с диалоговыми окнами, содержащую разные шаблоны окон для этих двух экранов, отличающихся габаритами. При таком подходе надлежащий шаблон может определять прикладная программа в ходе выполнения.
Еще одну проблему при программировании для устройств Windows CE создает вечно малый объем памяти рабочей среды, в которой приходится "существовать" программе. При том, что Windows CE предусматривает механизм подкачки страниц по мере надобности, она не позволяет применять файл подкачки для сохранения данных чтения-записи на вторичном устройстве памяти, например жестком диске. Другими словами, недоступные для записи страницы, например с программными кодами и постоянными данными, переносятся в память, как только в них возникает необходимость. Однако данные для чтения-записи никогда не заносятся в файл подкачки на жестком диске. Благодаря таким ограничениям быстрее происходит запуск программ в Windows CE, поскольку в память загружаются только те части программы, которые нужны на момент запуска. Но, поскольку Windows CE не позволяет сохранять в файле подкачки переменные данные, в распоряжении прикладных программ находится весьма ограниченное в объеме физическое ОЗУ устройства. По этой причине, вполне возможно, временами в ходе выполнения программа будет испытывать острый недостаток памяти. Следовательно, программы для Windows CE должны быть предельно "экономны" в потреблении оперативной памяти и снабжены средствами для "мягкого" выхода из возникающих в связи с этим аварийных ситуаций.
Инструменты
Как известно, Windows CE рассчитана на самые разные устройства, это серьезно осложняет жизнь создателям средств разработки. Поскольку Windows CE совместима с различными ЦП и предусматривает множество вариантов настройки, причем для каждого из них применяется свой API, необходим какой-то способ передачи конкретной среде разработки информации о целевой платформе. Для решения этой задачи Microsoft подготовила целый набор пакетов разработки для Windows CE, некоторые из них совместимы со всеми платформами, а другие ориентированы только на обычные и профессиональные ручные ПК.
Эти инструменты предназначены для применения в среде Windows NT. Разработка программ происходит в среде Developer Studio с помощью одного из упомянутых ниже языков. Готовая программа выполняется на Windows CE-устройстве, подключенном к ПК разработчика либо через последовательный порт, либо через локальную сеть. Соединение через последовательный порт - стандартный способ подключения в Windows CE, применяемый для синхронизации данных между ними и ПК. Сетевые соединения обеспечивают гораздо более высокую скорость загрузки, чем первый способ, но, к сожалению, некоторые инструменты отладки отказываются работать, если Windows CE-устройство подключено таким образом.
Microsoft предлагает версии языков Visual C++, Visual Basic и Visual J++ для одной или нескольких платформ Windows CE. Имеющиеся ныне версии Visual Basic и Visual J++ для Windows CE ориентированы только на обычные и профессиональные ручные ПК. В настоящее время для подготовки программ, рассчитанных на другие платформы, пригодна лишь версия Visual C++, совместимая с любой из них. Поэтому в нашей статье мы рассмотрим только среду программирования Visual C++, хотя не исключено, по множеству причин читатель предпочтет какой-то другой из языков.
Прежде чем приступить к разработке программы для Windows CE на языке Си или Си++, нужно установить стандартную версию Visual C++ (5.0 или 6.0) для настольных ПК, а затем расширение Visual C++ для Windows CE, которое поставляет Microsoft. Оно содержит компиляторы для всех возможных ЦП, с которыми работает Windows CE, а также версии MFC и ATL, рассчитанные на устройства РПК. Это расширение позволяет составлять программы и для ПК, просто благодаря ему увеличивается перечень целевых платформ и появляется возможность разработки приложений для Windows CE.
Для переноса Windows CE на новую аппаратную платформу Microsoft предлагает еще один инструмент - Windows CE Platform Builder - преемник набора Embedded Toolkit, который применялся в более ранних версиях Windows CE. С помощью данного инструмента можно представить операционную систему в формате библиотеки объектов, с тем чтобы разработчик разбил ее на компоненты и подготовил версию этой ОС для конкретной платформы. В состав Platform Builder входят также инструменты для формирования SDK, рассчитанного на конкретную платформу, для которой подготавливается разбитая на компоненты операционная система.
Те программисты, которые разрабатывают программы для РПК или других горизонтальных платформ, вполне обойдутся без Platform Builder, но его, несомненно, стоит порекомендовать серьезным авторам Windows CE-приложений. Этот сложный набор инструментов обеспечивает бесценную информацию об архитектуре Windows CE. Позднее мы поговорим о Platform Builder подробнее.
Базовый цикл разработки программ
А теперь приступим к разработке настоящей Windows CE-программы. Последовательность необходимых для этого шагов здесь такая же, как и при подготовке программы для Windows настольных систем. Для начала организуем новую рабочую область в окне Visual C++. Можно прибегнуть к услугам одного из множества "мастеров", призванных помочь в составлении Windows CE-программ, либо заняться этим самостоятельно, выбрав тип приложения Win32 application и установив флажки для тех процессоров, на которые, как предполагается, будет рассчитана программа.
По завершении разработки проекта следует просто набрать текст программы и подготовить ресурсы, в том числе меню, пиктограммы и шаблоны диалоговых окон, почти так же, как в ходе аналогичных процедур в среде Windows 98 или Windows NT, исключение составляют вышеупомянутые отличия в API. Как было отмечено ранее, отличия эти не слишком значительны; тем не менее некоторые особенности модели программирования для Windows CE все же заслуживают внимания. Первая, и, на поверхностный взгляд, наиболее удивительная из них, - отсутствие в Windows CE меню для окон верхнего уровня. Это не означает, что Windows CE-программы не могут иметь меню, просто управление ими организуется через панель команд.
Элемент управления "панель команд" и ее более сложные "сестры" - "командные полосы" - обеспечивают доступ к меню и инструментальным панелям, кроме того, предусматривают место для размещения кнопок вызова справочной системы программ Windows CE и их закрытия. Благодаря своей конструкции эти элементы управления предельно просты в программировании. На деле незамысловатая панель команд, которая обеспечивает доступ к меню и кнопкам закрытия программы, может быть представлена всего тремя строчками в тексте программы. В элементе управления "командная полоса" получила дальнейшее развитие концепция панели команд, компоненты которой, т. е. меню, кнопки и другие элементы, группируются в отдельные полосы, размещаемые на экране пользователем. Основой данного элемента служит элемент управления rebar (повторно используемая панель), разработанный для Internet Explorer 3.
Еще одно отличие Windows CE-программ состоит в том, что в масштабах отдельной программы пиктограммы назначаются классам, а не экземплярам окна. Следовательно, два окна одного и того же оконного класса будут иметь одну и ту же пиктограмму. Это не играет особой роли, поскольку пиктограмма окна отображается только на соответствующей кнопке панели задач.
Большинство остальных отличий, не считая уже перечисленных, касается соглашений по программированию, а не ограничений для программ или различий в реализации. Например, окна верхнего уровня в Windows CE могут содержать строки заголовка, в то время как по имеющимся соглашениям это недопустимо. Подобный запрет вызван необходимостью экономии места на крохотных экранах устройств Windows CE. В версиях Windows для настольных систем строка заголовка применяется для перемещения окна по экрану. Такой функции в Windows CE-системах чаще всего нет, так как по умолчанию окна верхнего уровня в Windows CE занимают весь экран.
Здесь уместно упомянуть одну из новинок Windows CE. Начиная с версии Windows CE 2.1 диспетчер окон обзавелся средствами для работы со стандартными окнами переменного размера. Операционная система всегда обеспечивала возможность формирования окон любого фиксированного размера, однако теперь диспетчер окон позволяет окаймлять перекрывающиеся окна рамками, в результате пользователь может менять их размеры. Тем не менее даже на новых профессиональных РПК такое увидишь не часто, поскольку по умолчанию окна верхнего уровня занимают всю площадь экрана, несмотря на его относительно немалые размеры.
Достаточно взглянуть на этот текст, чтобы увидеть, как похожи приложения Windows CE на обычные Windows-программы.
И конечно, с помощью интегрированного отладчика можно выполнять программу в пошаговом режиме. Основное различие между отладкой программ для Windows CE и Windows NT вызвано влиянием скорости последовательного соединения между ПК разработчика и удаленной Windows CE-системой. Из-за низкой скорости такого соединения пошаговая отладка превращается в раздражающе медленный процесс. Что касается меня, я обычно применяю отладчик только для поиска самых трудноуловимых ошибок.
Вместо дистанционного отладчика можно применять другой вариант. Все SDK для платформ РПК, КПК и автомобильных ПК (Auto PC) оснащены программными эмуляторами, которые пытаются имитировать удаленное Windows CE-устройство в среде Windows NT. Такой эмулятор запускает скомпилированную специальным образом версию подготовленной программы. Он эмулирует интерфейс API Windows CE, в том числе такие его расширения, как API СУБД. Но и здесь не обходится без проблем: модель среды Windows CE, обеспечиваемая эмулятором, далека от идеала. Иногда после целого дня работы вдруг понимаешь, что проблема, над решением которой бьешся, - проблема эмулятора, а не ошибка в программе.
Но выход из создавшейся ситуации все же есть: программы для Windows CE следует составлять таким образом, чтобы они компилировались как для Windows CE, так и для Windows NT. В результате общие для обеих систем фрагменты приложения можно отлаживать локально в среде Windows NT, а затем, выбрав иную целевую среду, провести компиляцию для Windows CE. Нужно только помнить, что многократные компиляции на любой из платформ чреваты сложностями. После бесконечных повторов компиляции для Windows NT придется потратить массу времени, чтобы путем внесения изменений добиться надлежащего функционирования программы в среде Windows CE.
Platform Builder
Подготовка программ для Windows CE - только одна сторона работы с этой операционной системой. Известно, что версии Windows для настольных машин можно переносить на другие совместимые ПК, однако права на поставку комплектов инструментов, необходимых для этих целей, принадлежат компании Microsoft и ее уполномоченным OEM-партнерам. Напротив, аналогичный набор Platform Builder для Windows CE, несмотря на его дороговизну, распространяется через розничные каналы. Таким образом, разработчики программ для Windows CE могут не только составлять программы, но и подготавливать различные версии самой операционной системы.
В состав Platform Builder входят тексты образцов программ для слоя абстракции OEM (OEM abstraction layer, OAL), который представляет собой слой программ, разработанных производителем оборудования для адаптации Windows CE к конкретной аппаратуре. OAL содержит ПО слоя аппаратной абстракции (Hardware Abstraction Layer, HAL), предназначенное для обслуживания ядра Windows CE, а также драйверы для встроенных аппаратных компонентов, например клавиатуры, сенсорного экрана и дисплея. Кроме того, имеются тексты программ для образцов драйверов аудиоустройств и последовательного порта, а также драйвера контроллера PCMCIA.
Комплект Platform Builder предусматривает и средства низкоуровневой отладки. Эти инструменты предназначены прежде всего для содействия в переносе Windows CE на новые аппаратные платформы, но они вполне пригодны и для диагностирования трудноустранимых проблем прикладного ПО. В новейших версиях Windows CE есть специальные программные процедуры для работы со встроенным профилировщиком Монте-Карло - весьма удобным средством оптимизации производительности программ. Наконец, Platform Builder сопровождает обширная, с точки зрения производителя оборудования, документация по эксплуатации Windows CE.
Программирование в среде Windows CE - занятие довольно интересное. Интерфейс API Win32 придает этому процессу сходство с программированием для Windows 98 или NT, однако при разработке программ приходится учитывать аппаратные ограничения. Менее быстродействующие ЦП и ограниченный объем памяти большинства Windows CE-устройств заставляют тщательно продумывать подходы к программированию, чтобы повысить эффективность своих творений. На самом деле довольно забавно в наше время, т. е. в эпоху многомегабайтных программ для ПК, увидеть программистов, всерьез озабоченных быстродействием ЦП и объемами программ.
контейнер приложений Windows CE — это технология, позволяющая большинству приложений CE выполняться на Windows 10 IoT Базовая.
Решение создается в два этапа. на первом этапе создается образ Windows CE 2013 с использованием загрузочного процессора для архитектуры x86 или ARM32. затем на втором этапе этот образ включается в образ Windows 10 IoT Базовая, который использует загрузочный процессор x64 или ARM32 для конкретного оборудования устройства, на котором будет установлено решение.
дополнительные сведения об этой архитектуре см. в этом видео: модернизации Windows CE devices.
Предварительные требования
для контейнер приложений Windows CE программного обеспечения требуется обновленная версия Windows Compact 2013 (сборка с номером 6294 с июня 2020 или более поздней версии) вместе с обновленными пакетами Windows 10 IoT Базовая для x64 и ARM32 (обновление за август 2020 и более поздние версии). чтобы получить последние пакеты для Windows 10 IoT Базовая, обратитесь к своему распространителю майкрософт.
Для распространения устройства, использующего технологию контейнера приложения CE, необходимо иметь действительную подписку на основные службы Интернета вещей .
Кроме того, вам потребуется следующее:
Microsoft Visual Studio 2013 Professional или Visual Studio 2015 Professional. Эти версии необходимы как для построителя приложений, так и для средств платформы Platform Builder.
Platform Builder для Windows Compact 2013
Рабочий загрузочный процессор Интернета вещей Core
не забудьте установить обновленные компоненты вместо компонентов, упоминаемых в этом пошаговом руководству (Windows 10 adk и Windows 10 надстройки PE для интернета вещей, надстройки IoT Core, панель мониторинга Windows 10 IoT Базовая).
настройка, сборка и упаковка CE для контейнер приложений Windows CE
процесс создания Windowsного образа Embedded Compact 2013 не был значительно обновлен. Общий процесс создания образа:
Создание проекта разработки ОС с помощью Platform Builder
Выберите пакет поддержки доски Builder (BSP)
Выберите подходящий шаблон проектирования
Настройка параметров, предоставляемых шаблоном проектирования
При необходимости добавьте подпроекты в проект проекта
Основное изменение заключается в выборе правильного загрузочного процессора и дополнительных соображениях для образа CE. в этом учебнике предполагается, что вы уже знакомы с процессом создания образа системы Windows CE, но в измененном разделе стоит взглянуть на более глубокое рассмотрение.
Шаг 2 является единственной частью предыдущего процесса проекта ОС, который изменяется при использовании контейнера приложения CE. Дополнительные сведения см. ниже.
Шаг 2. Выбор загрузочного процессора Platform Builder
для поддержки контейнер приложений Windows CE в построитель платформ добавлен новый BSP, предназначенный для архитектуры x86 и ARM.
при создании структуры ос для контейнера приложения CE выберите либо "контейнер приложений Windows CE: x86", либо "контейнер приложений Windows CE: ARMv7" (ARM32) в зависимости от базового оборудования для устройства на основе интернета вещей Core.
например, если на целевом устройстве IoT Core используется оборудование Intel, выберите параметр "контейнер приложений Windows CE: x86". кроме того, если оборудование центра интернета вещей использует нксп i. MX6, выберите параметр "контейнер приложений Windows CE: ARMv7".
после этого у вас будет возможность настроить параметры и подпроекты так же, как и для Windows внедренного компакт-образа. эти конфигурации будут встроены в контейнер CE, который будет развернут в образе Windows 10 IoT Базовая.
создание образа Windows 10 IoT Базовая
этот процесс более подробно рассматривается в лабораторных занятиях, которые являются частью Windows 10 IoT Базовая производственном руководством. В разделе ниже приведены только дополнительные действия, выполняемые на определенных этапах процесса создания образа в центре Интернета вещей. прежде чем продолжить, настоятельно рекомендуется ознакомиться с руководством по производству Windows 10 IoT Базовая.
Общие сведения о процессе
в отличие от процесса создания Windows внедренного образа Compact, Windows 10 IoT Базовая дефрагментации еще интегрирует создание встроенного по, пакетов поддержки плат, определения образа и включения приложения. Используя различные технологии для этих компонентов, можно разделить работу, необходимую для различных команд или отдельных лиц в Организации.
Ниже приведены основные шаги по созданию образа.
Импортируйте созданный ранее контейнер приложения CE
подробные руководства по каждому из этих шагов приведены в составе руководства по производству Windows 10 IoT Базовая. Хотя некоторые из этих шагов подобны процессу использования Platform Builder (PB) для создания образа устройства, стоит изучить некоторые области более глубоко.
Шаг 1. Создание рабочей области
Чтобы узнать, как создать рабочую область, ознакомьтесь с документацией, Создайте базовый образв руководстве по производству центра Интернета вещей Core.
Шаг 2. импорт соответствующего пакета поддержки для основной платы Интернета вещей (BSP)
Ознакомьтесь с документацией, Создайте базовый образв руководстве по производству центра Интернета вещей для поддержки вашей платы.
шаг 3. импорт контейнер приложений Windows CE
контейнер приложений Windows CE создается с помощью инструкции PB, как описано выше, и импортируется в рабочую область центра интернета вещей с помощью команды Import-иотцепал . Эта команда скопирует требуемое содержимое из каталога неструктурированного выпуска CE в рабочую область IoT ADK. Если вызывается несколько раз, предыдущее состояние архивируется в Source-\$Arch\CEPAL.OLD каталоге в рабочей области.
Шаг 4. Создание определения продукта
Чтобы создать определение продукта, ознакомьтесь с документацией, Создайте базовый образв руководстве по производству центра Интернета вещей Core.
Шаг 5. Добавление в продукт контейнера приложения CE
После импорта определения контейнера приложения CE в рабочую область необходимо убедиться в выполнении команды Add-иотцепал , которая добавит ссылку на пакеты контейнеров приложений CE в соответствующий продукт OEMInput.xml файлы (Test и Retail).
Следующим шагом является добавление IOT_CEPAL компонента в OEMInput.xml с помощью команды Add-иотпродуктфеатуре . это добавляет поддержку узла Windows для контейнер приложений Windows CE (Windows CE клиентское приложение UWP и драйверы поддержки) в определение продукта и включает контейнер приложения CE в группу приложений по умолчанию. Мы обсудим конфигурацию запуска в более позднем разделе.
Шаг 6. Создание CAB-файлов
Это важный шаг во время создания ФФУ и должен выполняться при каждом изменении конфигурации, добавлении или изменении приложения или драйверов. Вы будете использовать New-иоткабпаккаже с параметром ALL. Кроме того, при необходимости можно создать отдельные компоненты, но в целом следует перестроить все пакеты до этапа создания ФФУ в качестве рекомендации.
Шаг 7. Развертывание ФФУ на устройстве
После сборки образа его можно развернуть на устройстве. это можно сделать из командной строки с помощью DISM, с помощью процесса развертывания для конкретного устройства или панель мониторинга Windows 10 IoT Базовая. дополнительные сведения можно найти в составе Windows 10 IoT Базовая производственном руководством.
развертывание контейнер приложений Windows CE на устройстве при использовании существующего ффу
Файлы CAB для CE — это развертываемые пакеты в IoT Core. Если имеется образ Интернета вещей Core, эти CAB-файлы можно развернуть на устройстве с помощью APPLYUPDATE команды. Сначала скопируйте CAB на устройство, а затем выполните этап и зафиксируйте CAB с помощью APPLYUPDATE . Обратите внимание, что обновление таким образом учитывает управление версиями пакета, поэтому, если на устройстве развертываются обновленные версии пакетов, они должны иметь более высокий номер версии. (См. команду Set-IoTCabVersion в среде IoT ADK). Дополнительные сведения об этом можно найти в статьях Создание и установка пакетов .
Шаг 8. Создание образа для розничной торговли
Помимо средств разработки и развертывания, установленных на компьютере, для включения розничного подписывания потребуется следующее:
- Сертификат подписывания кода розничной торговли
- Сертификат перекрестной подписи
Правильная подпись и включение приложений
если у вас есть одно или несколько пользовательских приложений, которые необходимо включить в Windows 10 IoT Базоваяный образ розничной торговли, необходимо убедиться, что эти приложения подписываются надлежащим образом при их включении в розничный образ.
Дополнительные сведения
Добавление новых приложений к существующему образу
чтобы добавить новое приложение в существующую структуру ос, можно добавить проект в качестве подпроекта в Project проектирования ос или создать обычные пакеты CAB-файлов развертывания для развертывания на устройстве в ходе первоначальной настройки устройства.
Рекомендации по упаковке
Следует всегда следить за тем, чтобы пакеты были максимально детализированы для сокращения времени обновления.
Так как пакет является наименьшей единицей обновления, убедитесь, что размер каждого пакета максимально мал. При построении в построителе платформ созданные пакеты разделяются в соответствии с разделом памяти, типом модуля или файла в соответствии с автоматическим файлом BIB.
Для пользовательских ресурсов, созданных в Platform Builder и упакованных через Осдесигн. Bib, рассмотрите возможность добавления пользовательских ресурсов в отдельный раздел памяти в BIB (не в NK), чтобы обновления пользовательского кода могли поставляться отдельно от обновлений в ОС CE.
Для пользовательских ресурсов, добавленных с помощью команд пакета IoT ADK: Убедитесь, что созданные пакеты имеют максимально возможный размер.
Добавление других объектов в пакет Platform Builder
Как правило, рекомендуется не изменять полученный пакет, созданный построителем платформ, для включения дополнительных компонентов в образ системы. вместо этого следуйте руководству по производству Windows 10 IoT Базовая. Однако, если файлы необходимо добавить в пакет, созданный с помощью Platform Builder, выполните существующий процесс. При добавлении содержимого в пакет, созданный с помощью PB, учитывайте следующее.
Максимальный размер пакетов (около 400 МБ) и превышение этого размера приведет к невозможности обновления.
Обновления происходят при детализации пакета. Если необходимо обновить один ресурс в пакете, все ресурсы этого пакета будут обновляться одновременно. Чтобы уменьшить размер обновлений, изолируйте содержимое в отдельные пакеты, чтобы свести к минимальному размеру всего обновления.
Добавление дополнительных файлов с помощью Platform Builder
Описанный выше процесс упаковки управляется теми же входными данными, которые приводят к созданию файла-корзины CE. Таким образом, если файлы указываются в Осдесигн. Bib и записи реестра добавляются в Осдесигн. reg, MAKEIMG процесс будет включать эти файлы в полученный CAB-файл. В течение этого процесса MAKEIMG будут доступны следующие действия:
ROMIMAGE создаст каталог с именем CEPAL\_PKG в каталоге неструктурированного выпуска (фрд), который будет служить стадией установленной структуры каталогов для Windows CE для цепал.
ROMIMAGE выполняет инвентаризацию всех файлов CE, которые были размещены на CEPAL\_PKG основе файлов CE BIB.
ROMIMAGE создаст несколько WM.XML файлов для каждого раздела памяти. Это делается для того, чтобы обновления могли быть отправлены более детализированным образом, так как минимальная единица обновления является пакетом.
ROMIMAGE создаст, ссылающийся на все созданные пакеты.
Всем созданным пакетам будет присвоено имя с фиксированным префиксом “%OEM\_NAME%.WindowsCE.\*” , где %OEM\_NAME% заполняется в процессе создания ядра IOT при вызове “%OEM\_NAME%.WindowsCE.\*” . Имя пакета в пространстве имен является производным от раздела Memory в файле BIB (например, NK), за которым следуют модули и файлы (также определяемые файлом BIB).
обмен данными между Windows Embedded Compact 2013 и Windows 10 IoT Базовая приложений
Для обмена данными между приложениями, работающими в контейнере CE, рекомендуется использовать локальный замыкание на себя. Дополнительные сведения о локальном замыкании на себя можно прочитать в этом документе.
Автоматический запуск приложения в контейнере приложения CE
Чтобы автоматически запустить приложение-контейнер CE, можно создать пакет подготовки , который задает для приложения запуска значение "Майкрософт". Windows. IoT.CEPAL.DkMonUWP_cw5n1h2txyewy! Приложение "и включило этот пакет подготовки в образ. Также необходимо удалить приложение, запускаемое по умолчанию, с помощью команды Remove-иотпродуктфеатуре и удалить идентификатор компонента IOT_BERTHA из определения продукта центра Интернета вещей.
доступные параметры конфигурации для контейнер приложений Windows CE
Конфигурация на основе реестра в CE
Неисполняемый стек по умолчанию
по умолчанию в контейнер приложений Windows CE отключены исполняемые страницы стека для повышения безопасности. Однако некоторые устаревшие приложения могут правильно работать с этим поведением. Чтобы включить стек исполняемых файлов, установите следующее значение реестра в образе CE (рекомендуется переходить в Осдесигн. reg в Platform Builder).
16-разрядное переопределение 565 для ГВЕС
если контейнер приложений Windows CE настроена с 32-разрядным дисплеем, то преобразование 16-битных в 32-битные преобразования rgb выполняется гвес. предполагается, что 16-битные пиксельные данные rgb находятся в формате RGB555. Если ресурсы точечного рисунка находятся в 16-разрядной 565 и преобразование в RGB555 этих ресурсов невозможно, поведение преобразования ГВЕС по умолчанию можно изменить с помощью раздела реестра. Создайте следующий раздел реестра:
Настройка на основе реестра в узле (IoT Core)
настройка последовательных портов для контейнер приложений Windows CE
Последовательные порты узла должны быть сопоставлены с средой CE. Это сопоставление существует в реестре центра Интернета вещей Core и должно быть настроено создателем образа.
В разделе HKEY\_CURRENT\_USER\Software\Microsoft\Windows NT\CurrentVersion\CEPAL\Devices\Serial имеются записи конфигурации, позволяющие сопоставлять гостевые COM-порты для размещения COM-портов с помощью следующей схемы.
Если указанный выше путь к реестру не существует при загрузке CE, то конфигурация по умолчанию будет записана на основе обнаруженных последовательных устройств в системе.
Конфигурация на основе файлов в узле
Контейнер CE можно настроить с помощью локального файла на узле C:\WindowsCE\CEEnvConfig.json . Ниже приведен пример этого файла конфигурации.
оемоптионс
Ключ | Описание |
---|---|
Графический пользовательский интерфейс | Запуск контейнера приложений CE с помощью пользовательского интерфейса (по умолчанию true) |
Ширина | Ширина экрана для контейнера приложения CE (по умолчанию 1024) |
Высота: | Высота отображаемого контейнера приложения CE (по умолчанию 768) |
филлскрин | |
Clientareawidth | Задает биты по умолчанию на пиксель (по умолчанию 32) |
рефрешрате | Количество перерисовок отображения в секунду |
ноаслрсуппорт | Отключает случайный выбор макета адресного пространства в контейнере приложения CE (значение по умолчанию — true) |
оемконфигапп | Имя семейства пакетов для предоставленного изготовителем оборудования приложения, которое должно быть запущено для настройки. |
оемконфигфиле | Путь к файлу, содержащему дополнительные параметры конфигурации, общие для Оемконфигапп и контейнера приложения CE |
Контейнер приложения CE предоставляет только один сетевой интерфейс, доступный для использования. Если в системе размещения имеется несколько сетевых интерфейсов, необходимо выбрать один из них в реестре узла, чтобы убедиться, что выбранная сетевая карта детерминирована.
Всем привет! Ох, давненько я не писал тут, аж драйв упал)) Как началась запара с работой год назад, забросил я писанину, а потом свадьба, хлопоты и лень — взяли своё))) С машиной всё хорошо, полностью исправна, пару дней назад кончилась гарантия))) За прошедший год есть о чем рассказать по-мелочи, но сейчас не об этом.
В общем, пора вернуться, тем более появился очень весомый повод сделать новый пост.
Осторожно! Много текста!
Итак! Теперь у меня полноценный Apple CarPlay на штатном "говне мамонта", как называют наш мафун некоторые владельцы Вест и не только))
Данный разговор завел меня в инет, "А вдруг что-нибудь еще придумали? Помимо пресловутой CAN-панели"
И тут я наткнулся на группу ВК — CarPlay/AndroidAuto в ЛЮБОЕ АВТО!. Там обещают запустить CarPlay и AndroidAuto на любом ГУ авто, работающим на базе Android, и, внимание, на Windows CE 6.0, собственно на этой Винде и работает наш штатный мафун.
В этой группе есть несколько вариантов устройств: для беспроводной связи, для проводной связи и для машин, где с завода предусмотрен CarPlay, но по проводу, а данное устройство делает связь беспроводной.
В моем случае требовался именно беспроводной вариант, т.к. данное устройство подключается в USB-порт магнитолы, а напряжение там слишком мало, чтобы заряжать телефон, тобишь телефон будет просто садиться при таком подключении. Да и в принципе, какой смысл? — без провода намного удобнее, в этом и есть вся фишка!
Выбрали беспроводной черный адаптер, стоимостью 5999 руб. Решили пробовать! И, в случае успеха, с последующей от меня инструкцией и публикацией данного поста, согласились сделать мне небольшую скидку. Ну, а если не получится, сделают возврат. Как вы уже поняли — успех есть!)
Кстати, для читателей тоже будет скидка в 500 руб. по кодовому слову — ВЕСТА
В этот же день данная приблуда была уже у меня, и понеслась!
Кто готов ждать, данное устройство можно найти дешевле и на Али, правда не будет поддержки и помощи в настройке, которую мне оказали в этой группе. Почти все продавцы на Али этих устройств даже не заявляют работу на Windows CE, т.к. её поддержка давно прекращена. Да и ждать я был не готов, даже до следующего дня))
Завелось всё практически сразу, но с нюансами и глюками, с которыми я боролся ещё несколько дней. Тем не менее с работы в тот день я уже доехал по Яндекс.Навигатору с мафуна)) Сейчас всё работает практически идеально. Далее расскажу как и что нужно сделать.
1. Для работы донгла требуется приложение AutoKit — скачать. Скачиваем, распаковываем архив на SD флешку.
Флешку на всякий случай купил новую, стоит рублей 200))) заказал на озоне экспресс доставкой за бонусы, привезли за час)) деньгами не платил.
Запускается приложение из под оболочки Windows CE. Как туда выйти наверное многие знают, подробно расписывать не буду, если что есть инструкция на 4pda. А запустить проводник можно ещё раз тыкнув по углам окна "SYSTEM STATUS", либо через программу "Выполнить", написав "explorer.exe".
С флешки "SDMemory" я сразу перенес программу в память самой магнитолы "SDMMC"
Запускается программа кликом по файлу AutoKit.exe в папке "BIN". Если запустилась, значит адаптер должен заработать.
2. Для удобства запуска есть несколько вариантов. Можно подменить штатный СитиГид, для этого надо переименовать папку с СитиГидом на любое другое имя, а из папки программы AutoKit скопировать папку "BIN" в корень "SDMMC", переименовать её под папку СитиГида, а "AutoKit.exe" переименовать в файл запуска с таким же именем, что был у навигатора. Я пробовал данный вариант один раз в ходе ковыряний "для галочки", но как-то мне показалось глючным, не с первого раза открывалось, и вернул всё как было. Да и не планировал я изначально использовать таким образом.
Мой вариант — AppLauncher, тоже известный патч на драйве, у многих он уже есть. Разработал его KarpukAV , но в итоге забросил. До недавнего времени данной прогой занимались в группе ВК — ММС Lada Vesta, куда я и обратился, но получил ответ, что они прекратили поддержку лаунчера(((
Однако, один из админов всё ещё конфигурирует последнюю версию данного патча под конкретную магнитолу и продает по 1000 руб. — Андрей Ступаков. Мне некогда было заморачиваться с поисками, да и хотелось, чтобы всё работало идеально, так что я взял у него, прислав фотку с окном характеристик своей магнитолы. Если будут желающие, можно обращаться к нему. Андрей любезно предварительно перед покупкой протестировал программу AutoKit на предмет работы в апплаунчере, всё заработало.
На просторах инета конечно можно найти аплаунчер бесплатно, но всякие кривые сборки по слухам могут превратить мафун в кирпич(( Рисковать я тоже не хотел, да и сумма не так уж и велика, тем более по такому случаю))
Установка элементарная, подробно тоже не буду расписывать, к самой программе всегда прилагается инструкция в пару кликов.
После установки аплаунчера нужно добавить приложение для донгла в него.
Исполняемый файл — выбираем AutoKit.exe из перемещенной ранее папки с прогой в память магнитолы;
Название — любое, я вписал "CARPLAY";
Меню программы — это стрелочка быстрого закрытия программы, сначала использовал, но потом убрал. В правом верхнем углу мешается в навигаторе, в правом нижнем тоже мешается, а в других местах — некрасиво)) Тут на ваше усмотрение. Мне достаточно кнопки "MODE" на магнитоле и руле, чтобы вернуться в меню магнитолы, а закрывать сам CarPlay для использования других нештатных программ в апплаунчере мне не нужно;
Имя окна приложения — выбираем "AUTOPLAY";
Время ожидания — по умолчанию 5 сек, можно не трогать. Я вернул в итоге на дефолт.
На вкладке "Дополнительные" можно задать иконку для приложения
Свою картинку взял из папки с программой AutoKit, лежат по пути Change icon\Car-icon. Обычная машинка — это файл "AutoKit_default". При желании можно самому нарисовать что угодно)) Или найти в интернете готовые.
4. Запускаем добавленную программу, теперь надо немного сконфигурировать
Глобусиком меняется язык, есть Русский. Подсоединяем приблуду в USB-порт магнитолы под консолью и нажимаем стрелочку в верхней части экрана
1 — ВАЖНО! Установить на "Slow", иначе при подключении телефона будет черный экран, видимо связано с разрешением нашей магнитолы;
2 — Громкость 50 — не трогаем;
3 — Анти черный экран тыкал и так и так, разницы не увидел, оставил включённым;
4 — Режим зарядки меняет напряжение на выходе из адаптера, полезно если использовать проводное подключение, но толку мало, порт не используется, поставил на "Слабый";
Сначала я подключил в USB-порт адаптера видеорегистратор, чтобы не занимать выходы на прикуривателе, НЕ ДЕЛАЙТЕ ТАК! Адаптер начинает периодически "отваливаться" от магнитолы
5 — Режим подключения — Автоматический;
6 — Полевой микрофон — это встроенный микрофон на адаптере. Тут надо тестить, смотря как расположите у себя адаптер. Без движения и на небольшой скорости он работает лучше встроенного в мафун, но на скорости — хуже из-за моего расположения и шумов от дороги. Если включить — будет работать он, выключить — встроенный в мафун. Можно поэкспериментировать)) В идеале хочу вообще использовать микрофон от AppleWatch на руке, он работает лучше их вместе взятых)) пока не пробовал. Вроде как можно только если звук разговора будет идти через них же, а не через динамики авто.
Скотч клеил на сторону адаптера с надписями, чтобы микрофон смотрел в верх.
Над нишей под консолью очень подходящая для этого полочка, и подсветке не мешает.
5. Далее дело за малым. Ищем в блютуз телефона адаптер, подключаемся, активируем CarPlay и вуаля!
6. Но есть нюанс. По началу у меня никак не хотел идти звук через CarPlay. День ездил с подключенным одновременно CarPlay и блютузом непосредственно к самой магнитоле как раньше без адаптера, но такая схема не очень, хоть и рабочая.
При звонке штатная звонилка магнитолы сворачивала интерфейс CarPlay, что не очень удобно, когда едешь по навиатору, более того, любое обращение к голосовому набору в навигаторе или Siri так же сворачивает карплей на штатную звонилку, бесило жутко, да ещё и иногда зависал AutoKit от таких манипуляций, приходилось перезапускаться. Даже думал уже не писать на драйве об этой приблуде.
Но решение нашлось, помог 4pda по аналогичной ситуации, что было с Навителом.
На телефоне в блютузе забываем устройство (саму магнитолу), а на магнитоле выключаем блютуз.
Минус данного решения один — перестают работать кнопки переключения трека и ответа на звонок с руля, громкость при этом работает как надо. Переназначение кнопок для Windows CE версии программы китайцы не завезли(( только для Android версии. Но лично для меня это менее критично, чем сворачивающаяся программа)) Более того, все эти функции прекрасно выполняет Siri. Ну а громкость регулируется нормально и с магнитолы, и с руля.
Иногда при случайном нажатии кнопки ответа на звонок, запускается тот самый файлик и музыка начинает изредка прерываться на секунду, возможно даже однократно (было пару раз, не знаю), но достаточно просто нажать кнопку сброса звонка (поставит паузу на этом файле) и всё))
Тут уже как кто захочет, можно и использовать и с одновременным подключением по блютузу, тогда работает всё, но сворачивается при звонке и на голосовых помощниках. Лично у меня еще зависала программа при обращении к Siri, но не уверен, что именно из-за этого, т.к. ещё был в процессе поиска "правильных" настроек.
ИТОГ: Всё что нужно — работает! При запуске авто магнитола сразу же запускает CarPlay сама (5-7 сек). А если завести с автозапуска, CarPlay подключиться сразу, как адаптер увидит в зоне действия ваш телефон. Звонки, голосовые помощники — всё работает, ничего не сворачивается. Яндекс.Навигатор, Google Maps, 2ГИС, Яндекс.Музыка, Apple Music, Календарь, Telegram, WhatsApp и все прочие плюшки CarPlay в вашем распоряжении))
Идешь к машине, проложил себе маршрут в навигаторе на телефоне, выбрал желаемый плейлист, сел в авто, а там уже все проложено и играет музон)) Кайф!
Телефон я даже не достаю при этом из кармана, если поездка намечается не долгая, ну а если долгая, просто ставлю на зарядку)) Никаких теперь лишних манипуляций, ужасно бесящих телефонных держалок на вент. решетку и не дай боже — присоску. Осталось только избавится от видеорегистратора на лобовом, но об этом чуть позже, будет интересно!)
Всё так же будет и с AndroidAuto, кто ходит с гуглфонами. Ну а у кого сама магнитола на Android (тот же Teyes) и вдруг вам нужен CarPlay, с соответствующим адаптером будет еще проще и удобней.
Лично я до сих пор на штатном мафуне только из-за того, что у Teyes мне ОЧЕНЬ не нравится внешний вид, сенсорные кнопки — они же кривые, под углом каким то)) смотрится уж очень колхозно. Была у них кнопочная версия с крутилками, которая тоже "не ахти" конечно, но они её убрали с продажи уже очень давно. Даже было время почти купил, с намерением сразу же закатать эти кнопки в какую-нибудь непрозрачную пленку))) Хорошо, что не решился. А так, я находил за 40+ тыс. рублей магнитолы на Android, даже со встроенным CarPlay от тех же Redpower, но теряешь динамические линии и не редко брак(( особенно спустя время, а штатный мафун без единого глюка пашет уже 3 года. Ну, а теперь, и вовсе нет смысла его менять))) всё работает и штатно, и с карплеем!)))
Доволен как слон!
P.S. Отдельное спасибо Николаю из группы ВК — CarPlay/AndroidAuto в ЛЮБОЕ АВТО! за посильную помощь и ответы на вопросы до поздней ночи. Даже предлагал встретится лично, чтобы помочь сдружить адаптер с магнитолой, но у меня получилось самостоятельно))
P.P.S. Если кто захочет повторить сие мероприятие и получится ещё что-нибудь улучшить в данном процессе — очень буду рад почитать ваш опыт!
UPD: Проверили c AndroidAuto. Работает только по проводу на нашей магнитоле(( Без провода — пока только Apple CarPlay на Windows CE. Скорее всего AndroidAuto заведется без провода исключительно на магнитолах на Android (не штатных), либо если вдруг решат допиливать приложение под Windows CE, что вряд ли.
Windows CE (она же WinCE) — это вариант операционной системы Microsoft Windows для наладонных компьютеров, мобильных телефонов и встраиваемых систем. Windows CE не является «урезанной» версией Windows для настольных ПК и основана на совершенно другом ядре. Поддерживаются архитектуры x86, MIPS, ARM и процессоры Hitachi SuperH.
Windows CE оптимизирована для устройств, имеющих минимальный объём памяти: ядро Windows CE может работать на 32 Кб памяти. С графическим интерфейсом (GWES) для работы Windows CE понадобится от 5 мб. Устройства часто не имеют дисковой памяти и могут быть сконструированы как «закрытые» устройства, без возможности расширения пользователем (например, ОС может быть «зашита» в ПЗУ). Windows CE соответствует определению операционной системы реального времени.
На базе Windows CE основано множество платформ, включая Handheld PC, Pocket PC, Pocket PC 2002, Pocket PC 2003, Pocket PC 2003 SE, Smartphone 2002, Smartphone 2003, Windows Mobile, а также множество промышленных устройств и встроенных систем. Приставка Sega Dreamcast имела поддержку Windows CE. Самой Windows CE в изначальной поставке не было, но она могла запускатся на приставке с CD. Некоторые игры использовали данную возможность===
Основная платформа корпорации Microsoft для таких портативных устройств, как карманные персональные компьютеры (PDA, КПК), смартфоны и Portable Media Center. Стандартизация требований к оборудованию и программам позволила оптимизировать параметры устройств на основе Windows Mobile и обеспечить поддержку приложений от сторонних разработчиков. Платформа Windows CE предназначена для более широкого спектра встраиваемых устройств. Учитывая разнообразие устройств, которые могут быть созданы на базе Windows CE, к ним не предъявляется никаких стандартных требований относительно оборудования и программ.
Следует учитывать тот факт, что решения Windows Mobile всегда создаются на базе текущей версии Windows CE, которая в этом случае является ядром платформы. По мере совершенствования платформы Windows CE происходит обновление и платформы Windows Mobile. Для наглядности соответствие версий Windows CE и Windows Mobile сведено в таблицу.
Platform Builder – это интегрированная среда разработки для создания, отладки и развертывания специализированных образов ОС на базе Windows CE.
Подробный обзор основных потребительских характеристик платформы Windows Mobile приведен здесь.
В контексте сравнения с платформой Windows CE, следует отметить, что производитель устройств на базе Windows Mobile получает это программное обеспечение для своего устройства не в виде исходного кода, а в виде уже почти законченного продукта. В этот продукт производителю необходимо внести только те изменения, которые касаются аппаратных особенностей разрабатываемого им устройства, но благодаря стандартизации требований к устройствам Windows Mobile, внесение подобных изменений не требует от производителя значительных затрат. Таким образом, использование платформы Windows Mobile позволяет производителю портативных устройств значительно сократить время разработки устройства и снизить финансовые расходы на подготовку к выпуску в продажу своего издения. Для обозначения этого качества используется термин “go-to-market”.
Читайте также: