Интеграция Termux с аппаратными средствами Android: доступ к GPIO, I²C и SPI через libusb и пользовательские драйверы

Termux — удобная среда для запуска консольных инструментов на Android. Однако напрямую получить доступ к аппаратным интерфейсам (GPIO, I²C, SPI) бывает сложно: в Android ядро и HAL устроены так, что большинство низкоуровневых устройств открываются только через системные сервисы, права root или специализированные драйверы.

В этой статье рассмотрим практичный подход, который обычно работает в легальных сценариях разработки: вы выносите “низкоуровневый” контроль на внешнее устройство (например, USB-адаптер/микроконтроллер) и управляете им из Termux через libusb и пользовательские драйверы (в смысле: подготовка драйвера на хосте/USB-устройстве и корректная адресация устройства на стороне Linux-образа). Для Android это означает, что Termux не обязательно “лезет” в GPIO телефона, а управляет внешними интерфейсами, подключенными к USB-устройству.

Подход подходит для задач: опроса датчиков по I²C, обмена по SPI, управления линиями GPIO, регистров и протоколов (в пределах возможностей вашего USB-устройства).

Ключевая идея архитектуры

Существует два основных класса задач:

Прямой доступ к GPIO/I²C/SPI телефона через sysfs/char-dev устройства ядра. Это чаще требует root/специальных разрешений и зависит от конкретного производителя.
Косвенный доступ через USB: вы подключаете внешний модуль (например, MCU/USB-SPI/I²C мост) к телефону, а Termux управляет им через USB.

Ниже мы сосредоточимся на варианте №2, так как он реалистичнее в рамках типовой пользовательской конфигурации и устойчивее к отличиям производителей Android.

Что именно выбрать: USB-мост для I²C/SPI/GPIO

Вам нужен USB-устройство, которое умеет один или несколько режимов:

I²C (master/target — обычно master)
SPI (обычно master, с настройкой режимов и скоростей)
GPIO (как линии ввода/вывода и/или PWM — если поддерживается)

Часто такие устройства реализованы на базе контроллеров (микроконтроллер + USB) и публикуют собственный USB-протокол.

С практической точки зрения вы выбираете:

либо устройство, для которого есть готовая библиотека/утилита под Linux/USB;
либо устройство с документацией по USB-протоколу (тогда вы пишете клиентский код на Termux);
либо вы используете “универсальный” USB-bridge, где команды передаются в рамках CDC/USB HID/вендорских USB-классов.

libusb на Android в Termux: установка и проверка

Termux позволяет компилировать и использовать пользовательские программы. Для работы с USB на уровне пользовательского пространства обычно применяют libusb.

Пример типовой последовательности установки библиотек и утилит в Termux (на конкретной версии Termux пакеты могут немного отличаться):

pkg update
pkg install -y libusb clang make git

Дальше проверьте доступность USB-устройств. На Android наличие доступа зависит от настроек Termux: обычно нужен корректный режим доступа к USB (USB отладка для определенных сценариев) и разрешения, чтобы Termux видел устройства.

Проверка выполняется через утилиты, которые могут использовать libusb или через написанный тестовый код.

Проблема “видно/не видно”: доступ к USB и правила udev (идея)

На телефоне полноценный udev как на Linux может отсутствовать. Поэтому часто решают так:

внешняя сторона (ПК/сервер Linux) обрабатывает USB и предоставляет сервис по сети в адрес Termux;
либо на стороне Termux есть доступ к нужным узлам /dev/bus/usb (если устройство открывается пользователем или группой);
либо используется адаптер/посредник, который “перехватывает” USB и экспонирует управление на более простом интерфейсе.

Практический и надежный путь: если задача сложнее, чем простая отправка коротких команд, вы организуете локальный мост по сети между ПК (Linux с полноценным libusb+udev) и Termux (как клиент). Важно: речь идет о создании локальной сети для обмена управляющими командами, а не об обходе блокировок.

Вариант A (часто самый надежный): ПК как USB-хост, Termux как клиент

Если USB-устройство корректно работает на Linux-компьютере, то на ПК вы:

подключаете USB-модуль;
проверяете его идентификаторы (VID/PID);
пишете/запускаете сервис, который читает/пишет команды через libusb;
экспонируете API (локальный порт) на локальную сеть;
из Termux отправляете запросы в этот сервис.

Схема архитектуры:

USB (GPIO/I²C/SPI) → ПК (libusb service) → Wi‑Fi локальная сеть → Termux (клиент)

На ПК (примерно на уровне идеи) вы будете использовать libusb для обмена с USB устройством. Команды зависят от протокола конкретного моста.

Поиск VID/PID и базовая верификация

На Linux хосте обычно используют утилиты уровня udev/lsusb:

lsusb

Далее фиксируете VID/PID и проверяете доступность устройства. В реальном проекте это сопровождается правилами доступа (udev) и проверками, что процесс запускается с нужными правами.

Вариант B: Termux напрямую управляет USB-мостом

Если ваш Android-профиль/ядро позволяет открыть USB узлы доступно пользователю, вы можете делать полностью “в телефоне”. Однако стабильность зависит от устройства и версии Android, а также от того, насколько корректно Termux получает доступ к /dev/bus/usb.

Для начала — простой тест: перечисление устройств через libusb. Ниже — концептуальный шаблон на C (вам придется адаптировать к вашей среде и API, т.к. интерфейсы и версии библиотек могут отличаться):

// pseudo-example (шаблон). Реализуйте согласно вашей версии libusb
#include <libusb-1.0/libusb.h>
#include <stdio.h>

int main() {
  libusb_context ctx = NULL;
  libusb_device** list = NULL;

  libusb_init(&ctx);

  ssize_t cnt = libusb_get_device_list(ctx, &list);
  printf("devices=%ld
", (long)cnt);

  for (ssize_t i = 0; i < cnt; i++) {
    libusb_device dev = list[i];
    struct libusb_device_descriptor desc;
    libusb_get_device_descriptor(dev, &desc);
    printf("VID=0x%04x PID=0x%04x
", desc.idVendor, desc.idProduct);
  }

  libusb_free_device_list(list, 1);
  libusb_exit(ctx);
  return 0;
}

Компиляция:

clang test.c -o test -lusb-1.0

После успешного перечисления переходите к открытию конкретного устройства по VID/PID и дальнейшим командам согласно документации моста.

Протоколы команд: как “GPIO/I²C/SPI” становятся сообщениями

Важный момент: libusb — это транспорт (USB уровнем). “GPIO, I²C, SPI” реализуются уже на стороне вашего USB-моста. Термины “доступ к GPIO/I²C/SPI” в этом подходе означают, что ваш мост умеет соответствующие действия и вы отправляете ему команды.

Обычно протокол выглядит так:

вы выбираете устройство через endpoint’ы (bulk/interrupt/control);
формируете командный пакет (набор байтов);
отправляете OUT;
читаете IN (ответ/данные);
повторяете при необходимости.

Для I²C чаще всего вы задаете адрес устройства, длину чтения/записи, опционально регистры и формат повторного старта.

Для SPI задаете:

частоту (или прескалер/делитель);
режим (CPOL/CPHA);
битность (обычно 8);
набор байтов MOSI и ожидаемую длину MISO.

Для GPIO обычно задаете mask/направление и значение, либо отдельно пишете “set/clear” и “read”.

Точки интеграции в Termux: управление из Python/Go/Bash

Практически удобный путь в Termux — написать клиент на Python (через bindings libusb) или использовать готовые утилиты, если они есть. Если вы используете Python, то часто проще:

держать VID/PID в конфиге;
закладывать таймауты;
вводить уровень логирования;
делать повторные попытки при ошибках обмена USB.

Если ваш USB-мост предоставляет простую текстовую оболочку или CDC-соединение — вообще можно уйти от libusb в пользу серийного протокола. Но раз вы указали именно libusb и пользовательские драйверы, предполагаем встраивание в USB-клиент.

Пользовательские драйверы: что подразумевают на практике

В контексте “пользовательских драйверов” для Android чаще всего подразумевается следующее:

на ПК/хосте — написание минимального daemon/сервиса (user-space драйвер), который общается с USB устройством;
или на телефоне — пользовательская программа, которая реализует протокол USB-моста;
и в обоих случаях — подготовка прав/правил доступа (на Linux-хосте это udev, в Android — разрешения доступа к устройствам).

Смысл в том, что вы не пытаетесь “переписать” ядро Android, а строите контроллер в user space.

Безопасность, стабильность и типовые ошибки

Таймауты: USB read/write могут зависать при ошибках линии. Всегда задавайте таймауты и контролируйте ретраи.
Скорость обмена: слишком высокая частота SPI или слишком частые операции I²C могут приводить к NACK/ошибкам на мосту.
Очередность команд: некоторые мосты требуют явного “lock”/“start transaction”.
Инициализация: обязательно делайте handshake/инициализацию интерфейса после подключения.
Железная совместимость: проверьте уровни логики (3.3V/5V) и общую землю GND.

Минимальный пример CLI на Termux (концепт)

Ниже пример формы команды, которую можно использовать в вашем окружении после того, как вы реализовали клиентский модуль на Python/Go/C. Это не привязано к конкретному мосту, но показывает подход: CLI → USB-протокол → ответ.

# Пример: отправить команду чтения I²C по регистру
termux-i2c --vid 0x1234 --pid 0xabcd --bus i2c-1 --addr 0x68 --reg 0x75 --len 1

В реальном проекте названия опций и формат пакетов будут зависеть от вашего USB-моста.

FAQ по интеграции GPIO/I²C/SPI с Android из Termux

1) Можно ли получить GPIO именно телефона?
Иногда — но это зависит от ядра, поддержки драйверов и прав. На практике для большинства проектов надежнее управлять внешним USB-мостом.

2) Нужен ли root?
Не всегда. Если Termux/Android позволяет доступ к USB узлам и устройство не требует системных прав, root может не быть. Если доступ ограничен — используйте вариант с ПК-хостом.

3) Почему именно libusb?
libusb дает прямой user-space доступ к USB устройствам и хорошо подходит для протоколов, не поддерживаемых стандартными Android-сервисами.

4) А что насчет VPN?
Если вы организуете соединение между ПК и Termux по сети, используйте VPN только для создания локальной сети и безопасного обмена данными. Не используйте VPN для обхода блокировок.

Заключение

Интеграция Termux с аппаратными интерфейсами Android (GPIO, I²C, SPI) наиболее практична через внешний USB-мост: Termux управляет устройством через libusb, а пользовательские “драйверы” реализуются как user-space сервис/клиент, который передает команды протокола мосту. Такой подход снижает зависимость от различий ядра Android и упрощает поддержку.

Если вам нужен готовый стэк под ваш конкретный USB-мост (VID/PID, endpoints, формат команд) или помощь с архитектурой “ПК-хост + Termux-клиент”, обращайтесь в РыбинскЛАБ — поможем спроектировать, внедрить и отладить решение под ваши задачи.