Серія “STM32 з нуля без HAL” • Місяць 3 • Тижні 3-4

Про що ця стаття

Привіт! Ми продовжуємо серію про STM32 без HAL і embedded Linux. В минулих статтях ми розібрали Buildroot, DTS, підключили STM32 до Luckfox через UART — і тепер Linux керує STM32 через Python. Настав час додати до системи очі — камеру.

Але тут нас чекає сюрприз. Перше що робить кожен хто хоче стрімити відео з Linux — шукає GStreamer. І саме тут Luckfox показує характер.

В цій статті ми:

• З’ясуємо чому GStreamer на Luckfox порожній — і що Rockchip використовує замість нього
• Підключимо камеру MIS5001 і пройдемо всю діагностику від dmesg до живого стріму
• Запустимо RTSP через rkipc — IP camera daemon від Rockchip
• Зменшимо затримку стріму з 10 секунд до 1
• Порівняємо з нашим першим досвідом — тоді прошивка не знала про камеру

Частина 1. Очікування vs реальність

Що ми очікували

В попередній статті про Luckfox (dou.ua/forums/topic/58244/) ми вже запускали RTSP стрім. Але тоді прошивка з коробки не знала про камеру MIS5001 — довелося перепрошивати. Тепер у нас правильна прошивка, камера є. Здається — підключай і стрімь.

Перше що спадає на думку — GStreamer. Класичний pipeline для IP камери:

Перевіряємо:

⚠ GStreamer на Luckfox порожній. Не ‘мало плагінів’ — взагалі нічого. Це не баг і не помилка конфігурації. Це архітектурне рішення Rockchip.

Чому GStreamer відсутній

Rockchip для своїх SoC (RV1106, RV1103, RK3588 та інших) використовує власний медіа стек — Rockchip MPP (Media Process Platform). Це низькорівневий API для апаратного кодування і декодування відео через вбудований VPU.

Архітектура виглядає так:

Камера (MIPI CSI) → ISP (Image Signal Processor) → VPU (кодування H.264/H.265/JPEG) → мережа

GStreamer з плагіном gstreamer1-rockchip теоретично можна зібрати через Buildroot — але це окремий квест. Офіційний образ Luckfox не включає його. Натомість є:

• Rockchip MPP — С бібліотека для прямої роботи з VPU
• rk_mpi_* утиліти — тестові програми для кожного компонента
• rkipc — повноцінний IP camera daemon від Rockchip
• sample_demo_vi_venc — зразок pipeline VI→ISP→VENC

◆ Аналогія зі STM32: замість GStreamer (стандартний інтерфейс) Rockchip дає свій HAL для медіа. Як ми писали hal_uart.c замість використання готової бібліотеки — тут теж треба знати специфічний API.

Частина 2. Камера: підключення і діагностика

Камера MIS5001

MIS5001 — 5MP MIPI CSI камера з сенсором mis5001. Підключається до роз’єму CSI на Luckfox Pico Pro. Офіційно підтримується, але тільки в нових прошивках — в старих її немає в списку сенсорів.

Підключаємо камеру і дивимося dmesg:

Без камери (стара ситуація):

sc3336 4-0030: Unexpected sensor id(000000), ret(-5)

mis5001 4-0031: Failed to get pwdn-gpios

Після підключення камери:

rockchip-csi2-dphy csi2-dphy0: dphy0 matches m00_b_mis5001 4-0031:bus type 5

rockchip-mipi-csi2 mipi0-csi2: stream ON

rockchip-csi2-dphy0: dphy0, data_rate_mbps 891

◆ ‘stream ON’ в dmesg — CSI шина активна. Сенсор відповідає. Дані йдуть від камери до ISP. Це ще не означає що відео готове — ISP треба налаштувати, але фізичний рівень працює.

IQ файли — калібрування ISP

ISP (Image Signal Processor) на RV1106 — це апаратний блок який перетворює сирий Bayer патерн з сенсора в RGB зображення. Він робить корекцію кольору, заглушення шуму, AWB (авто баланс білого), AE (авто експозиція).

Для кожного сенсора потрібен свій файл калібрування — IQ (Image Quality) файл. Без нього ISP не знає характеристики сенсора і зображення буде сірим або взагалі не з’явиться, до речі сірий муар проявляється на початку підключення, а потім відео стабілізується.

Перевіряємо наявність IQ файлів:

⚠ Якщо IQ файла для вашого сенсора нема — перепрошивайте новішим образом. Без IQ файла rkipc запуститься але зображення не буде. Це перша причина ‘камера є але відео немає’.

Перший тест: rk_mpi_vi_test

Перед запуском повноцінного стріму перевіримо чи взагалі ISP отримує кадри:

⚠ Перед кожним тестом запускайте RkLunch-stop.sh! Процес rkipc тримає камеру і блокує інші програми. Якщо не зупинити — отримаєте ‘Address already in use’ або Segmentation fault.

Успішний вивід містить:

У моєму випадку були такі рядки:

Бо /data замалий. Тож, якщо бачите ‘write fail’ — проблема з місцем на /data:

◆ Файл test_0_0_1.bin — це сирий YUV буфер з ISP. Його можна переглянути на ПК через ffmpeg: ffplay -f rawvideo -pixel_format nv12 -video_size 1920×1080 test_0_0_1.bin

Частина 3. rkipc — IP camera daemon

Що таке rkipc

rkipc — це повноцінний IP camera daemon від Rockchip. Він реалізує весь pipeline від сенсора до мережевого стріму:

mis5001 → ISP (rkaiq) → MPP (H.264 encoding) → RTSP server (порт 554)

По суті rkipc — це те що в IP камерах робить прошивка. Rockchip відкрив цей код для розробників Luckfox.

Перевіряємо чи запущений:

Проблема: неправильний конфіг

При першому запуску rkipc шукає конфіг /userdata/rkipc.ini. Якщо його нема — генерує дефолтний, який не підходить для mis5001. Симптом:

RK_MPI_VENC_GetStream timeout a004800e

Це означає що відеоенкодер не отримує кадри від ISP — неправильні параметри в ini файлі.

Знаходимо правильний конфіг для нашої камери:

⚠ /userdata на Luckfox — тільки 2.2MB. Якщо він повний (100%) — cp не спрацює. Перевіряйте: df -h /userdata. Якщо повний — видаліть старий rkipc.ini і копіюйте знову.

Копіюємо правильний конфіг:

Запуск і перевірка

Запускаємо rkipc з правильним конфігом:

Перевіряємо лог:

Успішний вивід:

Якщо бачите ‘rtsp server starting on port 554’ і немає ‘VENC_GetStream timeout’ — все працює!

◆ Перевірка портів через /proc/net/tcp: 0x022A = 554 в hex. Якщо в списку є рядок з ‘00000000:022A’ — RTSP слухає на всіх інтерфейсах. На Luckfox команда ss відсутня, netstat теж показує не все — /proc/net/tcp надійніший.

Частина 4. RTSP стрім: підключення і затримка

VLC не працює — це нормально

Перша спроба підключитися через VLC: rtsp://192.168.1.125:554/live/0

VLC видає помилку з’єднання. Це відома проблема — VLC 3.x не завжди сумісний з RTSP сервером від Rockchip. Не витрачайте час на налаштування VLC.

Проблема затримки

Перший запуск ffplay дає ~10 секунд затримки. Це буферизація — ffplay за замовчуванням накопичує великий буфер для стабільного відтворення.

Для низької затримки (~ 1 секунда):

Розшифровка параметрів:

• -fflags nobuffer — не буферизувати вхідний потік
• -flags low_delay — режим мінімальної затримки для декодера
• -framedrop — дозволяє пропускати кадри якщо не встигає

◆ Затримка 1-2 секунди — це нормально для RTSP через TCP/IP. Для нульової затримки потрібен інший протокол (наприклад WebRTC) або UDP транспорт: ffplay -rtsp_transport udp rtsp://192.168.1.125/live/0

Два потоки: /live/0 і /live/1

rkipc піднімає два RTSP потоки:

• /live/0 — основний потік, висока роздільна здатність (1920×1080 або вища)
• /live/1 — субпотік, менша роздільна здатність для мобільних клієнтів

Параметри обох потоків задаються в rkipc.ini. У нас rkipc-mis5001-500w.ini (500w = 5 мегапікселів):

cat /userdata/rkipc.ini | grep -E ‘width|height|bitrate’ | head -10

Частина 5. Архітектура: що під капотом

Повний pipeline

Тепер коли стрім працює — розберемо що відбувається всередині:

mis5001 (MIPI CSI) → rkcif (CIF driver) → /dev/video0
↓
rkaiq (ISP tuning, AWB, AE) — читає mis5001_CMK-OT2115-PC1_30IRC-F16.json
↓
|rkisp (ISP hardware) → /dev/video11 (mainpath) /dev/video12 (selfpath)
↓
rkmpp (MPP encoder) → H.264 bitstream
↓
rtsp_demo → TCP port 554 → /live/0, /live/1

Кожен блок — окремий компонент:

• rkcif — CIF (Camera Interface) driver, забирає дані з MIPI шини
• rkaiq — Rockchip AIQ (AI quality), алгоритми обробки зображення. Читає JSON конфіг
• rkisp — ISP hardware, апаратна обробка RAW → YUV
• rkmpp — Media Process Platform, апаратне кодування через VPU
• rtsp_demo — RTSP сервер, вбудований в rkipc

◆ Порівняння з STM32: pipeline камери нагадує наш bare-metal підхід. Замість того щоб дати Universal HAL (як GStreamer намагається бути), Rockchip дає прямий доступ до апаратних блоків. Більше контролю, менше абстракцій.

Де сидить відео: /dev/video*

На платі 20+ відео пристроїв. Не лякайтесь:

• /dev/video0-3 — сирий вивід з CIF (RAW Bayer дані від сенсора)
• /dev/video11 — ISP mainpath (основний вивід після обробки, YUV)
• /dev/video12 — ISP selfpath (другий вивід, менша роздільна здатність)
• /dev/video13 — ISP bypasspath
• /dev/video17-18 — ISP rawrd (зворотній шлях для RAW capture)

rkipc читає з /dev/video12 (selfpath) через rkaiq і MPP, кодує в H.264, відправляє в RTSP.

Автозапуск: RkLunch.sh

При старті системи rkipc запускається автоматично через RkLunch.sh. Цей скрипт не в стандартному /etc/init.d/ — він запускається з іншого місця (специфіка образу Luckfox).

Для зупинки перед тестами:

⚠ Ніколи не запускайте два процеси які використовують камеру одночасно. rk_mpi_vi_test, sample_demo_vi_venc, rkipc — всі вони монопольно захоплюють ISP. Завжди зупиняйте попередній перед запуском нового.

Частина 6. Порівняння: тоді і зараз

Перший досвід (стаття про Luckfox, березень 2026)

В першій статті про Luckfox (dou.ua/forums/topic/58244/) ми вже запускали RTSP стрім. Але шлях був інший:

• Прошивка з коробки не знала про MIS5001 — sensor id = 0x000000
• Довелося перепрошивати через upgrade_tool і Maskrom режим
• rkipc запустився з дефолтним конфігом і стрім якось заробив
• VLC не працював вже тоді — рятував ffplay
• Наступного дня стрім ‘зник’ — rkipc потребує ~15 сек для підняття RTSP

◆ Цікавий патерн: тоді все ‘просто запрацювало’ після перепрошивки. Тепер ми знаємо чому: правильна прошивка включає rkipc-mis5001-500w.ini в /userdata при першому запуску. Але якщо /userdata переповнений — ini не скопіюється і буде проблема.

Зараз ми розуміємо кожен крок:

• dmesg показує стан сенсора — знаємо що шукати
• IQ файли — розуміємо навіщо вони і де шукати
• rkipc.ini — знаємо який файл правильний для якого сенсора
• /proc/net/tcp замість netstat — знаємо як перевірити порти на uclibc
• MTD розділи — розуміємо що /userdata це flash 2.2MB а не tmpfs
• -fflags nobuffer — знаємо як зменшити затримку

Це і є різниця між ‘запрацювало’ і ‘розумію чому запрацювало’. За місяць роботи з Luckfox накопичився контекст який перетворює магію в інженерію.

Алгоритм діагностики: коли стрім не йде

Якщо rtsp://192.168.1.125/live/0 не підключається — перевіряйте по черзі:

1. Камера детектується? dmesg | grep -iE ‘mis5001|csi’ — шукайте ‘stream ON’
2. IQ файл є? ls /etc/iqfiles/ — має бути файл для вашого сенсора
3. rkipc запущений? ps | grep rkipc
4. Порт 554 відкритий? cat /proc/net/tcp | grep ‘022A’ — шукайте рядок з 0A (listening)
5. Лог чистий? cat /tmp/rkipc.log | grep timeout — не має бути VENC_GetStream timeout
6. Правильний ini? Порівняйте /userdata/rkipc.ini з /oem/usr/share/rkipc-mis5001-500w.ini
7. /userdata не повний? df -h /userdata — якщо 100% — відразу проблема

⚠ VLC помилка з’єднання — це не діагностика. VLC не завжди сумісний з Rockchip RTSP. Завжди перевіряйте через ffplay rtsp://IP/live/0 перш ніж робити висновки.

Підсумок

За ці два тижні ми:

• З’ясували що GStreamer на Luckfox відсутній — і це не проблема
• Підключили камеру MIS5001, навчились читати dmesg для діагностики
• Розібрали IQ файли і їх роль в роботі ISP
• Запустили rkipc з правильним конфігом і отримали RTSP стрім
• Зменшили затримку з 10 секунд до 1 через ffplay параметри
• Зрозуміли архітектуру pipeline: CSI → ISP → MPP → RTSP

Далі — NPU і face detection. Камера знімає, rkipc дає RTSP. Наступний крок: навчити систему розпізнавати обличчя і через UART давати команду STM32 вмикати реле. Повний ланцюжок від камери до фізичної дії.

А якщо хочете побачити звідки ростуть ноги — ось попередні статті серії:

• IoT PowerHub — Pi Pico + SIM800L + реле: dou.ua/forums/topic/56126/
• Luckfox від ATmega8 до відеостріму: dou.ua/forums/topic/58244/
• STM32 з нуля без HAL: серія статей на DOU

Довідники

• rkipc_camera_guide.md — референс по камері, IQ файлах і конфігах rkipc
• rockchip_mpp_cheatsheet.md — команди для роботи з Rockchip MPP стеком

Репозиторій: github.com/pipicosim800-maker/stm32F103