Esp32

Зачастую в процессе разработки собственных устройств или моддинга уже существующих, встаёт задача выполнения стороннего кода: будь то ваши собственные программы с SD-флэшек, или программы, написанные другими пользователями с помощью SDK для вашего устройства. Тема компиляторов и кодогенерации достаточно сложная: чтобы просто загрузить ELF или EXE (PE) программу, вам нужно досконально разбираться в особенностях вашей архитектуры: что такое ABI, релокации, GOT, отличие -fPIE от -fPIC, как писать скрипты для ld и т. п. Недавно я копал SDK для первых версий Symbian и основываясь на решениях из этой ОС понял, каким образом можно сделать крайне «дешевую» загрузку любого нативного кода практически на любом микроконтроллере, совершенно не вникая в особенности кодогенерации под неё! Сегодня мы с вами: узнаем, что происходит в процессе загрузки программы ядром Linux, рассмотрим концепцию, предложенную Symbian Foundation и реализуем её на практике для относительно малоизвестной архитектуры — XTensa (хотя она используется в ESP32, детали её реализации «под капотом» для многих остаются загадкой). Интересно? Тогда добро пожаловать под кат!

❯ Как это работает?

Думаю, для многих моих читателей реализация процесса загрузки exe-программ и dll-библиотек в память процесса оставалась эдаким чёрным ящиком, в детали реализации которого вдаваться не нужно. Отчасти это так и есть: современные ОС разруливают процесс загрузки бинарников в память сами, не требуя от программиста вообще ничего, даже понимания того, куда будет загружена его библиотека или программа.

Давайте для общего понимания вкратце разберемся, как происходит загрузка программ в Windows/Linux:

1. Система создаёт процесс и загружает в память программы секции из ELF/PE. Обычные программы для своей работы используют 3 секции: .text (код), .data (не-инициализированный сегмент памяти для глобальных переменных), .bss (сегмент памяти для инициализированных переменных). Каждому процессу выделяется собственное адресное пространство, называемое виртуальной памятью, которое не позволяет программе испортить память ядра, а также позволяет не зависеть от разметки физической памяти на выполняющей машине. Концепцию виртуальной памяти реализует специальной модуль в процессоре, называемый MMU.

2. Если бы наши программы не использовали никаких зависимостей в виде динамических библиотек, то на этом процесс загрузки можно было бы закончить: каждая программа имеет свой адрес загрузки, относительно которого линкер строит связи между обращениями к коду/данным программы. Фактически, для самых простых программ линкеру остаётся лишь прибавить адрес загрузки программы (например, 0x100) к каждому абсолютному обращению к памяти.
Однако современные программы используют десятки библиотек и для всех предусмотреть собственный адрес загрузки не получится: кто-то где-то всё равно будет пересекаться и вероятно, портить память. Кроме того, современные стандарты безопасности в Linux рекомендуют использовать позиционно-независимый код, дабы использовать преимущества ASLR (Address Space Layout Randomization, или простыми словами возможность загрузить программу в случайное место в памяти, дабы некоторые уязвимости, завязанные на фиксированном адресе загрузки программы перестали работать).

3. Поэтому для решения этой проблемы придуман т. н. динамический линкер, который уже на этапе загрузки программы или библиотеки патчит программу так, чтобы её можно было загрузить в любой участок памяти. Для этого используются данные, полученные от обычного линкера а этапе компиляции программы: помимо .text, .data и .bss, линкер создаёт секции .rel и .rel-plt, которые называются релокациями. Если объяснять совсем условно, то релокации — это просто запись вида «какой абсолютный адрес в коде программы нужно пропатчить» -> «на какое смещение его пропатчить». Самая простая релокация выглядит вот так:

Где по итогу:

.rel-plt же служит для резолвинга вызовов к dll/so: изначально программа ссылается на заранее определенные в процессе компиляции символы, которые уже в процессе загрузки патчатся на физические адреса функций из загруженной библиотеки.

И казалось бы — всё очень просто, пока в дело не вступают GOT (Global Offset Table — глобальная таблица смещений) и особенности реализации конкретного ABI. И ладно бы x86 или ARM, там всё разжевано и понятно, однако на других архитектурах начинаются проблемы и не всегда очевидно что и где за что отвечает.

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

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

2. Зарезервировать определенный сегмент в памяти (пусть с 0xFFF по 0xFFFF) и скомпилировать нашу программу с адресом загрузки 0xFFF с параметром -fno-pic. В таком случае, линкер сгенерирует обращения к памяти по абсолютным адресам — если переменная лежит по адресу 0xFFF, то программа будет обращаться сразу к этому адресу памяти, без необходимости что либо динамически линковать. Именно такой подход использовался во времена ZX Spectrum, Commodore 64 и MS-DOS (однако там роль «виртуальной памяти» выполняла такая особенность 8086, как сегменты). У такого подхода есть и минусы: относительная невозможность загрузки сразу нескольких программ одновременно, зарезервированное пространство линейно отъест небольшой кусок памяти у основной прошивки, нет возможности динамической аллокации секций. Зато такой код теоретически будет работать быстрее, чем PIC.
   
   Проблемы реализации такого способа: иногда нужно лезть в систему сборки основной прошивки и патчить скрипт линкера так, чтобы он не трогал определенный регион памяти. В случае esp32, например, это требует патча в сам SDK и возможного «откола» от мейнлайн дистрибутива.

3. Использовать программу с относительной адресацией, однако без сегментов .bss и .data. Самый простой в реализации способ, который к тому же очень экономичен к памяти, позволяет загружать программу в любое место и пользоваться всеми фишками динамического аллокатора и не требует вмешательств в основную прошивку, кроме примитивного загрузчика программ. Именно его я и предлагаю рассмотреть подробнее.

Недавно мы сидели в чате ELF-сцены (разработка нативных программ под телефоны Siemens, Sony Ericsson, Motorola и LG с помощью хаков) и думали, как же можно реализовать загрузчик сторонних программ на практически неизвестных платформах. Кто-то предлагал взять ELF под основу — однако с его реализацией под некоторые платформы есть трудности, а кто-то предлагал писать «бинлоадер» — самопальный формат бинарников, который получается из, например, тех же эльфов.

В это же время я копал SDK для Symbian и хорошо помнил, что в прикладных приложениях для этой ОС нет поддержки глобальных переменных вообще. Да, сегмент .data и .bss полностью отсутствует — переменные предлагается хранить в структурах. Почему так сделано? Всё дело в том, что каждая программа в Symbian — это dll-библиотека, которую загружает EKA и создаёт экземпляр CApaApplication. И дабы была возможность загрузить dll один раз для всех программ (что справедливо для системных библиотек), ребята полностью выкинули возможность использования любых глобальных переменных. А ведь идея интересная!

Однако в таком подходе есть несколько серьезных ограничений:

• Отсутствие глобальных переменных может стать проблемой при портированиии уже существующего софта, хотя вашим программам ничего не мешает передавать в каждую функцию структуру с глобальным стейтом, который можно при необходимости изменять. Кроме того, нет ограничений на использование C++ (за исключением необходимости ручной реализации new/delete и отсутствием исключений).

• Отсутствие преинициализированных данных. Вот это уже может стать относительно серьёзной проблемой, у которой, тем не менее, есть свои обходные решения. Например если вы храните команды для инициализации дисплея в таблице, или какие-либо калибровочные данные — вы не сможете их объявить, просто используя инициализаторы в C. Тоже самое касается и строковых литерал. Тут есть два варианта: часть таблиц можно вынести на стек (если эти самые таблицы достаточно маленькие), либо подгружать необходимые данные из бинарника с помощью основной прошивки (например, LoadString и т. п.).

Давайте же на практике посмотрим, имеет ли право на жизнь такой подход!

❯ Практическая реализация

Формат нашего бинарника будет до безобразия прост: небольшой заголовок в начале файла и просто сырой дамп сегмента .text, который можно экспортировать из полученного elf даже без необходимости писать скрипт для линкера. При этом нужно учесть, что ESP32 — это микроконтроллер частично Гарвардской архитектуры, т. е. шина данных и кода у него расположены отдельно. Однако у чипа есть полноценный MMU, который позволяет маппить регионы физической памяти в виртуальную память, чем мы и воспользуемся в итоге!

Заголовок нашего бинарника будет выглядеть вот так:

Программа общается с основной прошивкой посредством псевдо-syscall'ов: функции, которая в качестве первого аргумента ожидает номер нужной службы и один 32х-битный указатель для описания структуры с параметрами. Реализация syscall'ов — одна из самых простых и неприхотливых с точки зрения обратной совместимости с будущими прошивками.

Концептуально всё очень просто: GetGlobalStateSize сообщает нашему загрузчику размер структуры для хранения глобального стейта, в то время как Start уже фактически заменяет main() в нашей программе. Необходимости в crt0 нет, поскольку весь необходимый инит выполняет бутлоадер ESP32. Впрочем, при желании вы можете выделить отдельный стек для вашей программы — это повысит надежность, если выполняемая программа удумает испортить стек.

Собираем нашу программу:

-fno-pic отключает генерацию кода, зависимого от GOT, -nostdlib и -nostartfiles убирает из билда crt0 и stdlib, благодаря чему мы получаем только необходимый код. --section-start задает смещение для загрузки секции .text на 0x0 (в идеале это делать необходимо из скрипта для ld).
objcopy скопирует из полученного ELF только необходимую нам секцию .text.

Как же это работает на практике? Давайте дизассемблируем выходной бинарник и посмотрим, что у нас дает на выхлопе cc:

Обратите внимание, что Start вызывает подфункции с помощью инструкции CALLX8, которая в отличии от обычного Immediate-версии CALL8, выполняет переход относительно текущего адреса в PC, благодаря чему переход полностью независим от адреса загрузки программы в памяти. А благодаря тому, что все данные, в том числе и указатель на глобальный стейт передаются через стек, нет необходимости релокейтить сегменты данных.

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

1. Загрузить программу в IRAM. Такая возможность теоретически есть, однако на практике загрузчик ESP32 устанавливает права только на чтение и выполнение на данный регион памяти. Попытка что-то скопировать туда закончится исключением SIGSEGV. Кроме того, сегмент IRAM относительно небольшой — всего около 200Кб.

2. Самопрограммирование. Для этого, в esp32 есть два механизма — Partition API и SPI Flash API. Я выбрал Partition API для простоты реализации.

Для нашей прошивки необходимо будет переразметить флэш-память. Для этого запускаем idf.py menuconfig, идём в Partition Table -> Custom partition table CSV. Создаём в папке проекта partitions.csv, куда пишем:

# ESP-IDF Partition Table
# Name, Type, SubType, Offset, Size, Flags
nvs, data, nvs, 0x9000, 0x6000,
phy_init, data, phy, 0xf000, 0x1000,
factory, app, factory, 0x10000, 1M,
executable, data, undefined, 0x110000, 0x10000

Для заливки программы можно использовать соответствующее Partition API, либо parttool.py:

Переходим к загрузчику программы:

Прошиваем ESP32:

И смотрим результат:

Всё работает!

❯ Заключение

Как видите, ничего сложного в выполнении сторонних программ при условии соблюдении некоторых ограничений нет. Да, в таком подходе есть как серьезные плюсы, так и минусы, однако он делает своё дело и позволяет реализовать запуск игр на кастомных игровых консолях, или сторонних программ на самодельных компьютерах. Ну и конечно же не стоит забывать про плагины! Авось в вашем решении нужна возможность расширения функционала устройства, однако предоставлять исходный код или даже объектные файлы нет возможности — тогда вам может пригодится и такая методика.

Пожалуй, стоит упомянуть ещё один… очень своеобразный метод, который я иногда встречаю при реализации самодельных компьютеров. Люди пишут… эмуляторы 6502/Z80 :)
И если такой подход ещё +- применим к ESP32, то в AVR просадки производительности будут слишком серьезными. Так зачем, если можно использовать все возможности ядра на максимум?

В старой гирлянде было крайне неудобно включать/выключать подсветку и переключать режимы. Это же необходимо встать с дивана, подойти к устройству, нажать кнопку. Соответственно, в новой системе необходимо реализовать управление через мобильный телефон. Так же, стоит учесть, что в моём доме ёлка стоит около окна, и будет видно сразу две гирлянды. Соответственно, стоит предусмотреть возможность обмена данными между этими гирляндами для возможности синхронизации режимов. Причём, синхронизация должна быть не "приколоченной намертво", а вполне себе опциональной.

Подбор железа

Исходя из ТЗ становится очевидно, что достаточно просто поменять контроллер с старой-доброй атмеги на что-то из семейства ESP. Эта система на кристалле (да, именно так её называет производитель, SoC) из коробки имеет на борту достаточно шустрое ядро, WiFi и приличный объём памяти. Но, имеет место быть небольшой конфликт: рабочее напряжение пинов ESP 3.3В. А напряжение питания WS2812b составляет от 3.5 до 5.3В, исходя из даташита. Причём, "протокол" передачи данных для светодиодов подразумевает формирование прямоугольных испульсов, кодирующих 24 бита цвета для каждого светодиода. Уровень "0" в этой последовательности должен быть <0.3VDD (напряжение питания), уровень "1" >0.7VDD.

Я покопался в своих закромах и обнаружил две платы Wemos D1 mini (на базе ESP8266) и одну плату LOLIN S2 mini (на базе ESP32-S2). Обе платы имеют всю необходимую обвязку для подключения внешнего питания 5В и подтягивающие резисторы для запуска МК. Там же, в закромах родины нашёл весьма удобные макетные платы под форм-фактор этих устройств.

Это снимает проблему согласования напряжения питания ESP и WS2812b. Но возникает опасение, что уровень логической "1" от контроллера будет недостаточным для формирования управляющего сигнала. Ведь, согласно даташиту, уровень "1" >0.7VDD. А питание светодиодов у нас 5В, соответственно, требуемый уровень логической единицы равен 0,7 * 5 = 3,5В. Тут я пошёл по пути экспериментов, быстренько набросал схемку на бредборде и проверил, а как оно, заведётся, или нет. Ведь, исходя из моего опыта общения с контроллерами семейства STM32, уровня 3.3В должно быть вполне достаточно. И оно завелось!

Подбор ПО

Очевидно, что прошивка будет самописная. Надеяться, что вот сейчас я зайду в гугл, забью "прошивка ESP8266 с моими требованиями" и все найдётся и заработает достаточно наивно. Да и неспортивно это. В случае с ESP есть два основных фреймворка для написания прошивки. Профессиональный ESP-IDF с его ориентированностью на чистый С и Arduino IDE с ядром ESP. Причём второе - это, по сути своей, обёртка вокруг ESP-IDF. Так как у меня была хоть и ущёрбная, но рабочая прошивка для Arduino Nano, написанная в Arduino IDE, я остановился на втором варианте.

Этап второй. Практическая реализация в железе.

Схема в общем виде выглядит так:

Ничего сложного и интересного. Единственное, для одной из систем одна из кнопок была заменена на устройство bme280, работающее по протоколу I2C. Интересно отслеживать влажность в помещении и уровень давления. Показания температуры врут безбожно: датчик находится слишком близко к ESP, которая имеет привычку сильно нагреваться. Спаять устройство по этой схеме не представляет ничего сложного. Но ведь хочется сделать всё красиво. А значит нужен корпус для устройства и система крепления гирлянды. С корпусом всё довольно просто. Минут 30 в Компас3D, час работы 3D принтера и в руках корпус, подогнанный под конкретное спаянное устройство. Магия термоклея, и на выходе получается вполне себе симпатичный прибор:

С системой крепления всё чуточку интереснее. Если на ёлку крепить гирлянду не требуется (просто берём и обматываем гирлянду вокруг дерева), то на окно требуется крепёж. Тут возможно реализовать два варианта: установить гирлянду непосредственно перед окном, но за шторой. Тогда праздничное настроение будет создано людям, гуляющим на улице и смотрящим на мой седьмой этаж. Либо размещать гирлянду перед шторой. Тогда праздничное настроение будет у всех, находящихся в комнате. Я пошёл по второму пути. Штора крепится на гардину с Т-образными пазами. И вновь на помощь приходит компас и 3D-принтер. В каждой точке, из которой спускается светодиодная гирлянда была изготовлена вот такая сборка из двух деталей:

Бонусом, такая конструкция хорошо фиксирует сборки проводов, и конструкция получается довольно добротной. Следующей "железной" проблемой стало то, что провод со светодиодами достаточно лёгкий, и гирлянда отказывалась висеть вертикально. И вновь 3D принтер спасает положение. Я напечатал несколько тематических грузиков, и привязал их на тоненькие верёвочки. Получилось весьма достойно:

Этап третий. Программное обеспечение aka прошивка

А вот прошивку не скину в чистом виде. Только если кто-то хочет повторить - могу ему слить данное поделие. Ибо в коде есть ряд проблем, которые пока не решены.

Принцип работы системы прост до ужаса. Намертво зашиты константы с SSID/PASS моей локальной WiFi сети и IP адреса всех гирлянд, участвующих во взаимодействии. Arduino IDE хорош, в первую очередь, невероятным количеством библиотек. Итак, что есть сейчас, и для чего используется.

1. Разумеется, WiFi, для подключения к локальной сети. SSID и пароль забиты в дефайны, что есть хардкод, и вообще моветон

2. FastLED для управления WS2812b. Реализован простейший алгоритм отслеживания потребляемого гирляндой тока и ограничение оного к возможностям источника питания. Работает, на мой взгляд, лучше встроенного в библиотеку.

3. WebServer для поднятия странички управления гирляндой, если сильно лень подходить и нажимать кнопку. Я не сильно дизайнер, но страничка получилась довольно простой и информативной.

4. UDP для общения между гирляндами. Да, я знаю, что есть ненулевой шанс потери данных, поэтому пришлось реализовать достаточно простой алгоритм проверки корректности пришедших данных. Битые пакеты отбрасываются. Вроде бы это не очень хорошо, но я тут не космический корабль запускаю, и не ядерным реактором управляю. Если синхронизация произойдёт на 100мс позже, то ничего страшного. Хардкод в данном случае - IP-адреса гирлянд, участвующих в обмене информацией, жестко прописанные в роутере.

5. ArduinoOTA. Лень каждый раз подключать ESP напрямую к компу, когда хочется что-то поменять в прошивке. А так всё выходит просто: обновились по воздуху, и радуемся.

В качестве гирлянды-мастера выбрана ёлочная. На её страничке можно поставить галочку с требованиями синхронизации остальных гирлянд, и её режим будет транслироваться всем остальным.

В сухом остатке получилось несколько устройств, на которые не стыдно посмотреть, которые не стыдно показать и которые работают и радуют глаз. Возможно, когда разберусь с текущими проектами - вернусь к доработке гирлянд. Избавиться от хардкода, что не очень сложно и чуть улучшить синхронизацию (заставить гирлянду-мастера передавать не только свой текущий режим, но и конкретный тик из millis() для более эффектного внешнего вида) и всё, пожалуй. Сделать полноценное Android-приложение, управляющее гирляндами. Возможно, имеет смысл сделать отдельный сервер на полновесной ESP32, который собирал бы данные с гирлянд, и синхронизировал их при необходимости. Но это уже вопрос полноценного самописного умного дома, т.к. к такому серверу можно подключить любое устройство на базе ESP. Для работы с MQTT так же есть полноценные библиотеки. В общем, проект получился достаточно простым, но интересным с точки зрения возможности масштабирования.

На этом всё, спасибо, что дочитали. Ссылок на телегу не будет, это всё от лукавого :)