Зачастую в процессе разработки собственных устройств или моддинга уже существующих, встаёт задача выполнения стороннего кода: будь то ваши собственные программы с SD-флэшек, или программы, написанные другими пользователями с помощью SDK для вашего устройства. Тема компиляторов и кодогенерации достаточно сложная: чтобы просто загрузить ELF или EXE (PE) программу, вам нужно досконально разбираться в особенностях вашей архитектуры: что такое ABI, релокации, GOT, отличие -fPIE от -fPIC, как писать скрипты для ld и т. п. Недавно я копал SDK для первых версий Symbian и основываясь на решениях из этой ОС понял, каким образом можно сделать крайне «дешевую» загрузку любого нативного кода практически на любом микроконтроллере, совершенно не вникая в особенности кодогенерации под неё! Сегодня мы с вами: узнаем, что происходит в процессе загрузки программы ядром Linux, рассмотрим концепцию, предложенную Symbian Foundation и реализуем её на практике для относительно малоизвестной архитектуры — XTensa (хотя она используется в ESP32, детали её реализации «под капотом» для многих остаются загадкой). Интересно? Тогда добро пожаловать под кат!
❯ Как это работает?
Думаю, для многих моих читателей реализация процесса загрузки exe-программ и dll-библиотек в память процесса оставалась эдаким чёрным ящиком, в детали реализации которого вдаваться не нужно. Отчасти это так и есть: современные ОС разруливают процесс загрузки бинарников в память сами, не требуя от программиста вообще ничего, даже понимания того, куда будет загружена его библиотека или программа.
Давайте для общего понимания вкратце разберемся, как происходит загрузка программ в Windows/Linux:
1. Система создаёт процесс и загружает в память программы секции из ELF/PE. Обычные программы для своей работы используют 3 секции: .text (код), .data (не-инициализированный сегмент памяти для глобальных переменных), .bss (сегмент памяти для инициализированных переменных). Каждому процессу выделяется собственное адресное пространство, называемое виртуальной памятью, которое не позволяет программе испортить память ядра, а также позволяет не зависеть от разметки физической памяти на выполняющей машине. Концепцию виртуальной памяти реализует специальной модуль в процессоре, называемый MMU.
2. Если бы наши программы не использовали никаких зависимостей в виде динамических библиотек, то на этом процесс загрузки можно было бы закончить: каждая программа имеет свой адрес загрузки, относительно которого линкер строит связи между обращениями к коду/данным программы. Фактически, для самых простых программ линкеру остаётся лишь прибавить адрес загрузки программы (например, 0x100) к каждому абсолютному обращению к памяти. Однако современные программы используют десятки библиотек и для всех предусмотреть собственный адрес загрузки не получится: кто-то где-то всё равно будет пересекаться и вероятно, портить память. Кроме того, современные стандарты безопасности в Linux рекомендуют использовать позиционно-независимый код, дабы использовать преимущества ASLR (Address Space Layout Randomization, или простыми словами возможность загрузить программу в случайное место в памяти, дабы некоторые уязвимости, завязанные на фиксированном адресе загрузки программы перестали работать).
3. Поэтому для решения этой проблемы придуман т. н. динамический линкер, который уже на этапе загрузки программы или библиотеки патчит программу так, чтобы её можно было загрузить в любой участок памяти. Для этого используются данные, полученные от обычного линкера а этапе компиляции программы: помимо .text, .data и .bss, линкер создаёт секции .rel и .rel-plt, которые называются релокациями. Если объяснять совсем условно, то релокации — это просто запись вида «какой абсолютный адрес в коде программы нужно пропатчить» -> «на какое смещение его пропатчить». Самая простая релокация выглядит вот так:
Где по итогу:
.rel-plt же служит для резолвинга вызовов к dll/so: изначально программа ссылается на заранее определенные в процессе компиляции символы, которые уже в процессе загрузки патчатся на физические адреса функций из загруженной библиотеки.
И казалось бы — всё очень просто, пока в дело не вступают GOT (Global Offset Table — глобальная таблица смещений) и особенности реализации конкретного ABI. И ладно бы x86 или ARM, там всё разжевано и понятно, однако на других архитектурах начинаются проблемы и не всегда очевидно что и где за что отвечает.
А ведь чаще всего нужно просто загрузить небольшую программу, которой не нужны комплексные загрузчики: немного кода, немного данных и всё. И тут у нас есть три выхода:
Писать полноценный загрузчик ELF-бинарников. ELF может оказаться громоздким для некоторых окружений и его реализация может оказаться тривиальной не для всех.
Зарезервировать определенный сегмент в памяти (пусть с 0xFFF по 0xFFFF) и скомпилировать нашу программу с адресом загрузки 0xFFF с параметром -fno-pic. В таком случае, линкер сгенерирует обращения к памяти по абсолютным адресам — если переменная лежит по адресу 0xFFF, то программа будет обращаться сразу к этому адресу памяти, без необходимости что либо динамически линковать. Именно такой подход использовался во времена ZX Spectrum, Commodore 64 и MS-DOS (однако там роль «виртуальной памяти» выполняла такая особенность 8086, как сегменты). У такого подхода есть и минусы: относительная невозможность загрузки сразу нескольких программ одновременно, зарезервированное пространство линейно отъест небольшой кусок памяти у основной прошивки, нет возможности динамической аллокации секций. Зато такой код теоретически будет работать быстрее, чем PIC.
Проблемы реализации такого способа: иногда нужно лезть в систему сборки основной прошивки и патчить скрипт линкера так, чтобы он не трогал определенный регион памяти. В случае esp32, например, это требует патча в сам SDK и возможного «откола» от мейнлайн дистрибутива.
Использовать программу с относительной адресацией, однако без сегментов .bss и .data. Самый простой в реализации способ, который к тому же очень экономичен к памяти, позволяет загружать программу в любое место и пользоваться всеми фишками динамического аллокатора и не требует вмешательств в основную прошивку, кроме примитивного загрузчика программ. Именно его я и предлагаю рассмотреть подробнее.
Недавно мы сидели в чате ELF-сцены (разработка нативных программ под телефоны Siemens, Sony Ericsson, Motorola и LG с помощью хаков) и думали, как же можно реализовать загрузчик сторонних программ на практически неизвестных платформах. Кто-то предлагал взять ELF под основу — однако с его реализацией под некоторые платформы есть трудности, а кто-то предлагал писать «бинлоадер» — самопальный формат бинарников, который получается из, например, тех же эльфов.
В это же время я копал SDK для Symbian и хорошо помнил, что в прикладных приложениях для этой ОС нет поддержки глобальных переменных вообще. Да, сегмент .data и .bss полностью отсутствует — переменные предлагается хранить в структурах. Почему так сделано? Всё дело в том, что каждая программа в Symbian — это dll-библиотека, которую загружает EKA и создаёт экземпляр CApaApplication. И дабы была возможность загрузить dll один раз для всех программ (что справедливо для системных библиотек), ребята полностью выкинули возможность использования любых глобальных переменных. А ведь идея интересная!
Однако в таком подходе есть несколько серьезных ограничений:
Отсутствие глобальных переменных может стать проблемой при портированиии уже существующего софта, хотя вашим программам ничего не мешает передавать в каждую функцию структуру с глобальным стейтом, который можно при необходимости изменять. Кроме того, нет ограничений на использование C++ (за исключением необходимости ручной реализации new/delete и отсутствием исключений).
Отсутствие преинициализированных данных. Вот это уже может стать относительно серьёзной проблемой, у которой, тем не менее, есть свои обходные решения. Например если вы храните команды для инициализации дисплея в таблице, или какие-либо калибровочные данные — вы не сможете их объявить, просто используя инициализаторы в C. Тоже самое касается и строковых литерал. Тут есть два варианта: часть таблиц можно вынести на стек (если эти самые таблицы достаточно маленькие), либо подгружать необходимые данные из бинарника с помощью основной прошивки (например, LoadString и т. п.).
Давайте же на практике посмотрим, имеет ли право на жизнь такой подход!
❯ Практическая реализация
Формат нашего бинарника будет до безобразия прост: небольшой заголовок в начале файла и просто сырой дамп сегмента .text, который можно экспортировать из полученного elf даже без необходимости писать скрипт для линкера. При этом нужно учесть, что ESP32 — это микроконтроллер частично Гарвардской архитектуры, т. е. шина данных и кода у него расположены отдельно. Однако у чипа есть полноценный MMU, который позволяет маппить регионы физической памяти в виртуальную память, чем мы и воспользуемся в итоге!
Заголовок нашего бинарника будет выглядеть вот так:
Программа общается с основной прошивкой посредством псевдо-syscall'ов: функции, которая в качестве первого аргумента ожидает номер нужной службы и один 32х-битный указатель для описания структуры с параметрами. Реализация syscall'ов — одна из самых простых и неприхотливых с точки зрения обратной совместимости с будущими прошивками.
Концептуально всё очень просто: GetGlobalStateSize сообщает нашему загрузчику размер структуры для хранения глобального стейта, в то время как Start уже фактически заменяет main() в нашей программе. Необходимости в crt0 нет, поскольку весь необходимый инит выполняет бутлоадер ESP32. Впрочем, при желании вы можете выделить отдельный стек для вашей программы — это повысит надежность, если выполняемая программа удумает испортить стек.
-fno-pic отключает генерацию кода, зависимого от GOT, -nostdlib и -nostartfiles убирает из билда crt0 и stdlib, благодаря чему мы получаем только необходимый код. --section-start задает смещение для загрузки секции .text на 0x0 (в идеале это делать необходимо из скрипта для ld). objcopy скопирует из полученного ELF только необходимую нам секцию .text.
Как же это работает на практике? Давайте дизассемблируем выходной бинарник и посмотрим, что у нас дает на выхлопе cc:
Обратите внимание, что Start вызывает подфункции с помощью инструкции CALLX8, которая в отличии от обычного Immediate-версии CALL8, выполняет переход относительно текущего адреса в PC, благодаря чему переход полностью независим от адреса загрузки программы в памяти. А благодаря тому, что все данные, в том числе и указатель на глобальный стейт передаются через стек, нет необходимости релокейтить сегменты данных.
По итогу всё, что нужно от загрузчика бинарников — это загрузить программу в память для инструкций, выделить память для структуры с стейтом программы и передать управление Start. Всё! Конкретно в случае ESP32, у нас есть два возможных решения задачи загрузки программы в память:
Загрузить программу в IRAM. Такая возможность теоретически есть, однако на практике загрузчик ESP32 устанавливает права только на чтение и выполнение на данный регион памяти. Попытка что-то скопировать туда закончится исключением SIGSEGV. Кроме того, сегмент IRAM относительно небольшой — всего около 200Кб.
Самопрограммирование. Для этого, в esp32 есть два механизма — Partition API и SPI Flash API. Я выбрал Partition API для простоты реализации.
Для нашей прошивки необходимо будет переразметить флэш-память. Для этого запускаем idf.py menuconfig, идём в Partition Table -> Custom partition table CSV. Создаём в папке проекта partitions.csv, куда пишем:
Как видите, ничего сложного в выполнении сторонних программ при условии соблюдении некоторых ограничений нет. Да, в таком подходе есть как серьезные плюсы, так и минусы, однако он делает своё дело и позволяет реализовать запуск игр на кастомных игровых консолях, или сторонних программ на самодельных компьютерах. Ну и конечно же не стоит забывать про плагины! Авось в вашем решении нужна возможность расширения функционала устройства, однако предоставлять исходный код или даже объектные файлы нет возможности — тогда вам может пригодится и такая методика.
Пожалуй, стоит упомянуть ещё один… очень своеобразный метод, который я иногда встречаю при реализации самодельных компьютеров. Люди пишут… эмуляторы 6502/Z80 :) И если такой подход ещё +- применим к ESP32, то в AVR просадки производительности будут слишком серьезными. Так зачем, если можно использовать все возможности ядра на максимум?
Полезный материал?
Приходилось ли загружать сторонний код в ваших устройствах?
Возникла необходимость прочитать и имитировать данные, посылаемые датчиком в ЭБУ. Датчик измеряет 4 параметра и шлёт их по шине LIN с нестандартной скоростью в ЭБУ. ЭБУ, в свою очередь, отображает полученные данные в ПО на компе.
Вопрос как считать поток и как вычленить нужные данные я решил. Промерял осциллом единичный бит, посчитал частоту.
Выяснил, скорость 8000 бод. Считал поток в терминал, вычленил ID отключая разные исполнительные девайсы, висящие на шине. Нашёл нужный мне ID, который давал данные при подключенном датчике, и не давал при отключенном.
Далее написал прошивку, которая отвечает на запрос ЭБУ вместо датчика. В ПО присутствие эмулятора видно (начинают появляться данные), корректность получаемых данных тоже подтверждена. Формат пакета стандартный LIN: синхра(0х55), ID (в моём случае 47), 4 байта данных, контрольная сумма один байт. Если просчитатся с контролькой и отправить некорректную, то датчик в ПО отваливается. Отсюда-данные передаются и воспринимаются ЭБУ и ПО корректно.
И вот тут затык. Из 4 байтов данных два средних байта не влияют на данные, отображаемые ПО. А малейшее изменение первого и последнего меняют три параметра, отображаемые ПО, один параметр постоянно болтается в ноле. На него 1 и 4 байт не влияют.
Как такое может быть? Как четырьмя тетрадами можно закодировать минимум три трёхзначных параметра, два с дробной частью до десятых и два до сотых? Четвёртый параметр тоже шевелится посредством реального датчика, но этот снимок я не сделал.
Провёл несколько экспериментов, полученные данные свёл в таблицу. Жёлтый столбик данные датчика, зелёный отображаемые в ПО.
Всем привет в новом году! Даже новогодний выходной не освобождает ТС от выхода рубрики, ибо Понедельник и Дисциплина (сам себе придумал знамя и теперь его не бросишь). Сегодня в виртуальном музее советской бытовой техники прибор, который вся страна смотрела прошлой ночью - телевизор:
Изготовлен новосибирским заводом Электросигнал в 1970 году. Полное погружение можно испытать от этого видео (нашел на ютубе, обращение Брежнева):
Телевизор черно-белый, ламповый. Классического вида, мог комплектоваться ножками и стоять на полу. Стоил в напольном исполнении 360 рублей. Мощность 180 Вт, размер изображения 305*384, что около 19 дюймов
Селектор каналов. Для переключения каналов требовалось вставать с дивана.
Задняя крышка алюминиевая.
@PaulZ не поделитесь сканом паспорта ТВ? я его на страничку музея добавлю)
Снимем заднюю крышку:
Монтаж на платах, после ТВ собранных навесным методом монтажа - приятно смотреть, да и ремонт сильно удобнее. Рама с платами на петлях, что облегчает доступ:
Красный провод - анодное напряжение на кинескоп. Поднимите руку, кого кусало оставшимся зарядом с кинескопа)
Лампы на панельках, в центре фото - неродная панелька, ее припаяли при ремонте. Метод ремонта ТВ "ударом по корпусу" ТВ связан как раз с этими панельками - лампы греются, металл контактов окисляется и контакт может нарушаться. От несильного удара по корпусу контакт на время восстанавливался.
Теплая ламповая топология, как из под топора.
Локализация не 100% - найдены венгерские и итальянские электролитические конденсаторы:
Пара динамиков.
Большой и жирный трансформатор - мечта самодельщиков - напряжения ламповые (6,3В накал ~200 анодное)
Провода вязались в жгуты.
Резисторы часто использовались как оправка для намотки катушек., намотка типа Универсаль для снижения собственной емкости (у буржуев 3-pi wound. Из-за прекращения производства этих катушек MOOG временно прекратил производство терменвоксов Theremin)
Навесной монтаж местами присутствует.
ТВС. Путь многих в высокое напряжение начинался с этих трансформаторов. Я, будучи школьником, шарился по помойкам. Народ массово менял советские ТВ на современные, и их корпусов удавалось вынуть заветный трансформатор строчной развертки. Несколько витков провода, пара резисторов и транзистор - и готов источник высокого напряжения, с разрядом в сантиметр! Как хорошо, что я был не очень умный, и до опытов Сифуна (Sifun) не дошел.
Ссылка на телеграм канал, если кому-то удобнее следить там.
Иногда, при разработке устройств на микроконтроллерах, возникает потребность в выводе на дисплей большого количества информации или же в выводе информации на крупный дисплей для возможности ее считывания с большого расстояния. К сожалению, готовых решений этой проблемы нет, а те что есть – весьма дороги. Например, графические ЖК-дисплеи с возможностью подключения к микроконтроллеру обычно имеют диагональ не более нескольких дюймов и достаточно существенную цену (причем, даже монохромные, о цветных вообще можно не говорить).
В то же время есть огромный парк старых ЖК мониторов. Модели с диагональю 15-19 дюймов можно приобрести в рабочем состоянии за 200 – 500 руб. Особенно это касается моделей с немодным сейчас соотношением сторон 4:3. Эти модели достаточно надежные. Лампы CCFL, используемые для подсветки, конечно, теряют яркость за годы эксплуатации и их спектр свечения уходит в неприятный красноватый оттенок, но благодаря большому количеству таких мониторов всегда есть возможность выбрать более-менее живой экземпляр. Кроме того, лампы CCFL относительно несложно заменить обычной светодиодной лентой, подключив ее напрямую к источнику питания 12 В монитора. Однако при этом обычно необходимо заблокировать цепи обратной связи от микросхемы управления подсветкой к контроллеру самого монитора, иначе монитор будет думать что подсветка неисправна и просто выключится. Также придется пожертвовать функцией регулировки яркости. Однако, этой функцией мало кто пользуется. Обычно яркость монитора настраивается один раз в жизни, сразу после его покупки и потом никогда не меняется.
Мной таким образом был доработан монитор диагональю 17” фирмы «Самсунг». Результат меня удовлетворил, монитором вполне можно было продолжать пользоваться по его прямому предназначению. Единственное, хочу отметить, что в моем случае причиной переделки стал пробитый повышающий трансформатор, а не вышедшая из строя лампа CCFL, которые, как я уже говорил, достаточно надежны. Также светодиодные ленты я подключил через ключ на мощном транзисторе npn для того, чтобы подсветка отключалась по команде от контроллера монитора, иначе во время инициализации монитора или переключении режимов на экране видны полосы и неприятные мерцания.
Кроме выхода из строя ламп подсветки и схемы их питания, другой наиболее частой проблемой в таких мониторах следует назвать выход из строя конденсаторов в блоке питания. Иных проблемных мест в мониторах обычно не бывает и после указанной доработки и замены конденсаторов на свежие они наверняка еще проработают не менее 10 лет.
Большинство старых мониторов обычно всегда имеют разъем VGA для подачи на него сигнала от компьютера. Часто присутствует только один этот разъем. Иногда в паре с разъемом DVI (чаще на более дорогих моделях). Разъем HDMI больше встречается на относительно современной технике.
Таким образом, разъем, который с почти 100% вероятностью найдется на старом мониторе – это разъем VGA. На него и будем ориентироваться.
Чтобы вывести изображение на монитор достаточно оперировать всего 5-ю сигналами – R, G, B – отвечающие за цвет и яркость, HS, VS – отвечающие за синхронизацию. Как это сделать, подробно рассмотрено в статьях 1, 2, 3, 4, поэтому не буду повторяться.
В вышеперечисленных статьях для вывода видеосигнала чаще всего используется ПЛИС, которая обычно весьма недешевая. В одном из вариантов сигналы генерируются на микроконтроллере и рассыпухе. Хотелось бы попроще и подешевле одновременно. Поэтому было принято решение использовать ПЛИС, но не PGA, а CPLD. Такие ПЛИС имеют существенно меньше доступных логических ячеек, но также и стоят дешевле. Например, макетную плату ПЛИС MAX II Altera EPM240 мне удалось приобрести на Aliexpress всего за 8,57$ (без учета доставки). Причем, в комплект входил также и программатор. Сами чипы можно найти за 1,6 – 2,1$ (не оригинал, разумеется).
Макетная плата MAX II Altera EPM240
Да, для реализации был выбран текстовый режим, как наиболее простой для микроконтроллера, но, в то же время, достаточно информативный. Некоторые простые графические вещи можно реализовать символами псевдографики, как это широко практиковалось во времена DOS. Для реализации графического режима потребуется передавать большой объем данных от микроконтроллера и дополнительно загружать его формированием графики, что не всегда допустимо, особенно для слабых ядер.
Первый шаг — успешный вывод на экран символа «2». Символ получился отзеркаленным. Не беда
У указанной ПЛИС на борту имеется flash ПЗУ, которое весьма заманчиво использовать для хранения ПЗУ знакогенератора. Однако объем его крайне невелик – всего 8 кБит или 1 кБайт. Этого может хватить только для символов с разрешением 5х7, да и то, если пожертвовать неотображаемыми, малозначительными и визуально идентичными символами из таблицы ASCII. Кроме того, использование встроенного ПЗУ потребует расхода логических ячеек, которых и так немного. Как бы ни был привлекателен этот вариант, придется от него отказаться и использовать микросхему внешнего ПЗУ, взятую, например, из старых материнских плат. Если найти микросхему с питанием 3,3 В, то даже не придется ничего думать насчет согласования уровней напряжений с ПЛИС. Объемы таких ПЗУ достаточно велики – 2/4/8 Мбит или 256...1024 кБайт, что позволяет хранить там большое количество различных шрифтов в хорошем разрешении 8х16.
Макетная плата Altera MAX II крупным планом
Для хранения образа экрана также потребуется микросхема ОЗУ. Рассчитаем примерный требуемый объем. Если мы планируем использовать шрифт 8х16, то при разрешении экрана 640х480 мы получим 80 знакомест по горизонтали и 30 строк по вертикали. Значит для хранения образа экрана необходимо 80∙30=2400 байт. Не очень удобное число. Оно лишь ненамного больше чем ближайшая степень двойки – 2048. Поэтому память используется нерационально, всего на 58%, поскольку ближайший объем, кратный степени двойки – 4096. Кстати, именно поэтому получил распространение текстовый режим 80х25, в котором 5 строк были попросту выброшены. В этом случае количество потребной памяти – 2000 байт, что замечательно помещается в объем памяти 2 кБайт. Однако современные микросхемы памяти имеют достаточно большие объемы, экономить ее сейчас смысла особого нет. Более того, можно сознательно пойти на нерациональное использование объема памяти в угоду упрощения логики дешифрации и экономии логических ячеек ПЛИС. Итак, нужен объем 4096 байт (212, 12 бит адреса), который можно разделить следующим образом: 5 бит адреса выделить на адрес строки (будет использовано 30 из 32) и 7 бит на адрес столбца (будет использовано 80 из 128).
Такой же объем памяти потребуется для страницы атрибутов символов. В качестве атрибутов обязательно нужны будут цвет символа, цвет фона, подчеркивание, мигание.
Итого, необходима память размером не менее 8 кБайт. Из вариантов «под рукой» лучше всего подходит статическая память (используемая как кэш-память), также взятая со старых материнок. Единственное, эта память обычно 5-вольтовая. Однако если это память КМОП, она чаще всего без проблем работает и при напряжении 3,3 В, единственное, при этом необходимо закладывать бОльшие тайминги.
Итак, получилась следующая схема.
Первый вариант схемы
Как видно, схема включает в себя только 3 микросхемы и минимум внешних деталей. Если применить в качестве основы вышеупомянутую макетную плату EPM240, то кроме нее потребуются только микросхемы ПЗУ, ОЗУ и разъем VGA с пятью резисторами. Подключение сигналов к ПЛИС показано условно, поскольку почти все ее ножки равнозначны (кроме глобальных тактовых сигналов, на один из которых необходимо подать сигнал с тактового генератора). При программировании микросхемы под конкретное устройство почти все сигналы можно будет переназначить. Пока же устройство собрано на макетной плате и этот вопрос можно отложить.
Устройство общается с микроконтроллером по параллельному 8-битному интерфейсу (сигналы с префиксом HOST), логически почти идентичному широко распространенному интерфейсу дисплеев на контроллере 1602 и им подобных. Единственное отличие – добавлен сигнал BUSY от устройства к микроконтроллеру. Его необходимость обусловлена тем, что доступ к микросхеме ОЗУ предоставляется только в момент обратного хода кадровой развертки. В остальное время микросхема занята логикой ПЛИС. Сигнал BUSY также имеет смысл сигнала запроса прерывания. По его перепаду контроллер может автоматически начинать запись в буфер экрана.
Второй шаг — вывод некоторых символов знакогенератора различным цветом символа и фона
Описание интерфейса:
DATA[7:0] – данные 8 бит, порт однонаправленный, только на запись в устройство.
CS – выбор устройства, 0 – устройство выбрано, 1 – устройство не выбрано. По положительному перепаду CS защелкиваются данные при записи.
AD – адрес/данные, при операции записи: 0 – передаются данные, 1 – передается адрес.
BUSY – занятость устройства, 0 – не занято, 1 – занято. Если устройство занято, операция записи данных в ОЗУ игнорируется. Возможна запись только в регистр адреса.
RESET – сброс устройства. 0 – сбросе, 1 — работа. Аппаратный сброс можно использовать для мгновенного гашения экрана. При активации этого сигнала прекращается выдача сигнала на монитор. Сброс не влияет на содержимое микросхемы ОЗУ.
Запись данных от микроконтроллера в ОЗУ возможна только во время кадрового гасящего импульса, когда микросхема ОЗУ не занята логикой ПЛИС. Это время составляет 1,440 мс. Несмотря на то, что это довольно-таки большой интервал, при использовании медленных микроконтроллеров может не хватить времени чтобы полностью перезаписать всю область памяти. Например, микроконтроллер AVR при работе на частоте 11,0592 МГц успевает записать только 3 полные строки экрана со всеми атрибутами. Если не перезаписывать атрибуты (как это обычно и происходит при реальном использовании – атрибуты записываются один раз при старте программы), то можно за один раз записать 6 строк. Наверное, если оптимизировать код, переписать его на ассемблере, то можно существенно ускорить обновление данных. Иначе для перезаписи всего экрана может потребоваться от 5 циклов (если обновлять только данные) до 15 циклов (если обновлять еще и атрибуты). При частоте развертки 60 кадров в секунду, это займет от 1/12 до 1/4 секунды. Если кто-то из читателей когда-то работал на машинах класса ХТ или АТ с тактовыми частотами процессора в районе 4 – 12 МГц, то ощущения при обновлении экрана будут примерно такие же.
Если же ждать очередной гасящий импульс неохота и хочется записать все за один присест, можно воспользоваться сигналом RESET. При его активации внутренняя логика ПЛИС останавливается и отключается от микросхемы ОЗУ, давая прямой доступ микроконтроллеру к памяти. Регистры для работы с ОЗУ сигнал сброса не затрагивает.
В общем же случае операции при записи такие: нужно дождаться когда сигнал BUSY станет нулевым, затем необходимо выставить на шину данных нужные данные, выставить сигнал типа данных (адрес или данные) – AD и «щелкнуть» сигналом CS, сначала в лог. 0, затем в лог. 1. При переходе этого сигнала из лог. 0 в лог. 1 данные защелкнутся в памяти. Во время гасящего импульса микросхема ОЗУ напрямую подключается к сигналам HOST микроконтроллера, соответственно, соблюдение таймингов при записи является заботой микроконтроллера. Но, чаще всего, статическое ОЗУ — достаточно шустрое устройство и обычно имеет тайминги существенно меньшие того, с какой максимальной скоростью средний микроконтроллер может управлять своими линиями ввода/вывода.
Микросхема ОЗУ D43256BGU-70LL подключается к ножкам ПЛИС сигналами с префиксом RAM. К этим сигналам относится 8-разрядная шина данных (двунаправленная) и 13-разрядная шина адреса. Из управляющих сигналов используется только сигнал WE. Поскольку на шине RAM микросхема одна и обе шины (адреса и данных) в ее полном и безграничном владении, сигналы OE и CS не используются, на них необходимо подать постоянный лог. 0, соединив их с общим проводом.
Примерно так же подключена (сигналы с префиксом ROM) микросхема ПЗУ SST49LF002A, за исключением того, что шина данных однонаправленная. Сигналы OE и WE этой микросхемы также не используются и напрямую подключены к лог. 0 и лог. 1 соответственно.
На свободные ножки ПЛИС подключены джамперы для выбора текущего шрифта. Поскольку объем микросхемы ПЗУ достаточно велик, это позволяет записать в нее несколько различных шрифтов, в т. ч. и с национальными алфавитами и переключать их простой установкой джамперов.
Разъем VGA подключен к ПЛИС с помощью всего 5 резисторов. Причем, резисторы в цепях HS и VS несут больше защитную функцию и их можно безболезненно исключить. Резисторы в цепях R, G, B подобраны таким образом, чтобы совместно с входным сопротивлением монитора (75 Ом) они образовывали делитель напряжения, уменьшающий напряжение на входе монитора до номинального 0,7 В.
Внешний вид макета
Ножки питания зашунтированы керамическими конденсаторами, а на ножку GCLK0 подается тактовый сигнал частотой 50 МГц от кварцевого генератора. Эти детали уже были на макетной плате.
К сигналу RESET подключены резистор, конденсатор и кнопка, собственно, и формирующие этот сигнал. Но если этот сигнал формируется микроконтроллером, то эти детали не нужны.
После написания основной части планируемой логики работы ПЛИС, оказалось что объем использованных логических ячеек ненамного превысил только половину от имеющихся. В связи с этим появилось желание немного усложнить логику работы, добавить больше возможностей. В первую очередь можно увеличить количество цветов до 16. Для этого нужно использовать еще 3 ножки ПЛИС и добавить в схему еще 3 резистора. Это не слишком усложнит схему, зато добавит еще 8 цветов. В этом случае страницу ОЗУ с атрибутами придется полностью отдать под цвет и добавить еще одну страницу с атрибутами, увеличив на 1 разряд шину адреса ОЗУ. В дополнительную страницу атрибутов можно перенести и выбор шрифта, добавить подчеркивание, моргание символа, моргание фона и т. д.
Новая схема имеет следующий вид. Она не сильно отличается от предыдущей.
Второй вариант схемы
При увеличении количества цветов возникает вопрос — какую палитру выбрать? Когда цветов всего 8 такого вопроса нет – все цвета это двоичный перебор трех основных цветов r, g, b (2^3=8). Когда больше – тут возможны варианты. Например, 16-цветная палитра EGA:
Палитра EGA
Как видно, в этой палитре 4-й бит отвечает за яркость. Но половинки таблицы поделены по яркости неодинаково. Первая половина «настроена» на 2/3 яркости (байт ААH = 170 = 2/3*256). Во второй половине добавляется еще 1/3 яркости (байт 55H = 85 = 1/3*256) и цвета называются bright *color*. Интересный момент: из схемы выбивается цвет №6 (yellow/brown), который по логике должен быть АААА00, но специально сделан АА5500 для того, чтобы малопривлекательный грязно-желтый цвет заменить на более востребованный коричневый. Это известная аппаратная фича видеокарт и мониторов EGA. Причем, в некоторых мониторах это было учтено, а в некоторых моделях с целью упрощения схемотехники на это забивали. А в других даже добавляли отдельный регулятор для настройки (назывался «BROWN ADJ.»), которым можно было отрегулировать желаемый оттенок этого цвета. Поэтому цвет в таблице обозначен как желтый/коричневый.
Нелинейное деление по яркости автоматически приводит к появлению в палитре двух оттенков серого – светло-серого и темно-серого цвета, которые весьма востребованы на практике.
Однако, 16-цветная палитра VGA немного другая. Там цвета делятся по яркости ровно пополам (80Н = 128 = 1/2*256):
Палитра VGA
В ней также выбивается из логики один цвет – светло серый (С0С0С0), который должен быть черным и, соответственно, дублировать уже имеющийся. Кроме того, этот цвет поменялся местами с темно-серым цветом (808080). Это сделано специально для совместимости 16-цветных палитр VGA и EGA, которые, таким образом, почти идентичны по восприятию.
В нашем же случае, когда сигналы формируются аппаратно с помощью резисторов представляется более удобным использовать палитру EGA. При этом необходимо добавить в логику дешифрации коррекцию только одного цвета – того самого №6. Все остальные цвета получаются автоматически. Для коррекции палитры VGA только изменением программы дело бы не обошлось — понадобилось бы добавлять еще группу резисторов для формирования светло-серого цвета (С0С0С0).
Резисторы должны быть рассчитаны так, чтобы одна группа давала 1/3 яркости, вторая 2/3 яркости, и вместе, соответственно, давали полную яркость. Нехитрыми вычислениями согласно закону Ома были рассчитаны их сопротивления: 390 Ом и 750 Ом.
Логика для формирования видеосигнала для статичного изображения (например, тестовых цветных полос) довольно простая. Однако если необходимо формировать изображение в зависимости от внешних событий или команд, задача несколько усложняется. Необходимо организовать интерфейс с ОЗУ и ПЗУ. Причем, обмен должен происходить не просто быстро, а очень быстро! Попробуем для начала оценить, будут ли вообще выбранные микросхемы успевать работать.
Итак, у нас режим 640х480. Частота вывода пикселей – 25 МГц (вообще то по стандарту должно быть 25,175 МГц, но можно абсолютно безболезненно округлить до 25, VGA, как и многие другие аналоговые стандарты допускает довольно значительный разбег по параметрам), частота кадровой развертки 60 Гц (реально получается – 59,5 Гц), частота строчной развертки – 31,46875 кГц (реально – 31,25 кГц), то есть, время вывода одного пикселя составляет 40 нс, символа шириной 8 бит – 320 нс. За 320 нс необходимо прочитать ASCII код символа (байт), код цвета (байт) и поле атрибутов (байт) из ОЗУ, затем используя ASCII код в качестве адреса прочитать из ПЗУ битовую маску символа. Только после этого у логики ПЛИС будет вся необходимая информация для начала формирования изображения.
Третий шаг — получение информации от микроконтроллера
Согласно даташиту, для выбранной микросхемы D43256BGU-70LL полный цикл чтения занимает 70 нс. Поскольку мы ее используем при пониженном напряжении, длительность цикла необходимо увеличить. Хотя бы до 100 нс. Таким образом, за 320 нс мы как раз успеем прочитать из ОЗУ 3 байта — ASCII код, код цвета и атрибуты символа. Отлично. С ПЗУ сложнее, в нем адрес записывается в 2 захода – по строкам и столбцам и, согласно описанию, цикл чтения занимает 270 нс. Небыстро, но в 320 нс укладываемся, даже с запасом.
Проблема в том, что мы не можем начать выдавать адрес ПЗУ пока не узнаем как минимум ASCII код, а на это нужно 100 нс. В сумме получается 370 нс. Выручает нас то, что каждый по отдельности цикл чтения ОЗУ и ПЗУ укладывается в допустимый интервал и можно просто потратить на чтение данных не один цикл, а два. На время подготовки данных необходимо сместить область отображения символов, сделав дополнительную область гашения шириной 2 символа в начале строки, и, на те же 2 символа уменьшить область гашения после конца строки. Это сделать несложно – просто смещаем гасящий импульс на 640 нс (соответственно, смещается и синхроимпульс). С точки зрения монитора – никакой разницы.
Для понимания того, что и в какой момент писать и считывать удобно составить циклограмму. Поначалу ее и все тайминги я держал в голове, однако составление ее на бумаге и взгляд на нее со стороны позволил существенно оптимизировать циклы чтения и даже уменьшить количество использованных дефицитных регистров.
Циклограмма обращения к ОЗУ и ПЗУ
Цикл начинается с выставления на шину адреса ОЗУ адреса байта ASCII символа. Через 80 нс на шине данных ОЗУ появляется запрошенный байт, который мы незамедлительно используем для формирования адреса для чтения байта из ПЗУ знакогенератора. На отметке 100 нс выставляем на шину адреса ОЗУ адрес байта атрибутов символа. На 140 нс (через 60 нс после выставления адреса) защелкиваем первую часть адреса ПЗУ. Ждем еще 60 нс и выставляем на шину адреса ПЗУ вторую часть адреса. К этому времени на шине данных ОЗУ уже должен быть байт данных с атрибутами символа, 5 бит которого (подробные описания регистров ниже) отвечают за шрифт и входят во вторую часть адреса ПЗУ. Оставшиеся 3 бита данных сохраняются во временном регистре 2. Еще через 60 нс защелкиваем вторую часть адреса ПЗУ. Данные на шине данных ПЗУ появятся через 120 нс после этого события и это произойдет уже во время второго цикла. Чтобы циклы не пересекались, эти данные запишем во временный регистр 1 (на отметке 80 нс). И, наконец, на отметке 300 нс необходимо переписать все подготовленные данные в рабочие регистры. Битовая маска символа из временного регистра 1 переписывается в регистр rom_reg, применяются ранее сохраненные биты атрибутов к считанному в этот момент байту с цветом.
Таким образом, к концу второго цикла будут готовы все данные для вывода символа.
Четвертый шаг — картинку полностью формирует микроконтроллер. Символы и фон разных цветов, символы разных шрифтов. Некоторые нижние строчки моргают (фото этого не передает, прошу поверить на слово)
Основные регистры:
Запись данных из микроконтроллера в ОЗУ происходит следующим образом. Дожидаемся когда сигнал BUSY станет нулевым, записываем в регистры адреса начальные адреса, куда будут записываться данные (чаще всего это адрес 0 – адрес начала страницы данных, но может быть и произвольный адрес если необходимо изменить только несколько байт). Затем записываем необходимые данные. После записи каждого байта, адрес автоматически увеличивается на 1. При подходе к краю экрана (80-й символ в строке) адрес положения символа в строке автоматически обнуляется, а адрес строки увеличивается на 1. После записи всей страницы данных адрес автоматически переключается на запись страницы атрибутов, а после страницы атрибутов – на запись страницы цвета. После записи всех трех страниц адрес также автоматически обнуляется и начинается запись в страницу с данными. Таким образом, начальный адрес можно выставить только один раз и далее гнать только данные. Это позволяет сэкономить несколько мкс на установку адреса, а также упрощает программирование, когда закинуть все данные можно в одном цикле на 7200 итераций.
sym attribute (3 bit): bit 0 – symbol blinking bit 1 – background blinking bit 2 – underline symbol
На странице атрибутов хранятся шрифты и атрибуты символов. Младшие два бита отвечают за аппаратное моргание символа или фона, третий бит – за формирование подчеркивания. Старшие биты выбирают шрифт. Соответственно, можно выводить на экран символы из разных шрифтов вперемешку в любой комбинации. 5 разрядов для выбора шрифта позволяют хранить 32 разных шрифта, включающие как любые символы национальных алфавитов, так и спрайты для вывода картинки, например.
color page [7 - 4] [3 - 0] background color (4 bit) symbol color (4 bit)
Страница цвета содержит, соответственно цвет символа и цвет фона. Цвета могут быть любые из 16-цветной палитры.
Регистров адреса — 3. Выбор, в какой конкретно из них идет запись осуществляется старшими битами. Если старший бит [7] равен лог. 0, то записывается регистр позиции в строке (столбец). Если он равен лог. 1, то записывается регистр номера строки (строка) и номера страницы ОЗУ (данные или атрибуты или цвет). Если три старших бит равны лог. 1 то записывается специальный управляющий регистр, биты 4, 3 которого определяют положение аппаратно формируемой черты при включении бита подчеркивания, биты 2 – 0 зарезервированы для будущих настроек.
page: 00 – data page, 01 – attribute page, 10 – color page
Регистр хранит номер строки и выбор страницы.
[7 - 5] [4 - 0] 1 1 1 control reg (5 bit)
control reg: bit 4,3 – adjust underline 00 – 11 and 12 lines 01 – 12 and 13 lines 10 – 13 and 14 lines 11 – 14 and 15 lines
bit 2,1,0 – for future use
Специальный управляющий регистр.
Если задать адрес вне диапазона 0-79 по столбцу и 0-29 по строке, то данные начнут записываться в теневую область памяти, которая не отображается на экране. Ничего страшного в этом нет, после прохождения адреса 128 данные снова запишутся в видимую область. Была идея использовать теневую область данных как дополнительное ОЗУ для микроконтроллера. При этом, шину данных необходимо сделать двунаправленной и добавить сигнал чтения/записи. Однако от этого было решено отказаться с целью упрощения интерфейса. Тем более, что современные микроконтроллеры не испытывают настолько сильного недостатка в ОЗУ, как это было раньше. Кроме того, доступ к этому ОЗУ происходит не в любое время по желанию микроконтроллера, а также только во время гасящего импульса.
Пятый шаг — попытка вывести графическое изображение (неудачно)
Внутренние регистры ПЛИС (некоторые):
hreg[10:0] min-0, max-1599 [10 - 4] [3 - 1] [ 0 ] sym col pos (7 bit) sym col (3 bit) tact bit
Регистр содержит текущее положение развертки по горизонтали. Тактируется от частоты 50 МГц, что в 2 раза больше необходимых 25 МГц, поэтому младший бит (tact bit) не используется. Соответственно, биты с 1 по 3 обозначают позицию внутри символа, биты с 4 по 10 – позицию символа в строке. При достижении значения 1600 регистр обнуляется и на 1 увеличивается регистр vreg.
Регистр содержит текущее положение развертки по вертикали. Тактируется от регистра hreg. Соответственно, биты с 0 по 3 обозначают строку внутри символа, биты с 4 по 8 – строку символов. Бит 9 попадает уже в область гашения, поэтому не используется. При достижении значения 525 регистр обнуляется.
page: 00 – data page 01 – color page, 10- attr page
Регистры содержат текущее значение адреса для доступа к ОЗУ (всего 16 кБайт). Младшие 7 бит – адрес символа в строке (столбец), затем 5 бит – адрес строки и 2 бита – адрес страницы (данные, атрибуты или цвет). Этих регистров 2 – один для внутреннего использования логикой ПЛИС, второй управляется извне, микроконтроллером и может быть изменен только им.
rom_addr[10:0] col [10 - 6] [5 - 1] [0] 0 0 0 0 0 font (5 bit) ASCII code[7]
Регистр адреса ПЗУ, записывается в два приема. Содержит адрес строки символа, ASCII код символа и адрес шрифта. Эти адреса расположены таким образом, что в ПЗУ можно прошивать стандартные файлы шрифтов *.fnt без какой-либо дополнительной обработки, просто подряд. Объединить несколько шрифтов в один файл для прошивки можно, например, программой редактирования файлов WinHex. Главное, чтобы шрифты были с разрешением 8х16.
rgb[5:0] [5 - 3] [2 - 0] rgb color 1/3 rgb color 2/3
Регистр вывода цвета. Этот регистр подключен непосредственно к ножкам ПЛИС, подающие сигналы R, G, B на монитор. Младшие 3 бита подают сигнал уровнем 2/3 яркости (должны подключаться к резисторам 390 Ом), старшие подают сигнал уровнем 1/3 яркости (их необходимо подключить к резисторам 750 Ом).
Поскольку объем данных ПЗУ достаточен, на монитор также можно выводить и графические изображения. При этом, изображение необходимо разбить на спрайты размером 8х16 и зашить в ПЗУ знакогенератора. Изображение только должно удовлетворять двум требованиям: чтобы в пределах одного спрайта было использовано не более двух цветов из палитры и количество спрайтов не превышало 256. Как, например, на изображении ниже. За специально подготовленное изображение спасибо художнику A_Foxli.
К слову сказать, уложиться в 256 спрайтов — задача не из легких, именно поэтому изображение выглядит больше как детский рисунок. В процессе подгонки его приходилось несколько раз упрощать. Рисование спрайтами отлично подходит, например, при выводе на экран логотипа фирмы.
Последний выпуск нашей рубрики в этом году символический - это таксофон. Телефон позволяет нам общаться, позвонить родным и близким, поздравить их с наступающим праздником.
Выпущен на пермском заводе ТЕЛТА в 1997 году. Модель АМТ-69 расшифровывается как Автоматический Монетный Телефон -1969 года разработки. Внешний вид минималистичен. Принимает жетоны (Вроде как есть АЖТ-69 именно жетонный, а АМТ-монетный, но в паспорте этого экземпляра написано именно АМТ):
Были разновидности принимающие копейки. Табличка - памятка из пластика.
Для защиты от вандалов крышки трубки стопорятся вот такими винтами. В старых моделях трубка из карболита.
На задней части видно язычок контактов, которые замыкаются, если телефон снять со стены. В таком случае диспетчер увидит попытку кражи и примет меры.
Отсек справа с ключом - монетница. Сама монетница имеет еще и свой замок.
Жетоноприемник сделан максимально просто разборным - дети помимо жетонов пихали все подряд, оно проваливалось и застревало. Поэтому для чистки части легко смещались., а если необходимо - извлекался целиком без использования инструмента.
Крепление троса. Внутри защитной пружинки расположен трос и сверхгибкий кабель. Трос принимает на себя все нагрузки, довольно надежное и долговечное решение.
Всем привет, снова) Моя хотелка так и не успокоилась. Цель была выбрана теперь другая - выбрать на авито КПК по лучшему соотношению цена/качество/возможности. Давайте приступим!
Введение
Только посмотрите на цены..... Печально, не правда-ли? Вот и я о том же.
Но не всех людей эти цены могут остановить. Бывают и довольно интересные случаи:
ого, да он просто мажор!
самая дорогая покупка кпк которую мне удалось заскринить
Что же случилось с ценами? Всё очень просто. Люди хотят заработать на коллекционерах в очередной раз) Но у них не всегда получается, некоторые девайсы висят на авито месяцами. И никто цену опускать не собирается. Не только я вижу данную ситуацию, люди не упускают возможность и сметают всё, что хоть немного ниже тысячи рублей:
Итак, данный КПК не имеет Wifi, у него всего 32мб памяти, а джойстик и вовсе отсутствует. В игрушки будет проблематично играть. Собственно, это типичная бюджетка тех времён. К тому же он имеет повреждения по корпусу. Но покупателя это не останавлиает, видимо берут их по какой-то другой причине. Типа "где ты возьмёшь классный КПК за такие деньги?"
Конечно, бывают хорошие варианты и за 1-2к рублей. Но бюджет мой ограничен -500р максимум. Что же в таком случае делать? А ведь КПК очень хочется!
Но что если посмотреть на авито не в разделе электроника/планшеты, а GPS-навигаторы? Хм, я пробовал. Листал очень долго, в основном видел никому нафиг не нужные кирпичи на windows CE. Вскоре начинают попадаться вот такие объявления:
Оказалось что КПК в отличном состоянии в пределах 500р можно найти
Выглядит здорово. И будет в комплекте даже зарядное устройство и диски с ПО для большого брата: ActiveSync, Руссификатор от Макцентра. Вот это да! Цена была чисто символическая - 400р, которая идеально подойдёт по моему бюджету. Но обьявление висит на авито уже наверное более месяца, а девайс никто не взял. Как так? Это такой же КПК на Windows Mobile, только предназначенный чуть-чуть для других вещей. В основном такая штука нужна для того, чтобы висеть на стекле автомобиля и выполнять роль навигатора.
Ситуация выглядит следующим образом
Оказалось всё очень просто. Люди думают что это обычный китайский навигатор который КПК вовсе не является. А коллекционеров такие вещи вовсе не привлекают и они проходят такие объявления стороной. Что-ж, я воспользуюсь этим)
Начало
Короче, я принял решение. Не важно кто сделал данное устройство, самое главное то, что оно будет работать на Windows Mobile, иметь достаточно большой яркий экран не менее 3.5" дюймов, иметь Wifi и bluetooth, а так же неплохой процессор. Mio MITAC p550 идеально подходит под эти требования, и я, не долго думая, решил его купить:
Как навигатор в 2023 году - не очень, давно появились крутецкие Яндекс карты. Но как КПК такая штука очень даже ничего. Толстый пластик, многопозиционный джойстик, защитное покрытие экрана придают данному девайсу дополнительную надёжноть и уверенность в том, что он прослужит долгие годы. Корпус не покрашен, это естественный цвет пластика. Это значит что Mio p550 всегда будет сохранять свой прекрасный внешний вид.
Итак, вот он у меня в руках:
Чтобы эти клавиши загорелись синим при нажатии, мне надо было установить энергопатч. Хорошо что на форуме 4pda была тема этого устройства.
К WIFI зверёк подключаться не хочет. Оказывается, что он не поддерживает WPA2 шифрование. Что же делать? Интернет по блютуз? Гемморой. Но есть ещё один способ - синхронизация с помощью ActiveSync. В таком случае Get Started CD от производителя нам очень поможет.
Программа не захотела работать на Windows 8.1 Пришло время достать своё древнее зло)
Вот он и поможет нам синхронизировать этого зверька. После установки необходимого ПО программа попросила нас перезагрузиться. За кадром я завершил настройку соединения, после чего большой брат сразу же синхронизирует наш девайс и даёт ему доступ к интернету:
Ура, теперь мы можем лазить в интернет. Ещё можно установить браузер Opera, который будет открывать большинство сайтов, включая 4pda, яндекс, википедия, old-dos, и прочие:
А что там по играм? Всё не так уж и плохо. Кроме портированных игр вроде doom и quake есть игры специально для windows mobile. Вот, например, некоторые из них:
SimCity2000 для Pocket PC
Серии игр Asphalt для КПК
Это то, во что я играл. Игр гораздо больше, мне просто лень перечислять) Ещё есть эмуляторы sega, gba, движка mophun и эмуляторы j2me, такие как Jbed, например. Всё это расширяет библиотеку игр для КПК в разы.
Заключение
Мне нравится Windows Mobile. Замечательная многозадачная операционная система, позволяющая делать пользователю всё что он захочет. Можно менять системные звуки, можно хоть весь интерфейс изменить. Программировать под неё так же довольно просто. Если вы не особо шарите в c++ и win32, существует .net compact framework и VS2008, чтобы программировать на C# или Visual Basic. Так же есть много полезных сторонних программ для этой ОС, которые позволяют редактировать реестр, разнообразить главный экран "Today", добавляя на него виджеты. Есть total commander, Pocket RAR, встроенный Pocket Office, Regedit, и даже софт для управления частотой процессора. В моём девайсе установлен процессор от samsung, SC2440 на 400мгц. С помощью программы ClockWizard я могу понижать и повышать частоту даже выше максимальной. Это называется OverClocking. Вот как это выглядит:
Максимальная частота - 420мгц. При этом батарея садится быстрее. Есть ещё AutoScaling который может автоматически поднимать или опускать частоту в зависимости от требований пользователя. Это пригодится если вы, например, хотите убрать тормоза в 3д играх. Так же не стоит забывать что Windows Mobile работает на ядре от WinCE, а это значит что и приложения от WinCE тоже будут работать на этой ОС. Перетаскивать окошки можно, но практического смысла от этого не будет. Кстати, ещё на физические кнопки можно повесить запуск любой программы или действия:
В общем, вещь очень классная, её можно брать с собой и читать новости или книги, играть в игры, выходить в интернет по блютузу, wifi(если очень постараться), или через usb, кастомизировать операционку, подключать различные переферийные устройства(данный КПК умеет в otg) и многое другое. Главное, чтобы аккумулятора хватило, а он тут не совсем съёмный. Крышка на винтике, прикрыта резиновой заглушкой, а сам аккумулятор на разъёме.
В общем, за такие смешные деньги я купил довольно крутой КПК, который уделывает по техническим параметрам многих конкурентов бюджетного сегмента. Пока что меня всё устравивает, покупкой доволен, и всем рекомендую выбирать КПК от Mio. Ведь они надёжные, прочные, имеют неплохие характеристики и стоят недорого, главное найти.
Всех с наступающим новым годом! Спасибо что прочитали!
