TECHNO BROTHER

❯ Что за станции такие – «НеоТерм»?

У саратовской компании «Магистр» целая линейка симпатичных паяльных станций «НеоТерм». Отличаются они составом и количеством инструмента, который можно одновременно к ним подключать.

Ранее я приобрёл трёхканальную станцию «НеоТерм-3Т».

Два паяльника позволяют работать одновременно с другом.

Или паять сразу в две руки, для чего я их и взял. Это очень удобно, особенно для демонтажа:

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

Кроме того, в паяльники можно вставить разные жала:

В один побольше, в другой поменьше. Для ювелирных работ это может быть полезным.
Часто бывают ситуации, когда нужно залудить что-то (например, тоненький проводок), а потом сразу припаять к крохотному разъёму с мелким шагом, который только и ждёт, чтобы засосать соплю между своими маленькими выводами.

Делать это одним паяльником не очень удобно: для лужения хорошо бы взять на жало побольше припоя, а для ювелирной пайки, наоборот, почти полностью убрать припой. У разъёмов обычно много выводов, и эти операции чередуются. Гораздо удобнее лудить и паять отдельными паяльниками.

Если паять вдвоём всё-таки скучно, то можно выбрать станцию с тремя паяльниками («НеоТерм-3С»).

И паять не только в две руки, но и левой ногой.

Вместо двух паяльников можно подключить вот такой термопинцет.

Термозачисткой можно снимать изоляцию.

Станцией я доволен.

❯ Что внутри?

Когда в руки попадает какой-нибудь приборчик, всегда интересно, что там у него внутри.
Снимаем переднюю панель.

На передней панели установлена основная плата с микроконтроллером STM32F071RBT6, энергонезависимой памятью 24LC02B-I/SN, пищалкой, экраном, кнопками и прочей мелочёвкой.

Питается станция от тороидального трансформатора ПКФЛ 671113.678ш мощностью 148 ВА, изготовленного белорусским предприятием «Юджэн».

Кроме управляющей платы есть ещё силовая. Все выводы трансформатора подключены к этой плате. На ней интересных деталей уже побольше: беленькие оптопары MOCD207R2M, 3 пары транзисторов (IRF7493 и IRFH6200), разъёмы для термоинструментов, 2 ОУ OP07C и разная мелочь.

❯ Как же работает управление нагрузкой?

Можно заметить, что транзисторы включены попарно и встречно – любопытненько! Вооружившись мультиметром срисовываем схему, приводим её в понятный читаемый вид (показана только одна из вторичных обмоток трансформатора).

Заодно можно помоделировать в Spice симуляторе.

Пусть на выводе 7 обмотки плюс, а на выводе 6 минус (положительная полуволна). Ток через R2, диод VD1 и обратный диод ключа VT2 заряжает конденсатор С1.

По каналам ключей VT1, VT2 ток не течёт, так как они закрыты.
Постепенно накопительный конденсатор С1 заряжается до напряжения, равного амплитуде синусоиды минус падение на диоде VD1 и обратном диоде транзистора VT2.

Теперь можно использовать заряд этого конденсатора для открывания полевых транзисторов. Если открыть транзистор оптопары U1B, то ключи VT1, VT2 откроются и ток нагрузки потечёт через них.

Закрыть транзисторы VT1, VT2 можно открыванием оптопары U2B, которая разрядит ёмкости затворов.

Посмотрим на графики SPICE модели. Сверху видим ток нагрузки и напряжение на ней. А также Напряжение на обмотке трансформатора, питающей схему. По центру – короткие прямоугольные импульсы открывания и закрывания (подаются на светодиоды оптопар U1B и U2B соответственно). Снизу приведены напряжения сток-исток VT1 и VT2.

Что здесь происходит?

1. В обмотке трансформатора положительная полуволна, напряжение нарастает. Напряжение сток-исток ключа VT1 так же нарастает, а вот напряжение на ключе VT2 остаётся низким. Почему так происходит? Дело в том, что диод ключа VT2 при такой полярности открыт, а диод VT1 закрыт. Если поменять полярность полуволны, то состояния их диодов поменяются местами.

2. Даём короткий импульс на открывающую оптопару, открывая её на время длительности импульса. Этого достаточно, чтобы зарядить ёмкости затвором зарядом из С1 и открыть транзисторы.

3. Транзисторы VT1, VT2 открыты (напряжения сток-исток на них малы).

4. Даём короткий импульс на закрывающую оптопару, открывая её на время длительности импульса. Этого достаточно, чтобы разрядить ёмкости затворов и закрыть транзисторы.

5. Транзисторы закрыты. Диод ключа VT1 закрыт, а VT2 открыт.

Такое управление похоже на фазовое управление тиристорами (симисторами), но здесь мы можем закрыть транзисторы в любой момент, а не ждать, пока напряжение анод-катод уменьшится до нуля и тиристоры (симисторы) закроются сами.

Значительный плюс – малое сопротивление канала полевого транзистора, по сравнению с сопротивлением открытого тиристора или симистора. Посмотрим на график из даташита транзистора IRFH6200.

При 4 В затвор-исток сопротивление канала в районе 1 мОм. При токе 50 А будет падение 50 мВ. У тиристора прямое падение напряжения на участке анод-катод будет более 1 В. Например, у тиристора CLA50E1200HB при 50 А будет падение 1,25 В.

У более низковольтного КУ202Г максимальное напряжение в открытом состоянии указано 1,5 В. 1500 мВ/50 мВ=30 раз. Разница значительная.

Стабилитрон VD2 на 12 В защищает затворы транзисторов от превышения напряжения. Резистор между затвором и истоком препятствует самопроизвольному открыванию и поможет закрыть транзисторы, если контроллер вдруг отвалится.

Зачем диод VD1? Представим, что его нет. Тогда накопленный в С1 при положительной полуволне заряд утёк бы из конденсатора во время отрицательной полуволны.

Вот такая любопытная схема. Очень интересное, простое и красивое схемное решение, на мой взгляд.

Мы рассмотрели схему управления нагрузкой в канале термозачистки. Аналогичным образом управляются паяльники в двух других каналах.

Хороший инструмент есть – время творить!

Зачастую в процессе разработки собственных устройств или моддинга уже существующих, встаёт задача выполнения стороннего кода: будь то ваши собственные программы с 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 просадки производительности будут слишком серьезными. Так зачем, если можно использовать все возможности ядра на максимум?