インターフェース説明

ファン

reComputer RK3576 は、Linux の hwmon サブシステムを通じてファン制御機能を備えています。ファン回転数はリアルタイムで読み取ることができ、PWM デューティ比は手動で設定することも、自動サーマルガバナーに任せることもできます。

ハードウェアモニターのパス

インターフェースパス説明
ファン回転数/sys/class/hwmon/hwmon6/fan1_input現在の RPM
PWM 値/sys/class/hwmon/hwmon6/pwm10–255、デューティ比を制御
PWM モード/sys/class/hwmon/hwmon6/pwm1_enable0=オフ 1=手動 2=自動

サーマルゾーン

ゾーンパス
SoC/sys/class/thermal/thermal_zone0/temp
Big コア/sys/class/thermal/thermal_zone1/temp
Little コア/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

温度値はミリ度(1000分の1℃)単位です。℃ に変換するには1000で割ってください。

ファン回転数の読み取り

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

出力は RPM 単位です。例: 2161

すべての温度を一括で読み取る:

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

ファン回転数の制御

  1. 手動モードに切り替える:
bash
echo 1 | sudo tee /sys/class/hwmon/hwmon6/pwm1_enable
  1. PWM 値を設定する(0–255):
PWM 値概算の回転速度
0ファン停止
64約25%
128約50%
192約75%
255フル回転
bash
# 50%に設定
echo 128 | sudo tee /sys/class/hwmon/hwmon6/pwm1
  1. 自動サーマル制御に戻す:
bash
echo 2 | sudo tee /sys/class/hwmon/hwmon6/pwm1_enable

自動サーマル制御スクリプト

このスクリプトは SoC 温度に基づいてファン回転数を調整し、バックグラウンドで継続的に動作します。

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

fan-control.sh として保存し、実行する:

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

バックグラウンドで実行する:

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

systemd サービス

  1. スクリプトをコピーする:
bash
sudo cp fan-control.sh /usr/local/bin/fan-control.sh
sudo chmod +x /usr/local/bin/fan-control.sh
  1. サービスファイルを作成する:
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. 有効化して起動する:
bash
sudo systemctl daemon-reload
sudo systemctl enable fan-control
sudo systemctl start fan-control
sudo systemctl status fan-control

クイックリファレンス

bash
# ファンの RPM を読み取る
cat /sys/class/hwmon/hwmon6/fan1_input

# SoC 温度を読み取る
echo "$(( $(cat /sys/class/thermal/thermal_zone0/temp) / 1000 ))°C"

# フル回転
echo 1 | sudo tee /sys/class/hwmon/hwmon6/pwm1_enable
echo 255 | sudo tee /sys/class/hwmon/hwmon6/pwm1

# 低速
echo 1 | sudo tee /sys/class/hwmon/hwmon6/pwm1_enable
echo 64 | sudo tee /sys/class/hwmon/hwmon6/pwm1

# 自動に戻す
echo 2 | sudo tee /sys/class/hwmon/hwmon6/pwm1_enable

テスト環境

項目
デバイスreComputer RK3576 DevKit
OSLinux 6.1(Debian ベース)
hwmon インターフェース/sys/class/hwmon/hwmon6(pwmfan)
アイドル時のファン回転数約2155 RPM
アイドル時の SoC 温度約36°C

LED インジケーターステータス

本デバイスのフロントパネルには、3個のオンボード LED インジケーター(Power、Status、User)が搭載されています。これらの LED により、ハードウェアの電源投入シーケンスを監視したり、システムの実行時の動作を観察したり、カスタムソフトウェア連携のための完全にプログラム可能なインターフェースを利用したりできます。

image24.png

  • LED の状態とデフォルトのハードウェア動作 デフォルトのシステムファームウェアでは、起動時および起動後の動作中に LED は以下の標準的な挙動を示します。

  • 開発者必須知識: 制御の境界 二次開発を始める前に、不要なトラブルシューティングを避けるためにも、各 LED の基盤となるハードウェア配線を理解しておくことが重要です。

  • Power LED(赤): 純粋なハードウェア制御。 この LED はメイン電源レールに直接ハードワイヤードされています。接続されている GPIO やカーネルインターフェースは存在しません。ソフトウェアやコマンドから制御することはできません

  • Status LED(緑): システムレベルのハードウェア制御。 この LED は、コアシステムの安定性を反映するために、基盤となるハードウェア電源管理ロジックまたは PMIC ファームウェアによって物理的に管理されています。Linux のユーザー空間に対するインターフェースは一切公開されておらず、ソフトウェアやコマンドから制御することはできません

  • User LED(RGB 3色): 開発者が完全に制御可能! これは、オンボードの GPIO エキスパンダー(gpiochip6)に接続された RGB LED カプセルです。デバイス上でカスタムプログラミングとソフトウェア自動化に開放されている唯一のインジケーターです。デフォルトでは、システムが青チャンネル(USER_LED_B)をハートビートインジケーターとして使用しており、赤チャンネルと緑チャンネルはアイドル状態のままです。

  • User RGB LED 制御ガイド Linux 環境(Armbian など)では、アイドル状態の赤チャンネルと緑チャンネルの操作には最新の gpiod ツールチェーン(gpioinfo / gpioset)を使用し、青チャンネルの制御には標準の Linux sysfs インターフェースを使用することを推奨します。 LED の特定 システム内では、LED は sysfs インターフェースを通じて管理されています。以下のコマンドを実行して LED ノードを確認してください。

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

期待される出力 :

image26.png

手動制御(ON/OFF) LED を手動で制御する前に、トリガーモードを none に設定する必要があります。

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

LED の ON/OFF

bash
# 点灯
echo 1 | sudo tee /sys/class/leds/user-led/brightness
# 消灯
echo 0 | sudo tee /sys/class/leds/user-led/brightness

自動トリガーモード カーネルは、システムイベントに基づいて LED の動作を自動化するさまざまなトリガーを提供しています。

bash
# ハートビートモード
echo heartbeat | sudo tee /sys/class/leds/user-led/trigger
# カスタムタイマーモード(点滅)
# タイマーを有効化
echo timer | sudo tee /sys/class/leds/user-led/trigger
# 間隔を設定
echo 500 | sudo tee /sys/class/leds/user-led/delay_on
echo 500 | sudo tee /sys/class/leds/user-led/delay_off

起動時の永続的な設定 /sys 内の変更は揮発性であり再起動後にリセットされるため、cron ジョブを追加するか rc.local を使用することで永続化できます。

ボタン

reComputer RK3576 シリーズのマザーボードには、主に電源制御と低レベルファームウェア書き込みに使用される3個のオンボード物理ボタンが搭載されています。

image27.png

注: Recovery または MaskROM を使用して書き込みを行う場合は、デバイスの Type-C OTG ポートがデータケーブルでホスト PC に接続されていることを確認してください。操作の実行には、Rockchip の公式ツール(Windows 用の RKDevTool や Linux 用の upgrade_tool など)が必要です。

GPIO

マザーボード上部には標準の40ピン拡張ヘッダーが搭載されており、開発者に包括的な低レベルハードウェアインターフェース群を提供します。これには電源、デバッグ、および一般的な産業用通信バス(I2C、UART、SPI、CAN など)が含まれており、外部センサーやドライバーボードの接続、またはシステムレベルのデバッグを容易に行うことができます。

image29.png

40ピン ピンアウト表

GPIO の使用方法 デフォルトでは、システムドライバーによって事前に割り当てられていない限り、40ピンヘッダー上のほとんどのピンは標準の GPIO として機能します。シェルレベルでの操作には、標準の gpiod ツールセット(gpiodetectgpioinfogpiosetgpioget)の使用を推奨します。 物理ピン21(汎用 GPIO として指定されており、現在未使用)を操作するには:

  • マッピングされているコントローラーとライン番号を特定する:
bash
sudo gpioinfo | grep -i PIN_21

出力:

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

これは gpiochip1 の Line 14 に属していることを示しています。

  • ピンを High に設定する(例: LED を点灯):
bash
gpioset gpiochip1 14=1
  • ピンを Low に設定する:
bash
gpioset gpiochip1 14=0
  • 物理ピン27の入力状態を読み取る: sudo gpioinfo | grep -i PIN_27 を実行すると、gpiochip4 の Line 23 にマッピングされていることがわかります。
bash
gpioget gpiochip4 23

ピンアウトに記載されている専用の周辺ハードウェア(I2C、UART、CAN、PWM)を有効化するには、対応する Device Tree Overlay(DTBO)を明示的に有効にする必要があります。有効にしない場合、それらは単なる汎用 GPIO として機能し続けます。 40ピン専用のオーバーレイ設定はすべて /boot/dtb/rockchip/overlay/ に格納されており、recomputer-rk3576-devkit-40pin- という厳密な命名プレフィックスに従っています。

設定手順:

  • システム環境設定ファイルを開く:
bash
sudo nano /boot/armbianEnv.txt
  • overlays= の行を探し(存在しない場合はファイル末尾に追加し)、目的のオーバーレイ名を**.dtbo 拡張子を付けずに**挿入します。複数のオーバーレイはスペースで区切ります:
text
overlays=recomputer-rk3576-devkit-40pin-i2c3 recomputer-rk3576-devkit-40pin-can0
  • 保存して終了し(Ctrl+O、Enter、Ctrl+X)、デバイスツリーの変更を適用するためにハードウェアを再起動します:
bash
sudo reboot

注: SPI はデフォルトで有効

SPI バスのピン(ピン19、21、23、24、26)は、起動時にデフォルトで有効化されています。armbianEnv.txt で SPI 用のカスタム DTBO を割り当てる必要はありません

ハードウェアアーキテクチャの共有: 40ピンヘッダー上の物理 SPI 信号は、オンボードの 4G LTE / LoRaWAN / Hailo Wi-Fi 拡張スロットと全く同じハードウェアバスドメインを共有しています。これらの通信モジュールをすぐに使える状態にするため、ベース OS はこの SPI チャンネルを常時有効な状態に保っています。

開発者への推奨事項: サードパーティ製のカスタム SPI ブレイクアウトボードを40ピン拡張ヘッダーに接続する場合は、内蔵モジュールとの通信バスのデッドロックを回避するため、Chip Select(CS)とアドレッシングを慎重に扱ってください。

USB

本デバイスは、reComputer RK3576 シリーズに対応した複数の物理 USB インターフェースを提供します。これらのインターフェースは、外部周辺機器の接続、システムファームウェアの書き込み(OTG)、および副次的なディスプレイ出力を担います。

USB リソースの割り当ては以下のとおりです:

インターフェースの位置/ラベル物理フォームファクターバスプロトコルと最大帯域幅ハードウェア仕様とコントローラールーティング
USB 3.0 HostUSB Type-AUSB 3.2 Gen 1x1(5 Gbps)内蔵の USB 3.0 コントローラー経由でルーティングされます。USB 3.0 産業用カメラ、NVMe ストレージ拡張、高速 DAQ モジュールに最適化された高帯域幅データチャンネルを提供します。
USB 2.0 HostUSB Type-A(複数)USB 2.0(480 Mbps)USB 2.0 ホストコントローラーによって管理されます。キーボード、マウス、4G/5G セルラーモデム、ハードウェア暗号化ドングル、USB-UART ブリッジボードなどの標準的な周辺機器に使用されます。
USB Type-CUSB Type-CUSB 3.0 / 2.0 OTG + DP 1.4 Alt ModeRK3576 の USB 3.0 OTG コントローラーと DisplayPort(DP)TX PHY にルーティングされるマルチプロトコル複合ポートです。双方向のホスト/デバイスロールとハードウェアによる映像ストリーミングをサポートします。

lsusb を使用すると、システムに接続されている USB デバイスの情報を確認できます:

image34.png

注: USB Type-C インターフェースアーキテクチャ

A. システムの書き込みとメンテナンス(USB OTG デバイスモード): Recovery / MaskROM キーによってトリガーされ、ポートはデバイスモードで起動し、RKDevTool を使用した低レベルファームウェアの書き込みを行います。

B. DisplayPort 出力(DP 1.4 Alt Mode): ハードウェアの映像レーンを多重化し、Type-C ケーブルまたはアダプタ経由で直接モニタを駆動し、標準の DP 1.4 ディスプレイ出力を実現します。

C. 標準ネイティブホストモード: 通常の OS 実行中はデフォルトで標準の USB 3.0 Host として動作し、Type-C ストレージ、ネットワークアダプタ、ハブと直接インターフェースします。

SD カードスロット

マザーボードには標準の Micro SD(TF)カードスロットが1個搭載されており、RK3576 SOC の SDMMC0 バスに直接接続されています。このインターフェースは主に、システムの起動、OS(Armbian OS など)の実行、およびローカルデータストレージに使用されます。

image35.png

すぐに使える体験 本デバイスには標準で 32GB Class 10 Micro SD カードが同梱されています。このカードは Seeed Studio による厳格な互換性テストに合格しており、日常的な Armbian OS の運用、基本的なネットワーク設定、軽量なエッジ AI アルゴリズムの検証を問題なく処理できるため、開発者はすぐに使い始めることができます。

注: 起動優先順位とストレージに関するガイダンス

起動優先メカニズム(MaskROM ステージ): RK3576 のファームウェア起動シーケンスは、低レベルの MaskROM によって厳密に制御されています。Micro SD カードとオンボード eMMC の両方に起動可能なファームウェアが存在する場合、MaskROM は Micro SD カードから SPL(Secondary Program Loader)を優先的にロードします。ファームウェアのアップグレードやマルチ OS の切り替えの際は、この物理的特性に十分注意してください。

NVMe 起動の制限(U-Boot ステージ): M.2 NVMe SSD は MaskROM の直接起動パスには含まれません。システムは生の NVMe ドライブから直接ステージ1の初期起動を行うことができません。NVMe SSD から OS を実行するには、まず Micro SD カードまたは eMMC 上でブートローダーを実行して U-Boot ステージに入る必要があり、その後 U-Boot が NVMe ストレージ上のメイン OS を初期化・ロードし、制御を引き渡します。

高負荷ワークロードのアップグレード推奨事項: エッジで高頻度の I/O 読み書きを必要とするアプリケーション(継続的なローカルロギングを伴う大規模データベースの実行や、複雑な Docker コンテナクラスタの管理など)を展開する予定がある場合、大量の 4K ランダム読み書きが標準の Class 10 カードの性能限界に達する可能性があります。このような高負荷の産業用途では、コア OS の rootfs を M.2 NVMe SSD に移行する(U-Boot チェーンロード経由)か、A1 または A2(Application Performance Class)を明示的に認定された高性能 Micro SD カードにアップグレードして、システムの応答性を最適化することを推奨します。

マウントポイント: Armbian OS では、Micro SD カードは通常 /dev/mmcblk0 として認識されます。

SIM カードスロット

マザーボードには1個のオンボードカードスロットが搭載されており、Mini-PCIe スロットに取り付けられた 4G LTE セルラーモジュールと連携するよう明示的に設計されています。標準的なキャリア SIM カードを挿入することで、有線 Ethernet のない環境でもエッジからクラウドへのセルラー接続を実現できます。

image36.png

ハードウェアアーキテクチャとメカニズム Nano SIM スロットの信号線は、Mini-PCIe スロットの特定のピン(UIM_PWR、UIM_DATA、UIM_CLK、UIM_RESET など)に直接接続されています。

  • SOC への直接接続なし: SIM カードの信号は RK3576 SOC と直接インターフェースしない点に注意してください。代わりに、Mini-PCIe スロットに取り付けられた 4G モジュールによって完全に管理・駆動されます。そのため、SIM カードは互換性のある 4G モジュールが動作している場合にのみ機能します。

注: 開発者向けの注意事項と運用基準

ホットプラグは厳禁: SIM カードの挿入・取り外しは、必ずデバイスが完全に電源オフの状態(DC 電源または PoE が切断された状態)で行ってください。システム動作中に SIM カードをホットプラグすると、4G モジュールの SIM インターフェースが永久に損傷したり、ネットワーク関連のシステムクラッシュを引き起こしたりする可能性があります。

フォームファクター仕様: 本スロットは、現代のスマートフォンで使用される最小の標準サイズである Nano SIM カード(4FF)にのみ対応しています。安価なプラスチックアダプタを使用した Micro SIM や Standard SIM カードは、スロット内部のピンに引っかかったり曲げたりしやすいため使用を避けてください。

挿入方向: 挿入前に、スロット付近のシルク印刷アイコンまたは構造上の切り欠きを確認してください。通常、SIM カードは金属接点を下向きにし、切り欠きのある角を先に挿入します(基板上の物理的な位置合わせマークに従ってください)。

M.2 Key M 2280 スロット

マザーボードには標準の M.2 Key M 2280 スロットが1個搭載されており、PCIe 2.1 x1 バスによって駆動されます。高速ストレージの拡張やエッジ AI コンピューティングのアクセラレーションを目的として設計されています。

image37.png

対応デバイス

  • NVMe SSD: システムの起動、大容量データストレージ、大規模 AI モデルの格納のための標準的な 2280 NVMe SSD に対応しています。
  • AI アクセラレータ: エッジ推論能力を強化する M.2 Key M ベースの AI アクセラレータモジュールと互換性があります。

テスト・検証済みデバイス 最適な互換性とシステムの安定性を確保するため、Seeed Studio によって十分にテスト・検証済みの M.2 拡張モジュールの使用を強く推奨します:

注:

プロトコル互換性: 本スロットは PCIe NVMe デバイスにのみ対応しています。M.2 SATA SSD はサポートされておらず、OS に認識されません。

帯域幅の制限: 本スロットは PCIe 2.1 x1 レーンで動作し、理論上の最大帯域幅は約500 MB/s です。NVMe SSD を購入する際は、コストパフォーマンスに優れた標準的な Gen3/Gen4 ドライブで十分です。超高速な Gen4 SSD は PCIe 2.1 x1 インターフェースによってボトルネックとなります。

フォームファクター: 取り付け用スタンドオフは、2280(22mm x 80mm)モジュール専用に設計されています。

SSD 使用ガイド

bash
lsblk

image38.png

Hailo YOLOv11 デプロイと推論ガイド

パッケージのインストール ベースの PCIe ドライバをインストールした後、変更を反映させるためにシステムの再起動が必要です。

image39.png

image40.png

bash
# PCIeドライバーをインストール
sudo dpkg -i hailort-pcie-driver_4.23.0_all.deb

# システムを再起動
sudo reboot

# 再起動後、ドライバーがロードされていることを確認
lsmod | grep hailo

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

# デバイスステータスをスキャンして確認
hailortcli scan

# 仮想環境を作成して有効化
python3 -m venv hailo_env
source hailo_env/bin/activate

# HailoRT Pythonライブラリをインストール
pip install hailort-4.23.0-cp311-cp311-linux_aarch64.whl

# インストールとデバイス接続を確認
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 のインストール 公式の学習済みモデルを実行するには、Hailo Model Zoo とそのシステム依存関係をインストールする必要があります。

bash
# 1. 必要なシステムライブラリをインストール
sudo apt update
sudo apt install -y git libglib2.0-0 libgl1-mesa-glx

# 2. 公式リポジトリをクローン(最新ブランチ推奨)
git clone https://github.com/hailo-ai/hailo_model_zoo.git
cd hailo_model_zoo
pip install -e .

YOLOv11 モデルの実行

  • カメラデバイスの確認: ウェブカメラのマウントポイントを特定します。
bash
v4l2-ctl --list-devices
  • モデルのダウンロード: yolov11n.hef モデルファイルをダウンロードし、作業ディレクトリに配置してください。

webcam_yolo11.py という名前のファイルを作成し、以下のコードを貼り付けます。設定セクションの HEF_PATHDEVICE_ID を、ご自身の環境に合わせて調整してください。

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

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

# COCOデータセット 80クラスラベル
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

RK182x デプロイと推論ガイド

RK182x はコプロセッサモードをサポートしており、ホスト SoC(RK3588/RK3576 など)がシステムのコアとして機能し、タスクスケジューリング、リソース割り当て、全体制御を担当します。RK1820/RK1828 アクセラレーションユニットへは、高速 PCIe(通常は Gen2 x1、5 GT/s でトレーニングされ、片方向で約400 MB/s の帯域幅を提供)または USB 3.0 インターフェース経由で接続します。RK1820 と RK1828 はいずれも同じ PCI デバイス ID(1d87:182a)を共有しています。開発フレームワークは、PC 側のモデル変換ツール(RKNN3 Toolkit)とボード側のランタイム環境(RKNN3 Runtime)で構成されています。

オプション A: 迅速な自動デプロイ(推奨) SDK に含まれるプリコンパイル済みの自動インストーラーパッケージを使用すると、カーネルドライバ、デバイスファームウェア、ランタイムライブラリ、デバッグツール、システム自動起動サービスをワンクリックでデプロイできます。

bash
# PCからADB経由でボードにパッケージをプッシュ
# オプションパッケージ:
#   - rknn3_rk182x_m2_installer_arm64.tgz(M.2モジュール)
adb push rknn3_rk182x_m2_installer_arm64.tgz /tmp/installer.tgz
adb shell "cd /tmp && tar xzf installer.tgz && ./install.sh"

# 注意:ハードウェアとファームウェアを正しく読み込むには、ハード電源サイクル(物理的な電源オフ)が必須です。
sudo poweroff

開発・デバッグ中にドライバのバインディングを手動で制御する必要がある場合、または自動パッケージがインストールされていない環境で作業する場合は、以下のシステムバスコマンドを順番に実行してください。注: RK1820 では、ドライバのプローブ後に BusMaster を手動で明示的に有効化する必要があります。

bash
# ドライバーオーバーライドを強制してバインディングをトリガー
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レジスタを有効にしてアクセラレータカードのバスマスタリングを有効化
sudo setpci -s 01:00.0 COMMAND=0x0406

ホストシステムはデフォルトで Python 3.11 で動作します。デプロイ前に、x86 マシン上で RKNN3 Toolkit を使用してモデルを専用の .rknn 形式(LLM と CNN の両方に対応)に変換し、生成されたファイル(例: qwen2_5_1_5b_rk1820.rknn)をホストにアップロードしておいてください。

bash
# 1. ワークスペースを作成
mkdir -p ~/rk_182x_work && cd ~/rk_182x_work

# 2. Model ZooとToolkitのリポジトリをクローン
git clone --recursive https://github.com/airockchip/rknn3-model-zoo.git
git clone https://github.com/airockchip/rknn3-toolkit.git

# 3. rknn3-toolkit-liteをインストール
cd rknn3-toolkit/rknn3-toolkit-lite/packages
pip3 install ./rknn3_toolkit_lite-1.0.0-cp311-cp311-linux_aarch64.whl

# 4. 依存関係をインストール
pip3 install -r requirements.txt

Mini-PCIe スロット

マザーボードには標準の Mini-PCIe(Mini PCI Express)スロットが1個搭載されており、主に 4G LTE、LoRaWAN、Wi-Fi HaLow などの産業グレードの無線通信モジュールを拡張するために設計されています。

image45.png

信号・バスアーキテクチャ この Mini-PCIe スロットは内部で PCIeUSB の両方の信号をルーティングしており、市場に出回っている大半の主流の無線通信モジュールとの優れた互換性を確保しています。

  • セルラー拡張: オンボードの Nano SIM カードスロットと組み合わせることで、4G LTE モジュールを直接挿入してセルラーネットワーク接続を有効化できます。

テスト・検証済みデバイス 最適な互換性とシステムの安定性を確保するため、Seeed Studio によって十分にテスト・検証済みの Mini-PCIe モジュールの使用を強く推奨します:

  • 4G セルラーネットワーク
    • 公式推奨の 4G LTE Mini-PCIe モジュール
  • LoRaWAN と IoT ワイヤレス
    • USB ベース/SPI ベースの LoRaWAN ゲートウェイモジュール
    • Wi-Fi HaLow(802.11ah)長距離・低消費電力無線モジュール

注:

SIM カードの組み込み: 4G LTE モジュールを使用する場合は、デバイスの電源がオフの状態でオンボードスロットに Nano SIM カードを挿入してください。SIM カードのホットプラグは、モジュールの認識失敗や永久的な損傷を引き起こす可能性があります。

アンテナの配線: 産業用筐体は無線信号を遮蔽する可能性があるため、4G または LoRaWAN モジュールを展開する際は、必ず IPEX-to-SMA ピッグテールを接続してアンテナを筐体外までルーティングしてください。

ドライバとネットワーク設定: ほとんどの産業用 4G モジュールは、Armbian OS 上で特定の USB シリアルドライバ(option ドライバなど)を必要とします。開発者は NetworkManager または pppd を使用してセルラー接続を確立できます。

4G モジュール(EC25)の設定とテストガイド

image46.png

AT コマンドによるセルラー設定 IoT SIM カードを装着した 4G モジュールを取り付け、システムを起動し、USB シリアルデバイスを確認します:

bash
lsusb
ls /dev/ttyUSB*

モジュールと通信するために minicom をインストールして起動します:

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

主要 AT コマンド クイックリファレンス

詳細なステータス確認とダイヤルのワークフロー SIM カードステータスの確認: AT+CPIN? を送信して SIM のステータスを確認します。

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

信号品質(RSSI)の確認: AT+CSQ を送信して無線環境を評価します。

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).

ネットワーク登録の確認: AT+CGREG?AT+CREG? を送信してセルラー接続状態を確認します。

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.

現在のキャリアの照会: AT+COPS? を送信して事業者とネットワークモードを確認します。

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.

データコンテキストの有効化: AT+QIACT? で照会し、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.

注: ハードウェアとキャリアプランが音声とデータの同時利用をサポートしている場合、ATD<number>; を使って音声通話を開始できます。

組み込み Ping テスト: AT+QPING を実行し、モジュールから直接 IP レベルの接続性を確認します。

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.

トラブルシューティング

LoRa モジュールの設定とテストガイド

USB

デバイス認識の確認

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

期待される出力には以下が含まれます:

bash
E: ID_MODEL=STM32_Virtual_ComPort
E: ID_VENDOR=STMicroelectronics

TX テストコマンド

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

期待される出力

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

よくあるエラーと対処法

ErrorCauseFix
chip version is 0xFFSPI mode used on a USB moduleAdd -u flag
failed to open COM port ... No such file or directoryDevice disconnected (e.g. after GPIO reset)Replug or reboot; do not run reset_lgw.sh
USB disconnect in dmesgreset_lgw.sh toggled GPIO and disconnected USBSkip the reset script for USB modules

注: USB モードのモジュールをテストする前に reset_lgw.sh を実行しないでください。このリセットスクリプトは GPIO ピンを切り替えてモジュールの電源を再投入し、USB の切断を引き起こします。SX1302 のリセットは STM32 MCU が内部で処理します。

SPI

デバイス認識の確認

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

期待される出力には以下が含まれます:

bash
E: ID_MODEL=STM32_Virtual_ComPort
E: ID_VENDOR=STMicroelectronics

TX テストコマンド

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

期待される出力

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

HaLow WiFi モジュールの設定とテストガイド

HaLow WiFi では、MM6108 チップの SPI バスと GPIO 設定を公開するためにデバイスツリーオーバーレイが必要です。

Armbian の環境設定にオーバーレイを追加します:

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

再起動前にファイルを確認します:

bash
tail -2 /boot/armbianEnv.txt

期待される出力:

image51.png

オーバーレイを適用するために再起動します:

bash
sudo reboot

再起動後、ドライバがロードされ、インターフェースが出現したことを確認します:

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

期待される出力:

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

morse-hostapd と morse-wpa_supplicant のバイナリは内部で morse_cli を呼び出しますが、実際にインストールされているバイナリの名前は morsectrl です。シンボリックリンクの作成が必要です。

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

この作業は一度行うだけで済みます。

インターフェースを確認します:

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

AP モード 設定ファイルを作成します:

bash
sudo nano /etc/morse-hostapd.conf

動作する最小構成:

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

インターフェースをダウンさせてから AP を起動します:

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

期待される出力(成功時):

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

注: Unable to set RAW という警告は致命的なものではありません。これは、インストールされているドライバのバージョンが RAW(Restricted Access Window)に対応していないために表示されるものです。AP は正常に起動します。

AP のステータスを確認します:

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

ステーションモード 設定ファイルを作成します:

bash
sudo nano /etc/morse-wpa_supplicant.conf

最小構成:

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

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

接続します:

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

接続を確認します:

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

Ethernet RJ45

マザーボードには2個の独立した ギガビット Ethernet(RJ45)ポートが搭載されています。このデュアル LAN 設計により、産業用エッジゲートウェイの構築、物理的なネットワーク分離(イントラネット/エクストラネット)の実装、複雑なネットワークルーティングの構成に最適です。

image52.png

ポートの定義と機能:

  • 1x 標準ギガビット Ethernet(GbE): 10/100/1000 Mbps オートネゴシエーション Ethernet 接続をサポートします。
  • 1x PoE 対応ギガビット Ethernet(PoE PD 付き GbE): 標準的なギガビットネットワーキングに加え、このポートは PoE PD(Powered Device) プロトコルをサポートします。

注: PoE Powered Device(PD)として、この RK3576 マザーボードは PoE スイッチ(PSE)から Ethernet ケーブルを通じて直接電力を受け取ることができ、別途 DC 電源アダプタを用意する必要がありません。

注:

PoE モジュールの要件: PoE 受電機能はベースボードに直接組み込まれてはいません。別途購入する PoE アドオンモジュールが必要です。このモジュールが取り付けられていない場合、ポートは標準的なギガビット Ethernet ポートとしてのみ機能します。

PD と PSE の違い: 本デバイスは PoE PD(受電機器)として動作する点にご注意ください。PoE 出力(PSE)には対応しておらず、PoE IP カメラのような外部デバイスに電力を供給することはできません。

システムネットワーク設定: Armbian OS では、これら2つの物理ポートは通常 eth0eth1 として認識されます。静的 IP アドレスの設定、ネットワークブリッジング、リンクアグリゲーション(ボンディング)の構成には、標準の Linux NetworkManager ツール(nmtui または nmcli 経由)または systemd-networkd の使用を推奨します。

DSI

マザーボードには **4レーン MIPI DSI(22ピン)**ディスプレイインターフェースが1個搭載されており、高解像度の組み込み LCD や産業用タッチパネルの接続専用に設計されています。

インターフェースの特徴

  • 高帯域幅伝送: 4レーンの物理リンク設計を採用しており、従来の2レーンインターフェースと比較して大幅に高いデータスループットを実現します。1080P、さらには 2K 解像度の HD ディスプレイもスムーズに駆動できます。
  • 物理フォームファクター: フリップロック機構を備えた 22ピン 0.5mm ピッチの FPC(フレキシブルプリント基板)コネクタを使用します。
  • Raspberry Pi エコシステム互換性: このインターフェースは物理的に後方互換性があり、標準の Raspberry Pi DSI スクリーンとの直接接続をサポートしているため、開発者はアクセサリの調達にかかるコストと手間を大幅に削減できます。

DSI の設定とテストガイド

reComputer-RK3576 では、MIPI DSI インターフェースは **Device Tree Overlays(DTBO)**を通じて管理されています。ユーザーは、接続するディスプレイ周辺機器に応じて必要なオーバーレイファイルを手動でロードする必要があります。 ターミナルを開き、Armbian の環境設定ファイルを編集します:

bash
sudo nano /boot/armbianEnv.txt

DSI スクリーンのオーバーレイを指定するため、ファイルの末尾に以下の行を追加します:

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

保存して終了します(nano で保存するには Ctrl + O を押して Enter、終了するには Ctrl + X を押します)。 パッケージリストを更新し、必要なマルチメディアおよびディスプレイ用プラグインがインストールされていることを確認します:

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

変更を適用するためにシステムを再起動します:

bash
sudo reboot

再起動後、システムがグラフィカルデスクトップ環境の初期化に成功したかどうかを確認します:

bash
echo $XDG_SESSION_TYPE

注:

x11 または wayland が出力された場合、DSI ディスプレイは正常に駆動されており、グラフィカルインターフェースに入っています。

FPC ケーブルの向き: FPC ケーブルを挿入する際は、金属接点の向きに細心の注意を払ってください。接点はコネクタ内部の接触ピンに向いている必要があります。ケーブルを逆向きに挿入すると、ショートが発生したりスクリーンが点灯しなかったりする可能性があります。挿入後はフリップロックが確実に固定されていることを確認してください。

ドライバとデバイスツリー: MIPI スクリーンは「プラグアンドプレイ」ではありません。ディスプレイを接続した後は、適切な Device Tree Overlays を適用する(例: armbian-add-overlay を使用する)か、/boot 内の DTB ファイルを変更することで、Armbian OS 上で対応するパネルドライバとバックライト制御ノードを有効化する必要があります。

タッチサポート: この22ピンインターフェースには、通常タッチフィードバック用の I2C 信号ピンが統合されています。MIPI タッチスクリーンを使用する場合は、ディスプレイドライバと I2C タッチ IC ドライバ(GT911 など)の両方が OS にロードされていることを確認してください。

CSI

マザーボードには **4レーン MIPI CSI(22ピン)**カメラインターフェースが2個独立して搭載されています。RK3576 の強力な ISP(Image Signal Processor)と内蔵 NPU に支えられたこのデュアル CSI 設計は、ステレオビジョンシステム、マシンビジョン検査ステーションの構築や、エッジ AI モデル推論向けの高フレームレート映像の直接ストリーミングに最適です。

インターフェースの特徴

  • デュアル4レーンアーキテクチャ: 2つの物理ポート(CSI_0CSI_1)を備え、それぞれフル4レーンのデータチャンネルを装備しており、2台の高解像度または高フレームレートの産業用カメラモジュールを同時に処理できます。
  • 物理フォームファクター: 22ピン 0.5mm ピッチの FPC コネクタを使用します。
  • Raspberry Pi エコシステム互換性: この22ピンコネクタは物理的にほぼピン互換であり、標準の Raspberry Pi CSI カメラとの直接接続をサポートしています(IMX219 / IMX477 センサーをベースとした純正またはサードパーティ製モジュールなど)。これにより、開発者はビジョンアルゴリズムを迅速に検証できます。

注:

互換性と選定: Seeed Studio によって公式に検証されたカメラモジュールの使用を強く推奨します。未検証または非標準のカメラを使用する場合、開発者が Linux V4L2(Video for Linux 2)ドライバを手動で移植する必要が生じる可能性があります。

ケーブル接続の基準: FPC ケーブルの金属接点の向きに十分注意してください。さらに、産業用途での展開やロボティクスフレームワークとの統合の際は、MIPI 信号が電磁干渉(EMI)に対して非常に敏感である点に留意してください。カメラのリボンケーブルの長さは30cm(12インチ)以内に抑えることを推奨します。

複数カメラの同時キャプチャ: Linux では、2台のカメラは通常 /dev/video0/dev/video1 として認識されます。AI アプリケーションやマルチメディアフレームワーク(GStreamer や OpenCV など)で両方のストリームを同時にキャプチャする必要がある場合は、適切なメモリ帯域幅の割り当てを確保し、ハードウェアアクセラレーションプラグインを活用して最適なパフォーマンスを得てください。

CSI の設定とテストガイド

このセクションでは、デュアル MIPI CSI カメラを同時に有効化する手順を説明します(Raspberry Pi Camera V3 を例として使用します)。 環境設定ファイルを編集します:

bash
sudo nano /boot/armbianEnv.txt

CAM0 と CAM1 の両方で V3 カメラドライバを有効化するため、ファイルの末尾に以下の行を追加します:

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

注: 複数のオーバーレイは半角スペース1つで区切る必要があります。 ファイルを保存し、デバイスを再起動します:

bash
sudo reboot

再起動後、v4l-utils ツールチェーンを使用してカメラのステータスを確認・テストします。 利用可能なカメラデバイスとノードを一覧表示します:

bash
v4l2-ctl --list-devices

特定のカメラ(例: /dev/video22)でサポートされるピクセルフォーマットと解像度を表示します:

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

カメラのフレームレートをベンチマークする: 特定の解像度とピクセルフォーマット(例: 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

GStreamer のコマンドラインツールをインストールします:

bash
sudo apt install gstreamer1.0-tools -y

以下のパイプラインを実行してリアルタイムのカメラ映像をプレビューします(device=/dev/video11v4l2-ctl --list-devices で取得した実際のビデオノードインデックスに置き換えてください):

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

HDMI

マザーボードには標準の HDMI(Type-A)ポートが1個搭載されており、主に外部モニタ、テレビ、産業用制御ディスプレイの接続を目的として設計されており、高精細で同期された音声・映像出力を提供します。

image57.png

インターフェースの特徴

  • 超高精細解像度: RK3576 の強力なマルチメディア機能に支えられ、このインターフェースは最大 4K の超高精細映像出力に対応しており、鮮明な GUI ダッシュボードや複数の監視映像ストリームの表示に最適です。
  • 音声・映像の同期: HDMI ポートは映像信号とデジタル音声信号を同時に伝送します。接続先のモニタにスピーカーが内蔵されている場合、追加の 3.5mm オーディオケーブルを必要とせず、HDMI 接続を通じてシステム音声を直接再生できます。
  • マルチディスプレイ対応: この HDMI ポートは、オンボードの Type-C(DP 1.4)や MIPI DSI インターフェースと同時に使用できます。開発者は、Linux OS 上で最大3画面にわたるクローンディスプレイまたは拡張デスクトップモードを構成できます。

注:

ケーブルの規格: 4K 解像度での安定性を確保し、画面のちらつきを防ぐため、HDMI 2.0 以上の規格に準拠した高品質ケーブルを必ず使用してください。

EDID と解像度の自動検出: OS(Armbian / Ubuntu など)は、起動時にモニタの EDID 情報を自動的に読み取り、最適な解像度を適用します。「No Signal」の問題が発生した場合は、SSH でログインし、xrandr コマンドを使用してディスプレイ出力のステータスをデバッグできます。

ヘッドレスモードでの運用: 物理モニタを接続せず、純粋にエッジコンピューティングノードとしてデバイスを展開する場合、OS はリソース節約のためデスクトップ UI のレンダリングを停止することがあります。それでもヘッドレス構成で VNC リモートデスクトップアクセスが必要な場合は、ポートに「ダミー HDMI プラグ(ディスプレイエミュレータ)」を接続することを推奨します。