Schnittstellenbeschreibung

Lüfter

Der reComputer RK3576 stellt die Lüftersteuerung über das Linux-Subsystem hwmon bereit. Die Lüfterdrehzahl kann in Echtzeit ausgelesen werden, und der PWM-Tastgrad kann entweder manuell gesetzt oder dem automatischen Thermal-Governor überlassen werden.

Hardware-Monitor-Pfade

SchnittstellePfadBeschreibung
Lüfterdrehzahl/sys/class/hwmon/hwmon6/fan1_inputAktuelle Drehzahl (U/min)
PWM-Wert/sys/class/hwmon/hwmon6/pwm10–255, steuert den Tastgrad
PWM-Modus/sys/class/hwmon/hwmon6/pwm1_enable0=aus 1=manuell 2=automatisch

Thermal-Zonen

ZonePfad
SoC/sys/class/thermal/thermal_zone0/temp
Big Core/sys/class/thermal/thermal_zone1/temp
Little Core/sys/class/thermal/thermal_zone2/temp
DDR/sys/class/thermal/thermal_zone3/temp
NPU/sys/class/thermal/thermal_zone4/temp
GPU/sys/class/thermal/thermal_zone5/temp

Temperaturwerte werden in Millicelsius angegeben — dividiere durch 1000, um °C zu erhalten.

Lüfterdrehzahl auslesen

bash
cat /sys/class/hwmon/hwmon6/fan1_input

Die Ausgabe erfolgt in U/min. Beispiel: 2161

Alle Temperaturen auf einmal auslesen:

bash
for zone in /sys/class/thermal/thermal_zone*; do
    name=$(cat $zone/type)
    temp=$(( $(cat $zone/temp) / 1000 ))
    echo "$name: ${temp}°C"
done

Lüfterdrehzahl steuern

  1. In den manuellen Modus wechseln:
bash
echo 1 | sudo tee /sys/class/hwmon/hwmon6/pwm1_enable
  1. PWM-Wert setzen (0–255):
PWM-WertUngefähre Drehzahl
0Lüfter aus
64~25%
128~50%
192~75%
255Volle Drehzahl
bash
# Auf 50% einstellen
echo 128 | sudo tee /sys/class/hwmon/hwmon6/pwm1
  1. Automatische Thermosteuerung wiederherstellen:
bash
echo 2 | sudo tee /sys/class/hwmon/hwmon6/pwm1_enable

Skript für automatische Thermosteuerung

Dieses Skript passt die Lüfterdrehzahl basierend auf der SoC-Temperatur an und läuft fortlaufend im Hintergrund.

bash
#!/bin/bash
TEMP_SENSOR="/sys/class/thermal/thermal_zone0/temp"
PWM_ENABLE="/sys/class/hwmon/hwmon6/pwm1_enable"
PWM_VALUE="/sys/class/hwmon/hwmon6/pwm1"

echo 1 > $PWM_ENABLE

while true; do
    TEMP=$(( $(cat $TEMP_SENSOR) / 1000 ))

    if   [ $TEMP -lt 40 ]; then PWM=50
    elif [ $TEMP -lt 50 ]; then PWM=100
    elif [ $TEMP -lt 60 ]; then PWM=160
    elif [ $TEMP -lt 70 ]; then PWM=210
    else                        PWM=255
    fi

    echo $PWM > $PWM_VALUE
    echo "$(date '+%H:%M:%S') Temp: ${TEMP}°C  PWM: $PWM"
    sleep 5
done

Als fan-control.sh speichern und ausführen:

bash
chmod +x fan-control.sh
sudo ./fan-control.sh

Im Hintergrund ausführen:

bash
sudo nohup ./fan-control.sh > /var/log/fan-control.log 2>&1 &

systemd-Dienst

  1. Skript kopieren:
bash
sudo cp fan-control.sh /usr/local/bin/fan-control.sh
sudo chmod +x /usr/local/bin/fan-control.sh
  1. Dienstdatei erstellen:
bash
sudo tee /etc/systemd/system/fan-control.service << 'EOF'
[Unit]
Description=Fan Speed Controller
After=multi-user.target

[Service]
Type=simple
ExecStart=/usr/local/bin/fan-control.sh
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target
EOF
  1. Aktivieren und starten:
bash
sudo systemctl daemon-reload
sudo systemctl enable fan-control
sudo systemctl start fan-control
sudo systemctl status fan-control

Kurzreferenz

bash
# Lüfterdrehzahl auslesen
cat /sys/class/hwmon/hwmon6/fan1_input

# SoC-Temperatur auslesen
echo "$(( $(cat /sys/class/thermal/thermal_zone0/temp) / 1000 ))°C"

# Volle Geschwindigkeit
echo 1 | sudo tee /sys/class/hwmon/hwmon6/pwm1_enable
echo 255 | sudo tee /sys/class/hwmon/hwmon6/pwm1

# Niedrige Geschwindigkeit
echo 1 | sudo tee /sys/class/hwmon/hwmon6/pwm1_enable
echo 64 | sudo tee /sys/class/hwmon/hwmon6/pwm1

# Automatik wiederherstellen
echo 2 | sudo tee /sys/class/hwmon/hwmon6/pwm1_enable

Getestete Umgebung

ElementWert
GerätreComputer RK3576 DevKit
BetriebssystemLinux 6.1 (Debian-basiert)
hwmon-Schnittstelle/sys/class/hwmon/hwmon6 (pwmfan)
Lüfterdrehzahl im Leerlauf~2155 U/min
SoC-Temperatur im Leerlauf~36°C

LED-Statusanzeigen

Dieses Gerät verfügt über drei fest verbaute LED-Anzeigen (Power, Status und User) auf der Frontblende. Diese LEDs ermöglichen es Nutzern, die Einschaltsequenz der Hardware zu überwachen, das Laufzeitverhalten des Systems zu beobachten und eine vollständig programmierbare Schnittstelle für eigene Software-Interaktionen zu nutzen.

image24.png

  • LED-Zustände und Standard-Hardwareverhalten Mit der werkseitigen System-Firmware zeigen die LEDs während des Boot-Vorgangs und im laufenden Betrieb folgendes Standardverhalten:

  • Wichtig für Entwickler: Steuerungsgrenzen Bevor du mit der Weiterentwicklung beginnst, ist es entscheidend, die zugrunde liegende Hardware-Verdrahtung jeder LED zu verstehen, um unnötige Fehlersuche zu vermeiden:

  • Power-LED (Rot): Reine Hardwaresteuerung. Diese LED ist fest mit der Hauptstromschiene verdrahtet. Es gibt keine GPIO- oder Kernel-Schnittstelle, die mit ihr verbunden ist. Sie kann nicht über Software oder Befehle gesteuert werden.

  • Status-LED (Grün): Hardwaresteuerung auf Systemebene. Diese LED wird physisch von der zugrunde liegenden Hardware-Power-Management-Logik bzw. der PMIC-Firmware gesteuert, um die Kernstabilität des Systems widerzuspiegeln. Sie stellt dem Linux-Userspace keine Schnittstelle zur Verfügung und kann nicht über Software oder Befehle gesteuert werden.

  • User-LED (RGB-Dreifarb): Vollständig durch Entwickler steuerbar! Hierbei handelt es sich um eine RGB-LED-Kapsel, die mit dem integrierten GPIO-Expander (gpiochip6) verdrahtet ist. Sie ist die einzige Anzeige am Gerät, die für eigene Programmierung und Software-Automatisierung offen ist. Standardmäßig belegt das System den blauen Kanal (USER_LED_B) als Heartbeat-Anzeige, während der rote und der grüne Kanal ungenutzt bleiben.

  • Anleitung zur Steuerung der User-RGB-LED In der Linux-Umgebung (z. B. Armbian) wird empfohlen, für die Ansteuerung des ungenutzten roten und grünen Kanals die moderne gpiod-Toolchain (gpioinfo / gpioset) zu verwenden und für die Steuerung des blauen Kanals die Standard-sysfs-Schnittstelle von Linux. LED lokalisieren Im System werden LEDs über die sysfs-Schnittstelle verwaltet. Führe den folgenden Befehl aus, um den LED-Knoten zu überprüfen:

bash
ls /sys/class/leds/user-led

Erwartete Ausgabe :

image26.png

Manuelle Steuerung (EIN/AUS) Bevor du die LED manuell steuerst, musst du ihren Trigger-Modus auf none setzen.

bash
echo none | sudo tee /sys/class/leds/user-led/trigger

LED EIN-/AUSSCHALTEN

bash
# Einschalten
echo 1 | sudo tee /sys/class/leds/user-led/brightness
# Ausschalten
echo 0 | sudo tee /sys/class/leds/user-led/brightness

Automatisierte Trigger-Modi Der Kernel stellt verschiedene Trigger bereit, um das LED-Verhalten anhand von Systemereignissen zu automatisieren.

bash
# Heartbeat-Modus
echo heartbeat | sudo tee /sys/class/leds/user-led/trigger
# Benutzerdefinierter Timer-Modus (Blinkend)
# Timer aktivieren
echo timer | sudo tee /sys/class/leds/user-led/trigger
# Intervalle festlegen
echo 500 | sudo tee /sys/class/leds/user-led/delay_on
echo 500 | sudo tee /sys/class/leds/user-led/delay_off

Dauerhafte Konfiguration beim Booten Da Änderungen unter /sys flüchtig sind und nach einem Neustart zurückgesetzt werden, kannst du sie dauerhaft machen, indem du einen Cronjob hinzufügst oder rc.local verwendest.

Taste

Die Mainboards der reComputer-RK3576-Serie sind mit 3 fest verbauten physischen Tasten ausgestattet, die vor allem für die Stromsteuerung und das Low-Level-Firmware-Flashen genutzt werden.

image27.png

Hinweis: Achte beim Flashen über Recovery oder MaskROM darauf, dass der Type-C-OTG-Port des Geräts über ein Datenkabel mit dem Host-PC verbunden ist. Für die Durchführung der Vorgänge benötigst du die offiziellen Rockchip-Tools (z. B. RKDevTool für Windows oder upgrade_tool für Linux).

GPIO

Das Mainboard verfügt oben über eine standardmäßige 40-polige Erweiterungsleiste, die Entwicklern einen umfassenden Satz an Low-Level-Hardwareschnittstellen bietet. Dazu gehören Stromversorgung, Debugging sowie gängige industrielle Kommunikationsbusse (I2C, UART, SPI, CAN usw.), wodurch sich externe Sensoren und Treiberplatinen einfach anschließen oder Debugging auf Systemebene durchführen lässt.

image29.png

40-Pin-Pinout-Tabelle

GPIO-Nutzung Standardmäßig fungieren die meisten Pins der 40-Pin-Leiste als Standard-GPIOs, sofern sie nicht bereits von Systemtreibern belegt sind. Für die Ansteuerung auf Shell-Ebene wird das Standard-gpiod-Toolset (gpiodetect, gpioinfo, gpioset, gpioget) empfohlen. Um physischen Pin 21 anzusteuern (der als allgemeiner GPIO spezifiziert und derzeit frei ist):

  • Zugehörigen Controller und Leitungsnummer ermitteln:
bash
sudo gpioinfo | grep -i PIN_21

Ausgabe:

text
line 14:     "PIN_21"       unused   input  active-high

Das zeigt, dass er zu gpiochip1, Leitung 14 gehört.

  • Pin auf High setzen (z. B. eine LED einschalten):
bash
gpioset gpiochip1 14=1
  • Pin auf Low setzen:
bash
gpioset gpiochip1 14=0
  • Eingangsstatus von physischem Pin 27 auslesen: Die Abfrage sudo gpioinfo | grep -i PIN_27 zeigt, dass er auf gpiochip4, Leitung 23 abgebildet ist:
bash
gpioget gpiochip4 23

Um die spezialisierte Peripherie-Hardware (I2C, UART, CAN, PWM), die auf dem Pinout gekennzeichnet ist, freizuschalten, musst du das zugehörige Device Tree Overlay (DTBO) explizit aktivieren. Andernfalls funktionieren die Pins weiterhin nur als gewöhnliche GPIOs. Alle spezifischen Overlay-Konfigurationen für die 40-Pin-Leiste befinden sich unter /boot/dtb/rockchip/overlay/ und folgen strikt dem Namenspräfix recomputer-rk3576-devkit-40pin-:

Konfigurationsablauf:

  • Öffne die Systemumgebungs-Konfigurationsdatei:
bash
sudo nano /boot/armbianEnv.txt
  • Suche die Zeile overlays= (oder füge sie ans Ende der Datei an, falls sie fehlt) und trage den gewünschten Overlay-Namen ohne die Endung .dtbo ein. Trenne mehrere Overlays durch ein Leerzeichen:
text
overlays=recomputer-rk3576-devkit-40pin-i2c3 recomputer-rk3576-devkit-40pin-can0
  • Speichere und beende (Ctrl+O, Enter, Ctrl+X) und starte die Hardware anschließend neu, um die Device-Tree-Änderung zu übernehmen:
bash
sudo reboot

Hinweis: SPI standardmäßig aktiv

Die SPI-Bus-Pins (Pins 19, 21, 23, 24, 26) sind beim Booten standardmäßig aktiviert. Du musst KEIN eigenes DTBO für SPI in armbianEnv.txt zuweisen.

Gemeinsam genutzte Hardware-Architektur: Die physischen SPI-Signale der 40-Pin-Leiste teilen sich denselben Hardware-Busdomänenbereich mit den integrierten 4G-LTE-/LoRaWAN-/Hailo-Wi-Fi-Erweiterungssteckplätzen. Um für diese Kommunikationsmodule eine sofort einsatzbereite Erfahrung zu ermöglichen, hält das Basisbetriebssystem diesen SPI-Kanal dauerhaft aktiv.

Entwicklerempfehlung: Wenn du eigene SPI-Breakout-Boards von Drittanbietern an die 40-Pin-Erweiterungsleiste anschließt, achte sorgfältig auf die Handhabung von Chip Select (CS) und Adressierung, um Deadlocks auf dem Kommunikationsbus mit den integrierten Modulen zu vermeiden.

USB

Dieses Gerät verfügt über mehrere physische USB-Schnittstellen, die der reComputer-RK3576-Serie zugeordnet sind. Diese Schnittstellen dienen dem Anschluss externer Peripheriegeräte, dem Flashen der System-Firmware (OTG) und der Ausgabe an ein zweites Display.

Die Zuordnung der USB-Ressourcen ist wie folgt definiert:

Schnittstellenposition / BeschriftungPhysischer FormfaktorBusprotokoll & maximale BandbreiteHardwarespezifikation & Controller-Routing
USB 3.0 HostUSB Type-AUSB 3.2 Gen 1x1 (5 Gbps)Über den internen USB-3.0-Controller geroutet. Bietet Hochbandbreiten-Datenkanäle, optimiert für USB-3.0-Industriekameras, NVMe-Speichererweiterungen oder Hochgeschwindigkeits-DAQ-Module.
USB 2.0 HostUSB Type-A (mehrfach)USB 2.0 (480 Mbps)Wird vom USB-2.0-Host-Controller verwaltet. Für Standardperipherie wie Tastaturen, Mäuse, 4G/5G-Mobilfunkmodems, Hardware-Verschlüsselungs-Dongles oder USB-zu-UART-Bridge-Boards.
USB Type-CUSB Type-CUSB 3.0 / 2.0 OTG + DP 1.4 Alt ModeEin Multiprotokoll-Kombiport, der zum RK3576-USB-3.0-OTG-Controller und zur DisplayPort-(DP)-TX-PHY geroutet ist. Unterstützt bidirektionale Host-/Device-Rollen und Hardware-Videostreaming.

Mit lsusb kannst du Informationen zu den am System angeschlossenen USB-Geräten anzeigen:

image34.png

Hinweis: Architektur der USB-Type-C-Schnittstelle

A. System-Flashing & Wartung (USB-OTG-Gerätemodus): Über die Tasten Recovery / MaskROM ausgelöst, bootet der Port in den Gerätemodus für Low-Level-Firmware-Flashing mit RKDevTool.

B. DisplayPort-Ausgabe (DP 1.4 Alt Mode): Multiplext Hardware-Videokanäle, um über Type-C-Kabel oder Adapter direkt einen Monitor anzusteuern und Standard-DP-1.4-Displays zu bedienen.

C. Standard-Native-Host-Modus: Fungiert im normalen Betriebssystembetrieb standardmäßig als USB-3.0-Host, um direkt mit Type-C-Speichermedien, Netzwerkadaptern oder Hubs zu kommunizieren.

SD-Kartensteckplatz

Das Mainboard verfügt über einen standardmäßigen Micro-SD-(TF)-Kartensteckplatz, der direkt an den SDMMC0-Bus des RK3576-SOC angebunden ist. Diese Schnittstelle wird vor allem zum Systemstart, zum Betrieb des Betriebssystems (z. B. Armbian OS) und zur lokalen Datenspeicherung genutzt.

image35.png

Sofort einsatzbereit Das Gerät wird standardmäßig mit einer im Lieferumfang enthaltenen 32-GB-Micro-SD-Karte der Klasse 10 ausgeliefert. Diese Karte hat die strengen Kompatibilitätstests von Seeed Studio bestanden und ist dem alltäglichen Betrieb von Armbian OS, grundlegenden Netzwerkkonfigurationen und der Validierung leichtgewichtiger Edge-KI-Algorithmen problemlos gewachsen, sodass Entwickler sofort loslegen können.

Hinweis: Boot-Priorität & Speicher-Hinweise

Boot-Prioritätsmechanismus (MaskROM-Stufe): Die Firmware-Bootsequenz des RK3576 wird strikt vom Low-Level-MaskROM gesteuert. Wenn sowohl auf der Micro-SD-Karte als auch im integrierten eMMC bootfähige Firmware vorhanden ist, lädt das MaskROM vorrangig den SPL (Secondary Program Loader) von der Micro-SD-Karte. Achte bei Firmware-Upgrades oder beim Wechsel zwischen mehreren Betriebssystemen genau auf diese physische Eigenschaft.

NVMe-Boot-Einschränkung (U-Boot-Stufe): M.2-NVMe-SSDs liegen NICHT im direkten MaskROM-Boot-Pfad. Das System kann den initialen Stage-1-Boot nicht direkt von einem rohen NVMe-Laufwerk ausführen. Um das Betriebssystem von einer NVMe-SSD zu starten, muss das System zunächst den Bootloader entweder auf der Micro-SD-Karte oder dem eMMC ausführen, um in die U-Boot-Stufe zu gelangen; dort initialisiert und lädt U-Boot dann das auf dem NVMe-Speicher liegende Hauptbetriebssystem und übergibt die Kontrolle an dieses.

Empfehlungen für Upgrades bei hoher Auslastung: Wenn du Anwendungen mit hochfrequenten I/O-Lese-/Schreibanforderungen am Edge einsetzen möchtest (etwa den Betrieb großer Datenbanken mit fortlaufendem lokalem Logging oder die Verwaltung komplexer Docker-Container-Cluster), kann die enorme Menge an zufälligen 4K-Lese-/Schreibzugriffen die Leistungsgrenze einer Standard-Klasse-10-Karte erreichen. Für solche anspruchsvollen industriellen Szenarien empfehlen wir, das Root-Dateisystem des Kern-Betriebssystems auf eine M.2-NVMe-SSD zu migrieren (per U-Boot-Chain-Loading) oder auf eine leistungsstarke Micro-SD-Karte umzusteigen, die explizit für A1 oder A2 (Application Performance Class) zertifiziert ist, um eine optimale Systemreaktionsfähigkeit sicherzustellen.

Mount-Punkt: In Armbian OS wird die Micro-SD-Karte typischerweise als /dev/mmcblk0 eingebunden.

SIM-Kartensteckplatz

Das Mainboard verfügt über einen fest verbauten Kartensteckplatz, der explizit für den Einsatz mit 4G-LTE-Mobilfunkmodulen im Mini-PCIe-Steckplatz konzipiert ist. Durch das Einsetzen einer Standard-SIM-Karte eines Mobilfunkanbieters kann das Gerät in Umgebungen ohne kabelgebundenes Ethernet eine Edge-to-Cloud-Mobilfunkverbindung herstellen.

image36.png

Hardware-Architektur & Mechanismus Die Signalleitungen des Nano-SIM-Steckplatzes sind direkt mit den entsprechenden Pins (wie UIM_PWR, UIM_DATA, UIM_CLK, UIM_RESET) des Mini-PCIe-Steckplatzes verbunden.

  • Keine direkte Verbindung zum SOC: Beachte, dass die SIM-Kartensignale nicht direkt mit dem RK3576-SOC verbunden sind. Stattdessen werden sie vollständig vom 4G-Modul im Mini-PCIe-Steckplatz verwaltet und angesteuert. Folglich funktioniert die SIM-Karte nur, wenn ein kompatibles 4G-Modul aktiv ist.

Hinweis: Entwicklerhinweise & Betriebsstandards

Striktes Verbot von Hot-Plugging: Setze die SIM-Karte immer nur ein oder entferne sie, wenn das Gerät vollständig ausgeschaltet ist (Gleichstromversorgung bzw. PoE getrennt). Hot-Plugging der SIM-Karte bei laufendem System kann die SIM-Schnittstelle des 4G-Moduls dauerhaft beschädigen oder netzwerkbedingte Systemabstürze verursachen.

Formfaktor-Spezifikationen: Dieser Steckplatz unterstützt ausschließlich Nano-SIM-Karten (4FF), die kleinste Standardgröße moderner Smartphones. Vermeide die Verwendung von Micro- oder Standard-SIM-Karten mit billigen Kunststoffadaptern, da diese leicht steckenbleiben oder die internen Pins des Steckplatzes verbiegen können.

Einsetzrichtung: Prüfe vor dem Einsetzen das Siebdrucksymbol oder die strukturelle Kerbe in der Nähe des Steckplatzes. Üblicherweise wird die SIM-Karte mit den goldenen Kontakten nach unten und der abgeschrägten Ecke voran eingesetzt (bitte an der physischen Ausrichtungsmarkierung auf der Platine orientieren).

M.2-Key-M-2280-Steckplatz

Das Mainboard verfügt über einen standardmäßigen M.2-Key-M-2280-Steckplatz, der über einen PCIe-2.1-x1-Bus angesteuert wird. Er ist für Hochgeschwindigkeits-Speichererweiterungen oder die Beschleunigung von Edge-KI-Berechnungen konzipiert.

image37.png

Unterstützte Geräte

  • NVMe-SSD: Unterstützt Standard-2280-NVMe-SSDs für den Systemstart, die Speicherung großer Datenmengen oder die Aufnahme großer KI-Modelle.
  • KI-Beschleuniger: Kompatibel mit KI-Beschleunigermodulen im M.2-Key-M-Format zur Verbesserung der Edge-Inferenzleistung.

Getestete & verifizierte Geräte Um optimale Kompatibilität und Systemstabilität sicherzustellen, empfehlen wir dringend die Verwendung von M.2-Erweiterungsmodulen, die vollständig von Seeed Studio getestet und verifiziert wurden:

Hinweis:

Protokollkompatibilität: Dieser Steckplatz unterstützt ausschließlich PCIe-NVMe-Geräte. M.2-SATA-SSDs werden NICHT unterstützt und vom Betriebssystem nicht erkannt.

Bandbreitenbeschränkung: Der Steckplatz arbeitet mit einer PCIe-2.1-x1-Lane und bietet eine theoretische maximale Bandbreite von etwa 500 MB/s. Beim Kauf einer NVMe-SSD genügen kostengünstige Standard-Gen3/Gen4-Laufwerke; ultraschnelle Gen4-SSDs werden durch die PCIe-2.1-x1-Schnittstelle ausgebremst.

Formfaktor: Der Montageabstandshalter ist speziell für 2280-Module (22mm x 80mm) ausgelegt.

Anleitung zur SSD-Nutzung

bash
lsblk

image38.png

Anleitung zu Hailo-YOLOv11-Deployment & -Inferenz

Paketinstallation Nach der Installation des grundlegenden PCIe-Treibers ist ein Systemneustart erforderlich, damit die Änderungen wirksam werden.

image39.png

image40.png

bash
# PCIe-Treiber installieren
sudo dpkg -i hailort-pcie-driver_4.23.0_all.deb

# System neu starten
sudo reboot

# Nach dem Neustart überprüfen, ob der Treiber geladen ist
lsmod | grep hailo

# HailoRT installieren
sudo dpkg -i hailort_4.23.0_arm64.deb

# Gerätestatus scannen und überprüfen
hailortcli scan

# Virtuelle Umgebung erstellen und aktivieren
python3 -m venv hailo_env
source hailo_env/bin/activate

# HailoRT-Python-Bibliothek installieren
pip install hailort-4.23.0-cp311-cp311-linux_aarch64.whl

# Installation und Geräteverbindung überprüfen
python3 -c "from hailo_platform import VDevice; vdev = VDevice(); print('Successfully connected via VDevice! Device info:', vdev)"

image41.png

image42.png

image43.png

Hailo Model Zoo installieren Um offizielle vortrainierte Modelle auszuführen, musst du das Hailo Model Zoo und dessen Systemabhängigkeiten installieren.

bash
# 1. Erforderliche Systembibliotheken installieren
sudo apt update
sudo apt install -y git libglib2.0-0 libgl1-mesa-glx

# 2. Offizielles Repository klonen (neuester Branch empfohlen)
git clone https://github.com/hailo-ai/hailo_model_zoo.git
cd hailo_model_zoo
pip install -e .

Das YOLOv11-Modell ausführen

  • Kamerageräte prüfen: Ermittle den Einbindungspunkt deiner Webcam.
bash
v4l2-ctl --list-devices
  • Modell herunterladen: Stelle sicher, dass die Modelldatei yolov11n.hef heruntergeladen und in deinem Arbeitsverzeichnis abgelegt ist.

Erstelle eine Datei namens webcam_yolo11.py und füge den folgenden Code ein. Passe HEF_PATH und DEVICE_ID im Konfigurationsabschnitt an dein Setup an.

python
import numpy as np
import cv2
import time
from hailo_platform import (VDevice, HEF, InferVStreams, ConfigureParams,
                            HailoStreamInterface, InputVStreamParams, OutputVStreamParams)

# ================= Konfiguration =================
HEF_PATH = 'yolov11n.hef'
DEVICE_ID = "/dev/video40"  # Update based on v4l2-ctl output
CONF_THRESHOLD = 0.45

# COCO-Datensatz 80 Klassenbezeichnungen
COCO_CLASSES = [
    "person", "bicycle", "car", "motorcycle", "airplane", "bus", "train", "truck", "boat", "traffic light",
    "fire hydrant", "stop sign", "parking meter", "bench", "bird", "cat", "dog", "horse", "sheep", "cow",
    "elephant", "bear", "zebra", "giraffe", "backpack", "umbrella", "handbag", "tie", "suitcase", "frisbee",
    "skis", "snowboard", "sports ball", "kite", "baseball bat", "baseball glove", "skateboard", "surfboard",
    "tennis racket", "bottle", "wine glass", "cup", "fork", "knife", "spoon", "bowl", "banana", "apple",
    "sandwich", "orange", "broccoli", "carrot", "hot dog", "pizza", "donut", "cake", "chair", "couch",
    "potted plant", "bed", "dining table", "toilet", "tv", "laptop", "mouse", "remote", "keyboard", "cell phone",
    "microwave", "oven", "toaster", "sink", "refrigerator", "book", "clock", "vase", "scissors", "teddy bear",
    "hair drier", "toothbrush"
]
# ==================================================

def main():
    # 1. Initialize Hailo Hardware
    hef = HEF(HEF_PATH)
    input_vstream_info = hef.get_input_vstream_infos()[0]
    input_h, input_w = input_vstream_info.shape[:2]

    cap = cv2.VideoCapture(DEVICE_ID)
    if not cap.isOpened():
        print("Cannot open webcam")
        return

    # Setup inference variables
    prev_time = 0

    with VDevice() as target:
        config_params_dict = ConfigureParams.create_from_hef(hef, HailoStreamInterface.PCIe)
        network_group = target.configure(hef, config_params_dict)[0]
        with network_group.activate():
            vstream_params = (InputVStreamParams.make_from_network_group(network_group),
                              OutputVStreamParams.make_from_network_group(network_group))
            with InferVStreams(network_group, vstream_params[0], vstream_params[1]) as vstreams:
                print("[INFO] Initialization successful! Running YOLOv11 real-time detection...")
                while True:
                    start_time = time.time()  # Record start time for FPS
                    ret, frame = cap.read()
                    if not ret:
                        break

                    # Preprocessing (Convert to RGB based on previous validation)
                    frame_rgb = cv2.cvtColor(frame, cv2.COLOR_BGR2RGB)
                    resized = cv2.resize(frame_rgb, (input_w, input_h))
                    input_tensor = np.expand_dims(resized, axis=0)

                    # Inference
                    outputs = vstreams.infer(input_tensor)

                    # Parsing and Drawing
                    h, w, _ = frame.shape
                    for name, class_list in outputs.items():
                        # Iterate through 80 classes
                        for class_id, detections in enumerate(class_list[0]):
                            if len(detections) > 0:
                                for det in detections:
                                    if len(det) >= 5:
                                        ymin, xmin, ymax, xmax, confidence = det[:5]
                                        if confidence > CONF_THRESHOLD:
                                            # Coordinate Mapping
                                            left, top = int(xmin * w), int(ymin * h)
                                            right, bottom = int(xmax * w), int(ymax * h)

                                            # Get class name, display ID if out of bounds
                                            class_name = COCO_CLASSES[class_id] if class_id < len(COCO_CLASSES) else f"ID {class_id}"

                                            # Draw bounding box
                                            cv2.rectangle(frame, (left, top), (right, bottom), (0, 255, 0), 2)
                                            # Draw background and label text
                                            label = f"{class_name}: {confidence:.2f}"
                                            cv2.putText(frame, label, (left, top - 10),
                                                        cv2.FONT_HERSHEY_SIMPLEX, 0.5, (0, 255, 0), 2)

                    # Calculate and display real-time FPS
                    curr_time = time.time()
                    fps = 1 / (curr_time - start_time)
                    # Print in the top left corner
                    cv2.putText(frame, f"FPS: {fps:.1f}", (20, 40),
                                cv2.FONT_HERSHEY_SIMPLEX, 1, (0, 0, 255), 2)

                    # Display window
                    cv2.imshow('reComputer RK3576 - Hailo YOLOv11', frame)
                    if cv2.waitKey(1) & 0xFF == ord('q'):
                        break

    cap.release()
    cv2.destroyAllWindows()

if __name__ == "__main__":
    main()

image44.png

Anleitung zu RK182x-Deployment & -Inferenz

RK182x unterstützt den Koprozessor-Modus, bei dem der Host-SoC (z. B. RK3588/RK3576) als Systemkern fungiert und für Aufgabenplanung, Ressourcenzuweisung und Gesamtsteuerung zuständig ist. Er verbindet sich über schnelles PCIe (typischerweise auf Gen2 x1 bei 5 GT/s trainiert, was ~400 MB/s unidirektionale Bandbreite bietet) oder USB-3.0-Schnittstellen mit der RK1820/RK1828-Beschleunigungseinheit. RK1820 und RK1828 teilen sich dieselbe PCI-Device-ID (1d87:182a). Das Entwicklungs-Framework besteht aus dem PC-seitigen Modellkonvertierungstool (RKNN3 Toolkit) und der board-seitigen Laufzeitumgebung (RKNN3 Runtime).

Option A: Schnelles automatisiertes Deployment (empfohlen) Mit dem vorkompilierten automatisierten Installationspaket aus dem SDK lassen sich Kerneltreiber, Gerätefirmware, Laufzeitbibliotheken, Debugging-Tools und Autostart-Dienste des Systems per Ein-Klick-Deployment einrichten.

bash
# Paket via ADB vom PC auf das Board übertragen
# Optionale Pakete umfassen:
#   - rknn3_rk182x_m2_installer_arm64.tgz (M.2-Modul)
adb push rknn3_rk182x_m2_installer_arm64.tgz /tmp/installer.tgz
adb shell "cd /tmp && tar xzf installer.tgz && ./install.sh"

# Hinweis: Ein vollständiger Netzzyklus (physisches Ausschalten) ist ZWINGEND erforderlich, um das korrekte Laden von Hardware und Firmware sicherzustellen.
sudo poweroff

Wenn während der Entwicklung und beim Debugging eine manuelle Kontrolle über die Treiberbindung erforderlich ist oder du in einer Umgebung ohne installiertes Automatisierungspaket arbeitest, führe die folgenden Systembus-Befehle der Reihe nach aus. Hinweis: Bei RK1820 muss BusMaster nach dem Treiber-Probing explizit manuell aktiviert werden.

bash
# Treiberüberschreibung erzwingen und Bindung auslösen
echo pcie-rkep | sudo tee /sys/bus/pci/devices/0000:01:00.0/driver_override
echo 0000:01:00.0 | sudo tee /sys/bus/pci/drivers/pcie-rkep/bind

# BusMaster-Register aktivieren, um Bus-Mastering der Beschleunigerkarte zu aktivieren
sudo setpci -s 01:00.0 COMMAND=0x0406

Das Host-System läuft standardmäßig unter Python 3.11. Stelle vor dem Deployment sicher, dass du deine Modelle auf einem x86-Rechner mit dem RKNN3 Toolkit in das dedizierte .rknn-Format konvertiert hast (sowohl für LLMs als auch für CNNs) und die resultierenden Dateien (z. B. qwen2_5_1_5b_rk1820.rknn) auf den Host hochgeladen hast.

bash
# 1. Arbeitsbereich erstellen
mkdir -p ~/rk_182x_work && cd ~/rk_182x_work

# 2. Model Zoo und Toolkit-Repositories klonen
git clone --recursive https://github.com/airockchip/rknn3-model-zoo.git
git clone https://github.com/airockchip/rknn3-toolkit.git

# 3. rknn3-toolkit-lite installieren
cd rknn3-toolkit/rknn3-toolkit-lite/packages
pip3 install ./rknn3_toolkit_lite-1.0.0-cp311-cp311-linux_aarch64.whl

# 4. Abhängigkeiten installieren
pip3 install -r requirements.txt

Mini-PCIe-Steckplatz

Das Mainboard verfügt über einen standardmäßigen Mini-PCIe-(Mini PCI Express)-Steckplatz, der vor allem zur Erweiterung um industrietaugliche Funkkommunikationsmodule wie 4G LTE, LoRaWAN oder Wi-Fi HaLow konzipiert ist.

image45.png

Signal- & Busarchitektur Dieser Mini-PCIe-Steckplatz führt intern sowohl PCIe- als auch USB-Signale, was eine hervorragende Kompatibilität mit der großen Mehrheit der marktüblichen Funkkommunikationsmodule sicherstellt.

  • Mobilfunkerweiterung: In Verbindung mit dem integrierten Nano-SIM-Kartensteckplatz ermöglicht er das direkte Einsetzen von 4G-LTE-Modulen für die Mobilfunkanbindung.

Getestete & verifizierte Geräte Um optimale Kompatibilität und Systemstabilität sicherzustellen, empfehlen wir dringend die Verwendung von Mini-PCIe-Modulen, die vollständig von Seeed Studio getestet und verifiziert wurden:

  • 4G-Mobilfunknetz
    • Offiziell empfohlenes 4G-LTE-Mini-PCIe-Modul
  • LoRaWAN & IoT-Funk
    • USB- bzw. SPI-basierte LoRaWAN-Gateway-Module
    • Wi-Fi-HaLow-(802.11ah)-Funkmodule mit großer Reichweite und niedrigem Energieverbrauch

Hinweis:

SIM-Karten-Integration: Setze bei Verwendung eines 4G-LTE-Moduls die Nano-SIM-Karte in den integrierten Steckplatz ein, während das Gerät ausgeschaltet ist. Hot-Plugging der SIM-Karte kann zu Erkennungsfehlern des Moduls oder zu dauerhaften Schäden führen.

Antennenverlegung: Da industrielle Gehäuse Funksignale abschirmen können, verwende beim Einsatz von 4G- oder LoRaWAN-Modulen stets IPEX-zu-SMA-Pigtails, um die Antennen außerhalb des Gehäuses zu verlegen.

Treiber- & Netzwerkkonfiguration: Die meisten industriellen 4G-Module benötigen in Armbian OS spezielle USB-Serial-Treiber (wie den Treiber option). Entwickler können NetworkManager oder pppd verwenden, um Mobilfunkverbindungen herzustellen.

Konfigurations- und Testanleitung für das 4G-Modul (EC25)

image46.png

Mobilfunk-Einrichtung über AT-Befehle Setze das 4G-Modul mit der IoT-SIM-Karte ein, starte das System und überprüfe die USB-Seriell-Geräte:

bash
lsusb
ls /dev/ttyUSB*

Installiere und starte minicom, um mit dem Modul zu kommunizieren:

bash
sudo apt install minicom
sudo minicom -D /dev/ttyUSB2

Kurzreferenz der wichtigsten AT-Befehle

Detaillierte Statusprüfung & Verbindungsablauf SIM-Kartenstatus prüfen: Sende AT+CPIN?, um den SIM-Status zu überprüfen.

text
Command:  AT+CPIN?
Response: +CPIN: READY
Meaning:  The SIM card is present and ready (no PIN lock applied).

Signalqualität (RSSI) prüfen: Sende AT+CSQ, um die Funkumgebung zu bewerten.

text
Command:  AT+CSQ
Response: +CSQ: 28,99
Meaning:  Excellent signal. The value 28 maps to approx. -57 dBm (range 0-31, >20 is excellent). 99 indicates unknown Rx error rate (normal).

Netzwerkregistrierung prüfen: Sende AT+CGREG? und AT+CREG?, um die Mobilfunkanbindung zu überprüfen.

text
Command:  AT+CGREG?  and  AT+CREG?
Response: +CGREG: 0,1  /  +CREG: 0,1
Meaning:  The trailing 1 indicates "Registered, home network", meaning the module has successfully attached to the tower.

Aktuellen Anbieter abfragen: Sende AT+COPS?, um Betreiber und Netzwerkmodus zu überprüfen.

text
Command:  AT+COPS?
Response: +COPS: 0,0,"T-Mobile",7
Meaning:  Currently attached to the specific carrier (e.g., T-Mobile). The trailing 7 indicates the connection is in LTE (4G) mode.

Datenkontext aktivieren: Frage über AT+QIACT? ab und aktiviere den Kontext anschließend mit AT+QIACT=1.

text
Command:  AT+QIACT?   -> Response: OK (If empty, no context is currently active)
Command:  AT+QIACT=1  -> Response: OK
Meaning:  Successfully activates Context ID 1. The module will fetch a private IP from the carrier and enable cellular routing.

Hinweis: Sprachanrufe können über ATD<number>; eingeleitet werden, sofern gleichzeitige Sprach-/Datenübertragung von Hardware und Mobilfunktarif unterstützt wird.

Integrierter Ping-Test: Führe AT+QPING aus, um die IP-Konnektivität direkt vom Modul aus zu überprüfen.

text
Command:  AT+QPING=1,"www.google.com",1,4
Response: +QPING: 0["142.250.190.46",32,45,255]
          +QPING: 0,4,4,0,40,52,45
Meaning:  Successfully pinged the target domain. 4 packets sent, 4 received, 0% loss.

Fehlerbehebung

Konfigurations- und Testanleitung für das LoRa-Modul

USB

Geräteerkennung überprüfen

bash
ls /dev/ttyACM*
udevadm info /dev/ttyACM0 | grep -E "ID_VENDOR|ID_MODEL"

Die erwartete Ausgabe umfasst:

bash
E: ID_MODEL=STM32_Virtual_ComPort
E: ID_VENDOR=STMicroelectronics

TX-Testbefehl

bash
cd ~/sx1302_hal/libloragw
sudo ./test_loragw_hal_tx \
  -u \
  -d /dev/ttyACM0 \
  -r 1250 \
  -m LORA \
  -f 867.1 \
  -s 12 \
  -b 125 \
  -n 1000 \
  -z 100 \
  --dig 3 \
  --pa 0 \
  --pwid 13

Erwartete Ausgabe

text
Opening USB communication interface
INFO: Configuring TTY
INFO: Connect to MCU
INFO: Concentrator MCU version is V01.00.00
INFO: MCU status: sys_time:197172 temperature:37.2oC
Note: chip version is 0x10 (v1.0)
TX done
TX done

image49.png

Häufige Fehler & Lösungen

FehlerUrsacheLösung
chip version is 0xFFSPI-Modus bei einem USB-Modul verwendetFlag -u hinzufügen
failed to open COM port ... No such file or directoryGerät getrennt (z. B. nach GPIO-Reset)Neu einstecken oder neu starten; reset_lgw.sh nicht ausführen
USB disconnect in dmesgreset_lgw.sh hat GPIO umgeschaltet und USB getrenntReset-Skript bei USB-Modulen überspringen

Hinweis: Führe reset_lgw.sh nicht aus, bevor du Module im USB-Modus testest. Das Reset-Skript schaltet GPIO-Pins um, die das Modul aus- und wieder einschalten und dadurch die USB-Verbindung trennen. Der STM32-MCU übernimmt den SX1302-Reset intern.

SPI

Geräteerkennung überprüfen

bash
ls /dev/ttyACM*
udevadm info /dev/ttyACM0 | grep -E "ID_VENDOR|ID_MODEL"

Die erwartete Ausgabe umfasst:

bash
E: ID_MODEL=STM32_Virtual_ComPort
E: ID_VENDOR=STMicroelectronics

TX-Testbefehl

bash
cd ~/sx1302_hal/libloragw
sudo ./test_loragw_hal_tx \
  -u \
  -d /dev/ttyACM0 \
  -r 1250 -m LORA -f 867.1 -s 12 -b 125 \
  -n 1000 -z 100 --dig 3 --pa 0 --pwid 13

Erwartete Ausgabe

text
Opening USB communication interface
INFO: Configuring TTY
INFO: Connect to MCU
INFO: Concentrator MCU version is V01.00.00
INFO: MCU status: sys_time:197172 temperature:37.2oC
Note: chip version is 0x10 (v1.0)
TX done
TX done
...

image50.png

Konfigurations- und Testanleitung für das HaLow-WLAN-Modul

HaLow-WLAN erfordert ein Device Tree Overlay, um den SPI-Bus und die GPIO-Konfiguration für den MM6108-Chip freizulegen.

Füge das Overlay der Armbian-Umgebungskonfiguration hinzu:

bash
echo "overlays=recomputer-rk3576-devkit-halow-wifi" | sudo tee -a /boot/armbianEnv.txt

Überprüfe die Datei vor dem Neustart:

bash
tail -2 /boot/armbianEnv.txt

Erwartete Ausgabe:

image51.png

Starte neu, um das Overlay anzuwenden:

bash
sudo reboot

Bestätige nach dem Neustart, dass der Treiber geladen wurde und die Schnittstelle erschienen ist:

bash
dmesg | grep -i morse | grep -E "found|Loaded|initialized|MAC"

Erwartete Ausgabe:

text
morse_spi spi3.1: Morse Micro SPI device found, chip ID=0x0306
morse_spi spi3.1: Loaded firmware from morse/mm6108.bin, size 459124, crc32 0x51d355b9
morse_spi spi3.1: Loaded BCF from morse/bcf_default.bin, size 1251, crc32 0x941b2a82
morse_spi spi3.1: Firmware initialized
morse_spi spi3.1: Firmware Manifest MAC: 90:03:71:52:9d:8e

Die Binärdateien morse-hostapd und morse-wpa_supplicant rufen intern morse_cli auf, die installierte Binärdatei heißt jedoch morsectrl. Ein symbolischer Link ist erforderlich.

bash
sudo ln -s /usr/bin/morsectrl /usr/local/bin/morse_cli

Dies muss nur einmal durchgeführt werden.

Schnittstellen überprüfen:

bash
ip link show | grep -E "wlan0|wlan1|morse0"

AP-Modus Konfiguration erstellen:

bash
sudo nano /etc/morse-hostapd.conf

Minimal funktionierende Konfiguration:

text
interface=wlan0
driver=nl80211
ssid=HaLow_Test
country_code=AU          # Change to your region
hw_mode=a
channel=42               # AU channel, see table below
op_class=69
beacon_int=100
dtim_period=2
ieee80211ah=1
s1g_prim_chwidth=1
s1g_prim_1mhz_chan_index=0
s1g_capab=[SHORT-GI-ALL]
wpa=2
wpa_passphrase=12345678
wpa_key_mgmt=WPA-PSK
rsn_pairwise=CCMP
ctrl_interface=/var/run/hostapd

Schnittstelle deaktivieren und AP starten:

bash
sudo ip link set wlan0 down
sudo morse-hostapd /etc/morse-hostapd.conf -B

Erwartete Ausgabe (Erfolg):

text
s1g mapped ht channel 159
Full Channel Information
    Operating Frequency: 923000 kHz
    Operating BW: 2 MHz
wlan0: interface state COUNTRY_UPDATE->ENABLED
wlan0: AP-ENABLED

Hinweis: Warnungen der Art Unable to set RAW sind unkritisch. Sie treten auf, weil die installierte Treiberversion RAW (Restricted Access Window) nicht unterstützt. Der AP startet normal.

AP-Status überprüfen:

bash
sudo morse-hostapd_cli -i wlan0 status
sudo morse-hostapd_cli -i wlan0 all_sta   # list connected clients

Stationsmodus Konfiguration erstellen:

bash
sudo nano /etc/morse-wpa_supplicant.conf

Minimale Konfiguration:

text
ctrl_interface=/var/run/wpa_supplicant
country=AU

network={
    ssid="HaLow_Test"
    psk="12345678"
    key_mgmt=WPA-PSK
}

Verbinden:

bash
sudo ip link set wlan0 down
sudo morse-wpa_supplicant -i wlan0 -c /etc/morse-wpa_supplicant.conf -D nl80211 -B
sudo dhclient wlan0

Verbindung überprüfen:

bash
sudo morse-wpa_cli -i wlan0 status
ip addr show wlan0

Ethernet RJ45

Das Mainboard verfügt über zwei unabhängige Gigabit-Ethernet-(RJ45)-Ports. Das Dual-LAN-Design macht es ideal für den Aufbau industrieller Edge-Gateways, die physische Netzwerktrennung (Intranet/Extranet) oder die Konfiguration komplexer Netzwerk-Routings.

image52.png

Port-Definitionen & Merkmale:

  • 1x Standard-Gigabit-Ethernet (GbE): Unterstützt eine Ethernet-Verbindung mit automatischer 10/100/1000-Mbps-Aushandlung.
  • 1x PoE-fähiges Gigabit-Ethernet (GbE mit PoE PD): Zusätzlich zur Standard-Gigabit-Vernetzung unterstützt dieser Port das PoE-PD-(Powered-Device)-Protokoll.

Hinweis: Als PoE Powered Device (PD) kann dieses RK3576-Mainboard direkt über das Ethernet-Kabel von einem PoE-Switch (PSE) mit Strom versorgt werden, wodurch ein separates DC-Netzteil entfällt.

Hinweis:

PoE-Modul erforderlich: Die Funktion zum Empfang von PoE-Strom ist nicht direkt in das Basisboard integriert. Sie erfordert ein zusätzliches, separat erhältliches PoE-Zusatzmodul. Ohne installiertes Modul funktioniert der Port ausschließlich als Standard-Gigabit-Ethernet-Port.

Klarstellung PD vs. PSE: Beachte, dass dieses Gerät als PoE-PD (Stromempfänger) fungiert. Es unterstützt KEINE PoE-Ausgabe (PSE) und kann somit keine externen Geräte wie PoE-IP-Kameras mit Strom versorgen.

Netzwerkkonfiguration des Systems: In Armbian OS werden diese beiden physischen Ports typischerweise als eth0 und eth1 bezeichnet. Wir empfehlen, für die Konfiguration statischer IP-Adressen, Netzwerk-Bridging oder Link-Aggregation (Bonding) das Standard-Linux-Tool NetworkManager (über nmtui oder nmcli) oder systemd-networkd zu verwenden.

DSI

Das Mainboard verfügt über eine 4-Lane-MIPI-DSI-(22-Pin)-Display-Schnittstelle, die speziell für den Anschluss hochauflösender eingebetteter LCDs oder industrieller Touch-Panels konzipiert ist.

Schnittstellenmerkmale

  • Hochbandbreitige Übertragung: Nutzt ein physisches 4-Lane-Link-Design, das im Vergleich zu herkömmlichen 2-Lane-Schnittstellen deutlich höheren Datendurchsatz bietet. Es kann problemlos HD-Displays mit 1080p- oder sogar 2K-Auflösung ansteuern.
  • Physischer Formfaktor: Verwendet einen 22-poligen FPC-Steckverbinder mit 0,5-mm-Rastermaß (Flexible Printed Circuit) mit Klapp-Verriegelungsmechanismus.
  • Kompatibilität mit dem Raspberry-Pi-Ökosystem: Die Schnittstelle ist physisch abwärtskompatibel und unterstützt den direkten Anschluss von Standard-Raspberry-Pi-DSI-Displays, was den Aufwand und die Kosten für die Beschaffung von Zubehör für Entwickler deutlich reduziert.

Konfigurations- und Testanleitung für DSI

Beim reComputer-RK3576 wird die MIPI-DSI-Schnittstelle über Device Tree Overlays (DTBO) verwaltet. Nutzer müssen die erforderliche Overlay-Datei je nach angeschlossenem Display-Peripheriegerät manuell laden. Öffne das Terminal und bearbeite die Armbian-Umgebungskonfigurationsdatei:

bash
sudo nano /boot/armbianEnv.txt

Füge die folgende Zeile ganz am Ende der Datei hinzu, um das DSI-Display-Overlay anzugeben:

text
overlays=recomputer-rk3576-devkit-raspi-7inch-touchscreen

Speichere und beende (drücke Ctrl + O, dann Enter, um in nano zu speichern, und Ctrl + X zum Beenden). Aktualisiere die Paketlisten und stelle sicher, dass die erforderlichen Multimedia- und Display-Plugins installiert sind:

bash
sudo apt-get update
sudo apt install v4l-utils -y
sudo apt-get install gstreamer1.0-plugins-base gstreamer1.0-plugins-good gstreamer1.0-plugins-bad gstreamer1.0-x -y

Starte das System neu, um die Änderungen zu übernehmen:

bash
sudo reboot

Überprüfe nach dem Neustart, ob das System die grafische Desktop-Umgebung erfolgreich initialisiert hat:

bash
echo $XDG_SESSION_TYPE

Hinweis:

Wenn x11 oder wayland ausgegeben wird, wird das DSI-Display korrekt angesteuert und die grafische Oberfläche wurde aufgerufen.

Ausrichtung des FPC-Kabels: Achte beim Einsetzen des FPC-Kabels genau auf die Ausrichtung der goldenen Kontakte. Sie müssen zu den Kontaktstiften im Inneren des Steckverbinders zeigen. Ein verkehrt herum eingesetztes Kabel kann einen Kurzschluss verursachen oder verhindern, dass sich das Display einschaltet. Stelle sicher, dass die Klappverriegelung nach dem Einsetzen sicher geschlossen ist.

Treiber & Device Tree: MIPI-Displays sind nicht „plug-and-play". Nach dem Anschließen eines Displays musst du in Armbian OS den entsprechenden Panel-Treiber und die Hintergrundbeleuchtungs-Steuerungsknoten aktivieren, indem du die passenden Device Tree Overlays anwendest (z. B. mit armbian-add-overlay) oder die DTB-Dateien unter /boot änderst.

Touch-Unterstützung: Diese 22-polige Schnittstelle integriert üblicherweise I2C-Signalpins für Touch-Feedback. Wenn du ein MIPI-Touchscreen verwendest, stelle sicher, dass sowohl der Display-Treiber als auch der I2C-Touch-IC-Treiber (z. B. GT911) im Betriebssystem geladen sind.

CSI

Das Mainboard verfügt über zwei unabhängige 4-Lane-MIPI-CSI-(22-Pin)-Kameraschnittstellen. Angetrieben von der leistungsstarken ISP (Image Signal Processor) des RK3576 und der integrierten NPU eignet sich das Dual-CSI-Design hervorragend für den Aufbau von Stereo-Vision-Systemen, Machine-Vision-Prüfstationen oder das direkte Streaming von Video mit hoher Bildrate für die Edge-KI-Modellinferenz.

Schnittstellenmerkmale

  • Dual-4-Lane-Architektur: Bietet zwei physische Ports (CSI_0 und CSI_1), jeweils mit einem vollständigen 4-Lane-Datenkanal ausgestattet, die gleichzeitig zwei hochauflösende oder hochbildratige industrielle Kameramodule verarbeiten können.
  • Physischer Formfaktor: Verwendet einen 22-poligen FPC-Steckverbinder mit 0,5-mm-Rastermaß.
  • Kompatibilität mit dem Raspberry-Pi-Ökosystem: Der 22-polige Steckverbinder ist physisch und weitgehend pinkompatibel und unterstützt den direkten Anschluss von Standard-Raspberry-Pi-CSI-Kameras (etwa offizielle oder Drittanbietermodule auf Basis von IMX219-/IMX477-Sensoren). Dies ermöglicht Entwicklern, ihre Vision-Algorithmen schnell zu validieren.

Hinweis:

Kompatibilität & Auswahl: Wir empfehlen dringend die Verwendung von Kameramodulen, die offiziell von Seeed Studio verifiziert wurden. Bei nicht verifizierten oder nicht standardmäßigen Kameras müssen Entwickler die Linux-V4L2-(Video for Linux 2)-Treiber unter Umständen manuell portieren.

Standards für den Kabelanschluss: Achte genau auf die Ausrichtung der goldenen Kontakte des FPC-Kabels. Beachte außerdem, dass MIPI-Signale bei industriellen Einsätzen oder der Integration in Robotik-Frameworks sehr empfindlich gegenüber elektromagnetischen Störungen (EMI) sind. Es wird empfohlen, die Länge des Kamera-Flachbandkabels unter 30 cm (12 Zoll) zu halten.

Gleichzeitige Multi-Kamera-Erfassung: Unter Linux werden die beiden Kameras typischerweise als /dev/video0 und /dev/video1 bezeichnet. Wenn deine KI-Anwendung oder dein Multimedia-Framework (wie GStreamer oder OpenCV) beide Streams gleichzeitig erfassen muss, achte auf eine angemessene Speicherbandbreitenzuweisung und nutze hardwarebeschleunigte Plugins für optimale Leistung.

Konfigurations- und Testanleitung für CSI

Dieser Abschnitt führt dich durch die gleichzeitige Aktivierung von zwei MIPI-CSI-Kameras (am Beispiel der Raspberry Pi Camera V3). Bearbeite die Umgebungskonfigurationsdatei:

bash
sudo nano /boot/armbianEnv.txt

Füge die folgende Zeile am Ende der Datei hinzu, um die V3-Kameratreiber für CAM0 und CAM1 zu aktivieren:

text
overlays=recomputer-rk3576-devkit-cam0-rpi-v3 recomputer-rk3576-devkit-cam1-rpi-v3

Hinweis: Mehrere Overlays müssen durch genau ein Leerzeichen getrennt werden. Speichere die Datei und starte das Gerät neu:

bash
sudo reboot

Verwende nach dem Neustart die v4l-utils-Toolchain, um den Kamerastatus zu überprüfen und zu testen. Verfügbare Kamerageräte und -knoten auflisten:

bash
v4l2-ctl --list-devices

Unterstützte Pixelformate und Auflösungen für eine bestimmte Kamera anzeigen (z. B. /dev/video22):

bash
v4l2-ctl --list-formats-ext --device=/dev/video22

Bildrate der Kamera benchmarken: Teste die Streaming-Leistung bei einer bestimmten Auflösung und einem bestimmten Pixelformat (z. B. 3280x2464 MJPG):

bash
v4l2-ctl -d /dev/video22 --set-fmt-video=width=3280,height=2464,pixelformat='MJPG' --stream-mmap=4 --set-selection=target=crop,flags=0,top=0,left=0,width=3280,height=2464 --stream-count=500

Installiere die GStreamer-Kommandozeilen-Tools:

bash
sudo apt install gstreamer1.0-tools -y

Führe die folgende Pipeline aus, um den Echtzeit-Kamerastream in der Vorschau anzuzeigen (ersetze device=/dev/video11 durch den tatsächlichen Video-Knotenindex aus v4l2-ctl --list-devices):

bash
gst-launch-1.0 v4l2src device=/dev/video11 ! video/x-raw,format=NV12,width=3280,height=2464

HDMI

Das Mainboard verfügt über einen standardmäßigen HDMI-(Type-A)-Port, der vor allem für den Anschluss externer Monitore, Fernseher oder industrieller Steuerungsdisplays konzipiert ist und eine hochauflösende, synchronisierte Audio- und Videoausgabe bietet.

image57.png

Schnittstellenmerkmale

  • Ultra-HD-Auflösung: Angetrieben von den leistungsstarken Multimedia-Fähigkeiten des RK3576 unterstützt diese Schnittstelle Videoausgaben in bis zu 4K-Ultra-HD-Auflösung – ideal zur Darstellung gestochen scharfer GUI-Dashboards oder mehrerer Überwachungs-Videostreams.
  • Audio- & Video-Synchronisation: Der HDMI-Port überträgt gleichzeitig Video- und digitale Audiosignale. Wenn dein angeschlossener Monitor über eingebaute Lautsprecher verfügt, wird die Systemaudioausgabe direkt über die HDMI-Verbindung wiedergegeben, ohne dass ein zusätzliches 3,5-mm-Audiokabel erforderlich ist.
  • Multi-Display-Unterstützung: Dieser HDMI-Port kann gleichzeitig mit den integrierten Type-C-(DP-1.4)- und MIPI-DSI-Schnittstellen betrieben werden. Entwickler können innerhalb des Linux-Betriebssystems geklonte Displays oder erweiterte Desktop-Modi über bis zu drei Bildschirme hinweg konfigurieren.

Hinweis:

Kabelstandards: Um Stabilität sicherzustellen und Bildschirmflackern bei 4K-Auflösungen zu vermeiden, verwende bitte ausschließlich hochwertige Kabel, die der Spezifikation HDMI 2.0 oder höher entsprechen.

EDID & automatische Auflösungserkennung: Das Betriebssystem (z. B. Armbian / Ubuntu) liest beim Booten automatisch die EDID-Informationen des Monitors aus, um die optimale Auflösung anzuwenden. Falls das Problem „Kein Signal" auftritt, kannst du dich per SSH anmelden und mit dem Befehl xrandr den Status der Display-Ausgabe debuggen.

Betrieb im Headless-Modus: Wenn du das Gerät ausschließlich als Edge-Computing-Knoten ohne physischen Monitor einsetzt, kann das Betriebssystem das Rendering der Desktop-Oberfläche zur Ressourcenschonung aussetzen. Falls du in einem Headless-Setup dennoch VNC-Fernzugriff auf den Desktop benötigst, empfehlen wir, einen „Dummy-HDMI-Stecker (Display-Emulator)" in den Port zu stecken.