Об 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, о чём мне и написал.

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

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

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

Об подсветку кода

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

Сейчас будет заход издалека.

Мое мнение, что сложную прикладную задачу надо решать через построение базиса/API, при помощи которого в дальнейшем и выражается вся тело программы. Обычно этот базис называют “ядром” или “моделью предметной области/прикладной моделью”
В большинстве языков такой базис реализуют на основе функций/методов, а вовсе не операторов языка.

А в самых простых “расцвечивателях” используется именно раскраска ключевых слов. И в этом весь трюк.

Если такую подсветку конструкций языка сделать ярко выделяющейся в тексте, то градация яркости кода очень хорошо показывает, где именно разработчик не в том месте решил “срезать угол” и использовал слишком низкоуровневый код в виде ключевых слов языка, а не прикладную модель. В это месте код будет насыщен ключевыми словами, а цвет его будет "ярким"

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

А больше я подсветку ни для чего и не использую.

Об Аду на контроллере и загрузку в память

Кто-то, проделав упражнения из предыдущего поста, мог втянуться в разработку и отладку. И первое, с чем вы столкнетесь при отладке - с тем, что после пересборки прошивки необходимо еще записать её на flash. Но, во-первых, с ростом размера прошивки это замедляется, во-вторых, flash изнашивается. На помощь приходит возможность ядра Cortex M4 исполнять код прямо из встроенной в чип static RAM (1). Особенность данного ядра в том, что адресное пространство SRAM находится не там же, где ROM, поэтому линковать программу надо по другому адресу.

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

ПРИЕМЛЕМО.

1. Итак, первое, что надо сделать, это собрать программу с поддержкой запуска из SRAM. Для этого достаточно передать ключ вот так:

alr build -XLOADER=RAM

Линкер выдаст предупреждение, что обнаружил секцию данных, которая содержит исполнимый код; игнорируем. А вот bin мы готовить не будем, грузить будем прямо из elf-файла, он уже содержит всю информацию о правильных адресах.

2. На борту у stm32-discovery 1Мб Flash и всего 192кб SRAM, из неё часть придется потратить под программу, поэтому нужно ещё и следить за оптимизацией кода, и за тем, чтобы не случилось переполнения памяти. Мы собираемся оптимизировать код, а также посмотреть, что там с запасом по памяти. Для этого надо немного доработать файл disco1.gpr следующим образом:

package Linker is
   for Default_Switches ("Ada") use (
      "-Wl,--gc-sections",
      "-Wl,--print-memory-usage");
end Linker;

Теперь, если собрать приложение командой выше, мы увидим следующий текст:
Memory region         Used Size  Region Size  %age Used
           flash:                  0 GB         1 MB         0.00%
          sram12:          25272 B       128 KB     19.28%
             ccm:                   0 GB        64 KB         0.00%
Обратите внимание, теперь мы не будем перетирать флэш каждый раз (flash used = 0)

3. Теперь запустим наш OpenOCD так же, как мы делали раньше, но сбросим и остановим процессор:
openocd -f board/stm32f4discovery.cfg -c "init; reset halt; arm semihosting enable;"

4. Как я и говорил, грузить будем дебаггером. Для этого в соседней консоли запустим вот какую команду.
alr exec -- arm-eabi-gdb bin/disco1 -ex 'target extended-remote localhost:3333' -ex 'load'

Отладчик загрузит прошивку, остановится на первой команде. В этой консоли надо набрать команду "cont", и переключиться на консоль OpenOCD. Если всё сделано верно, можно увидеть сообщения от исполняющейся программы, как и в предыдущей серии.

--

Итого, теперь при перекомпиляции и заливке flash-память мы не будем трогать, код будет работать из встроенной RAM кристалла. А когда понадобится опять подготовить прошивку для flash, нужно будет указать ключ -XLOADER=ROM или удалить его вовсе из строки.

(1) То, что исполнение из SRAM может быть медленнее, чем из Flash, удивительно для десктопа, но вполне нормально для некоторых чипов с эффективной подкачкой кода.