Мой Инстаграм https://www.instagram.com/nix_cosplays?igsh=OGRiaW0weTV5dHEy

Мой тг канал https://t.me/nix_cosplay

P.S. На последнем фото беру репортаж где прорвало мультивселенную)

Если не соврать, это, конечно здорово. Но вот хочетсся понять что там за бардак творится в компьютерном супермаркете Никс и как там у них "само" в системе без следов такое происходит?

Артикул на сайте висит в увеличенным ценником.

Океееееееееееееееееееей..... Значит просто не будет...

Доки, если кому интересно:
https://nix.dev/tutorials/first-steps/reproducible-scripts

PS: В Linux shebang (#!) — это специальная строка в начале сценария, которая сообщает операционной системе, какой интерпретатор использовать при выполнении сценария. Эта строка, также известная как хэшбанг, шабанг или «резкое восклицание», является первой строкой тире и начинается с «#!» за которым следует путь к интерпретатору

Тыщу раз это использовал, но я не знал, что это называется shebang

Китайские производители не перестают удивлять: многие видят явные перспективы рынка одноплатных компьютеров и стараются представить целую линейку девайсов на самых разных чипсетах, а разработчики стараются использовать уже привычное и поддерживаемое долгие годы железо. К ним относятся решения на чипсетах AllWinner, RockChip, Tegra. Другие же стараются взять малоизвестный, но дешевый чип для иного круга применений, развести на нем компактную плату и продавать по цене пачки сухарей, подобные решения появляются регулярно. Один из таких одноплатников я недавно купил на AliExpress — некий DongShan Pi Pico W, на базе экзотического чипсета SigmaStar SSD210, всего за 600 рублей. И тут действительно есть на что посмотреть: два ядра Cortex-A7, контроллер TTL матриц, 2D GPU, Wi-Fi, 64Мб ОЗУ и Embedded Linux на борту. Более того, девайс поставляется в виде System on Module с переходной Evaluation-платой, что позволяет использовать это устройство в составе других гаджетов! Что это за красавец и на что он способен? Читайте в статье!!

❯ Что это за девайс?

Думаю, большинство моих читателей когда-либо слышали об одноплатных компьютерах. Это компактные и достаточно мощные устройства, которые можно использовать как в качестве компактных серверов или даже десктопных машин, так и собрать своё устройство на базе готового одноплатного компьютера. Одноплатники используется во многих сферах: вендинговые автоматы, умные экраны, самопальные игровые консоли и смартфоны, DIY-ноутбуки!

Однако чаще всего можно увидеть обзоры и проекты на базе довольно известных устройств: Raspberry Pi, Orange Pi, Olimex. Эти платы, скажем так, достаточно дорогие: и если Orange Pi One/Zero ещё можно ухватить за 1.000 рублей на вторичке (один из таких я купил еще летом. Узнав о моем блоге, продавец стал моим читателем и вместо одного OPi прислал мне целых два — один в подарок!), а за RPi Zero придется выложить как минимум 2.000 рублей. Однако есть ещё один сегмент одноплатных компьютеров: ультра-дешевые, разработанные на базе чипов для конкретного применения. Один из самых известных представителей — MangoPi/CherryPi R3, который работает на базе AllWinner F1C200s — чипа для… электронных книг!

Информации по дешевым, почти неизвестным одноплатникам довольно мало. У них не очень хорошая поддержка (кроме AllWinner, там почти все чипсеты есть в mainline-ветке Linux), в них могут обнаружится аппаратные баги, да и многие люди вообще не замарачиваются с ними, предпочитая переплатить, но купить что-то более стабильное. Но не я! Я просто обожаю различные ультрадешевые девайсики, поэтому недавно по наводке моего активного читателя NutsUnderline, я заказал интереснейший девайс — DongShan Pi Pico-W. Устройство обошлось мне всего в 600 рублей, но в первую очередь, меня привлек форм-фактор устройства и его чипсет. Некий SigmaStar SSD210!

Я заказал сразу два устройства: первую партию очень быстро разобрали, поэтому я взял «с запасом». Сейчас конкретно этот одноплатник пока-что не доступен в магазине продавца, однако у него же продаются другие устройства на базе SSD210. Можете найти их по ключевому слову: «SSD210» (прямые линки публиковать не буду, дабы не сочли за рекламу). Через месяц оба красавца пришли ко мне и я принялся их изучать.

Какое же было моё удивление, когда я обнаружил, что это по сути System on Module, который вручную надо припаять к Evaluation-плате! Вкратце это значит, что на базе таких SoM вы можете развести плату, протравить её, а затем припаять одноплатник поверх нее и сделать своё полноценное устройство, «без соплей»! Производителю плюсик за такую гибкость — я не очень люблю одноплатники с штырьковыми гребенками. Хотя, конечно, это очень сильно помогает при разработке макета устройства.

❯ Характеристики

Но чем он так меня привлек, помимо SoM направленности? Своим крутым чипсетом! Давайте ознакомимся с его характеристиками поближе:

• Процессор: SigmaStar SSD210. 2 ядра Cortex-A7, работающие на частоте до 1ГГц. 16Кб кэш инструкций и 16Кб кэш данных, плюс 128Кб L2-кэша. В процессоре есть FPU и поддержка SIMD-инструкций Neon (альтернатива SSE в x86). Нехило, правда?

• Поддержка дисплеев: У чипсета есть выделенный модуль для работы с внешними матрицами. Поддерживаются TTL дисплеи (до 1024x768), SPI-матрицы с клоком до 54МГц (480x320), а также прямой RGB аналоговый RGB сигнал (этот интерфейс можно использовать для подключения к ТВ с тюльпанами или аналоговым матрицам). Про типы дисплеев, вы можете прочитать в моей статье.

• 2D GPU: Поддержка отрисовки линий, прямоугольников, градиентной заливки, BitBLT, клиппинг, дизеринг, автоматическая конвертация формата пикселя (с RGB888 в RGB565). Это серьёзно снимает нагрузку с ЦПУ при рисовании графики, однако поддерживается ли он в Linux — вопрос другой.

• ОЗУ: 64Мб DDR2 памяти «бутербродом» прямо с чипсетом, плюс поддержка до 512Мб DDR2 внешней памяти, до 1333Мб/с.

• Звук: Один моно-выход DAC, два выходных канала I2S, вход микрофона. Входные каналы поддерживают частоту дискретизации до 96КГц. Можно организовать вывод звука лишь подключив внешний усилитель. Внешний ЦАП не обязателен, если вам не нужен стерео-звук.

• Память: Контроллер NOR/NAND SPI-памяти, до двух параллельно подключенных чипов, плюс поддержка SDIO. BootROM поддерживают загрузку с MicroSD карт.

• Сеть: Ethernet, на DongShan Pi есть Wi-Fi.

• USB: Как хост, так и ведомое устройство

• Периферия: 4 канала ШИМ, GPIO, 4 UART, 2 канала SPI, 2 канала I2C

• Камера: До двух камер по интерфейсу MIPI CSI

• Безопасность: Есть аппаратное шифрование.

• Питание: 0.9В ядро, 1.8В ОЗУ, 3.3В I/O

Очень даже бодро, согласитесь? Вообще, производитель подразумевает SSD210 как чипсет для HMI-дисплеев — т. е. умные дисплеи, которые могут, например, служить стендами в музеях, или служить для заказа билетов в кино. Есть внешние HMI-дисплеи, которыми можно управлять используя другие МК: просто посылая команды и реагируя на нажатия кнопок. Тут мы и видим, как китайский производитель решил применить этот чипсет для другой сферы: одноплатный компьютер для DIY!

На SSD210 есть порт Linux, предлагается использовать Embedded Linux в качестве основной системы. Никаких дистрибутивов по типу Ubuntu для устройства нет — предполагается, что вы сами реализуете весь необходимый для ваших программ функционал (отрисовку графики, обработку ввода, звук и т. п.). Есть Build root и исходный код ядра, а также U-Boot.

Помимо этого, вендор предлагает целое SDK для разработки уже готовых устройств на этом чипсете. Но есть один нюанс: документации практически нет :( Такие пакеты предлагаются крупным коммерческим производителям устройств, поэтому и основная поддержка есть только для них. Есть некоторые сэмплы, как, например, использовать графические дисплеи (показан пример с TTL-матрицей 1024x600), но совершенно не ясно как использовать SPI-матрицы, поскольку они требуют отдельной инициализации.

Но сначала наш одноплатник нужно собрать и запустить. И здесь есть множество тонких моментов, которые необходимо знать перед покупкой такого девайса. Переходим к сборке!

❯ Сборка и запуск

Для более удобного процесса разработки нашего устройства, лучше всего заказывать сразу две платы: одну припаять к переходной плате с штырями, а другую использовать на нашем устройстве. Как я уже говорил ранее, одноплатник предлагается в виде System on Module, которые можно при желании распаять на переходной плате:

Честно сказать, я очень люблю такой тип монтажа и топлю за то, чтобы другие одноплатники не форсировали использование штырьков, а позволяли припаять себя «бутербродом» к другой плате. Обычно SoM дороже чем простые одноплатники, один из примеров — Olimex A20 SoM. Припаиваем основную плату к eval-плате. Обратите внимание, что припой должен находится «скосом» с внешней стороны пинов!

После этого, можно распаять гребенку. После окончания процесса сборки, вызваниваем все пятачки на плате и гребенку, дабы исключить непропай в каком-то месте.

Теперь подключаем питание. На плате уже разведены Step-down преобразователи с 5В на 3.3В (основная логика), 1.8В (DDR2), и 0.9В/1.0В (ядро), нам достаточно подключить лишь 5В, либо запитать плату от 3.7В аккумулятора. Устройство стабильно работает и от 0.5А порта ПК (если не юзать Wi-Fi).

Для работы с одноплатником, обязательно нужен COM-преобразователь. Открываем Putty, задаем COM-порт, выставляем бодрейт 115200 и отключаем контроль четности. После подачи питания на устройство, в консоли побегут логи, U-Boot начнет загружать систему… однако, есть один важный нюанс…

Все платы прошиваются на заводе с помощью фирменного флэшера SSD210. Но фирменный флэшер, по каким-то причинам, на некоторых платах не может сохранить U-Boot Environment (переменные окружения, которые в том числе определяют таблицу разделов и коммандлайн ядра).

Поэтому если ваша плата повисла на CRC Error, нужно ввести следующие команды:

setenv mtdids nand0=nand0

setenv mtdparts ' mtdparts=nand0:0x140000(CIS),0x1a0000(BOOT0),0x1a0000(BOOT1),0x40000(ENV),0x40000(ENV1),0x20000(KEY_CUST),0x500000(KERNEL),0x500000(RECOVERY),0x600000(rootfs),0xa0000(MISC),-(UBI)

setenv bootargs ubi.mtd=UBI,0x800 root=/dev/mtdblock8 rootfstype=squashfs ro init=/linuxrc LX_MEM=0x3FE0000 mma_heap=mma_heap_name0,miu=0,sz=0x1E00000 cma=2M highres=off mmap_reserved=fb,miu=0,sz=0x300000,max_start_off=0x3C00000,max_end_off=0x3F00000 ${mtdparts}

setenv bootcmd ' nand read.e 0x22000000 KERNEL ${kernel_file_size}; dcache on ; bootlogo 0 0 0 0; bootm 0x22000000;nand read.e 0x22000000 RECOVERY ${recovery_file_size}; dcache on ; bootm 0x22000000

setenv autoestart 0

setenv sstar_bbm off

setenv ipl_version "##p3##gdf99011IPL_##########

setenv ipl_version "DUALENV=1 SILENT_CONSOLE=1 CFG_SDMMC_DISABLE=n ALK=1 SPINAND=1 CHIP=pioneer3""

saveenv

После этого отправляем плату в ресет и система загружается как ни в чем не бывало!

Поскольку на плате не разведен разъем USB, для прошивки нужно распустить нерабочий кабель для зарядки смартфона, либо купить внешний USB-разъем на плате. VBUS кидаем на вход питания, белый провод на DM-, зелёный на DM+. Не забывайте провести общую землю между UART-преобразователем и основным питанием платы, дабы не потерять логи.

Замыкаем два пина в центре платы пинцетом и жмем RESET. Плата определится как MSDC-флэшка (не удивляйтесь). Прошивальщик глючный и бывает не с первого раза может прошить устройство. Если девайс после прошивки не включается — введите команды в консоль U-Boot выше.

Теперь переходим к самой системе.

❯ Система

Девайс работает на базе ядра Linux 4.9. Тем не менее, производителем заявлена поддержка Mainline-ядра, что даёт надежду на поддержку устройства в будущем.

Таблица разделов устройства организована в виде ubifs. Вообще, предполагается, что для тестов можно будет запускать ваш софт без перезагрузки, однако когда речь заходит о серьезных модификациях, ребут и прошивка устройства глючным софтом — дело неизбежное.

«Из коробки» на устройстве доступен лишь i2cdev, благодаря которому можно свободно общаться с i2c-устройствами из юзерспейса. Хотите получить доступ к SPI? Готовьтесь качать билдрут, вручную включать spidev в конфиге и редактировать DeviceTree, дабы spidev мог получить доступ к физическим spi-устройствам ядра.

Кроме того, конечно же, есть доступ к GPIO из sysfs.

На самой плате, Wi-Fi реализован в виде внешнего USB-хаба + Wi-Fi адаптера. Чипсет также поддерживает Ethernet.

Для разработки устройств, производитель предлагает отдельное SDK для общения с периферией устройства из юзерспейса. С помощью этого SDK, можно получить доступ к камере, аппаратному декодеру, звуку и настроить матрицу. Судя по всему, общение происходит с помощью ioctl к необходимым устройствам. Это сделано для того, чтобы разработчики не копались в низкоуровневых драйверах, ведь например, ALSA, на устройстве нет совсем.

Если включить нужные нам модули в юзерспейс (spidev, i2cdev, gpio), то можно будет проектировать устройства более простым путем. Например, подключить дисплейчик и прямо из юзерспейса выводить на него графическую информацию. Это открывает перспективы для самых разных применений: опрос датчиков и хранение информации в внутренней памяти, умные сигнализации, самодельные часы, DIY игровые консоли, самодельные телефоны и т. п. Применений просто куча!

❯ Заключение

Вот мы и посмотрели с вами на дешевые одноплатники, где используются чипсеты, которые разработаны для использования в совершенно других сферах. Девайсы весьма своеобразные и для полноценной работы с ними нужно обладать навыками прожженного линуксоида и иметь навыки системного программирования. Но, чего уж точно нельзя отрицать, так это перспектив подобных девайсов для своих проектов. Да, под них нет готовых гайдов, как для Raspberry Pi или Orange Pi, информации по ним минимум… но если захочется — то всегда можно «сварганить» самопальное устройство за минимальный прайс!

Вероятнее всего, я применю один из этих одноплатников для своего проекта немного позже. И конечно же, я напишу об этом отдельный материал — ведь про экзотические чипсеты на Пикабу пишут не так часто!

Чуть позже выйдет материал про Repka Pi. Их одноплатник получился не менее интересным и как раз таки метит в нишу одноплатников с хорошей поддержкой, где есть уже готовые гайды, информация и даже сами разработчики могут помочь с решением некоторых проблем. Без косяков не обошлось: есть пару аппаратных проблем, о которых я расскажу открыто, но в целом девайс выглядит интересным!

Для многих разработчиков приложений далеко не секрет, что экосистема Android не предполагает написание полностью нативных приложений: в этой платформе очень многое завязано на Java и без ART можно запустить только простые службы без какого-либо интерфейса. Однако, есть один способ писать практически под «голый» Linux, не перекомпилируя ядро и при этом пользоваться самыми интересными фишками устройства без оверхеда в виде тяжелого Android: ускорение 3D-графики (OpenGLES), микшер звука, ввод с различных устройств, OTG, Wi-Fi и если очень постараться — даже 3G. Это открывает множество разных интересных применений старым устройствам: «железо» смартфонов зачастую гораздо мощнее современных недорогих одноплатников. Сегодня я покажу вам, как написать и запустить программу, которая полностью написанное на C без Android, на No-Name Android-смартфоне практически без модификаций. Интересно? Жду вас в статье!

❯ Что нам нужно знать?

Даже относительно старые устройства флагманского сегмента обладают весьма неплохими характеристиками. Зачастую они гораздо мощнее современных дешевых одноплатников и могут выполнять самые разные задачи: эмуляция консолей, работа в качестве плееров, да даже просто сделать настольные часики самому было бы здорово. Но есть одно но — это Android. Платформа от Google может тормозить даже на достаточно мощном железе, что резко ограничивает потенциально возможные применения подобных гаджетов. Да и многие программисты не особо хотят заморачиваться и учить API Android для реализации каких-то своих проектов.

Но конечно же, есть один способ писать нативные программы, при этом используя все ресурсы смартфона/планшета. Для этого нужно понимание, как работает процесс загрузки на многих Android-гаджетах:

1. Первичный загрузчик (BootROM) инициализирует какую-то часть периферии и загружает вторичный загрузчик (U-boot/LK).

2. Вторичный загрузчик, используя определенные аргументы (например зажата ли какая-то кнопка) выбирает, с какого раздела грузить ядро системы.

3. После загрузки ядра Linux и подключения ramdisk начинается выполнение процессов системы.

Как раз в третьем пункте и лежит ключ к способу, который будем использовать мы. Дело в том, что в смартфоне обычно есть несколько boot-разделов и у каждого свой образ ядра Linux со своим ramdisk. Первый из них — это знакомый моддерамboot.img, который отвечает за загрузку системы и инициализирует железо/монтирует разделы/подготавливает окружение к работе (.rc файлы) и запускает главный процесс Android —zygote. При этом используется собственная реализация init от Android.

Второй, не менее знакомый многим раздел —recovery, отвечает за так называемый режим восстановления, в котором мы можем сбросить данные до заводских настроек/очистить кэши или прошить кастомную прошивку. Вероятно, многие из вас замечали, насколько быстро ваш девайс загружает этот режим, гораздо быстрее, чем загрузка обычного Android. И именно в его реализацию нам нужнозаглянуть(я намеренно выбрал бранч версии 2.3 — т.е Gingerbread для простоты):

А recovery оказывается самой обычной нативной программой, написанной на C со своим небольшим фреймворком для работы с графикой и вводом. В процессе загрузки режима recovery, скрипт запускает одноименную программу в /sbin/, благодаря которому мы видим простую и понятную менюшку. Так почему бы не использовать этот раздел в своих целях и не написать какую-нибудь нативную программу самому?

Как я уже говорил выше, в этом режиме доступны многие аппаратные возможности вашего смартфона, за исключением модема. Используя полученную информацию, предлагаю написать наше небольшое приложение под Android-смартфон без Android сами!

❯ Подготавливаем окружение

В первую очередь, хотелось бы отметить, что программы под «голый» смартфон можно писать не только на C/C++. Нам доступен как минимум FPC, который довольно давно умеет компилировать голые бинарники под Android. Кроме того, мы можем портировать маленькие embedded-версии интерпретаторов таких языков, как lua, micropython и duktape (JS).

Однако в случае нативных программ, есть два важных правила, которые необходимо понимать. Во-первых, в Android используется собственную реализацию стандартной библиотеки libc — bionic, в то время как на десктопных дистрибутивах используется glibc. Между собой они не совместимы — именно поэтому вы не можете просто взять и запустить консольную программу для Raspberry Pi, например.

А второе правило заключается в том, что начиная с версии 4.1, Androidтребует, чтобы все нативные программы были скомпилированы в режиме -fPIE — т. е. выходной код должен не зависеть от адреса загрузки программы в виртуальную память. Для этого достаточно добавить ключ -fPIE, однако учтите, что если вы разрабатываете программу под Android 4.0 и ниже, то fPIE наоборот необходимо убрать — старые версии Androidнеподдерживают такой способ генерации кода и будут вылетать с Segmentation fault.

Для разработки нам понадобится ndk — там есть все необходимые заголовочники и компиляторы для нашей работы. Я используюndk r9c, поскольку в свежих версиях Google регулярно может что-то сломать.
ndk-build, к сожалению, здесь работать не будет, поэтому Makefile придется написать самому. Я составил полностью рабочий Makefile, который без проблем скомпилирует валидную программу, вам остаётся лишь поменять NDK_DIR.

NDK_DIR = D:/android-ndk-r11c/

TOOLCHAIN_DIR = $(NDK_DIR)toolchains/arm-linux-androideabi-4.9/prebuilt/windows-x86_64/bin/

GCC = $(TOOLCHAIN_DIR)arm-linux-androideabi-g++

PLAT_DIR = $(NDK_DIR)platforms/android-17/arch-arm/usr/

LINK_LIBS = -l:libEGL.so -l:libGLESv1_CM.so

OUTPUT_NAME = cmdprog

build:

$(GCC) -I $(PLAT_DIR)include/ -L $(PLAT_DIR)lib/ -fPIE -Wl,-dynamic-linker=/sbin/linker $(LINK_LIBS) -static -o $(OUTPUT_NAME) main.cpp micro2d.cpp

После этого пишем простенькую программу, которая должна вывести «Test» и компилируем её.

❯ Деплоим на устройство

Несмотря на то, что грузиться мы будем в режим recovery, нам всё равно будет доступен adb, через который мы сможем запускать и отлаживать нашу программу. Это очень удобно, однако по умолчанию adb включен только в TWRP, который нужно сначала найти или портировать под ваш девайс (на большинство старых брендовых устройств порты есть, на нонейм придется портировать самому — гайды есть в интернете). Под ваше устройство есть TWRP? Отлично, распаковываете recovery.img с помощью так называемой «кухни» (MTKImgTools как вариант):

Открываете init.recovery.service.rc и убираете оттуда запуск одноименной службы (можно просто оставить файл пустым).

Запаковываем образ обратно тем же MTKImgTools и прошиваем флэшером для вашего устройства — в моём случае, это SP Flash Tool (MediaTek):

Заходим в режим рекавери и видим зависшую заставку устройства и звук подключения устройства к ПК. Если у вас установлены драйвера, то вы сможете без проблем зайти в adb shell и попасть в терминал для управления устройством. Теперь можно закинуть программу — прямо в корень рамдиска (записывается программа в ОЗУ, но при переполнении, телефон уйдет в ребут — осторожнее с этим). Пишем:

adb push cmdprog /: adb shell chmod 777 cmdprog ./cmdprog

И видим результат. Наша программа запускается и работает!

Это просто отлично. Однако я ведь обещал вам, что мы напишем программу, которая сможет выводить графику и обрабатывать ввод, предлагаю перейти к практической реализации!

❯ Выводим графику

Для вывода графики без оконных систем, мы будем использовать API фреймбуфера Linux, которое позволяет нам получить прямой доступ к массиву пикселей на экране. Однако учтите, что этот способ полностью программный и может оказаться тормозным для вашего приложения: скорость работы прямо-пропорциональна разрешению дисплея вашего устройства. Чем выше разрешение, тем ниже филлрейт. В моём случае, матрица была с разрешением 960x540, 32млн цветов, IPS — очень недурно, согласны?

Фреймбуфер Linux может работать с самыми разными форматами пикселя, имейте это ввиду. На некоторых устройствах может быть 16-битный формат (262 тысячи цветов, RGB565), на моём же оказался 32х-битный с выравниванием по строкам (имейте это также ввиду). 32х битный формат. Работать с ним легко: открываем устройство /dev/graphics/fb0, получаем параметры (разрешение, формат пикселя), делаем mmap для отображения буфера с пикселями на экране в память нашего процесса и выделяем второй буфер для двойной буферизации дабы избежать неприятных мерцаний.

void m2dAllocFrameBuffer()

{

fbDev = open(PRIMARY_FB, O_RDWR);

fb_var_screeninfo vInfo; fb_fix_screeninfo fInfo;

ioctl(fbDev, FBIOGET_VSCREENINFO, &vInfo);

ioctl(fbDev, FBIOGET_FSCREENINFO, &fInfo); fbDesc.width = vInfo.xres;

fbDesc.height = vInfo.yres;

fbDesc.pixels = (unsigned char*)mmap(0, fInfo.smem_len, PROT_WRITE, MAP_SHARED, fbDev, 0); f

bDesc.length = fInfo.smem_len; fbDesc.lineLength = fInfo.line_length;

backBuffer = (unsigned char*)malloc(fInfo.smem_len); memset(backBuffer, 128, fInfo.smem_len);

printf("Framebuffer is %s %ix%ix%i\n", (char*)&fInfo.id, fbDesc.width, fbDesc.height, vInfo.bits_per_pixel, fInfo.type);

}

Если не сделать предыдущий шаг и запускать нашу программу параллельно с recovery, то они обе будут пытаться друг друга «перекрыть» — эдакий race condition:

После этого пишем простенькие функции для блиттинга картинок (в том числе с альфа-блендингом). В инлайнах и критичных к скорости функциям лучше не делать условия на проверку границ нашего буфера — лучше «отрезать» ненужное еще на этапе просчета ширины/высоты:

__inline void pixelAt(int x, int y, byte r, byte g, byte b, float alpha)

{

if(x < 0 || y < 0 || x >= fbDesc.width || y >= fbDesc.height) return;

unsigned char* absPtr = &backBuffer[(y * fbDesc.lineLength) + (x * 4)];

if(alpha >= 0.99f)

{

absPtr[0] = b;

absPtr[1] = g;

absPtr[2] = r;

}

else {

absPtr[0] = (byte)(b * alpha + absPtr[0] * (1.0f - alpha));

absPtr[1] = (byte)(g * alpha + absPtr[1] * (1.0f - alpha));

absPtr[2] = (byte)(r * alpha + absPtr[2] * (1.0f - alpha));

} absPtr[3] = 255; }

for(int i = 0; i < image->height; i++)

{

for(int j = 0; j < image->width; j++)

{

byte* ptr = &image->pixels[((image->height - i) * image->width + j) * 3]; pixelAt(x + j, y + i, ptr[0], ptr[1], ptr[2], alpha);

}

}

И загрузчик TGA:

CImage* m2dLoadImage(char* fileName) {

FILE* f = fopen(fileName, "r");

printf("m2dLoadImage: Loading %s\n", fileName);

if(!f)

{

printf("m2dLoadImage: Failed to load %s\n", fileName);

return 0;

}

CTgaHeader hdr;

fread(&hdr, sizeof(hdr), 1, f);

if(hdr.paletteType)

{

printf("m2dLoadImage: Palette images are unsupported\n");

return 0;

}

if(hdr.bpp != 24) {

printf("m2dLoadImage: Unsupported BPP\n");

return 0;

}

byte* buf = (byte*)malloc(hdr.width * hdr.height * (hdr.bpp / 8));

assert(buf);

fread(buf, hdr.width * hdr.height * (hdr.bpp / 8), 1, f);

fclose(f);

CImage* ret = (CImage*)malloc(sizeof(CImage));

ret->width = hdr.width;

ret->height = hdr.height;

ret->pixels = buf;

printf("m2dLoadImage: Loaded %s %ix%i\n", fileName, ret->width, ret->height);

return ret;

}

И попробуем вывести картинку:

m2dInit();

test = m2dLoadImage("test.tga");

test2 = m2dLoadImage("habr.tga");

while(1)

{

m2dClear();

m2dDrawImage(test, 0, 0, 1.0f);

m2dDrawImage(test2, tsX - (test2->width / 2), tsY - (test2->height / 2), 0.5f);

m2dFlush();

}

Не забываем про порядок пикселей в TGA (BGR, вместо RGB), меняем канали b и r местами в pixelAt и наслаждаемся картинкой на большом и классном IPS-дисплее:

Производительность отрисовки не очень высокая, однако если оптимизировать код (копировать непрозрачные картинки сразу сканлайнами и убрать проверки в инлайнах), то будет немного шустрее. Google для подобных целей сделали собственный простенький софтрендер —libpixelflinger.

Есть вариант для быстрой и динамичной графики: использовать GLES, который без проблем доступен и из recovery. Однако, насколько мне известно (в исходники драйверов посмотреть не могу), указать фреймбуфер в качестве окна не получится, поэтому в качестве Surface для рендертаргета у нас будет служить Pixmap (так называемый off-screen rendering), которому нужно задать правильный формат пикселя (см. документацию EGL). Рисуем туда картинку с аппаратным ускорением и затем просто копируем в фреймбуфер с помощью memcpy.

❯ Обработка нажатий

Однако, ни о каких GUI-программах не идёт речь, если мы не умеет обрабатывать нажатия на экране с полноценным мультитачем! Благо, даже механизм обработки событий в Linux очень простой и приятный: мы точно также открываем устройство и просто читаем из него события в фиксированную структуру. Эта черта мне очень нравится в архитектуре Linux!

Каждое устройство, которое может передавать данные о нажатиях, находится в папке /dev/input/ и имеет имя вида event. Как узнать нужный нам event? Нам нужен mtk-tpd — реализация драйвера тачскрина от MediaTek (у вашего чипсета может быть по своему), для этого загружаемся в Android и пишем getevent. Он покажет доступные в системе устройства ввода — в моём случае, это event2:

Из event можно читать как в блокирующем, так и не в блокирующем режиме, нам нужен второй. Более того, в них можно инжектить события, что я показывал в статье про создание своей консоли из планшета с нерабочим тачскрином:

// Open input device evDev = open(INPUT_EVENT_TPD, O_RDWR | O_NONBLOCK);

После этого, читаем события с помощью read и обрабатываем их. На устройствах с резистивным тачскрином, передается просто ABS_POSITION_X, на устройствах с поддержкой нескольких касаний — используетсяпротокол MT. Когда пользователь нажал на экран, посылается нажатие BTN_TOUCH с значением 1, а когда отпускает — соответственно BTN_TOUCH с значением 0. Разные драйверы тачскрина используют разные координатные системы (насколько я понял), в случае MediaTek — это абсолютные координаты на дисплее (вплоть до ширины и высоты). На данный момент, я реализовал поддержку только одного касания, но при желании можно добавить трекинг нескольких нажатий:

void m2dUpdateInput()

{

input_event ev;

int ret = 0;

while((ret = read(evDev, &ev, sizeof(input_event)) != -1))

{

if(ev.code == ABS_MT_POSITION_X) tsState.x = ev.value;

if(ev.code == ABS_MT_POSITION_Y) tsState.y = ev.value;

if(ev.code == BTN_TOUCH) tsState.isPressed = ev.value == 1;

}

tsState.cb(tsState.isPressed, tsState.x, tsState.y); }

Теперь мы можем «возить» логотип Хабра по всему экрану:

void onTouchUpdate(bool isTouching, int x, int y) {

if(isTouching)

{

tsX = x;

tsY = y;

}

}

int main(int argc, char** argv) {

printf("Test\n");

m2dInit();

test = m2dLoadImage("test.tga");

test2 = m2dLoadImage("habr.tga");

printf("Volume: %i %i\n", vol, muteState);

m2dAttachTouchCallback(&onTouchUpdate);

while(1) {

m2dUpdateInput();

m2dClear();

m2dDrawImage(test, 0, 0, 1.0f);

m2dDrawImage(test2, tsX - (test2->width / 2), tsY - (test2->height / 2), 0.5f);

m2dFlush();

}

return 0;

}

В целом, это уже можно назвать минимально-необходимым минимумом для взаимодействия с устройством и использованию всех его возможностей на максимум без Android. Более того, такой метод заработает почти на любом устройстве, в том числе и китайских NoName, где ни о каких исходниках ядра и речи нет. Теперь вы можете попытаться использовать ваше старое Android-устройство для чего-нибудь полезного без необходимости изучать API Android.

❯ Звук, модем и другие возможности

Для звука нам придётся использовать ALSA — поскольку эта подсистема звука сейчас используется в большинстве устройств на Linux. Судя по всему, тут есть режим эмуляции старого и удобного OSS, поскольку устройства /dev/snd/dsp присутствует. Однако, вывод в него какого либо PCM-потока не даёт ничего, поэтому нам пригодится ALSA-lib.

Другой вопрос касается модема и сети. И если Wi-Fi ещё можно поднять (wpa_supplicant можно взять из раздела /system/), то с модемом будут проблемы — нет единого протокола по общению с ним и кое-где, чтобы его заставить работать, нужно будет немного попотеть. Не стесняйтесь изучать исходники ядра (MediaTek охотно делится реализацией вообще всего — там и RIL, и драйвер общения с модемом) и смотреть интересующие вас фишки!

❯ Заключение

Как мы с вами видим, у старых девайсов все еще есть перспективы стать полезными в какой-либо сфере даже без Android на борту. На тех устройствах, где нет порта Ubuntu или обычного десктопного Linux, всё равно сохраняется возможность писать нативные программы и попытаться приносить пользу.

Не стесняйтесь лезть и изучать вендорские исходники — это даёт понимание, как работают устройства изнутри. Собственно, благодаря такому ежедневному копанию исходников системы и появилась данная статья! :)

Каждый год выпускается с десяток новых моделей одноплатных компьютеров. Свежие девайсы представляют как старые и уважаемые фирмы по типу Raspberry Pi, Orange Pi или Banana Pi, так и относительные новички на рынке — Repka Pi, или, например, Lctech Pi. Одноплатники работают на достаточно большом парке железа: кто-то использует чипы AllWinner, кто-то Amlogic, кто-то Beoadcom, а кто-то… мобильные! Пару лет назад Orange Pi отличились выпуском нескольких одноплатников на базе чипсетов очень бюджетных мобильников 2013-2015 годов — 2G IoT и 3G IoT. На данный момент, выпуск 3G IoT завершен, а компания предлагает купить абсолютно новый одноплатник с 3G, Bluetooth, Wi-Fi, GPS, поддержкой Linux и Android всего за 1.000 рублей (500 само устройство и 500 доставка). На что оно способно и стоит ли его брать — узнаем в статье!

Что за устройство?

IoT устройство уже прочно закрепились в нашей жизни. Сейчас уже есть возможность приобрести полноценный внешний GSM-модуль за пару сотен рублей, который способен будет выйти в сеть или обрабатывать SM. Однако, в мире одноплатников всё не так просто: большинство из этих устройств использует планшетные чипсеты, которые обычно не обладают встроенными модемами для работы в GSM-сетях. На помощь приходят внешние модули, но чем выше необходимое поколение связи, тем выше цена. И есть 200 рублей за 2G модуль — это совсем немного, то 3G, а тем более LTE модули могут влететь в копеечку. Конечно в мейнлайн дистрибутивах уже есть драйвера на некоторые модемы Huawei, благодаря чему можно просто воткнуть копеечный USB-свисток но это не совсем спортивно.

С весьма интересным решением пришла компания Orange Pi. Несколько лет назад они представили весьма занимательное устройство: 2G IoT, которое работало на базе давным-давно забытого мобильного чипсета RDA8810, который является родственником Spreadtrum SC6820 — чипа, который использовался в очень многих китайских ультрабюджетниках 2012-2014 годов. Устройство отличалось весьма неплохими характеристиками за низкий прайс:

• Процессор: RDA8810, Cortex-A5, 1Ghz.

• ОЗУ: 256 мегабайт DDR2.

• ПЗУ: 512 мегабайт NAND памяти + возможность загрузки с MicroSD флэшек.

• Дисплей: 40-пиновый коннектор, мимикрирующий под стандартизированный. Однако производитель предлагает свой дисплей от мобильниках втридорого, а распиновка несколько отличается от общепринятой — нужно делать переходник.

• Питание: 5в от USB, до 2А нагрузки при работе с сетью, 3.7в от АКБ с встроенным контроллером питания.

• Звук: Микрофон + встроенный в чипсет ЦАП для вывода звука из системы.

• Интерфейсы: SPI, I2C, GPIO, UART, Wi-Fi, Bluetooth.

Причина низкой цены и хорошего функционала очень проста: Orange Pi просто взяли референсную плату ультрабюджетного смартфона за 1.500-2.000 рублей и развели из нее одноплатник, который затем начали производить. На момент выхода одноплатника, смартфоны на 8810 не производились, так что отпускная цена на чипы была копеечная, в то время как на AllWinner'ы спрос весьма хорош. Год назад они продавались по 700 рублей с учетом доставки, но сейчас их окончательно распродали и найти их можно только на вторичке.

3G IoT — следующая ветвь развития IoT линейки OPi, которая на этот раз работает на базе чипсета MediaTek и имеет полноценную поддержку 3G. По сути, возможности остались те же, однако возможности вывода на HDMI до сих пор нет — теперь производитель предлагает LVDS матрицу, опять же, втридорого. Однако схема есть, чисто теоретически есть возможно купить какой-нибудь бюджетник от ZTE/Huawei, найти схему платы и сделать переходник с шлейфа нашей матрицы на коннектор одноплатника. Драйвер матрицы можно взять в исходниках ядра и без изменений перенести. Работает девайс на базе чипа для бюджетных смартфонов, однако теперь в нашем распоряжении целых два ядра!

Характеристики девайса такие:

• Процессор: 2х-ядерный MT6572, Cortex-A7, 1.2Ghz.

• ОЗУ: 256мб.

• ПЗУ: 512мб eMMC флэшка от Leahkinn + возможность загрузки с MicroSD.

• Дисплей: MIPI DSI, LVDS.

• Питание: 5в, до 2А в пике, 3.7в с контроллером питания.

• Звук: всё так же, микрофон + ЦАП.

• Интерфейсы: SPI, I2C, GPIO, UART, Wi-Fi, Bluetooth.

Весьма недурно, согласны? На момент выхода статьи, этот одноплатник можно заказать на всем известном сайте за 1.000 рублей — это с учетом доставки. Идет недели 3, поставляется в фирменной коробочке. Гребенка уже распаяна с завода.

Ну что-ж, предлагаю посмотреть, что может предложить нам такой одноплатник и стоит ли его вообще брать?

Накатываем систему

На выбор у нас есть Android и Linux. Учтите, что GSM стек работает только в Android! Теоретически есть возможность связаться с модемом из под Linux, но это требует дальнейшего изучения местного factory-режима. Впрочем, GSM под Android не так уж и плохо — нужное вам поведение, вероятно, можно реализовать в виде службы. Но управлять Android придется только, и только через ADB, если у вас нет дисплея.

Для установки ОС можно использовать как внутреннюю память (только Android, rootfs линукса туда не влезет), так и на MicroSD. Оба способа требуют прошивки eMMC с помощью фирменого флэшера — SP Flash Tool. Суть в том, что выбор варианта загрузки с SD/NAND реализован здесь в виде настройки точки монтирования: ядро так или иначе будет находится на eMMC, но в зависимости от выбранного образа boot, будет загружать систему с соответствующего носителя. Примерно как это реализовано здесь.
Мы будем ставить Linux: качаем SP Flash Tool, выбираем scatter-файл и ставим Format All + Download. Осторожно, форматирование сотрет NVRAM и IMEI, так что лучше сделать бэкапы (хотя их все равно можно легко перебить из системы вручную):

На первом проходе, флэшер переразметит внутреннюю память, но ругнется на отсутствующий раздел System. После этого, нужно вернуть режим Download only, снять галку с System и прошить устройство еще раз — после этого, плата будет загружаться с MicroSD:

Теперь нужно записать саму систему на флэшку. Образы записываются как обычно — берем флэшку на 4-8гб, вставляем в кард-ридер и записываем образ через Win32DiskImager. Флэшку желательно брать 10-класса, но у меня и «пятерка» работала с адекватной производительностью:

После записи, вставляем флэшку в устройство и запитываем его. Возможны варианты питания как напрямую от БП, так и от аккумулятора — в таком случае, при подключении БП, контроллер питания будет заряжать аккумулятор, а за статусом зарядки можно следить через устройство battery в /sys/class/power_supply/ (и в Linux, и в Android).

Для общения с системой через консоль, нам понадобится UART-преобразователь. Я для этого использую плату ESP32-WROOM с выпаянным чипом ESP32. Подтыкиваемся (или подпаиваемся) к UART'у, запускаем putty, ставим бодрейт 115200 и вперед наблюдать за консолью!

Настраиваем Linux

Тут ничего особо сложного нет, лишь некоторая подготовка к полноценному использованию системы. Если для вас написанное малопонятно — можете просто скопипастить, все должно работать без проблем.

Итак, система запустилась и требует логин, а кроме этого — сыпет логами в UART. Стандартный логин — root, пароль orangepi, лучше смените пароль сразу. Надоели логи? Пишем:

dmesg -n 1

Можно сразу записать эту команду в rc.local, если не хотите после каждого ребута писать команду по новой.

После этого, нам нужно настроить Wi-Fi. В системе предустановлен wpa_supplicant, поэтому для подключения мы идем в /etc/network/ и редактируем с помощью nano файл interfaces:

nano interfaces

... Дописываем

auto wlan0

iface wlan0 inet dhcp

wpa-ssid "Имя вашей сети"

wpa-psk "Пароль вашей сети"

Жмем Ctrl + X, сохраняем и перезапускаем сервис networking service networking restart Возникли проблемы? wpa_supplicant жалуется на существующий контекст? Удаляем wpa_supplicant из /run/, если все равно не работает - отправляем систему в ребут, должно заработать.

Имейте ввиду: плата без проблем питается от стандартных 5В/0.5А USB-порта ПК, но если подключить к ней USB-устройство во время работы — то плата начнет уходить в ребут при попытке поднять Wi-Fi, даже если вытащить флэшку. Лечится легко: обесточиваем плату, затем включаем снова.

Подключиться можно хоть к точке Wi-Fi от вашего смартфона, дабы объединить их в локальную сеть. Тогда с помощью VNC можно будет вывести изображение с одноплатника на экран разбитого сяоми — чем не применение старому гаджету? Пингуем гугл, сеть есть — отлично!

Теперь ставим icewm из репозиториев, tightvnc и пошло поехало… ан нет! Debian Stretch уже выкинули из официальных репозиториев, перенеся его в архив. Пользовались старыми версиями убунты/дебиана? Тогда следующая операция для вас будет знакома:

nano /etc/apt/sources.list

...

Меняем ftp2.cn.debian.org на archive.debian.org во всех строках. Ctrl + X, сохраняем.

Пишеv apt-get update. Ждём обновления списка пакетов.

Теперь мы можем ставить официальные бинарные пакеты из репозиториев. Нам доступна куча софта, в том числе с более старших Raspberry Pi и Orange Pi — ABI то одно! Можно поставить TightVNCServer, запустить его и без проблем подключиться к нашей машинке (5900 — базовый порт, 5901 — будет для первого дисплея и.т.п).

Но сейчас у нас просто маленький и слабенький десктоп. Надо же использовать возможности одноплатника по полной, верно?

GPIO

У устройства есть гребенка с 40 пинами, часть из которых мы без проблем можем использовать для наших целей. Друзья, если вы уже имели опыт с другими одноплатниками, то знаете что для Broadcom/AllWiiner и других иных чипсетов уже есть готовые библиотеки для работы с GPIO. Под MediaTek их нет, но ничего сложного в работе с ними из user-space нет. Рассмотрим схему подробнее и два способа работы с ними:

Первый из официального мануала, подразумевает чтение и запись в специальное виртуальное устройство — mt_gpio, а вернее — в его дебаг-режим. В него можно писать хоть из shell-скрипта при желании. Виртуальное устройство расположено по пути/sys/devices/virtual/misc/mtgpio/pin. Если просто начать читать из него, то мы получим список всех пинов и их состояние:

PIN: [MODE] [PULL_SEL] [DIN] [DOUT] [PULL EN] [DIR] [INV] [IES]
0:1000000-1
1:1000000-1
...

Чтобы записать состояние, нам нужно послать специальную строку:

echo -wdout<номер пина> > 1/0

Чтобы выбрать направление пина, нам нужно послать:

echo -wdir<номер пина> > 1/0, где 0 - вход

Чтобы получить состояние пина, нужно прочитать все строки устройство pin и потом распарсить, например, с sscanf (хотя поскольку одно поле — один char, можно взять абсолютное смещение от начала строки). Если читаем — то 3 столбец после двоеточия будет состоянием нашего пина. Я уже все проверил, все точно работает без каких либо проблем, главное не забывайте за режим GPIO :)

Пожалуйста, согласовывайте уровни! GPIO у MT6572 имеют лог. уровень 1.6в. Часть периферии чипсета работает на стандартных 3.3в.
Как это работает? См.в исходниках ядра.

Такой способ подойдет для приложений, где не требуется сильно высокая скорость работы. Для шелл-скриптов или даже полноценных нативных приложений таким методом можно управлять пинами без проблем — если вы конечно не реализовываете SPI софтварно :)

Есть и второй способ — использовать mt-gpio напрямую через вызов ioctl. Я этот режим пока еще не пробовал, но он гораздо быстрее — для юзерспейса самое то, а работать с ним довольно легко. См. исходники драйвера здесь.

UART

Это второй способ коммуникации с внешним миром, доступный из коробки. На устройстве целых два канала UART, которые могут работать как минимум со скоростью 921600б/с (или 115200 килобайт в секунду). лучше всего использовать эту шину для общения с другими микроконтроллерами или ПК.

Получить доступ к UART можно благодаря соответствующему character-устройству /dev/ttyMTxx. При стандартных настройках (921600б/с), можно без проблем работать с UART из shell-скриптов, как с самым обычным терминалом: echo для записи, cat — для чтения. Из нативных программ, есть такая же возможность открыть ttyMT и читать/писать при стандартных настройках, а если конфигурацию необходимо изменить, то на помощь приходит termios.

SPI/I2C

А вот тут уже все гораздо интереснее. Как известно, в Linux драйвера шин делятся на два типа: kernel-mode, для работы с драйвером SPI/I2C из других драйверов (например, драйвер камеры хочет получить информацию о модуле через i2c) и user-space i2c-dev/spi-dev. Последние два есть из коробки в большинстве дистрибутивов для «взрослых» одноплатников, но их забыли включить в текущий релиз ядра 3G IoT. Почему? Не ясно — драйвера для i2c и spi у MediaTek точно есть.

На гребенке есть один I2C и один SPI. Исходники ядра для платы можно найти на гитхабе OrangePi. Чуть позже надо будет попробоваать скомпилировать i2cdev и spidev в виде отдельных модулей ядра, которые можно будет загрузить через modprobe.

Я хочу бэйр-метал, а не эти ваши линуксы!!!

И такая возможность есть, но лишь частично. Orange Pi открыли исходники вторичного загрузчика MediaTek — lk (альтернатива u-boot) или Little Kernel. При некоторой модификации логики lk, можно реализовать свою прошивку используя почти всю мощь чипсета. За этим — сюда.

Для чего он еще может пригодится?

Давайте смотреть сами. У нас есть полноценный десктопный Linux, есть Android, есть 2 неплохих ARMv7 ядра, работающих на частоте 1.2ггц, есть 256 мегабайт ОЗУ. Чем он может еще пригодится:

• Сервер: Нет, речь конечно же не о NAS. Однако поднять простенькую домашнюю страницу, или попытаться реализовать на нем умный дом можно вполне.

• Сбор информации с датчиков: В паре с микроконтроллером, на таком устройстве можно собирать, обрабатывать и хранить довольно большое количество данных с высокой скоростью опроса.

• Ретро-машинка для эмуляторов: При условии, что Вы купили фирменный дисплей, поскольку через VNC поиграть не получится. К сожалению, ни одного вывода на ТВ, данный чипсет не имеет, поэтому либо пытаться прикрутить дисплей от китайчика, либо покупать фирменный.

• Хитрая и дешевая сигнализация с GPS: В целом, для сигнализации такую плату можно рассматривать как System On Module: сразу и линух есть, и GPS из коробки, и 3G. Выйдет дешевле, чем купить отдельно GPS, ESP32 и 3G модуль.

В целом, можно найти еще кучу всяких разных применений данной плате в embedded.

Схема платы доступна здесь:drive.google.com/drive/folders/19R66eFtCDVDVGs7P_WTTBaHTfshnIIqK

Заключение

Я считаю, что подобных ультрадешевых плат должно быть гораздо больше на рынке, ведь не все готовы платить несколько тысяч рублей за одноплатники. Однако, такие решения не подойдут для тех людей, которые хотят «купить и чтобы работало, с кучей гайдов» — у таких плат банально околонулевая поддержка. Да, Orange Pi уважаемая компания, они предоставляют полный исходный код не только ядра, но и загрузчиков — чего они делать не обязаны были, но по сути они просто произвели на свет эту плату, а разбираться в ней придется конечному пользователю. Без мануалов, без гайдов.

Стоит ли такую себе брать? Я лично не пожалел :) Плата очень перспективная, а ковыряться в исходниках ядра я люблю. Попробую сделать из неё что-то полезное!