Как создать сборку windows ce
Обновлено: 04.07.2024
Содержание
Введение
"Третья" 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-устройств заставляют тщательно продумывать подходы к программированию, чтобы повысить эффективность своих творений. На самом деле довольно забавно в наше время, т. е. в эпоху многомегабайтных программ для ПК, увидеть программистов, всерьез озабоченных быстродействием ЦП и объемами программ.
Пока я доделывал работу в этом блоге уже написали столько интересного, что глаза разбегаются. Сейчас я хочу затронуть тему создания инсталляционного фаила.
Возможно многим это покажется интересным, потому как инсталлировать программу рано или поздно придется. В этой заметке я в сриншотах постараюсь раскрыть эту тему. И, кстати, это мой первый пост, надеюсь получится полезным.
Для того чтобы создать инсталлятор нужно добавить проект к этому solution-у.
В окне выбора проекта нужно выбрать Other Project Types -> Setup and Deployment и Smart Device CAB Project, я его называю ButtonTestCab
Solution Explorer после этого должен выглядеть примерно так.
Правой кнопкой мыши нажать на название появившегося проекта и выбрать File System
В Application Folder необходимо добавить исходный проект программы.
Правой кнопкой Add -> Project Output и выбрать там название проекта ButtonTest. Появится ссылка на проект и необходимые библиотеки.
В принципе можно строить инсталлятор, но мы еще добавим ссылки в разные папки Windows CE или Windows Mobile, такие как Program Files и Start Menu.
Для этого если открыть слева Program Files Folder можно добавить ссылку на исполняющий фаил в этой папке.
В открывшемся диалоговом окне нудно выбрать проект из Application Folder
Точно так же можно добавить ссылку в папку Start Menu. И вообще есть возможность добавить папки самому, например мы хотим что бы программа запускалась при запуске устройства, для этого добавим ссылку в папку Startup.
Так же как и File System в Solution Explorer установочного проекта можно выбрать View -> Registry и добавить нужные ключи в реестр
Правой кнопкой на имени проекта можно выбрать Properties. Тут можно установить папку в которой будет возникать инсталлятор.
После того как все установки сделаны, нужно построить (Build) установочный проект.
В той папке которую мы выбрали появится как минимум два фаила, в данном случае ButtonTestCab1.CAB и ButtonTestCab1.inf. CAB фаил нам и нужно скопировать в инсталляционную (AutoInstall) папку Windows CE или установить в ручную.
Используя утилиту Platform Builder разработчики встраиваемых систем могут собрать специально настроенную ОС CE для своего устройства, которая включает только необходимые свойства. Platform Builder выполняется в знакомой среде Visual Studio IDE . Новую ОС можно загрузить в целевое устройство CE или эмулятор, и затем использовать его для отладки новой ОС и приложений устройства.
Сборка настроенного ядра CE
Каждое новое встраиваемое устройство нуждается в Операционной системе, специально настроенной для уникальных требований устройства. Включая только те драйверы и службы, которые требуются устройству, можно минимизировать размер ядра. Это ведет к меньшим требования памяти. Даже если экономия недостаточно большая, чтобы дизайнер мог для создания устройства перейти на менее дорогие устройства памяти, любое сбережение памяти тем не менее означает больше памяти, которая будет доступна для прикладных программ и хранилища.
Процесс сборки нового ядра операционной системы иногда называется sysgen (генерация системы). Помните, что этот процесс требует существенно больше внимания, чем простая компиляция и компоновка простой прикладной программы. Он требует копирования, проверки, компиляции и компоновки сотен, если не тысяч, различных модулей и файлов, поэтому будьте терпеливы, когда процесс потребует нескольких минут. В Windows Embedded CE для генерации нового настроенного ядра используется специальный графический инструмент разработки ОС, называемый Platform Builder , который выполняется в Visual Studio.
Видео & Виртуальная лаборатория: Знакомство с инструментами CE через Web
- Windows Embedded CE 6.0 - Введение в сборку/отладку образов операционных систем
Эта виртуальная лаборатория показывает процесс создания, настройки, сборки и отладки образа времени выполнения ОС Windows CE OS и знакомит со свойствами Platform Builder . Новый образ времени выполнения затем выполняется на поставляемом с CE эмуляторе устройства ARM.
Эта лабораторная работа показывает процесс создания образа операционной системы CE 6.0, которая поддерживает разработку приложений Win32 и MFC (Microsoft Foundation Classes), сюда включается сборка специального SDK (Software Development Kit) для поддержки разработки приложений на настроенном образе операционной системы, и будет использоваться Visual Studio 2005 для написания и развертывания простого приложения MFC на образе операционной системы, выполняющемся на эмуляторе ARM.
Виртуальные лабораторные работы являются быстрым и легким способом начального изучения использования инструментов для CE на любом ПК. Пользователи без целевого оборудования eBox могут выполнять и отлаживать многие примеры, которые выполняются на эмуляторе ARM, используя инструкции, предоставленные в виртуальных лабораторных работах для компиляции кода для процессора ARM, и соединяясь с эмулятором ARM для загрузки разработки и кода новой ОС. Все примеры, которые требуют внешнего оборудования, не поддерживаемого эмулятором, такие как устройства В/В Phidgets USB будут работать неправильно.
Далее мы соберем новую ОС с помощью Platform Builder и запустим выполнение CE на реальном устройстве, eBox 2300.
Инструкции по установке программного обеспечения
Прежде чем переходить к учебному материалу, необходимо установить на ПК системы разработки несколько программных пакетов. Для системы разработки требуется Windows XP с памятью от 512K до 1G RAM и не менее 18 GB свободного доступного дискового пространства до установки программного обеспечения. Это оставит достаточно пространства для поддержки нескольких новых сборок ОС. Нам понадобятся следующие объекты, и они должны быть установлены в данном порядке:
Каждый дополнительный проект новой сборки ОС может использовать около 2 GB дискового пространства, поэтому может понадобиться очистить или удалить более старые проекты сборки ОС в некоторый момент, чтобы освободить дисковое пространство, если дисковое пространство ограничено. Очищенные проекты сборок ОС являются относительно небольшими и их всегда можно собрать заново. Начальная установка Visual Studio 2005 и требуемого пакета VS 2005 SP1 требует достаточно много времени, поэтому начинайте эти процессы установки, когда имеется достаточно времени для их завершения. После установки всего перечисленного программного обеспечения или проверки, что они уже установлены в системе разработки, вы будете готовы начать знакомство с учебным материалом.
ПРИМЕЧАНИЕ: Не забудьте отключить все антивирусное программное обеспечение на доступе к файлам. Отключите сканирование при доступе, или как минимум исключите его из проверки при доступе к основному каталогу CE. Используемым по умолчанию основным каталогом CE является C:\WINCE600, и сканирование вирусов при доступе к файлам этого каталога является основной проблемой. Каждая копия сборки ОС создает и открывает несколько тысяч файлов и проверка каждого из них на вирусы делает длинный процесс сборки ОС действительно слишком медленным.
ПРИМЕЧАНИЕ: Если имеется брандмауэр, выполняющийся в системе разработки, может понадобиться задать его, настроить или отключить, чтобы позволить eBox соединиться и взаимодействовать с настольным ПК через сеть. Сетевое соединение используется для загрузки нового кода и поддержки удаленных операций отладки.
Сетевое соединение ПК разработки и eBox должно быть в одной подсети, чтобы позволить выполнять удаленную загрузку и отладку на eBox. eBox должен иметь в сети включенный DHCP или иметь статический IP-адрес. Дополнительные подробности о сетевых параметрах настройки предоставлены далее.
Порядок установки всего этого добра:
При установке все директории для установки оставляем без изменений, чтобы потом геморроя не было с путями. Также в висте/7-ке на всякий случай лучше все установщики запускать от имени администратора. Все файлы системы находятся в папке c:\\WINCE600\\PLATFORM\\Mini2440\\. Можно там полазить, посмотреть исходники драйверов и т.д.
Когда все установилось, попробуем собрать образ системы. Запускаем студию, причем ОБЯЗАТЕЛЬНО от имени администратора, иначе будут косяки при сборке образа! Запустили. Жмем File-Open-Project/Solution. и находим файл c:\\WINCE600\\OSDesigns\\Mini2440\\Mini2440.sln и открываем его. На скриншоте показано окно студии с открытым проектом.
Update: Перед сборкой на всякий случай отключите все антивирусы, файерволы или, если комп достаточно мощный, заведите виртуальную машину (VMWare, VirtualBox) с XP и всем необходимым софтом, и делайте все в ней.
Когда в окне Output студии появится что-то типа:
значит все готово к заливке в мини 2440. Идем в папку c:\\WINCE600\\OSDesigns\\Mini2440\\Mini2440\\RelDir\\Mini2440_ARMV4I_Release\\ и ищем там файл NK.bin — это и есть образ системы. Теперь будем его заливать. Предполагается, что у нас уже поставлен драйвер USB из комплекта поставки, есть необходимые шнурки и прошит загрузчик последней версии в мини.
1) Запускаем DNW.exe
2) Configuration-Options. Выставляем номер своего COM-порта, скорость 115200, Download address 0x30000000. Жмем ОК.
3) Подсоединяем к мини USB шнурок, COM-портовый шнурок и шнурок питания(ПИТАНИЕ НЕ ВКЛЮЧАЕМ!), переключатель S2 переводим в положение NOR.
4) В DNW Serial Port-Connect. Теперь включаем питание мини с помощью переключателя S1.
В окне DNW появится нечто подобное:
5) в файл \\WINCE600\\PLATFORM\\Mini2440\\FILES\\platform.reg добавляем
Собираем образ как описано выше. Все, драйвер интегрирован в систему, образ можно заливать в плату.
Читайте также: