Об remoteproc

В комментариях к предыдущему посту (https://t.me/architect_says/501) задают резонный вопрос: если Atmega не успевает даже вовремя выполнять деление, как вообще писать более-менее производительный код? Ну, как -- брать более мощный процессор. Правда, с этим начинаются нюансы.

Так уж вышло, что на борту нашего изделия есть многоядерный ARM, который было бы неплохо заиспользовать для этой задачи. Учитывая, что основные вычисления у нас ведет аппаратный ускоритель, кажется, что процессор мог бы нам помочь рисовать OSD.

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

Во-первых, там установлен linux. Как заставить его забыть про 1 процессорное ядро, а на него повесить выделенную активность вне ОС -- это вопрос отдельного исследования. Да, есть Xenomai, есть китайский RROS, но всё равно это задача непростая.

Второе, и более сложное: несмотря высокую производительность ARM-ядра Cortex-Axx, оно менее детерменировано: тактовая частота в доменах плавает и троттлится, шиной доступа к периферии управляет арбитр, конвейер живет своей жизнью, как и механизм кэша, контроллер прерываний сам по себе сложнее, чем К580.
Между прочим, за одну микросекунду экран съезжает на 10 пикселей, мы себе не можем позволить дрожание (=неопределенность в обработке прерывания) даже в 500 нс.

Для решения такой ситуации ограниченными аппаратными средствами используется выделенное микроконтроллерное ядро, доступное как периферия и простое: никаких кэшей, никаких конвейеров, фиксированная частота, выделенный коммутатор шины: по сути, это микроконтроллер внутри процессора. Например, таким ядром оборудованы SoC Amlogic, TI или Allwinner. Иногда его могут назвать типа Power management core. Здорово, что в linux kernel начинают появляться зачатки подсистемы работы с ним: https://docs.kernel.org/staging/remoteproc.html

Работа с таким ядром ~~темна и полна ужасов~~ полна неожиданностей и "ОКР" (можно расшифровать как угодно). Слышал даже, что по этой причине некоторые поступающие к нам по параллельному импорту 😏 чипы остаются с отключенным ним, потому что на это просто нет документации, которую вендор передает за деньги и только особо избранным.

По многим китайским системам такая документация не только закрытая, но еще и есть исключительно на китайском.

..

СМОЖЕТ ЛИ НАШ ГЕРОЙ РЕШИТЬ ЭТУ ПРОБЛЕМУ? УЗНАЕМ В СЛЕДУЩИХ СЕРИЯХ

Об микросервисы в который разНу, хорошо, всем продали микросервисы: дескать, и устройство системы понятнее из-за них, и two pizza team вообще стандарт в Гугл ИТ, значит, и нам надо тоже. И код можно писать на самом подходящем языке: хочешь, пишешь на php, не хочешь, пишешь на nodejs, что очень удобно (особенно потом сопровождать комплекс, написанный на 10 языках). А еще можно переписать за две недели маленький микросервис, любой. Ну круто же, правда?! А еще архитектура очень отказоустойчивая, и если один сервис упал, то остальные выживут (на практике - не работает никогда). И самое главное - можно МАСШТАБИРОВАТЬ приложения! О том, что монолит тоже можно масштабировать, тем более сейчас, когда железо ничего не стоит, молчат.

Но это все selling points для недоверчивых технарей, а я расскажу, почему на самом деле бизнес выбирает микросервисы. Причин всего две:
1. Быстрая проверка гипотез, которые в 9 из 10 случаев проваливаются - да, продакт-менеджеры тоже не боги. В случае монолита вы стоите перед непростым выбором: или вкладываться по полной в эксперимент (дизайн, код, тесты), который, скорее всего, будет выброшен, или на коленке слепить то, что рискует выстрелить, и тогда с этим поделием придется жить вечно в монолите. Какой вариант хуже? Оба хуже. В случае с микросервисами эксперименты не сильно трогают ядро системы, которая кормит всю компанию и их семьи.
2. Найм. В ситуации, когда средней компании найти хорошего разработчика за праздник, в случае микросервисной архитектуры можно нанимать вообще любых программистов, которые подвернулись, а не те, которые подходят по стеку или согласны работать с легаси и т.п.

Эти две причины пересиливают все сложности, связанные с МСА. А сложностей немало, от оркестрации до смены парадигмы владения системами.

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

На последней TeamleadConf один из докладчиков пожаловался на то, что на их микросервисное монорепо, все писанное на Go, перестало хватать разработчиков -- буквально вот не могут найти на рынке, конкуренция жёсткая даже между командами внутри (ха-ха, кто мог подумать? Вот бы кто-то об этом раньше написал!)

А я в связи с этим предлагаю вспомнить один пост из этого канала трехлетней давности, из которого становится ясно, почему делать микросервисы, но все писать на одном языке (а монорепо значит с вероятностью 99% и моноязык) это потенциальная глупость и ошибка 👇

Об GPIO в линуксах

Как вы знаете, некоторые время назад в линуксе декомиссовали управление GPIO через псевдо-ФС /sysfs. Несмотря на то, что поддержка в целях совместимости сохраняется, использовать это ни в коем случае не надо. Вместо этого предлагается символьное устройство, на большинстве дистрибутивов это /dev/gpiochipX и ядерный интерфейс uapi к нему. А чтобы воспользоваться интерфейсом, лучше всего использовать libgpiod.

Если в Raspberry PI этот момент разобран достаточно подробно, то наш дорогой Xulong предоставил владельцев Orange PI самим себе, опубликовав только wiringOP и байндинги к разным языкам, который еще и работает из-под рута. И если в дистрибутиве Orange OS про i2c как-то подумали и есть инструкции, то про GPIO api там вообще ничего нет. Ну и ничего, мы справимся, щас покажу как.

Сначала надо поставить libgpiod посвежее подходящей версии. У меня Ubuntu 22.04, я качал предсобранный архив отсюда https://raw.githubusercontent.com/devdotnetorg/docker-libgpiod/HEAD/out/libgpiod-bin-2.1.2-ubuntu-22.04-aarch64.zip Но у автора есть шелл-скрипт, который позволит и версию выбрать, и собрать из исподников, если надо. Скачанное просто нужно распаковать в /usr как есть.

Дальше я поставил библиотеку для питона вот такой командой:
LINK_SYSTEM_LIBGPIOD=1 pip install gpiod
Переменная окружения тут говорит, что не надо тащить с собой никакие библиотеки, надо брать, что в системе есть.

По умолчанию доступ к GPIO есть только из-под рута, поэтому чтобы обычный юзер получил доступ, потребуется слегка настроить udev. Доступ необходимо дать к устройству, отвечающему за нужный вывод ( /dev/gpiochipX). Как определить нужное устройство в Orange Pi, тоже есть нюанс.

Открываем распиновку платы в документации, скажем, вывод (pin) 27 помечен как GPIO1_A0. Надеюсь, вы не активировали альтернативные функции — UART, I2C, SPI — в device tree через orangepi-config на этот вывод, и он доступен (проверьте командой gpio readall, рядом не должно светиться ALTx). GPIO1_A0 расшифровывается так:
1 - чип
A - банк выводов (A= 0, B = 1, C.., D..)
0 - номер вывода в банке.
Номер чипа = 1, номер линии (понадобится потом) = 8 * номер_банка + номер вывода. В моем случае chip = 1, line = 0, пригодится.

Делается это в моём случае так:

sudo groupadd gpiod sudo usermod \-aG gpiod orangepi sudo echo '\# udev rules for gpio port access through libgpiod SUBSYSTEM=="gpio", KERNEL=="gpiochip1", GROUP="gpiod", MODE="0660"' > /etc/udev/rules.d/61\-gpiod.rules

gpiochipX=gpiochip1, потому что у меня chip=1. После перезагрузки у пользователя orangepi, как состоящего в группе gpiod, будет доступ к нужному контроллеру.

Теперь в вашем скрипте управления умным изделием можно сделать так:

import gpiod from gpiod.line import Direction, Value LINE = 0 request = gpiod.request\_lines("/dev/gpiochip1", consumer="example", config={LINE: gpiod.LineSettings(direction=Direction.OUTPUT, output\_value=Value.ACTIVE)}) \# ... request.set\_value(LINE, Value.ACTIVE) \# .. request.set\_value(LINE, Value.INACTIVE)

Если есть дополнения, то пишите тоже.

Об OSD

Если вы умеете не только в цифровое, но и в аналоговое радио, то сделать прототип векторного OSD для своей fpv-камеры не составит труда. Кое-что добавить на экран с картинкой с композитного видео не помешает. Следующим постом я покажу картинку со схемой, а тут приведу описание. Что нам нужно для работы простого монохромного OSD - суметь в правильный момент вмешаться в формирование строки и кадра, и подтянуть напряжение в нужных точках на нужное время к питанию (это будет белая точка или к земле — это будет черная). Для того, чтобы это сделать, хватит atmega на кристалле 16 Мгц и несколько ширпотребных радиодеталей. Я буду рисовать белым.

Сначала из входного сигнала надо отсечь положительное смещение, потому что у разных камер оно разное, это делается конденсатором C1. После этого на R1 и D1 собрана схема восстановления положительной составляющей, которая поднимает сигнал до нужного нам уровня. На R2 и D2 собран генератор референсного напряжения порядка 0.56В. D1, D2 у меня это дешевые импульсные диоды 1N4148.

В итоге мы получаем на входе Comparator-A сигнал, который каждую строку и каждый кадр проседает до примерно 0.3В. Теперь потенциометром R3 на входе Comparator-B можно задать примерно 0.3 вольта, а на atmega настроить аналоговый компаратор, чтобы он генерировал прерывание по сравнению двух входов. В итоге мы получим, что в обработчике прерывания у нас есть момент начала гасящего импульса строки или кадра. Таймером мы считаем время, пока компаратор не вернется в исходное, и понимаем, это был ССИ или КГИ, и выставляем у себя переменные.

Итого, мы имеем номер строки на экране, понимаем начало кадра — и далее в обработчике прерывания компаратора осталось отработать эту информацию и нарисовать развертку. С таким медленным чипом, как Атмега, это непросто, и работать надо в реальном времени, так что лишего бюджета времени во время рисования линии нет даже на операцию настоящего деления - настоящее деление занимает 1/20 кадра по горизонтали — так что приходится пользоваться битовыми сдвигами или предрасчитывать ранее.

Собственно, зная, что нужно изобразить в данной точке строки экрана, загоняем соответствующие байты в SPI регистр. SPI на atmega, как вы помните, может разгоняться аж до половины тактовой частоты кристалла, и на каждый такт на выходе из него будет появляться бит, начиная со старшего. 1 будет рисовать белый участок линии, 0 — оставит картинку как есть. Чтобы
На частоте кристалла в 16МГЦ это позволит рисовать только сдвоенные пиксели относительно максимального разрешения PAL, то есть около 340 пикселов на экранную строку, но и это неплохо. Разрешение в 300+ линий по высоте остается. Самое сложное тут будет посчитать тайминги — каждая машинная операция идет в зачет, писать придется на Си или Ассемблере.

Кажется, мы тут применили знания из десятка разных предметов. А еще говорят, что программистам математика, физика, электроника не нужны..

Что рисовать на экране? Это уже что фантазия предложит. Кому-то нужны линии уровня, кому-то текст — для текста надо будет реализовать свой знакогенератор. Я добавил i2c-интерфейс, чтобы управлять картинкой при помощи SMBus-протокола.

Дальше будет принципиальная схема.

Об мышиное зрение

В связи с появлением у меня Intel Core Ultra 155H решил попробовать оседлать NPU, встроенный в него. Для тестирования использовал модельки YOLO, потому что они достаточно понятно написаны на Питоне, а также могут быть легко экспортированы во множество форматов.

Что касается inference — работает без проблем, всё ускоряется в 2-3 раза по сравнению с голым cpu таргетом. Для компиляции и запуска я использовал OpenVINO и готовую модель, датасеты для которой стащил с сайта Roboflow и все сразу заработало в дефолтной конфигурации.

Что касается обучения, то результат хуже.

Само по себе YOLO не умеет использовать для обучения ускорители, кроме CUDA (похоже). Есть некие проекты вроде:
1. Intel extensions for pytorch (ipex) - для CPU и XPU (дискретная карта Intel)
2. intel-npu-acceleration-library (npu)
3. DirectML для ускорения операций при помощи любого железа, поддерживающего opencl
4. Разные опенсорсные поделки, приземляющие openCL на железо.

Из всего этого списка я смог разобраться только со вторым пунктом, так что YOLO успешно стало тренироваться с загрузкой NPU на 35-50%. Также хочу еще попробовать п.1 для CPU. Как использовать встроенный iGPU для обучения я пока не нашел способов.

Результатом NPU я, скорее, недоволен — обучение ускоряется всего на 20-25% относительно голого CPU в моей конфигурации. С учетом перспектив п.1 с расширениями для CPU, которые потенциально могут ускорить итерации вдвое, NPU не выглядит как подходящий бэкенд для тренировки — видимо, сказывается недостаточное количество блоков в архитектуре. А вот запуск натренированной сетки — ускоряет заметно.

Про ipex напишу еще, если что-то получится.

Пересидели React; надо найти еще немного сил пересидеть горячку с Go

Об искусственный интеллект

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

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

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

Спустя два дня переговоров с оператором и такой-то матери ссылку удалось исправить и переотправить.

Будующее такое яркое..