Rozruch kamery na RK3576 z użyciem systemu Linux: od sterownika czujnika do pierwszej klatki

RK3576 to procesor opracowany przez Rockchip dla zastosowań w przemyśle wizyjnym, inteligentnych systemach bezpieczeństwa oraz terminalach AI wizyjnych. Zawiera procesor sygnału obrazu (ISP) wersji V3.9 (obsługujący maksymalnie 16 MP) oraz trzy moduły odbiorników MIPI CSI-2 (dwa moduły D-PHY wersji V2.0 oraz jeden moduł C/D-PHY). Maksymalna prędkość transmisji na każdą linię D-PHY wynosi 4,5 Gbps, każdy triad C-PHY obsługuje 2,5 Gsps, a każdy port CSI obsługuje cztery kanały wirtualne.

Rozwiązanie kamery RK3576 opiera się na strukturze Linux Media oraz modelu podurządzeń V4L2-subdev. Pełna ścieżka przetwarzania danych wygląda następująco: czujnik obrazu → kontroler odbiornika MIPI CSI → jednostka przechwytywania wideo VICAP → ISP V3.9. Czujnik działa jako niezależne podurządzenie i współpracuje z MIPI CSI, VICAP oraz ISP, tworząc kompletną potokową ścieżkę pozyskiwania obrazu.

Chociaż układ RK3576 udostępnia trzy kanały odbiornika MIPI CSI, a moduł VICAP może jednocześnie odbierać wiele strumieni obrazu, sprzętowy ISP w wersji 3.9 obsługuje tylko jeden kanał i może wykonywać przetwarzanie algorytmów ISP wyłącznie na jednym strumieniu obrazu naraz.

Podczas debugowania projektu mogą wystąpić problemy, takie jak nieprawidłowa komunikacja I2C, niestabilne połączenie MIPI lub niepowodzenie utworzenia potoku multimedialnego (Media pipeline), co ostatecznie uniemożliwia wyjście pierwszej klatki obrazu. W niniejszym artykule przedstawiono kompleksowe podejście do debugowania z perspektywy realizacji inżynierskiej, które może stanowić punkt odniesienia przy debugowaniu systemów wizyjnych wbudowanych.

1. Przygotowanie sprzętu i jądra: eliminacja problemów sprzętowych niskiego poziomu przed rozpoczęciem debugowania

Podczas debugowania sterownika większość napotykanych problemów nie wynika z samego kodu sterownika, lecz z zagadnień niskopoziomowych, takich jak połączenia sprzętowe, kolejność włączania zasilania lub brak odpowiedniej konfiguracji jądra. Dlatego przed rozpoczęciem tworzenia sterownika czujnika należy najpierw sprawdzić i zweryfikować podstawowe środowisko sprzętowe oraz jądro.

Kluczowe sprawdzenia sprzętowe obejmują szyny zasilania czujnika, magistralę I2C, różnicowe łącza MIPI oraz piny GPIO do resetu i sterowania zasilaniem.

Kolejność włączania zasilania czujnika jest jednym z najważniejszych aspektów debugowania. Wiele szyn zasilania, takich jak AVDD, DOVDD i DVDD, musi ściśle przestrzegać kolejności włączania określonej przez producenta czujnika. Zbyt duże odchylenia napięć zasilania lub nieprawidłowa kolejność włączania/wyłączania zasilania mogą bezpośrednio powodować awarie komunikacji I2C oraz niestandardowe zachowanie czujnika.

Magistrala I2C: sprawdź konfigurację wielofunkcyjności pinów oraz adres podrzędny czujnika, a także upewnij się, że rezystory podciągające I2C są prawidłowo zamontowane.

MIPI: Potwierdź kanał CSI używany przez sprzęt, liczbę linii MIPI oraz dopasowanie impedancji na liniach sygnału różnicowego. Ponadto potwierdź, że zegar odniesienia czujnika (XVCLK) wyjściowy z układu RK3576 działa poprawnie.

Piny sterowania resetem/wyłączeniem zasilania: Określ logikę poziomu aktywnego (aktywny wysoki/aktywny niski) i upewnij się, że konfiguracja GPIO jest zgodna ze schematem.

Konfiguracja jądra: Sprawdź opcje jądra dotyczące podsystemu Media, urządzeń podrzędnych V4L2-subdev, kontrolera i sterowników PHY interfejsu MIPI CSI, modułu VICAP oraz ISP w wersji 3.9. Jeśli wymagany komponent nie został wbudowany w jądro lub został skompilowany jako moduł, ale nie załadował się prawidłowo, potok Media nie będzie w stanie rozpoznać sprzętu aparatu. Po skompilowaniu i wgraniu jądra najpierw sprawdź stan załadowania poszczególnych modułów sterowników. Przeanalizuj dziennik dmesg i upewnij się, że nie występują błędy, takie jak brakujące moduły lub niepowodzenia inicjalizacji.

2. Konfiguracja drzewa urządzeń (DTS): Ustalenie połączeń między urządzeniami

Drzewo urządzeń kamery RK3576: Opisuje zasoby sprzętowe i wykorzystuje węzły portów oraz punktów końcowych do powiązania łączy potoku obrazowego między czujnikiem, interfejsem MIPI CSI, modułem VICAP oraz procesorem ISP.

Węzeł czujnika jest dołączony do odpowiedniego węzła magistrali I2C i definiuje adres podrzędny I2C, pin resetu, pin sterowania trybem wyłączenia zasilania oraz odniesienia zegara czujnika. Właściwości można skonfigurować tak, aby opóźnić inicjalizację czujnika do momentu gotowości sprzętu PHY interfejsu CSI, unikając wyścigów czasowych spowodowanych niegotowością PHY. Punkt końcowy wewnątrz portu węzła czujnika wskazuje na wejście MIPI CSI i określa liczbę kanałów danych MIPI.

Węzeł kontrolera MIPI CSI zawiera dwa porty: wejście jest połączone z czujnikiem obrazu, a wyjście – z jednostką VICAP. VICAP przesyła dane obrazu do ISP V3.9. Należy pamiętać, że punkty końcowe muszą odwoływać się do siebie wzajemnie, a właściwości remote-endpoint z obu stron muszą odpowiadać sobie jeden do jednego. Jeśli powiązanie dwukierunkowe nie jest poprawne, struktura Media nie może rozpoznać pełnej ścieżki przesyłu danych. Po zmodyfikowaniu, skompilowaniu i wgraniu pliku DTS najpierw przeanalizuj dziennik dmesg, aby potwierdzić, że wszystkie węzły urządzeń są w stanie normalnym oraz że nie występują błędy związane z wielokrotnym odkładaniem sondowania. Powtarzające się odkładanie sondowania zwykle wskazuje na niepoprawną konfigurację GPIO, zegara lub zasobów zasilania.

3. Opracowanie sterownika podurządzenia czujnika: model V4L2-subdev

Sterownik czujnika platformy RK3576 został opracowany na podstawie struktury V4L2-subdev. Sterownik czujnika nie tworzy węzła /dev/video; istnieje wyłącznie jako jednostka podurządzenia multimedialnego. Jego główne obowiązki obejmują konfigurację rejestrów czujnika, zarządzanie zasilaniem i resetem, konfigurację formatu obrazu oraz kontrolę uruchamiania i zatrzymywania strumienia.

Sterownik jest głównie podzielony na pięć modułów: wykrywanie przez I2C, kontrola zasilania i resetu, tabele rejestrów trybów, konfiguracja formatu padów oraz kontrola uruchamiania i zatrzymywania strumienia.

W trakcie etapu wykrywania przez sterownik odczytywany jest identyfikator układu czujnika (Chip ID) za pośrednictwem magistrali I2C, aby sprawdzić, czy układ został prawidłowo rozpoznany. W przypadku niepowodzenia odczytu identyfikatora diagnostyka może być natychmiast skoncentrowana na usterkach sprzętowych związanych z magistralą I2C, zasilaniem oraz sygnałem resetu. Funkcje zasilania/resetu realizują pełną sekwencję włączania i wyłączania zasilania czujnika: podczas włączania kolejne szyny zasilania są aktywowane sekwencyjnie, sygnał resetu jest aktywowany przez określony czas opóźnienia, po czym sygnał resetu jest zwalniany, a czujnikowi udzielany jest czas na stabilizację wewnętrzna. Sekwencja wyłączenia zasilania wykonuje operacje odwrotne.

Tabele rejestrów trybów przechowują pełne konfiguracje rejestrów czujnika dla różnych rozdzielczości, szybkości klatek oraz szybkości MIPI. Gdy warstwa wyższa zmienia parametry przechwytywania, sterownik zapisuje odpowiadający im pełny zestaw rejestrów. Interfejs formatu pad konfiguruje format obrazu magistrali multimedialnej (media-bus), który musi ściśle odpowiadać formatowi Bayer wyjściowemu czujnika (np. BGGR lub RGGB). Nieprawidłowa konfiguracja powoduje bezpośrednio błędy kolorów obrazu. Interfejs kontroli strumienia używa polecenia stream_on do zapisywania poleceń rejestrów włączających wyjście obrazu MIPI czujnika, podczas gdy stream_off zatrzymuje przesyłanie obrazu. Po zaimplementowaniu sterownika opcje kompilacji są dodawane do plików konfiguracyjnych jądra Kconfig i Makefile, aby sterownik można było albo wbudować bezpośrednio do jądra, albo skompilować jako moduł jądra możliwy do załadowania dynamicznie.

4. Debugowanie etapowe: Uzyskanie pierwszej klatki krok po kroku

Nie zaleca się natychmiastowego podejmowania próby przechwytywania obrazu. Zastosuj wielowarstwową metodę rozwiązywania problemów w trzech etapach: potwierdź, że wykrywanie sterownika działa poprawnie → sprawdź, czy cała ścieżka przetwarzania multimediów jest prawidłowo połączona → przechwyć surowe obrazy przy użyciu V4L2.

Etap 1: Sprawdzenie, czy sterownik czujnika został poprawnie wykryty

Po uruchomieniu systemu przeanalizuj dane z polecenia dmesg i wyszukaj komunikatów dziennika generowanych przez sterownik czujnika. Użyj narzędzia i2cdetect do skanowania odpowiedniego magistrali I2C i potwierdź, czy adres urządzenia podrzędnego czujnika został wykryty.

• Jeśli żadne urządzenie I2C nie zostało wykryte: sprawdź zasilanie czujnika, logikę resetu, lutowanie sprzętu I2C oraz multipleksowanie pinów.
• Jeśli adres I2C można wykryć, ale odczyt identyfikatora układu (Chip ID) jest nieprawidłowy: ścieżka sprzętowa I2C działa poprawnie, a przyczyną problemu jest najprawdopodobniej błędny adres rejestru lub niezgodność modelu czujnika.

Etap 2: Sprawdzenie ścieżki przetwarzania w ramach struktury Media Framework

Użyj polecenia media-ctl, aby wyświetlić listę jednostek urządzeń multimedialnych. W warunkach normalnych powinny być widoczne jednostki podurządzeń, takie jak czujnik, mipi_csi, vicap oraz isp39, przy czym każdy port pad powinien zostać prawidłowo rozpoznany.

• Jeśli jednostka czujnika nie jest widoczna: próba zainicjowania sterownika czujnika zakończyła się niepowodzeniem.
• Jeśli jednostki istnieją, lecz połączenie między nimi jest rozłączone: konfiguracja dwukierunkowego sparowania punktów końcowych w pliku DTS jest niepoprawna.

Podczas debugowania polecenie media-ctl można użyć do ręcznej konfiguracji całego potoku: utworzenia połączeń między jednostkami oraz ustawienia formatu obrazu, rozdzielczości i konfiguracji kanałów dla każdej fazy podurządzenia. Błędy generowane przez media-ctl wynikają zazwyczaj z przekroczenia liczby kanałów, formatu magistrali multimedialnej (media-bus) lub parametru rozdzielczości wykraczającego poza możliwości sprzętowe czujnika. Pomyślna konfiguracja media-ctl oznacza, że ścieżka oprogramowania od czujnika do procesora ISP została poprawnie ustanowiona.

Etap 3: Przechwyć obraz za pomocą V4L2 i uzyskaj pierwszą ramkę surowych danych

VICAP/ISP generuje węzeł /dev/video, który stanowi punkt wejścia przestrzeni użytkownika do przechwytywania obrazów. Użyj polecenia v4l2-ctl, aby ustawić format pikseli obrazu, przechwycić pojedynczą klatkę za pomocą mmap i zapisać dane surowe Bayer RAW. Jeśli rozmiar wygenerowanego pliku RAW zgadza się z oczekiwaną wartością teoretyczną, pierwsza klatka obrazu została pomyślnie przechwycona. Plik RAW można następnie otworzyć w profesjonalnym narzędziu do analizy obrazów, aby sprawdzić oryginalny obraz Bayer.

5. Typowe metody rozwiązywania problemów

• polecenie media-ctl zgłasza błąd podczas konfigurowania połączenia: Najpierw sprawdź powiązanie dwukierunkowych punktów końcowych DTS, a następnie zweryfikuj parametry formatu magistrali media-bus, rozdzielczości oraz liczby linii (lane-count).
• Przechwytywanie klatek V4L2 kończy się przekroczeniem limitu czasu bez wyjściowych danych obrazu: Upewnij się, że polecenie stream_on zostało poprawnie wykonane w sterowniku, że fizyczna warstwa CSI (CSI PHY) osiągnęła blokadę sygnału zegarowego oraz że czujnik rzeczywiście przesyła strumień danych MIPI.
• Uszkodzone obrazy lub paski zakłóceń: Możliwe przyczyny obejmują nieprawidłową częstotliwość zegara MIPI, nieprawidłową liczbę kanałów (lane), niezgodność wzorca Bayera lub nadmierny szczyt napięcia na zasilaniu czujnika.
• Przerywane wyjście obrazu lub okresowe utraty klatek: Czas włączania/resetowania czujnika może nie spełniać wymagań, lub zasilanie sprzętowe może być niewystarczająco stabilne.

Posiadamy dojrzałe rozwiązanie RK3576 oraz profesjonalne kompetencje w zakresie niestandardowego rozwoju, adaptacji sprzętowej i wdrożenia masowego. Dla różnych czujników obrazu oraz wymagań dotyczących rozdzielczości/częstotliwości klatek możemy zaproponować modyfikacje sprzętu, debugowanie sterowników oraz optymalizację całego systemu, aby skutecznie wspierać projekty dostosowane do zastosowań w przemyśle wizyjnym, inteligentnych systemach bezpieczeństwa, terminalach wizji AI oraz innych obszarach. Skontaktuj się z nami pod adresem [email protected].