Обычно Android-устройства принято считать "бесполезными" через 5-10 лет после выхода. Особенно, это касается бюджетных моделей, которые "не тянут" современные сервисы или те девайсы, которые по каким-то причинам физически пострадали в процессе своей жизни. Но пока одни выкидывают смартфоны и планшеты, считая их электронным хламом и засоряя мир, другие стараются найти применение всему подряд и оказывается, что Android-устройства ещё вполне себе могут оказаться полезными. Однако порой необходимо реализовать автоматическое включение устройства при подключения к зарядке и вот здесь многие впадают в ступор - ведь замкнуть кнопку включения зачастую недостаточно! В сегодняшнем материале я расскажу свои кейсы запитывания устройств от блоков питания, а также реализацию автовключения на разных чипсетах. Интересно? Тогда добро пожаловать под кат!
❯ Как и зачем?
Вероятно, читатель спросит мол "зачем 10-летние Android устройства могут быть нужны?". И если немного призадуматься, то можно прийти к выводу, что действительно гаджеты прошлых лет могут быть достаточно полезными во многих сферах, причём не только планшеты, но и Android-смартфоны. И помимо реализации чего-то "стандартного" на манер красивых Android-часов с будильником или, например, мультимедиа станции а-ля iPod, есть ещё множество интереснейших кейсов, в которых можно использовать такие устройства. Я лично собрал для себя несколько:
HMI-панель: это умные программируемые дисплейные модули, которые могут выводить ту или иную информацию с микроконтроллеров или любых других устройств на экран. Благодаря 10-дюймовому планшету можно сделать очень удобное переключение режимов работы каких-то устройств, либо сделать показ информации с различных датчиков в помещении в реальном времени. Никто не мешает и в машину такой планшет поставить для сбора информации о двигателе.
У Android-устройств перед классическими HMI-дисплеями есть огромное преимущество: наличие 3D-ускорителя и возможность выводить красивые визуалиации и графики, а также анимацию. В будущем проекте со своей машиной - "ВАЗ 2110", я покажу как использовать планшет в таких целях на практике.
Сбор данных: у микроконтроллеров слишком маленький объем встроенной Flash-памяти, чтобы хранить какие-то большие датасеты и строить из них статистику. Конечно можно подключить MicroSD... но ведь ко всем сразу не будешь по отдельной флэшке подключать, да и MicroSD отнюдь невечные при постоянной перезаписи данных - и здесь приходит на помощь такой планшет. eMMC обычно значительно более выносливая через MicroSD, с неё можно достать данные (при отсутствии шифрования), а мощный процессор планшета вполне может ещё и обрабатывать приходимые данные и куда-то отправлять. Вполне полезно!
Использование как одноплатника: я писал об этом недавно статью. Во многих бюджетных планшетах разведен UART на плате, к которому есть доступ из пользовательского окружения и даже Java-приложений! Таким образом, можно общаться с микроконтроллерами по проводному интерфейсу, или напрямую дергать ножками микроконтроллера реализовав прошивку-прослойку для МК.
Нестандартные применения: ну, тут я просто хотел похвастаться своим проектом с превращением планшета в игровую консоль с помощью внешнего микроконтроллера :)
Так что, как мы с вами видим, устройства прошлых лет отнюдь не бесполезны и при определенной смекалке мы можем им дать вторую жизнь и приспособить для работы на каком-нибудь объекте. Понятное дело что что-то серьёзное на них никто вешать не будет, но например панель заказа нямки в чебуречной или что-то на манер ГУ в машине - почему бы и нет?
Однако порой возникает задача реализовать авто-старт устройства при подключении смартфона к зарядке или вообще реализация автономной схемы питания. Автономная схема питания реализуется относительно легко: порой можно кинуть 5В от блока питания на VBat (плюсовой и минусовой контакт АКБ) напрямую. КП у MediaTek, имеют пороговое напряжение на аккумуляторе до 5.5-5.6В и не выгорают. Но это рискованно, если БП плохой и произойдет скачок - есть шанс того, что окажется пробитой обвязка/КП/ключи (вход со стороны USB обычно защищен от такого). Лучше всего использовать DC-DC преоразователь на ~4.2В с током от 1.5-2А.
А вот с авто-стартом вопрос интереснее. Всё зависит от реализации этой самой кнопки включения и от чипсета: например, на смартфонах Sony с чипами Qualcomm иногда достаточно лишь сдуть кнопку включения и замкнуть её контакты перемычкой: всё будет работать без каких-либо проблем. Но на некоторых смартфонах, зажатая кнопка включения будет уводить устройство в циклический ребут каждые 10 секунд, что может быть неприемлемо.
Несколько месяцев назад, читатель под ником @A1f подогнал мне китайский iPhone 7 Plus на Android - всё как я и люблю :) Девайс был рабочий, однако после того, как читатель отдал его в сервис, у него по каким-то причинам потерялось пару винтов, оказалась сломана кнопка включения на шлейфе, а смартфон не заряжался...
Ну, с зарядкой вопрос я решил быстро: китайские айфоны иногда используют свои "Lighting'и", несовместимые с оригиналом и которые не могут заряжатьоригинальный айфон. Благо в комплекте был пожухлый оригинальный кабель, который я разобрал и припаял всё обратно. Теперь и USB, и зарядка работают нормально!
С кнопкой вопрос был интереснее: хотя найти такую на шлейфе и кинуть с неё перемычки - дело 5 минут, я лёгких путей не искал и решил сделать автостарт при подключении к зарядке - как и на оригинальном айфоне :)
И, как вы уже поняли, просто так поставить перемычку на контакте Power и массу не получится - смартфон будет постоянно уходить в ребут. Поэтому я сдампил загрузчик с помощью SP Flash Tool и начал ковырять его в IDA Pro, благо устройство не требует разблокировки этого самого загручзика. Способ рабочий для многих устройств на MediaTek, в том числе и некоторых 67xx (возможно придется разблокировать загрузчик), а на устройствах с другими чипсетами алгоритм может быть +- похожим, но если нет возможности напрямую вмешаться в загрузчик, можно сделать авто-загрузку патчем boot.img.
❯ Реверсим и патчим
Для реализации автозагрузки, необходимо пропатчить загрузчик. В устройствах на чипсетах MediaTek их два - первый Preloader, который занимается первичной инициализацией периферии и ОЗУ, а второй - lk, который инициализирует дисплей, грузит ядро Linux и передаёт ему управление. В сети уже давно лежат слитый исходный код и Preloader, и lk, так что с их изучением проблем не возникнет, идея общая у всех устройств.
Итак, что-же происходит при включении смартфона? lk определяет так называемый режим загрузки, в зависимости от которого меняется раздел, с которого грузится ядро (boot или recovery), а также параметры передаются ядру (atags). В процессе работы lk и перед загрузкой ядра, перед тем как показать анимацию зарядки, загрузчик проверяет нажата ли кнопка включения - и если да, то быстренько перезагружает устройство в обычный режим.
Да, всё так легко! Таким образом, нам остаётся лишь пропатчить условие с проверкой кнопки включения, дабы смартфон считал что кнопка нажата тогда, когда она по факту не нажата. В IDA Pro, lk загружается с смещением памяти в 0x0, а найти нужную инструкцию нам поможет зацепка в виде отладочной строки. IDA Pro сразу строит все xref'ы и обращения к строкам, так что найти нужные данные не составит труда. Ищем "[%s] PowerKey Pressed in Kernel Charging Mode Before Jumping to Kernel, Reboot Os" и смотрим все обращения к адресу памяти, с которого начинается строка.
Чуть выше метода вызова printf, можно найти наше условие, которое начинается с инструкции CMP R0, #0. Сразу после него идёт инструкция BNE, которая бранчит код и продолжает загрузку системы в режиме "зарядки". Нам остаётся лишь заменить её на NOP в hex-редакторе в той-же IDA Pro и система сразу после попытки включится в режиме зарядки уйдет в ребут и перезагрузится в обычном режиме, будто мы просто включили смартфон с кнопки!
Прошиваем наш новый lk:
И видим, что всё работает! :)
❯ Второй способ
Если возможности пропатчить загрузчик нет, в дело вступает второй способ, заключающийся в патче boot.img - раздела с ядром устройства и ramdisk'ом, в котором содержаться скрипты для инициализации устройства (*.rc). Всё дело в том, что даже при зарядке смартфон загружает ядро Linux, первоначальный рамдиск и в зависимости от режима загрузки запускает либо app_process (главныйй процесс в Android), стартуя загрузку системы, либо специальную программу, которая часто называется charger и находится в /system/bin/ (иногда в самом boot.img).
На смартфонах с разными чипсетами реализация этого способа может сильно отличаться, однако приведу пример с смартфонами Sony Erisson из 2011 года (у меня есть Xperia Play с сломанной кнопкой включения). Там устройство начинает выполнение скрипта init.rc, тот в свою очередь запускает init.semc.rc и на этапе инициализации запускает программу chargemon, которая выводит анимацию зарядки, отключает смартфон, если кабель вытащили и слушает нажатие кнопки включения, продолжая процесс загрузки, если пользвоатель зажал кнопку включения. Соответственно, весь фикс - закомментировать эту строку :)
#exec /system/bin/chargemon
В случае MTK, можно попробовать ещё пропатчить init.rc, дабы он продолжал загрузку системы даже в случае подключения кабеля в режиме зарядки. Способов много, главное проявить смекалку и не бояться разбираться в чём-то непонтяном :)
❯ Заключение
Как видите, ничего сложного в реализации автоматического старта устройства нет. Где-то можно обойтись перемычкой на кнопку включения, где-то патчем boot.img, а где-то и патчем загрузчика. Но тем не менее, это вполне возможно на практике и позволяет делать такие приколюхи, как я со своим китайским айфоном :)
Надеюсь, материал вам был интересен и полезен! Пишите, нужно ли вам было реализовать что-то подобное и как это делали в комментариях!
Друзья, если у вас есть подобные китайчики и вы не разделяете желания пытаться вдохнуть в них жизнь, но выбрасывать их жалко — можете задонатить их мне :) Как сами видите — девайсы попадают в хорошие руки. Из недавнего — я взял нерабочую, утопленную китайскую копию 14 Pro Max из под СЦ в качестве основного смартфона. Также у меня есть канал в Telegram, куда я выкладываю бэкстейджи статей, различные заметки о ремонте, моддинге, программировании и реверс-инжиниринге и свои мысли, а также ссылки на свои новые статьи и видео. Кому интересно — залетайте!
Интересный материал?
Если вы постоянный читатель, смотрите ли вы мой YouTube-канал?
Статья подготовлена при поддержке TimeWeb Cloud. Подписывайтесь на меня и @Timeweb.Cloud, чтобы не пропускать новые статьи каждую неделю!
Всем привет Жил не тужил и решил поменять акб. Я его и сам купил с рук(примерно года 2 бу)и сам походил лет 5. Думаю поменяю акб на новый и домой буду приходить не с 25 процентами(в среднем) а с 40 процентами. Как человек не сильно шарящий покупаю vixion и теперь прихожу домой с 10-15 процентами(2 месяца как батарею поменял, о раскачке даже не говорите) S10plus керамика на 1 терабайт)менять не вижу смысла, прогресс развития мобильных устройств стоит на месте и смысла в новом устройстве нет(ради акб не думаю что стоит телефон менять) Мастера посоветуйте нормальный бренд по акб, что-бы поменять и радоваться
В наше время, из-за санкций одноплатники стали стоить каких-то «конских» денег. Даже б/у RaspberryPi Zero стоит 2-3 тысячи рублей на барахолках, что, мягко скажем, не совсем лояльная цена для «самого дешевого одноплатного компьютера в мире». Конечно, Orange Pi Zero всё ещё можно купить в пределах 1.500-2.000 рублей, но как по мне и эта цена не слишком лояльна за те характеристики, который предлагает такой одноплатник. С другой стороны, Android-планшеты 10-летней давности продаются на барахолках по 100-300 рублей, что выглядит гораздо привлекательнее, причём на некоторые устройства практически без костылей можно установить полноценный дистрибутив Linux! Вероятно, многие читатели скажут мол «автор бомж» и будут правы: ведь в рамках этой статьи, я хочу рассказать о том, как использовать полурабочий древний планшет в качестве полноценного одноплатника путём подключения его к микроконтроллеру и выводу GPIO! Сегодня мы с вами: узнаем, как подключить микроконтроллер к шине UART в планшете и научимся работать с последовательной шиной в Android прямо из Java и нативных программ. Интересна моя концепция антикризисного одноплатника? Тогда добро пожаловать под кат!
❯ Зачем это нужно?
Пожалуй, нельзя сказать, что подобная концепция пристраивания старых планшетов — вопрос исключительно цены. 2-3 тысячи рублей не такие уж и большие деньги и при желании можно купить хотя-бы Б/У, но всё таки полноценный одноплатник с нормальной GPIO-гребенкой. Однако здесь стоит вопрос не столько дешевизны, сколько E-Waste: зачем выкидывать в помойку потенциально рабочие планшеты с живым процессором, если их можно пристроить куда-то ещё?
На самом деле, планшеты с ROOT-доступом уже из коробки могут выполнять весьма полезные задачи, как, например, хостинг http-сервера для домашней страницы, работать как панель с часиками и погодой, или, например, работать в качестве HMI-панели для оформления заказов в шаурмечной. Кроме того, многие планшеты на базе смартфонных чипсетов (MediaTek, Spreadtrum) имеют полноценный Bluetooth-модуль, что позволяет «подружить» планшет с микроконтроллером через радиоканал, что значительно расширяет возможный спектр применений.
Преимуществ у такого подхода много: у «пожилого» планшета уже есть большой, достаточно качественный (хороший TN, либо даже IPS) дисплей с тачскрином, который поддерживает мультитач, GPU для вывода 3D-графики, 3.5мм для вывода звука + встроенные динамики, а также весьма неплохое, по сравнению с дешевыми одноплатниками, железо. Звучит весьма вкусно для цены в 300 рублей: собрать хоть немного похожую конфигурацию на базе RPi выйдет в 10-15 тысяч рублей (учитывая дороговизну MIPI-матриц с тачскринами + цену самой «малинки» и обвязки для аудиотракта).
Но при всех перечисленных достоинствах, атрибутом любого полноценного одноплатника является наличие GPIO — и даже здесь мы сможем с вами выкрутится! Первый способ, о котором я чуть выше вскользь рассказал, позволяет реализовать общение с МК и «ногодрыг» через BT-радиоканал, но минусы такого подхода очевидны (МК с BT дороже, радиоканал потребляет дополнительную энергию, некоторые могут посчитать BT небезопасным). Однако есть и второй подход, который заключается в использовании диагностических пятачков UART на плате устройства для наших личных целей!
С таким подходом можно использовать как «голый» Linux, используя концепцию, которую я представил в этой статье, так и взаимодействовать из Java-приложений для Android (что даёт уже, как минимум, удобный GUI-фреймворк). Сегодняшняя статья будет «без воды», только чистая конкретика, поэтому давайте перейдем к реализации!
❯ Подготовка
Как я уже говорил выше — в рамках данной статьи мы рассмотрим использование UART в планшете для наших собственных целей. UART — это двунаправленная полнодуплексная цифровая шина, которая позволяет обеспечить стабильную передачу данных при относительно невысокой скорости, измеряемой вбодах. То есть, быстро стримить картинку с её помощью вы не сможете, но сможете, например, получить состояние входов МК, прочитать что-то на шине I2C, используя мост UART -> I2C или, например, прочитать показания датчиков, которые МК предварительно опросил.
Сама по себе концепция очень простая: многие китайские производители планшетов и смартфонов не только разводят UART в виде отдельного пятачка на плате, но и подписывают его, задействуя UART-канал как вывод для логов ядра, а иногда и предоставляя доступ к рутовой консоли! В свою очередь, из юзерспейса мы можем получить доступ к UART с помощью устройства/dev/ttyS<x>на подавляющем числе чипсетов и/dev/ttyMT<x>на MediaTek. Однако учтите, что в некоторых случаях придется патчить загрузчик, дабы редиректнуть логи ядра в /dev/null.
Однако наличие UART на плате — не всегда признак того, что он сконфигурирован в системе верно. Например, на смартфонах с чипсетами SC6820 нормально завести UART я так и не смог, а на некоторых устройствах на базе MT657x нужно патчить загрузчик, дабы он «увидел» нужный канал UART! В моём случае, героем статьи стал планшет Prestigio, у которого отказал тачскрин, но был доступен UART:
Конкретно в моём случае, после установки последней официальной прошивки планшет перестал слать логи на UART и устройство /dev/ttyMT3 оказалось доступным для наших операций, в вашем же случае может потребоваться настройка devicetree, или просто патчинг загрузчика, дабы редиректнуть консоль на другой вывод UART. Кроме того, необходимо обязательно получить root-доступ хотя-бы к adb shell, поскольку доступ к /dev/tty устройствам возможен только от имени суперпользователя. Как же проверить UART на возможность чтения/записи? Сначала нам необходимо взять ESP32 или любой UART-USB преобразователь, припаять сигнальные линии RX/TX и использовать любую программу для работы с последовательным портом, например Putty. Заходим в adb shell, и пишем что-нибудь в консоль:
Вуаля! Всё работает :)
Работает? Замечательно, значит мы сможем использовать планшет вместе с микроконтроллером! Переходим к практической реализации нашего приложения!
❯ Используем из Java
Я специально решил выделить для Java-подхода отдельный раздел, поскольку просто взять и открыть /dev/ttyMT3 с помощью FileInputStream не выйдет. Дело в том, что даже несмотря на наличие root-доступа, по факту ни одно Android-приложение его не имеет (за исключением подписанных системных в папке /system/app/) и для всех операций, требующих повышенных привилегий, либо распаковывают и запускают внешнюю нативную программу из под суперпользователя, либо с помощью специального костыля с запуском sh-программ читают/пишут нужные блочные устройства сами. Связано это с тем, что все Android-приложения работают в хост-процессе app_process, который форкается (отпочковывается) от «главного» процесса, который запущен из под «простого» пользователя, который не находится в группе system.
Здесь концепция также очень простая: su имеет аргумент -c, который позволяет запустить команду от имени root-пользователя и возвращает объект процесса, дабы мы потом могли перехватить stdout:
Таким образом, для чтения текстовых данных из UART'а нам достаточно лишь периодически «слушать» stdout команды cat и обрабатывать данные:
Костыль, но со вкусом :) Если вас не устраивает такой подход или ваше приложение значительно более комплексное, вы можете использовать UART и из под нативных программ.
❯ Используем из C
Работа с последовательными портами в Linux не отличается от работы с любыми другими файлами и устройствами: вызовов open, read, write и close обычно хватает и лишь иногда к ним в довесок нужен ioctl.
int fd = open("/dev/ttyMT3", O_RDWR); int result = write(fd, command, strlen(command));
Для работы с терминалом необходимо использовать модуль termio который предоставляет все необходимые структуры для настройки режима работы терминала, в т.ч и бодрейт. Дело в том, что изначально последовательное устройство настроено на режим работы в качестве терминала, т.е драйвер отдаст данные только после того, как устройство на UART пошлёт \n, или превысит размер внутреннего буфера для сообщения. Если вам нужно работать с бинарными данными и получать их «на лету» — необходимо настроить последовательный порт в «binary» режим:
Если же вам достаточно текстового терминального режима, то можно продолжить как есть и использовать fgets, fscanf и прочие удобные функции из libc! О том, как собрать нативную программу для смартфона и как вообще выбросить Android из него, читайте в моей отдельной статье.
❯ Заключение
Вот таким образом можно использовать проводную шину в планшете для собственных нужд! Как видите, совершенно ничего сложного и используя эти наработки, я реализовал уже не один проект! Надеюсь, материал вам был интересен и полезен :) Пишите своё мнение, можно ли использовать дешевые планшеты по 300 рублей в качестве одноплатников?
Статья была подготовлена при поддержке TimeWeb Cloud. Подписывайтесь на меня и @Timeweb.Cloud, дабы не пропускать новые статьи каждую неделю! Ну а больше подробностей о будущем контенте, как обычно, в первом комменте! Также у меня есть свой Telegram-канал, куда я выкладываю свои мысли, советы по ремонту и моддингу различных гаджетов, а также вовремя публикую ссылки на новые статьи!
Если сейчас приехать в пункт приема металлолома, то можно обнаружить просто огромные кучи различных телефонов и прочих электронных «отходов», которые стоят под открытым небом и ждут, когда придёт их черёд окончательного разложения. Однако при ближайшем рассмотрении выясняется, что многие девайсы оказываются полностью рабочими даже после недельного лежания под палящим солнцем и проливными дождями, а сдали их в чермет по причинам «не нужен, надоел, купил новый» и т. п. Я не считаю это правильным, ведь даже в простые кнопочные звонилки имеется возможность вдохнуть новую жизнь, если знать один интересный, но малоизвестный факт: для них можно писать нативные приложения на C и использовать железо телефона в своих целях. А это, на минуточку, как минимум: дисплей с подсветкой, вибромотор, динамик, клавиатура и GSM-радиомодуль с возможностью выхода в сеть. Сегодня мы с вами: узнаем, на каких аппаратных платформах работают китайские телефоны, какие существуют программные платформы и где взять для них SDK, а в практической части мы напишем 2D-игру с нуля, которая будет работать на многих китайских кнопочниках. Интересно? Тогда жду вас под катом!
Содержание:
Не J2ME едины
Аппаратные ресурсы
Кроссплатформенный рантайм
Кроссплатформенный рантайм: Win32
Кроссплатформенный рантайм: MRE
Кроссплатформенный рантайм: VXP
Наконец-то пишем игру
Тестируем на реальных девайсах
Заключение
❯ Не J2ME едины
Думаю, многие мои читатели помнят о такой платформе, как J2ME. Java-приложения стали фактически основной возможностью расширения функционала телефонов в 2000-х годах. API для них был достаточно хорошо стандартизировано, программы не зависели от архитектуры процессора и ОС устройства, а порог вхождения для написания собственных приложений был довольно низкий и даже новички могли за пару дней написать свою игрушку или какое-нибудь GUI-приложение!
Однако не одним J2ME мы были едины: существовало множество платформ, которые так или иначе пытались занять нишу Java на рынке. Некоторые из них я упоминал в своей прошлой статье о написании 3D-игры под Sony Ericsson с нуля: например, была такая платформа на телефонах Sony Ericsson серии T, как Mophun, а CDMA-телефонами с чипсетами Qualcomm использовалась нативная платформа BREW. Пожалуй, я не буду упоминать о .sis и .cab — поскольку это форматы нативных приложений для смартфонов, а не простых «фичефонов».
В какой-то момент, ближе к 2006-2007 году, прилавки российских официальных ритейлеров (по большей части это были телефоны Fly) и неофициальных продавцов на рынках заполонили различные китайские телефоны, которые предлагали какой-то немыслимый функционал для тех лет за копейки, да ещё и визуально напоминали флагманские модели известных брендов. Пожалуй, одним из самых популярных таких телефонов была Nokla TV E71/E72 (да, именно «нокла»), вышедшая примерно в 2008 году и производившаяся аж до 2011 года! За 2-3 тысячи рублей (это менее 100 баксов), пользователь получал здоровый 2.4" дисплей с разрешением 240x320 весьма неплохого качества (когда в те годы многие продолжали ходить с 176x220), да ещё и с тачскрином, гироскоп, огромный громкий динамик (пусть и не очень качественный), поддержку SD-карточек до 32Гб, нередко фронтальную камеру, а также премиальный дизайн с вставками из алюминия. Частенько китайцы заботливо клали в коробку ещё чехольчик и дополнительный аккумулятор :)
Были даже полные копии существующих устройств от Nokia. Особенно китайцы любили подделывать массовые модели на S40: они были очень популярными и китайцы хотели откусить свой кусок рынка у Nokia. Пусть и рынка серого импорта — очевидно, в салонах связи подделки никто не продавал:
Но была и ложка дёгтя в этой бочке меда: китайские телефоны очень часто не имели поддержки Java, из-за чего многие пользователи разочаровывались в них из-за отсутствия возможности установить необходимые им приложения. Никакой тебе оперы, аськи, игр… Скорее всего, это связано с необходимостью отчислений Sun, а также разработчикам реализации J2ME-машины (JBed/JBlend) и установки чипа флэш-памяти чуть большего объёма.
Но многие пользователи не знали, что такие девайсы не просто поддерживали сторонние приложения, но и умели выполнять настоящие нативные программы, написанные на полноценном C! Всему помешала китайская костыльность и тотальная закрытость. Платформа предполагалась для работы на внутреннем рынке. Для вызова менеджера нативных приложений необходимо было вводить специальный инженерный код в номеронабирателе, предварительно скопировав приложение в нужную папку, а SDK долгое время было платным и доступно только для компаний из Китая. Кроме того, далеко не все приложения могли запустить на конкретном девайсе — были серьезные проблемы с совместимостью.
Всё как вы любите: HiTech-девайсы на фоне ковра, который старше автора лет на 30 :)
В ранних китайских телефонах использовалась платформа Mythroad (MRP, MiniJ) от китайской компании SkyWorks, которая лицензировала свою технологию производителям чипсетов. Поддержку MRP можно было встретить на телефонах с чипсетами MediaTek, Spreadtrum, а также MStar (и возможно Coolsand). Mythroad предоставлял некоторое API для работы с железом телефона и разработки как UI-приложений, так и игр, кроме того, Mythroad позволял хранить ресурсы в одном бинарнике с основной программой и даже имел какой-то интерпретируемый язык помимо возможности запуска нативного кода. Для работы таких приложений необходимо было скопировать менеджер приложений dsm_gm.mrp и игру в папку mythroad во внутренней памяти устройства или на флэшке, а затем набрать в номеронабирателе код *#220807#, иногда при отключенной первой SIM-карте. Костыльно? Костыльно! Откуда об этом знать среднестатистическому пользователю? Не откуда! Но работало!
Эта платформа поддерживалась на большинстве подделок под брендовые устройства Nokia, Sony Ericsson и Samsung, а также iPhone и на многих китайских кнопочных телефонах 2008-2010 годов.
Ближе к 2010 году MediaTek разработала свою собственную платформу, которая должна была заменить MRP — WRE (VXP). Эта платформа была гораздо шире с точки зрения функционала (например, был доступ к UART) и её API был вполне удобно читаем для программиста, а SDK свободно доступен для всех. Один нюанс всё портил — приложения без подписи привязывались к IMSI (даже не IMEI) симки в девайсе и на некоторых девайсах требовали переподписания под каждую конкретную SIM или патчинг дампа оригинальной прошивки телефона на отключение проверки подписи. Эта платформа поддерживалась на многих кнопочниках и смарт-часиках 2010-2020 годов: к ним относятся новодельные телефоны Nokia, телефоны DNS и DEXP, Explay и т. п. Для запуска приложений достаточно было выбрать файл с разрешением VXP в проводнике и просто запустить его. Но с совместимостью всё равно имелись проблемы: если запустить VXP для версии 2.0 и выше, мы получим лишь белый экран. Ну хоть не софтресет, и на том спасибо!
Далеко не все такие часы поддерживают MRE, смотреть нужно от устройства к устройству
❯ Аппаратные ресурсы
Большинство китайских кнопочных телефонов работает на базе одних и тех же чипсетов. В конце нулевых чаще всего использовались чипсеты MT6225, SC6520 и некоторые чипы от Coolsand. Средние хар-ки девайса были следующими:
Процессор: ARMv5 ядро на частоте ~104МГц, ARM926EJ-S. Нет FPU, есть Thumb. Большую часть процессорного времени программа могла забрать себе.
ОЗУ: ~4Мб SDRAM. Программам было доступно 512Кб-1Мб Heap'а. Это, в целом, довольно немало для большинства применений.
Флэш-память: ~32Мб, пользователю доступно пару сотен килобайт. Да, вы не ослышались, килобайт! Однако можно без проблем использовать MicroSD-флэшки до 32Гб.
Дисплей: от 128x128 до 320x480, почти всегда есть 18-битный цвет (262.000 цветов), в случае TV E71/E72 используется очень неплохая TN-матрица с хорошими углами обзора и яркой подсветкой. Иногда есть тачскрин.
Звук: громкий динамик, наушники.
Аккумулятор: ~800мАч, на некоторых девайсах может быть и 2.000мАч, а то и больше!
Ввод: клавиатура, иногда была поддержка QWERTY.
Внешние шины: почти всегда был доступен UART, причём его можно было свободно взять прямо с платы — он был явно подмечен! Взять GPIO с проца не выйдет (кроме, возможно, вибромотора), SPI и I2C также напрямую недоступны. Внешние шины можно реализовать с помощью UART через GPIO-мост из микроконтроллера.
В итоге мы получаем очень неплохие характеристики для устройства, которое сочетает в себе сразу всё. На базе такого девайса можно сделать и сигнализацию, и HMI-дисплей с интерфейсом для управления каким-нибудь устройством, и игровую консоль с эмуляторами… да на что фантазии хватает! И это за какие-то 200-300 рублей, если мы говорим о б/у устройстве или 600 рублей, если говорим о новом. Это дешевле, чем собирать девайс с подобным функционалом самому из готового МК (например, RP2040) и отдельных модулей. Кстати, дешевые 2.4" дисплеи на алике — это ни что иное, как невостребованные остатки дисплеев для подобных китайских телефонов на складах! А вы думали, откуда там значки на тачскрине снизу?
Однако в рамках данной статьи мы не будем ограничиваться лишь теорией и на практике напишем примитивную 2D-игрушку, которая будет работать сразу на трех платформах без каких-либо изменений в коде самой игры: Windows, MRP (Mythroad) и VXP. Но для того, чтобы достигнуть такого уровня абстракции от платформы, нам необходимо написать рантайм, который оборачивает все необходимые платформозависимые функции для нашей игры.
Игрушка будет простой: 2D скролл-шутер с видом сверху, а-ля Asteroids. Летаем по космосу, и стреляем по враждебным корабликам, стараясь не попасть под вражеские лазеры. Всё просто и понятно :)
❯ Практическая часть: Кроссплатформенный рантайм
Итак, что нам необходимо от абстракции для такой простой игры? Давайте посмотрим:
Графика: очистка экрана, отрисовка спрайтов с прозрачностью (без альфа-блендинга, только колоркей), отрисовка текста. При возможности, желательно использовать нативное API системы для рисования графики, а не городить собственный блиттер. Формат пикселя фиксирован: RGB565 (65к цветов).
Ресурсы: хранятся в одном образе с основной игрой. Фактически, все ресурсы упакованы в виде обычных массивов байт в заголовочных файлах. Я пользуюсь вот этой тулзой для конвертации спрайтов в массивы байтов.
Звук: воспроизведение хотя-бы одного WAV-потока. Почему одного? Потому что далеко не на всех платформах есть доступ к аппаратному микшеру… да и вообще не везде есть прямой доступ к PCM (привет MRP), иногда разработчики ограничиваются лишь одним каналом для WAV-звука без возможности воспроизведения нескольких аудиофайлов одновременно.
Ввод: абстракция от клавиатуры классического моноблока: стрелки, OK, левый и правые софткеи.
Стандартная библиотека: не на всех платформах можно вызывать функции напрямую из stdlib. Как минимум в MRP и, например, «эльфах» для Motorola, нет возможности вызывать аллокатор, rand и некоторые другие функции из обычных заголовочников стандартной библиотеки. На таких платформах, системные инклуды дефайнами подменяют стандартные функции на своих реализации:
#define malloc system_alloc
#define free system_free
Но если у нас игра кроссплатформенная, то и платформозависимые инклуды мы использовать не будем.
Выглядит всё достаточно просто, верно? Примерно такого набора функций хватит для нашей игры:
❯ Win32
Давайте же перейдем к реализации рантайма на каждой платформе по отдельности. Начнём с Win32, поскольку адекватно отлаживать игру можно только на ПК.
На десктопе у нас будет фиксированное окно 240x320, в качестве GAPI будет использоваться аппаратно-ускоренный OpenGL, а для обработки ввода будет использоваться классически GetAsyncKeyState. Реализация точки входа, создания окна и инициализации контекста GL и главного цикла приложения у нас такая:
Реализация отрисовки спрайтов очень примитивная — OGL 1.0, полностью FFP, вся отрисовка — это 2 треугольника, формирующие квад. Спрайт заливается при первом использовании в текстуру, последующие кадры реюзается уже готовая текстура. Фактическая реализация всего рендерера — т. е. функций для рисования «просто картинок», без поддержки атласов, блендинга цветов (З.Ы - длинные листинги будут на пастбине, на Пикабу нет нормального тега для кода):
С вводом тоже всё просто. Есть биндинг кнопок клавиатуры к кнопкам на кейпаде телефона. inGetKeyState предполагается вызывать один раз за кадр, поэтому функция опрашивает ОС о состоянии нажатых кнопок на клавиатуре и назначает состояние виртуальных кнопок относительно состояния физических кнопок на клавиатуре.
Результат:
❯ MiniJ
Переходим к реализации рантайма для первой китайской платформы — MRP. Обратите внимание — я использую нативное API платформы для рисования спрайтов. Связано это с тем, что софтварный блиттер работает невероятно медленно даже с прямым доступом к скринбуферу устройства, а в чипсете предусмотрена отдельная графическая подсистема с командбуфером для быстрой отрисовки примитивов и графики:
SDK для MRE можно найти здесь (SKYSDK.zip): оно уже пропатчено от необходимости покупки лицензии. MRP не развивается более 10 лет, поэтому, думаю, его можно считать Abandonware. Компилятор находится в compiler/mrpbuilder.NET1.exe. За китайские SDK в публичном доступе нужно поблагодарить пользователя 4pda AjlekcaHgp MejlbHukoB, который раздобыл их на всяких csdn и выложил в свободный доступ :)
У MRP собственная система сборки, основанная на конфигурациях. Поскольку MRP может работать на устройствах с разными платформами и размерами дисплеев, под каждую можно настроить свой конфиг, который пережмет ресурсы в нужный формат. Дабы ничего не ломать, я заюзал абсолютные пути:
Компиляция приложения:
mrpbuilder.net1.exe game.mpr
Начинаем с функций обработки событий и инициализации, которые вызывает рантайм при старте приложения: mrc_init вызывается при старте приложения, а mrc_event при возникновении события. Вся инициализация очень простая: создаём таймер для обновления и перерисовки состояния игры и вызываем инициализацию игры:
С вводом тоже никаких проблем нет, нажатия кнопок прилетают как события в mrc_event. Переводим кейкоды MRE в наши кейкоды и сохраняем их состояние:
Опять же, отлаживать MRP-приложение под реальным устройством проблематично, поэтому платформозависимый код должен быть минимальным. Кроме того, обратите внимание, что некоторые функции в MRP зависят от библиотек-плагинов. Линкер слинкует вашу программу, но на реальном устройстве их вызов вывалится в SIGSEGV и софтресет устройства. Также нельзя использовать ничего из стандартной библиотеки именно в стандартных заголовочниках (т. е. stdlib.h, string.h и т. д.), часть стандартной библиотеки реализовывается MRP и дефайнится в mrc_base.h
Что интересно, защиты памяти толком нет. Если приложение падает в SIGSEGV или портит память — систему, судя по всему, ребутит Watchdog. Защиты памяти никакой, можно напрямую читать и писать в память ядра, а также писать в регистры периферии чипсета. jpegqs, покумекаем над этим? :)
Переходим к рендереру. Тут буквально две функции, gClearScreen очищает экран, а gDrawBitmap рисует произвольный спрайт с форматом пикселя RGB565. В качестве ROP используется BM_TRANSPARENT — таким образом, mrc_bitmapShowEx будет использовать левый верхний пиксель в качестве референсного цвета для реализации прозрачности без альфа-блендинга.
voidgDrawBitmap(CBitmap* bmp, int x, int y) {
mrc_bitmapShowEx((uint16*)bmp->pixels, x, y, bmp->width, bmp->width, bmp->height, BM_TRANSPARENT, 0, 0);
}
Да, всё вот так просто. Рантайм теперь запускается на реальных китайских девайсах и работает стабильно.
❯ VXP
Теперь переходим к VXP — платформе не менее неоднозначной, чем MRP. Пожалуй, начать стоит с того, что VXP существует аж в трёх версиях: MRE 1.0, MRE 2.0 и MRE 3.0. В MRE 2.0 и выше появилась поддержка плюсов (в MRE 1.0 только Plain C) и довольно интересного GUI-фреймворка, MRE 1.0 же предлагает реализовывать гуй самому. Платформа распространена на большинстве кнопочных телефонов и смарт-часиков на чипсетах MediaTek, примерно начиная с 6235 и заканчивания 6261D. SDK можно скачать вот здесь (см MRE_SDK_3.0).
VXP сам по себе более функционален чем MRE, поскольку ориентирован исключительно на телефоны с чипсетами MediaTek. Но что самое приятное — есть доступ к уарту без каких либо костылей! То есть, если сделать GPIO-мост на условной ESP32, то мы можем получить готовый мощный МК с клавиатурой, кнопками, дисплеем, звуком и т. д. Звучит не хило, да? Кроме того, у нас есть доступ и к BT, и к GPRS, и к SMS без каких либо ограничений.
Однако в бочке мёда нашлась и ложка дёгтя: для компиляции MRE-приложений необходимо накатывать и крякать довольно старый компилятор ADS, который сам по себе поддерживает только C89 (например, нет возможности объявить переменную в объявлении цикла или середине функции, только в начале, как в Pascal). ADS уже вроде как Abandonware, так что это вроде не наказуемо… но всё равно неприятно.
Кроме того, на некоторых девайсах (в основном, фирменных Nokia а-ля 225), прошивка требует подписи у всех бинарников, либо если бинарник отладочный, то должна быть привязка к конкретному IMSI.
К тому же, каждая программа должна фиксированно указывать в заголовке, сколько Heap-памяти ей необходимо выделить. Оптимальный вариант — ~500Кб, тогда приложение запустится вообще на всех MRE-телефонах.
Зато у VXP есть адекватный симулятор под Windows. Но зачем он нам, если у нас порт игры под Win32 есть? :)
Начинаем с инициализации приложения. В процессе вызова точки входа, приложение должно назначить обработчики системных событий, коих бывает несколько. Для обработки ввода и базовых событий хватает всего три: sysevt (события окна), keyboard (физическая клавиатура. Есть полная поддержка QWERTY-клавиатур), pen (тачскрин).
Переходим к обработчику системных событий. Обратите внимание, что MRE-приложения могут работать в фоне, из-за чего необходимо ответственно подходить к созданию и освобождению объектов. Что важно усвоить с самого начала — в MRE нет понятия процессов и защиты памяти, как на ПК и полноценных смартфонах. Любая программа может попортить память или стек ОС, более того, программа использует аллокатор остальной системы, поэтому если ваша программа не «убирает» после себя, данные останутся в памяти со временем приведут к зависанию. Впрочем, WatchDog делает свою работу быстро и приводит телефон в чувство (софтресетом) за 1-2 секунды. Но как и в случае с MRE, есть приятный бонус: прямой доступ к регистрам чипсета :)
Переходим к обработке событий с кнопок. Тут всё абсолютно также, как и на MRE, лишь имена дейфанов поменялись :)
И наконец-то, к графике! Пожалуй, стоит сразу отметить, что более 20-30 FPS на большинстве устройств вы не получите даже с прямым доступом к фреймбуферу. Похоже, это связано с тем, что в MRE довольно замороченная графическая подсистема с поддержкой альфа-канала (только фиксированного во время вызова функции отрисовки картинки/примитивов, сам пиксельформат всегда RGB565) и нескольких слоев. Кроме того, похоже есть ограничения со стороны контроллера дисплея.
Изначально, MRE предполагает то, что все картинки в программе хранятся в формате… GIF. Да, весьма необычный выбор. Однако для работы с пользовательской графикой, есть возможность блиттить произвольные картинки напрямую из RAM. Вот только один нюанс — посмотрите внимательно не объявление следующей функции:
dst_disp_buf — это целевой RGB565-буфер. Логично предположить, что и src_disp_buf — тоже обычный RGB565-буфер! Но как бы не так. Документация крайне скудная, пришлось посидеть и покумекать, откуда в обычном 565 буфере возьмется индекс кадра. С подсказкой пришёл пользователь 4pda Ximik_Boda — он скинул структуру-заголовок, которая идёт перед началом каждого кадра. В документации об этом не сказано ровным счетом ничего!
Сначала я реализовал софтовый блиттинг, но он безбожно лагал. Мне стало интересно, почему нативный blt быстрее и… вопросы отпали после того, как я поглядел в ДШ чипсета: тут есть аппаратный блиттинг. И даже с ним девайс не может выдать более 20FPS!
Для реализации более-менее шустрого вывода графики, необходимо сначала создать канвас (фактически, Bitmap в MRE), создать и привязать к нему layer, получить указатель на буфер слоя и только потом скопировать туда нашу картинку. Да, вот так вот замороченно:
И только после этого всё заработало достаточно шустро :) В остальном же платформа довольно неплохая. Да, без болячек не обошлось, но всё же перспективы вполне себе есть.
На данный момент, этого достаточно для нашей игры.
❯ Пишем геймплей
Рантайм у нас есть, а значит, можно начинать писать игрушку. Хоть пишем мы на Plain-C, я всё равно из проекта в проект использую +- одну и ту же архитектуру относительно системы сущностей, стейтов и т. п. Поэтому центральным объектом у нас станет CWorld, который хранит в себе на пулы с указателями на другие объектами в сцене, а также игрока и его состояние:
Система стейтов простая и понятная — фактически, между состояниями передавать ничего не нужно. При нажатии в главном меню на «старт», нам просто необходимо проинициализировать мир заново и начать геймплей, при смерти игрока — закинуть его обратно в состояние меню. Стейты представляют из себя три указателя на функции: переход (инициализация), обновление и отрисовка.
typedefvoid(CGameStateCallback)();
Поскольку мы хотим некоторой гибкости при создании новых классов противников, то вводим структуру CEnemyClass, которая описывает визуальную составляющую врагов и их флаги — могут ли они стрелять по игроку или просто летят вниз (астероиды), как они передвигаются (зигзагами например) и т. п.
Всё! Для текущего уровня реализации игры этого достаточно :) Переходим к реализации игровой логики. Вообще, динамический аллокатор в играх для китайских платформ лучше использовать как можно меньше. Heap'а довольно мало (~600Кб), да и не совсем понятно, как этот аллокатор реализован, есть вероятность, что используется аллокатор и куча основной ОС.
Начинаем с реализации полёта кораблика. Для этого он должен реагировать на стрелки и не улетать за границы экрана, а ещё для красоты он должен «вылетать» из нижней границы экрана при старте игры:
Переходим к динамическим пулам с объектами. Как вы уже заметили, их всего два — враги и летящие снаряды. Реализация спавна врагов/снарядов простая и понятная: мы обходим каждый элемент пула, если указатель на объект не-нулевой, значит объект всё ещё жив и используется на сцене. Если нулевой — значит ячейка свободна и можно заспавнить новый объект:
При обходе пула во время обновления кадра, мы обновляем состояние каждого объекта и если его функция Think вернула true, значит объект больше не нужен и его нужно удалить:
if (enemyThink(world.enemyPool[i]))
{
sysFree(world.enemyPool[i]);
world.enemyPool[i] = 0;
}
А вот и реализация Think:
boolenemyThink(CEnemy* enemy) {
enemy->y += enemy->_class->speed;
if (enemy->y > gGetScreenHeight() || enemy->health <= 0) return true;
return false;
}
Но кораблики должны же откуда-то появляться! Для этого у нас есть переменная nextSpawn, которая позволяет реализовать самый простой тип спавнера — относительно времени (или в нашем случае тиков):
world.nextSpawn--;
if (world.nextSpawn < 0) {
CEnemy* enemy = spawnEnemy(&enemyClasses[0]);
world.nextSpawn = randRange(40, 70);
}
Результат: мы уже можем полетать, пострелять и поуворачиваться от вражеских корабликов!
Уже что-то напоминающее игру! Осталось лишь добавить подсчет очков, менюшку, разные виды противников, возможно какие-то бонусы и у нас будет готовая простенькая аркада. В целом, выше приведена достаточно неплохая архитектура для простых 2D-игр на Plain C. Фактически, она может быть хорошей базой и для ваших игр: в теме о китах на 4pda я встречал немало людей, которые банально не знали, с чего начать.
❯ Что у нас получилось?
Но без тестов на реальных устройствах материал не был бы таким интересным! Поэтому давайте протестируем игру на двух реальных телефонах, как вы уже догадались, один — Nokla TV E71, а второй — клон Nokia 6700, который подарил мне мой читатель Никита.
На TV E71 игра идёт не сказать что очень бодро. Кадров 15 точно есть, что, учитывая разрешение 240x320, весьма неплохо для такого девайса.
а 6700,, даже учитывая более низкое разрешение — 176x220, дела примерно также — ~15FPS! Но поиграть всё равно можно. Уже хотите написать «автор наговнокодил, а теперь ноет из-за низкого FPS»? Ан-нет, я попробовал игры сторонних разработчиков — они идут примерно также :( К сожалению, таковы аппаратные ограничения устройства.
Исходный код игры с Makefile'ами и файлами проектов для Visual Studio и MRELauncher доступны на моём GitHub. Свободно изучайте и используйте его в любых целях :)
❯ Заключение
Но в остальном же, демка получилась довольно прикольной, как и сам опыт программирования для китайских телефонов. В общем и целом, китайцы пытались максимально упростить API и привлечь разработчиков к своей платформе. Если ради примера взглянуть на API для Elf'ов на Motorola, можно ужаснуться от state-based архитектуры платформы P2K. А тут тебе init, event, draw — и всё!
Но популярности помешала непонятная закрытость платформы, костыльный запуск программ, отсутствие нормального симулятора. А ведь сколько фишек было: даже возможность писать и читать память ядра! А вы как считаете? Можно ли вдохнуть в китайские кнопочники новую жизнь, узнав о наличии возможности запуска нативного кода на них?
P. S.: Друзья! Время от времени я пишу пост о поиске различных китайских девайсов (подделок, реплик, закосов на айфоны, самсунги, сони, HTC и т. п.) для будущих статей. Однако очень часто читатели пишут «где ж ты был месяц назад, мешок таких выбросил!», поэтому я решил в заключение каждой статьи вставлять объявление о поиске девайсов для контента. Есть желание что-то выкинуть или отправить в чермет? Даже нерабочую «невключайку» или полурабочую? А может, у этих девайсов есть шанс на более интересное существование! Смотрите в соответствующем посте, что я делаю с китайскими подделками на айфоны, самсунги, макбуки и айпады! Да и чего уж там говорить: эта статья уже сама по себе весьма наглядный пример! Найти меня можно в комментариях тут, на Пикабу, и в тг @monobogdan
Понравился материал? У меня есть канал в Телеге, куда я публикую бэкстейдж со статей, всякие мысли и советы касательно ремонта и программирования под различные девайсы, а также вовремя публикую ссылки на свои новые статьи. 1-2 поста в день, никакого мусора!
Полезный материал?
Были ли у вас такие китайчики?
Материал подготовлен при поддержке TimeWeb Cloud. Подписывайтесь на меня и @Timeweb.Cloud, дабы не пропускать новые статьи каждую неделю!
Давным-давно приобрёл себе такие проводные наушники, всем меня устраивали, но наслаждался эксплуатацией я недолго - спустя полгода в спортзале одним ловким движением оторвал разъём начисто 🙈 погоревал недолго и убрал наушники в ящик где они пролежали без малого три года. И как-то в ходе ревизии всей своей электроники решил я их отремонтировать - отнёс в мастерскую в Питере где мне припаяли новый разъём. Визуально получилось не очень, конечно, но как говорится - на "скорость" не влияло. И пользовался я ими до недавнего времени, но практически одновременно случились два события - в одном из наушников стал пропадать звук по причине того, что провод где-то перетёрся в районе разъёма (если провод пошевелить, то звук снова появляется), второе событие - приобрёл я себе новый смартфон без выхода mini-jack. В связи с чем появилась задумка - модернизировать данные наушники путем замены разъёма jack 3.5 на USB type C. Можно, конечно, отремонтировать имеющийся разъём и прикупить переходник как на фото, но как мне видится - получится более громоздкая и менее надёжная конструкция. В связи с чем вопрос - подскажите где можно найти распиновку для наушников Beats Tour и для переходника с USB type C на mini-jack. Хочу попробовать заморочиться.
P.S. беспроводные наушники не предлагать - во-первых они уже есть, во-вторых хочу себе сделать наушники про запас - в таком состоянии их или продать за бесценок или выбросить. Всем заранее спасибо.
К огромному сожалению, старые смартфоны всё чаще и чаще находят своё пристанище в мусорном баке. К прошлым, надежным «друзьям» действует исключительно потребительское отношение — чуть устарел и сразу выкинули, словно это ненужный мусор. И ведь люди даже не хотят попытаться придумать какое-либо применение гаджетам прошлых лет! Отчасти, это вина корпораций — Google намеренно тормозит и добивает довольно шустрые девайсы. Отчасти — вина программистов, которые преследуют исключительно бизнес-задачи и не думают об оптимизации приложений совсем. В один день я почувствовал себя Тайлером Дёрденом от мира IT и решил бросить вызов проприетарщине: написать свою прошивку для уже существующего смартфона с нуля. А дабы задачка была ещё интереснее, я выбрал очень распространенную и дешевую модель из 2012 года — Fly IQ245 (цена на барахолках — 200-300 рублей). Кроме того, у этого телефона есть сразу несколько внешних шин, к которым можно подключить компьютер или микроконтроллер, что даёт возможность использовать его в качестве ультрадешевого одноплатника для DIY-проектов. Получилось ли у меня реализовать свои хотелки? Читайте в статье!
Мотивация
Честно сказать, идея попытаться реализовать свою прошивку мне пришла ещё давно. Однако, дабы не завлекать опытного читателя кликбейтом, я сразу поясню, в чём заключается «прошивка с нуля»:
Мы всё ещё используем Linux: в качестве ядра мы продолжаем использовать образ Linux, предоставленный нам производителем. Написание прошивки полностью с нуля заняло бы очень много времени (особенно без схемы на устройство). Однако, мы вообще не загружаем Android никаким образом.
Мы не используем библиотеки AOSP: наша прошивка без необходимости не использует никаких библиотек уже имеющегося образа Android. Вся работа с железом происходит с помощью низкоуровневого API Linux. Это значит, что отрисовка графики, звук, управление ресурсами и питанием ложится полностью на нас.
Прошивка может запускать только нативные программы: да, это тоже камень в сторону Android. Изначально, наша прошивка умеет запускать только нативные программы, написанные на C. Причём она экспортирует собственное C API — дабы приложения могли использовать всю мощь нашего смартфона в виде простого и понятного набора методов.
Проектов по выкидыванию Android из, собственно, Android-смартфонов как минимум несколько: UBPorts — бывший Ubuntu Touch, FireFox OS и его наследник Kai OS и конечно же, postmarketOS. Отчасти можно сюда отнести и Sailfish OS — но там образы имеются в основном на смартфоны от Sony. Все эти проекты объединяет сложность портирования и невозможность их завести на устройствах без исходного кода ядра. Даже если у вас есть исходный код ядра, но, например, устройство использует ядро 2.6 — навряд-ли вы сможете завести современный дистрибутив на нём.
Другой вопрос в том, что можно использовать полу-baremetal подход, когда от Linux берется практически минимальный функционал. Всё, что мы имеем — busybox, libc и низкоуровневый доступ к железу, благодаря API самого ядра. Как под это всё программировать — я рассказывал впрошлойстатье. Этот же подход мы будем использовать и сейчас — как иллюстрация реального применения подобного способа.
Итак, что наша прошивка должна уметь:
Отрисовывать произвольную графику: графическая подсистема нашей прошивки должна работать с фиксированным форматом пикселя, уметь загружать прозрачные и непрозрачные изображения, отрисовывать картинки с альфа-блендингом и т. п.
Уметь звонить и работать с модемом: общение с модемом происходит посредством AT-команд — общепринятого в индустрии стандарта. Однако в случае нашего устройства, есть м-а-а-а-ленький нюанс, о котором я расскажу позже.
Иметь механизм приложений: мы ведь не будем хардкодить все «экраны» в прошивке в виде кучи стейтов, верно? Для этого у нас должен быть простой и понятный механизм слинкованных с прошивкой приложений.
Обрабатывать ввод: обработка тачскрина и жестов — это задача подсистемы ввода.
Реализовывать анимированный UI: здесь всё очевидно, наша прошивка должна иметь готовые элементы пользовательского интерфейса для будущих приложений: кнопки, текстовые поля и т. д. О деталях реализации этой подсистемы, я расскажу ниже (а реализовал я её очень необычно для такой системы).
Начинаем мы с хардварной части. Именно здесь я покажу вам, как использовать внешние шины вашего устройства.
Аппаратная часть
В качестве смартфона для нашего проекта, я выбрал популярную бюджетную модель из 2012 года — Fly IQ245 Wizard. Это простенький китайский смартфон, который работал на базе популярного в прошлом 2G-чипсета: MediaTek MT6573, да и стоил около 2х тысяч рублей новым. Однако вот в чём суть: мне удалось заставить работать «медиатековский» модем и даже позвонить с него на свой основной телефон, но… только ввод и вывод данных из звукового тракта модема происходит через звуковую подсистему Android — к которой доступа у нас нет!
Именно поэтому, мы идём на очень хитрый и занимательный костыль: мы распаяем внешний модем сами! В качестве радиомодуля у нас выступит модуль SIM800 от компании SIMCOM. И даже он очень близок к нашему смартфону в аппаратном плане: ведь в основе этого модуля лежит популярнейший чипсет из кнопочников тех лет: MediaTek MT6261D. Преимущество SIM800 в его цене — он стоит пару сотен рублей, так что по карману выбор модема не влияет.
На весу паять крайне неудобно. В финальном варианте перепаяю нормально.
Но как его подключать? SIM800 общается с другими устройствами посредством протокола UART — универсальный асинхронный приемо-передатчик. И вот тут мы включаем смекалочку. Разбираем устройство и видим то, что я пытаюсь долгое время донести до моих читателей — аж два канала UART: один практически посередине, второй справа. Нам нужны пятачки TXD4 и RXD4:
Обычно на этот канал UART летят логи ядра, которые можно без проблем отключить минорной правкой U-Boot в HEX-редакторе. Впрочем, модем никак не реагирует на «мусор» из консоли и просто отвечает ошибками — хватит лишь очистить буфер сообщений для того, чтобы все работало нормально. Подпаиваемся к UART'у с помощью преобразователя — у меня оным выступает ESP32 с выпаянным чипом.
Увидели логи? Замечательно, пора попытаться что-то отправить на ПК и с ПК. UART работают без тактовых сигналов и зависит исключительно от старт/стоп битов и бодрейта, который на устройствах MediaTek равен 921600. TXD4 и RXD4 обнаруживаются в системе на консоли/dev/ttyMT3. Пробуем что-то отправить: всё работает!
Вот теперь-то можно подключить наш внешний модем и попытаться пообщаться с ним, отправив тестовую командуAT. Модем отвечаетOK! На этот раз я работаю с смартфоном из режимаFactory mode— практически тоже самое, что и режим recovery, но позволяющий, например, получить доступ к камере устройства. Простая и понятная схема, поясняющая что и куда подключать:
На этом модификация аппаратной частипоказакончена. Пора переходить к реализации софта! Я решил разделить материал на каждый модуль, который я реализовывал — дабы вам был понятен процесс разработки и отладки прошивки!
Заставляем смартфон запускать нашу прошивку
На этот раз я решил загружать смартфон из режима рекавери. Однако никто не мешает в будущем просто прошить раздел recovery вместо boot и получить прямую загрузку прямо в нашу прошивку. Время такой загрузки будет заниматься ~3-4 секунды с холодного старта. Очень даже ничего.
Я взял уже готовый образ TWRP для своего смартфона и пропатчил его, дабы сам рекавери не мешал своим интерфейсом. Для этого я распаковал образ recovery.img с помощью MtkImgTools и убрал в init.rc запуск службы /sbin/recovery. После этого, я залил прошивку обратно на устройство и получил подобную свободу действий — консоль через USB и чистый холст в виде смартфона! Старые смартфоны на чипсетах MediaTek шьются через USB только после замыкания тест-поинта — на моем аппарате его местонахождение очевидно. Замыкаем контакты между собой, подключаем смартфон без АКБ к ПК и ждем прошивки:
Теперь можно деплоить программы! Важный нюанс: в отличии от Makefile из прошлой статьи, для Android 2.3 параметр -fPIE нужно убрать — иначе динамический линкер (/sbin/linker) будет вылетать в segmentation fault.
❯ Графическая подсистема
В комментариях под прошлой статьёй меня похвалили за то, что я делюсь достаточно профильными знаниями касательно эффективной отрисовки 2D-графики. Собственно, к реализации графической подсистемы я подошёл ответственно и постарался реализовать достаточно шустрый рендерер, к которому затем можно подключить другие модули.
Как я уже говорил ранее, графическая подсистема должна уметь загружать картинки, выводить некоторые примитивы, выводить картинки с прозрачностью и без, загружать и отрисовывать заранее подготовленные шрифты, а также управлять отрисовкой бэкбуфера на экран.
В случае с этим устройством (и большинством старых устройств), формат пикселя оказался RGB565 — т. е. 5 бит красный, 6 бит синий, 5 бит зеленый. Конвертация форматов пикселей всегда была занозой в заднице для программных рендереров, поскольку занимает дополнительное время, которое обратно зависимо от размера дисплея. Изначально я решил выделить буфер в том же формате, что и фреймбуфер, но затем решил сделать классический и самый портативный формат — RGB888 (24х-битный цвет), а при копировании кадра на экран, на лету делать преобразования цвета:
Очень важный нюанс, который я не упомянул в предыдущей статье: на устройствах прошлых лет для обновления фреймбуфера необходимо послать структуру var_screeninfo, где хотя бы что-то изменено, иначе никаких изменений мы не увидим. Этот же костыль используется в родном recovery для отрисовки, а судя по исходникам драйвера fb, «правильный» способ обновить экран — послать драйверу ioctl (который я пока что не пробовал).
После того, как я смог управлять дисплеем, я решил загрузить и отобразить какую-нибудь картинку. Пусть это будут обои для нашей прошивки:
Загрузчик TGA сильно не поменялся: я таскаю его в неизменном виде из проекта в проект. Он поддерживает любые форматы пикселя, кроме палитровых, но я его искусственн ограничиваю на RGB888 и RGBA8888 — для поддержки обычных картинок и картинок с альфа-каналом. После этого, я написал не очень шустрые, но достаточно универсальные методы для отрисовки картинок. Для больших участков кода, я буду использовать pastebin, поскольку на Пикабу до сих пор не добавили ни подсветки синтаксиса, не нормальный перенос форматирования табов :(
PutPixel желательно заинлайнить в будущем. В целом, сама отрисовка работает достаточно быстро, но поскольку рендеринг выполняется на ЦПУ — рано или поздно мы упремся в количество картинок на экране. Есть некоторые оптимизации: например, непрозрачные картинки можно просто коприовать сканлайнами прямо в задний буфер.
Сразу же реализовываем методы для рисования шрифтов: они у нас будут совсем простенькими — только моноширинные (все символы имеют одинаковую ширину) и растровыми (для каждого размера придется «запекать» несколько шрифтов). Для этого я написал маленькую программку, которая рисует виндовые шрифты прямо в наш самопальный формат:
Формат примитивнейший:
1 байт говорит нам о размере шрифта и далее идут 255 изображений символов. Да, это не очень эффективно т.к попадают пустые символы из ASCII-таблицы, но в будущем это можно поправить.
Прозрачность в символах обеспечивает фоновый цвет Magena — ярко-розовый. Я не стал делать дополнительный альфа-канал, т. к. иначе будут серьезные лаги при выводе большого количества текста.
Теперь у нас есть отображение картинок и текста! Что с этим можно сделать?
❯ Обработка ввода
Пока что здесь не хватает обработки «хардварных» кнопок — домой, меню, назад и т. п. Однако в будущем это всё можно реализовать!
❯ Анимация
Не забыл я и про анимации. Ну кому с такими ресурсами нужен неанимированный топорный интерфейс? Пусть лучше будет анимированный, пусть и примитивный!
Аниматор напоминает оный из ранних версий Android: он имеет фиксированный набор свойств, которые умеет интерполировать в промежутках определенного времени. Если простыми словами: то он оперирует линейными отрезками времени a и b, в промежутке которых мы имеем значение «прогресса» — которое даёт нам результат от 0.0f (начало анимации) до 1.0f (конец анимации). Пока время тикает до необходимого интервала (duration), аниматор интерполирует заранее назначенные ему поля до нужных значений.
Именно так и получается плавность! Похожим образом реализованы анимационные системы во многих играх и мобильных ОС, только там они гораздо более комплексны: есть сериализация/десериализация из файлов, поддержка кейфреймов (несколько последовательных состояний на одном промежутке времени), поддержка кастомных свойств и т. п.
❯ Модем
Как я уже говорил раннее, работа с модемом происходит посредством AT-команд. Лучше всего обрабатывать ввод-вывод модема из отдельного потока, поскольку он может отвечать довольно медленно и тормозить UI-поток основной программы, вызывая лаги. В SIM800 уже реализован весь GSM-стек, в том числе декодирование и вывод звука через встроенный усилитель с фильтром — остается только подключить динамики и микрофон от нашего телефона. Пока что я подсобрал аудиотракт на том, что было под рукой — микрофон от нерабочего смартфона и динамик от планшета, но для проверки этого хватает:
Важный нюанс: по умолчанию, tty-устройства в Linux работают по терминальному принципу — т. е. дробят транзакции по символу окончания строки (\n), имеют ограниченный буфер и т. д. Для нормальной работы в условиях модема — когда фактически длина ответа неизвестна, а в сам ответ могут «вклиниваться» Unsolicited-команды (своеобразные флаги о состоянии от модема, которые могут прийти в произвольное время — т. е. при входящем звонке, модем начнёт флудить RING в терминал), необходимо иметь возможность точно прочитать весь буфер до конца и парсить данные «по месту». Для этого используется raw-режим терминала:
Пытаемся позвонить с помощью метода Dial и видим, что всё работает! Это очень круто! А теперь, конечно же, самое время переходить к реализации того, чего вы ждали — пользовательского интерфейса!
❯ Главный экран
К выбору концепции для интерфейса, я поступил максимально просто — «слизал» дизайн первых версий iOS. Как по мне, это одни из самых красивых версий iOS вообще — все эти приятные градиенты и переливания. Конечно, я не так крут, как инженеры Apple, да и мощного UI-фреймворка у меня пока что нет, поэтому я приступил к реализации с «минимальным» функционалом.
Начал я с разделения главного экрана на модули и продумывания архитектуры основного «лаунчера». У нас есть статусбар, который рисуется поверх всех приложений, полка с приложениями — AppDrawer и сами экраны приложений, унаследованные от суперкласса CScreen.
На данный момент, отрисовка достаточно примитивная: сначала рисуются фоновые обои, затем, если нет никаких активных экранов — AppDrawer и в самом конце рисуется статусбар и всевозможные оверлеи.
Выглядит симпатичненько. Если я смогу поднять хардварный GLES, то это получится сделать в разы плавнее и шустрее — не хуже айфонов тех лет! Реализация самого статусбара примитивненькая, но вполне рабочая:
Кроме этого, я сразу же реализовал предварительный механизм приложений в системе — пока что они слинкованы статически с основным лаунчером. Для этого есть структура CAppDesc, которая содержит минимально-необходимую информацию для показа информации о приложении и фабрику для создания его основного экрана.
Обратите внимание на удобство примененного подхода Immediate GUI. Нам понадобился новый элемент интерфейса, который описывает кнопку номеронабирателя? Мы просто реализовываем ещё один метод, который берет за основу стандартную кнопку и дорисовывает к ней текст. Всё крайне просто и понятно, хотя на данный момент слишком захардкожено. :)
❯ Звоним!
Пришло время совершить первый звонок с нашей по настоящему кастомной прошивки. Набираем номерок и…
Да, всё работает и мы без проблем можем дозвониться :)
❯ Заключение
Конечно же, это далеко не весь функционал, необходимый любому современному смартфону. Здесь много чего еще нужно реализовать хотя бы для соответствия уровню бюджетных кнопочных телефонов: телефонную книгу, поддержку СМС/ММС, мультимедийный функционал с играми. Однако начало уже положено и самая необходимая часть модулей реализована. Этот проект очень занимательный для меня и я горд, что смог не на словах, а на деле показать вам, моим читателям, возможности моддинга совершенно NoName-устройств, без каких либо опознавательных знаков…
Моя задача заключается в том, чтобы показать вам возможности использования старых телефонов не только в потребительских, но и в гиковских DIY-сферах. Судите сами: огромный классный дисплей, емкостной тачскрин, готовый звук, камера — и всё это за каких-то пару сотен рублей. Главное показать людям, как всю эту мощь использовать в своих целях и делать совершенно новые устройства из существующих, а не выбрасывать их на помойку! Сейчас смартфоны, подобные Fly из этого поста стоят копейки, а портировать на них прошивку можно без каких-либо трудностей. Я очень надеюсь, что после этого поста читатели попытаются сделать что-то своё из старых смартфонов, благо свои наработки я выкладываю на GitHub!
В прошлой статье, мы с вами рассмотрели на что способен одноплатный компьютер, который стоит всего 1.000 рублей. Как мы выяснили, перспективы у данного девайса весьма неплохие, однако по факту, Orange Pi продаёт практически голую железку, которую нужно дорабатывать самому. Да, тут есть Ubuntu/Fedora, да, тут выведена гребенка с I2C/SPI — однако из коробки это всё работает криво-косо, либо не работает совсем. Даже обещанные шины SPI/I2C фактически не доступны в системе «из коробки». Материалов о доработке этого одноплатника в сети мало, поэтому я решил довести его до ума сам и поделится с вами — в том числе, готовыми бинарными образами! Интересно, на что способен доработанный одноплатник по цене ящика пива? :)
Над чем будем работать
В прошлой статье, мы с вами определились с потенциальными перспективами такого устройства. По цене 3х ESP32, производитель предлагает нам два полноценных вычислительных ARM-ядра, 256 мегабайт оперативной памяти, 512 мегабайт встроенной NAND-памяти, контроллер питания с возможностью работы от литий-ионных АКБ и 3G модем. Но в бочке меда нашлась ложка дегтя: никто не собирался это всё поддерживать и Orange Pi практически сразу «забили» на поддержку устройства, ограничившись портом Debian/Ubuntun на устройство.
Более того, производитель даже не описал как работать с GPIO и шинами устройства — что фактически превращало его из одноплатника в обычную ТВ-приставку, только без нормального видеовыхода. Меня крайне удивило, почему над такой дешевой платой не хотело работать коммьюнити — большинство людей только видели всю ситуацию и шли оставлять негативный отзыв, не попытавшись даже разобраться. А ведь для опытного линуксоида-эмбеддера здесь работы на день-два!
Ко всему прочему, в Linux не работает GSM-стек. Да, совсем. Производитель даже не стал кооперироваться с MediaTek, чтобы попытаться реализовать работу с модемом на уровне системы. А ведь фактически, вся работа с модемом происходит лишь на уровне AT-команд. Так в чем же проблема была?
Со всем этим мне и предстоит разобраться! Клонируем репозиторий с исходниками ядра и бежим собирать!
Собираем ядро. I2C и SPI.
Вместо типичного Buildroot, Orange Pi использует свою собственную простую систему сборки на shell-скриптах: в качестве тулчейна используется уже готовый linaro. Отчасти, это связано с самими чипами, на которых работают их устройства — MediaTek, например, не использует Mainline ядро и в процессе сборке имеет ещё кучу шагов для подготовки финального образа. Там даже menuconfig не работает и все изменения приходится делать в уже сгенерированной когда-то конфигурации.
Клонируем репозиторий с системой сборки и запускаем скрипт:
Выбираем нашу плату — 3G IoT и ждем, пока система сборки фактически скачает все необходимое для сборки — исходный код ядра, папки external (драйвера, загрузчик и порт linux MediaTek). Обратите внимание, OrangePi даже систему сборки завязали на конкретной версии системы: только Ubuntu 18.04, но на самом деле, ядро соберется без проблем практически где угодно. После того, как все было скачано, переходим в папку с скриптом сборки и запускаем скрипт сборки:
А нет, не запускаем — скрипт жалуется на то, что не может поставить некоторые пакеты. Не беда — ставим bsdtar и python minimal вручную и идем править код скрипта. Находится в он scripts/general.sh: убираем оттуда устаревшие имена пакетов.
После этого, компиляция ядра должна пройти успешно. Обратите внимание на версию вашей платы — те, что продают сейчас — именно A. Если пытаться подкинуть им ядро для B, то они будут уходить в kernel panic из-за отсутствия eMMC.
Если mkbootimg будет жаловаться на libstdc++6, то ставим его x86 версию из репозиториев.
Готовое ядро будет лежать вoutput/kernel/boot.img, которое можно прошить на устройство. С одним маленьким нюансом — оно рассчитано на загрузку из внутренней памяти, которой критически мало для дистрибутива Linux! У нас нет boot_sd.img, который есть в оригинальном дистрибутиве. Попытка разобрать образ стандартным AndImgTool не увенчалась успехом — рамдиск встроен прямо в образ zImage, а не отдельно, как это обычно бывает у Android-образов.
Покопавшись в скриптах сборки, я так и не понял логику создания boot_sd, ничего связанного с sd я не нашел даже grep'ом по всей папке. Ну что-ж, тогда попробуем обходным путем: скомпилируем нужные драйвера в виде загружаемых модулей (ko). Идём в наш конфиг, расположенный в linux/arch/arm/configs/3giot_defconfig и меняем CONFIG_I2C_CHARDEV и CONFIG_SPI_SPIDEV на m. Пояснение: y заставит систему сборки скомпоновать драйвер статически с ядром, а m выделит его в виде отдельного модуля ko, который затем можно загрузить черезinsmod.
Снова собираем ядро, на этот раз компиляция занимает не больше минуты. Нужные нам файлы появятся в linux/drivers/spi/spidev.ko и linux/drivers/i2c/i2c-d-ev.ko. Переносим их на хост-пк, а затем и на само устройство с помощью SSH:
Загружаем модули ядра:
insmod i2c-dev.ko
И та-дам! Целых две i2c шины появилось в системе (/dev/i2c-0, /dev/i2c-1). Устанавливаем i2c-tools и идем проверять с помощью i2cdetect: первая шина полностью свободна под наши проекты, а на второй по некоторым адресам висит периферия (FM-радио как вариант):
I2C теперь точно работает! Но как насчет SPI?
insmod spidev.ko Device or resource busy.
Увы! spidev нельзя подгружать динамически, только статически линковать с ядром, чего мы сделать пока не можем. Однако техническая возможность заставить работать SPI есть: например, написать свой драйвер, который транслирует команды из юзерспейса в SPI API, которое работает на уровне ядра.
GPIO
В прошлой статье, я вкратце рассказал, как работать с gpio из user-space на уровне терминала. Однако, большинство разработчиков потенциально будет пользоваться нативным API для GPIO — ну не всерьез же им парсить вывод состояния в консоль? Поэтому я решил написать крошечную библиотеку для работы с GPIO, такую же простую, как и DigitalWrite/DigitalRead!
Давайте сначала разберемся, как именно работать с драйвером GPIO. Для этого открываем исходники ядра и смотрим внимательно, что нам предлагает драйвер: в нашем случае, это вызовы IOCTL, да еще и простые и понятные. Это просто отлично! Я написал single-header библиотеку минут за 10: без проверки ошибок, но работоспособная.
Пример использования (141 — крайний пин на гребенке):
#define GPIO_IMPL
#include "gpio.h"
#include <stdio.h>
voidtestPin(int pin)
{
printf("Pin state %i is %i\n", pin, gpioGetState(pin));
gpioSetDir(pin, 1);
gpioWrite(pin, 0);
printf("Pin state %i is %i\n", pin, gpioGetState(pin));
gpioWrite(pin, 1);
printf("Pin state %i is %i\n", pin, gpioGetState(pin));
}
intmain(int argc, char** argv) {
gpioInit();
testPin(141);
}
Модем
Скажу сразу: пока что завести модем мне не удалось, но я активно работаю над этим. В этой части статьи я распишу свои находки и догадки касательно модемов на чипах MediaTek.
В устройствах MediaTek, драйвер для общения с GPS, A-GPS и модемом один — ccci, судя по всему cross chip communication interface. Именно ccci создает устройства, с в которые поступает вход с микрофона и выход на динамики, а также он создает управляющие интерфейсы для общения с различными модулями этого SoC.
При старте ядра, ccci создаёт много устройств — ccci_ioctl, ccci_ipc, ccci_fs и самое нужное нам —ttyC0/ttyC1/ttyC2— в зависимости от количества СИМ-карт в системе. Кроме ccci, в системе есть некий 6620_launcher — бинарник, который загружает прошивку Wi-Fi и gsm0710muxd — специальный сервис, который позволяет в GPRS-сетях одновременно разговаривать и сидеть в интернете.
На смартфонах MTK есть factory mode — так называемый тестовый режим, который гоняют на заводах. Вы, вероятно, когда-то видели китайские меню похожее на рекавери — это и есть factory mode. Из этого режима можно дозвонится в 911 и активировать модем без запуска Android и RIL. Как это работает? Идём читать исходники ядра!
В factory-режиме, для каждого теста, программа активирует модем заново. Для этого есть функции тестового режима для работы с AT-командами и для инициализации модема. Сначала, она открывает терминал /dev/ttyC0 — именно там происходит общение с модемом с помощью AT-команд:
После этого, программа выводит модем из режима сна с помощью команды «AT+ESLP=0», инициализирует СИМ-карту с помощью команды «AT+ESIMS» и задает режим работы с помощью «AT+EFUN=1» и «AT+CREG=1». После этого, модем начинает искать сеть и доступен для обычного общения с помощью AT-команд. Однако, написав тестовую софтину для общения с модемом из под Debian, я получал ошибки вида Device not found. Почему? Пока не знаю. Однако я продолжаю изучать данный вопрос!
Заключение
Подготовленные мною файлы вы можете скачать на диске. Там скомпилированные модули ядра, библиотека для работы с GPIO и пару тестовых программ в качестве примеров.
К счастью, довести гаджет до ума мы смогли своими силами. Весьма странно, что такой крупный и уважаемый производитель как Orange Pi, банально решил «забить» на поддержку собственного устройства. И я лично считаю, что не стоит закидывать в долгий ящик их тем читателям, которые купили когда-то себе подобный девайс и забили, смирившись с отсутствием гайдов.
Немного энтузиазма, опыта и видения будущего проекта — и все получится :)