Interfaces de hardware del reComputer RK3576

Última actualización: 2026-11-02

Esta guía explica cómo inspeccionar y utilizar las interfaces de hardware del reComputer RK3576 con Armbian. Usa los enlaces de sección para ir directamente al periférico que quieras conectar o probar.

Antes de empezar

• Completa la configuración del primer arranque e inicia sesión de forma local o por SSH con un usuario que pueda ejecutar sudo.
• Usa los diagramas de puertos y placa base para identificar el conector antes de conectar un periférico.
• Apaga el dispositivo y desconéctalo de la alimentación antes de instalar tarjetas internas, cables planos o cableado GPIO.
• Los nodos de dispositivo, números de bus e índices de hwmon que aparecen a continuación corresponden a la imagen de referencia. Confirma los dispositivos reales de tu sistema antes de copiar un comando que modifique alguna configuración.

Ventilador

Armbian expone el ventilador a través de hwmon de Linux. La imagen de referencia usaba /sys/class/hwmon/hwmon6, pero este índice puede variar. Busca el nodo llamado pwmfan antes de usar las rutas siguientes:

for node in /sys/class/hwmon/hwmon*; do
    [ -r "$node/name" ] || continue
    printf '%s: ' "$node"
    cat "$node/name"
done

Leer velocidad del ventilador y PWM

Para el nodo hwmon6 de referencia:

cat /sys/class/hwmon/hwmon6/fan1_input
cat /sys/class/hwmon/hwmon6/pwm1
cat /sys/class/hwmon/hwmon6/pwm1_enable

fan1_input muestra las RPM. pwm1 es un valor de solicitud de 0 a 255; no representa un porcentaje de las RPM medidas del ventilador. En la ejecución de referencia original se obtuvieron aproximadamente 2155 RPM y una temperatura de 36 °C en el SoC en reposo. Las lecturas reales dependen de la carga de trabajo y la temperatura.

Leer temperaturas

for zone in /sys/class/thermal/thermal_zone*; do
    [ -r "$zone/type" ] && [ -r "$zone/temp" ] || continue
    printf '%s: ' "$(cat "$zone/type")"
    awk '{printf "%.1f°C\n", $1 / 1000}' "$zone/temp"
done

Los valores de temperatura en sysfs se expresan en miligrados Celsius. El comando los convierte a °C y muestra el nombre reportado por cada zona.

Comprobar una escritura PWM

La documentación de pwm-fan de Linux define pwm1_enable como una política de PWM y regulador. Sus valores no proporcionan un conmutador universal entre modo manual y automático. En particular, escribir 2 no garantiza que se haya restablecido el control térmico automático.

Para una comprobación breve, guarda el valor PWM actual, solicita 128, vuelve a leerlo y restaura el valor guardado. Sustituye hwmon6 si tu ventilador se detectó en otro índice:

FAN_PWM=/sys/class/hwmon/hwmon6/pwm1
ORIGINAL_PWM=$(cat "$FAN_PWM")
printf '128\n' | sudo tee "$FAN_PWM"
cat "$FAN_PWM"
printf '%s\n' "$ORIGINAL_PWM" | sudo tee "$FAN_PWM"

El controlador térmico del kernel puede sobrescribir una solicitud manual. Una escritura exitosa no demuestra un control manual sostenido. Mantén el control térmico existente en la imagen; un controlador personalizado requiere validación frente al controlador del fabricante y el device tree en ejecución.

Indicador LED

El panel frontal incluye los LED de alimentación (Power), estado (Status) y usuario (User). El LED de usuario se puede controlar desde Linux; los demás indicadores reflejan el estado de alimentación y del sistema del dispositivo.

Antes de ejecutar los ejemplos, verifica qué LED deseas controlar:

• LED de alimentación (rojo): Controlado por hardware; no se proporciona interfaz de control desde Linux.
• LED de estado (verde): Indicador del sistema sin interfaz de control en espacio de usuario en esta configuración.
• LED de usuario (RGB): Conectado a través del expansor GPIO (gpiochip6 en la imagen de referencia). El canal azul se usa para el heartbeat; los canales rojo y verde están libres en esta configuración.
• Guía de control del LED RGB de usuario En el entorno Linux (por ejemplo, Armbian), se recomienda utilizar la cadena de herramientas moderna gpiod (gpioinfo / gpioset) para manipular los canales libres Rojo y Verde, y la interfaz estándar sysfs de Linux para controlar el canal Azul. Localizar el LED En el sistema, los LED se gestionan a través de la interfaz sysfs. Ejecuta el siguiente comando para verificar el nodo del LED:

ls /sys/class/leds/user-led

Salida esperada:

Control manual (ON/OFF) Antes de controlar el LED manualmente, debes establecer su modo de disparo (trigger) en none.

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

Encender/apagar el LED

# Turn ON
echo 1 | sudo tee /sys/class/leds/user-led/brightness
# Turn OFF
echo 0 | sudo tee /sys/class/leds/user-led/brightness

Modos de disparo automatizados El kernel proporciona varios triggers para automatizar el comportamiento del LED en función de eventos del sistema.

# Heartbeat Mode
echo heartbeat | sudo tee /sys/class/leds/user-led/trigger
# Custom Timer Mode (Blinking)
# Enable timer
echo timer | sudo tee /sys/class/leds/user-led/trigger
# Set intervals
echo 500 | sudo tee /sys/class/leds/user-led/delay_on
echo 500 | sudo tee /sys/class/leds/user-led/delay_off

Configuración persistente al arrancar Dado que los cambios en /sys son volátiles y se restablecen tras el reinicio, puedes hacerlos permanentes agregando una tarea cron o usando rc.local.

Botón

Las placas base de la serie reComputer RK3576 están equipadas con 3 botones físicos integrados, utilizados principalmente para el control de energía y el flasheo de firmware de bajo nivel.

Nota: Al usar Recovery o MaskROM para el flasheo, asegúrate de que el puerto Type-C OTG del dispositivo esté conectado al PC host mediante un cable de datos. Necesitarás usar herramientas oficiales de Rockchip (como RKDevTool para Windows o upgrade_tool para Linux) para ejecutar las operaciones.

GPIO

El conector de 40 pines expone GPIO, alimentación y buses periféricos como I2C, UART, SPI y CAN. Consulta la tabla de pines, el voltaje y la función activa de cada pin antes de conectar un sensor o una placa de expansión.

Tabla de asignación de pines de 40 pines

Uso de GPIO De forma predeterminada, la mayoría de los pines del cabezal de 40 pines funcionan como GPIO estándar, a menos que estén preasignados por controladores del sistema. Se recomienda el conjunto de herramientas estándar gpiod (gpiodetect, gpioinfo, gpioset, gpioget) para la manipulación a nivel de shell. Para manipular el pin físico 21 (especificado como GPIO general y actualmente libre):

• Localiza su controlador asignado y número de línea:

sudo gpioinfo | grep -i PIN_21

Salida:

line 14:     "PIN_21"       unused   input  active-high

Esto indica que pertenece a gpiochip1, línea 14.

• Establece el pin en alto (por ejemplo, para encender un LED):

gpioset gpiochip1 14=1

• Establece el pin en bajo:

gpioset gpiochip1 14=0

• Lee el estado de entrada del pin físico 27: Al consultar sudo gpioinfo | grep -i PIN_27 se muestra que corresponde a gpiochip4, línea 23:

gpioget gpiochip4 23

Para desbloquear el hardware periférico especializado (I2C, UART, CAN, PWM) etiquetado en la asignación de pines, debes habilitar explícitamente su Device Tree Overlay (DTBO) correspondiente. De lo contrario, seguirán funcionando simplemente como GPIO genéricos. Todas las configuraciones de overlay específicas de los 40 pines residen en /boot/dtb/rockchip/overlay/ y siguen el prefijo de nomenclatura estricto recomputer-rk3576-devkit-40pin-:

Procedimiento de configuración:

• Abre el archivo de configuración del entorno del sistema:

sudo nano /boot/armbianEnv.txt

• Localiza la línea overlays= (o añádela al final del archivo si no existe), luego inserta el nombre del overlay deseado sin la extensión .dtbo. Separa varios overlays con un espacio:

overlays=recomputer-rk3576-devkit-40pin-i2c3 recomputer-rk3576-devkit-40pin-can0

• Guarda y sal (Ctrl+O, Enter, Ctrl+X), luego reinicia el hardware para aplicar la modificación del device tree:

sudo reboot

Nota: SPI activo de forma predeterminada

Los pines del bus SPI (pines 19, 21, 23, 24, 26) están habilitados de forma predeterminada al arrancar. No necesitas asignar ningún DTBO personalizado para SPI en armbianEnv.txt.

Arquitectura de hardware compartida: Las señales SPI físicas del cabezal de 40 pines comparten exactamente el mismo dominio de bus de hardware con las ranuras de expansión integradas de 4G LTE / LoRaWAN / Hailo Wi-Fi. Para facilitar una experiencia lista para usar con estos módulos de comunicación, el sistema operativo base mantiene este canal SPI permanentemente activo.

Recomendación para desarrolladores: Si conectas placas breakout SPI personalizadas de terceros al cabezal de expansión de 40 pines, asegúrate de gestionar cuidadosamente el Chip Select (CS) y el direccionamiento para evitar bloqueos (deadlocks) en el bus de comunicación con los módulos integrados.

USB

Este dispositivo proporciona múltiples interfaces USB físicas asignadas a la serie reComputer RK3576. Estas interfaces gestionan la conexión de periféricos externos, el flasheo de firmware del sistema (OTG) y la salida de pantalla secundaria.

La asignación de recursos USB se define de la siguiente manera:

Usar lsusb te permite ver información sobre los dispositivos USB conectados al sistema:

Nota: arquitectura de la interfaz USB Type-C

A. Flasheo y mantenimiento del sistema (modo dispositivo USB OTG): Activado mediante las teclas Recovery/MaskROM, el puerto arranca en modo dispositivo para el flasheo de firmware de bajo nivel usando RKDevTool.

B. Salida DisplayPort (DP 1.4 Alt Mode): Multiplexa los carriles de video por hardware para controlar un monitor directamente a través de cables o adaptadores Type-C, ofreciendo pantallas DP 1.4 estándar.

C. Modo host nativo estándar: Por defecto funciona como un Host USB 3.0 estándar durante el funcionamiento normal del SO, para conectarse directamente a almacenamiento Type-C, adaptadores de red o hubs.

Ranura para tarjeta SD

La placa base está equipada con una ranura estándar para tarjeta Micro SD (TF), conectada directamente al bus SDMMC0 del SoC RK3576. Esta interfaz se utiliza principalmente para el arranque del sistema, la ejecución del sistema operativo (como Armbian OS) y el almacenamiento local de datos.

Usa la tarjeta microSD incluida para arrancar el sistema proporcionado, o prepara una tarjeta nueva siguiendo la guía de instalación de Armbian. Verifica el almacenamiento incluido con tu dispositivo antes de elegir el destino de instalación.

Nota: prioridad de arranque y recomendaciones de almacenamiento

Mecanismo de prioridad de arranque (etapa MaskROM): La secuencia de arranque del firmware en el RK3576 está estrictamente controlada por el MaskROM de bajo nivel. Si coexiste firmware de arranque tanto en la tarjeta Micro SD como en el eMMC integrado, el MaskROM priorizará la carga del SPL (Secondary Program Loader) desde la tarjeta Micro SD. Presta especial atención a esta característica física durante las actualizaciones de firmware o el cambio entre múltiples sistemas operativos.

Limitación de arranque NVMe (etapa U-Boot): Las unidades SSD NVMe M.2 NO están dentro de la ruta de arranque directa de MaskROM. El sistema no puede realizar el arranque de la etapa 1 directamente desde una unidad NVMe sin procesar. Para ejecutar el SO desde un SSD NVMe, el sistema primero debe ejecutar el bootloader desde la tarjeta Micro SD o el eMMC para entrar en la etapa U-Boot, donde U-Boot inicializará, cargará y entregará el control al SO principal alojado en el almacenamiento NVMe.

Recomendaciones de actualización para cargas de trabajo intensas: Si planeas desplegar aplicaciones con altas demandas de E/S de lectura/escritura en el edge (como ejecutar bases de datos grandes con registro local continuo, o gestionar clústeres complejos de contenedores Docker), el enorme volumen de lecturas/escrituras aleatorias de 4K puede alcanzar el cuello de botella de rendimiento de una tarjeta Clase 10 estándar. Para estos escenarios industriales exigentes, recomendamos migrar el rootfs del SO principal a un SSD NVMe M.2 (mediante carga en cadena desde U-Boot), o actualizar a una tarjeta Micro SD de alto rendimiento con clasificación explícita A1 o A2 (Application Performance Class) para garantizar una capacidad de respuesta óptima del sistema.

Punto de montaje: En Armbian OS, la tarjeta Micro SD normalmente se enumera como /dev/mmcblk0.

Ranura para tarjeta SIM

La placa base cuenta con una ranura integrada, diseñada explícitamente para funcionar con módulos celulares 4G LTE instalados en la ranura Mini-PCIe. Al insertar una tarjeta SIM de operador estándar, el dispositivo puede lograr conectividad celular de edge a nube en entornos sin Ethernet cableado.

Arquitectura y mecanismo de hardware Las líneas de señal de la ranura Nano SIM están conectadas directamente a los pines específicos (como UIM_PWR, UIM_DATA, UIM_CLK, UIM_RESET) de la ranura Mini-PCIe.

• Sin conexión directa al SoC: Ten en cuenta que las señales de la tarjeta SIM no se conectan directamente con el SoC RK3576. En su lugar, son gestionadas y controladas completamente por el módulo 4G instalado en la ranura Mini-PCIe. En consecuencia, la tarjeta SIM solo funcionará cuando un módulo 4G compatible esté activo.

Nota: notas para desarrolladores y estándares de operación

Estrictamente prohibido el hot-plugging: Inserta o retira siempre la tarjeta SIM con el dispositivo completamente apagado (alimentación DC o PoE desconectada). El hot-plugging de la tarjeta SIM mientras el sistema está en funcionamiento puede dañar permanentemente la interfaz SIM del módulo 4G o provocar fallos del sistema relacionados con la red.

Especificaciones del factor de forma: Esta ranura admite estrictamente tarjetas Nano SIM (4FF), el tamaño estándar más pequeño usado en los smartphones modernos. Evita usar tarjetas SIM Micro o Estándar con adaptadores de plástico económicos, ya que pueden atascarse fácilmente o doblar los pines internos de la ranura.

Orientación de inserción: Verifica el icono serigrafiado o la muesca estructural cerca de la ranura antes de la inserción. Normalmente, la tarjeta SIM debe insertarse con los contactos dorados hacia abajo y la esquina con muesca entrando primero (sigue la marca de alineación física en la placa).

Ranura M.2 Key M 2280

La placa base está equipada con una ranura estándar M.2 Key M 2280, impulsada por un bus PCIe 2.1 x1. Está diseñada para la expansión de almacenamiento de alta velocidad o la aceleración de computación de IA en el edge.

Dispositivos compatibles

• SSD NVMe: Admite unidades de estado sólido NVMe 2280 estándar para el arranque del sistema, almacenamiento de datos de alta capacidad o alojamiento de modelos de IA de gran tamaño.
• Acelerador de IA: Compatible con módulos aceleradores de IA basados en M.2 Key M para mejorar las capacidades de inferencia en el edge.

Dispositivos probados y verificados Para garantizar una compatibilidad y estabilidad del sistema óptimas, recomendamos encarecidamente usar los módulos de expansión M.2 que han sido completamente probados y verificados por Seeed Studio:

• Almacenamiento
  • SSD NVMe 2280 oficiales de Seeed Studio: https://www.seeedstudio.com/M-2-2280-SSD-128GB-p-5332.html
• Aceleradores de IA
  • Serie Rockchip: RK1820 / RK1828
  • Serie Hailo: Hailo-8
  • Serie DeepX: DX-M1

Nota:

Compatibilidad de protocolo: Esta ranura admite estrictamente dispositivos PCIe NVMe. Los SSD M.2 SATA NO son compatibles y el SO no los reconocerá.

Limitación de ancho de banda: La ranura opera en un carril PCIe 2.1 x1, proporcionando un ancho de banda máximo teórico de aproximadamente 500 MB/s. Al comprar un SSD NVMe, las unidades estándar económicas Gen3/Gen4 son suficientes; los SSD Gen4 de ultra alta velocidad se verán limitados por la interfaz PCIe 2.1 x1.

Factor de forma: El estándar de montaje está diseñado específicamente para módulos 2280 (22 mm x 80 mm).

Guía de uso del SSD

lsblk

Guía de despliegue e inferencia de Hailo YOLOv11

Instalación del paquete Después de instalar el driver PCIe base, es necesario reiniciar el sistema para que los cambios surtan efecto.

# Install the PCIe driver
sudo dpkg -i hailort-pcie-driver_4.23.0_all.deb

# Reboot the system
sudo reboot

# After reboot, verify the driver is loaded
lsmod | grep hailo

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

# Scan and verify device status
hailortcli scan

# Create and activate a virtual environment
python3 -m venv hailo_env
source hailo_env/bin/activate

# Install HailoRT Python library
pip install hailort-4.23.0-cp311-cp311-linux_aarch64.whl

# Verify installation and device connection
python3 -c "from hailo_platform import VDevice; vdev = VDevice(); print('Successfully connected via VDevice! Device info:', vdev)"

Instalar Hailo Model Zoo Para ejecutar modelos oficiales preentrenados, necesitas instalar Hailo Model Zoo y sus dependencias del sistema.

# 1. Install required system libraries
sudo apt update
sudo apt install -y git libglib2.0-0 libgl1-mesa-glx

# 2. Clone the official repository (latest branch recommended)
git clone https://github.com/hailo-ai/hailo_model_zoo.git
cd hailo_model_zoo
pip install -e .

Ejecutar el modelo YOLOv11

• Verificar dispositivos de cámara: Identifica el punto de montaje de tu webcam.

v4l2-ctl --list-devices

• Descargar el modelo: Asegúrate de que el archivo del modelo yolov11n.hef esté descargado y colocado en tu directorio de trabajo.

Crea un archivo llamado webcam_yolo11.py y pega el código a continuación. Ajusta HEF_PATH y DEVICE_ID en la sección de configuración para que coincidan con tu entorno.

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

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

# COCO Dataset 80 Class Labels
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()

Guía de despliegue e inferencia de RK182x

RK182x admite el modo coprocesador, en el que el SoC host (por ejemplo, RK3588/RK3576) actúa como núcleo del sistema, encargándose de la planificación de tareas, la asignación de recursos y el control general. Se conecta a la unidad de aceleración RK1820/RK1828 mediante PCIe de alta velocidad (típicamente entrenado a Gen2 x1 a 5 GT/s, proporcionando ~400 MB/s de ancho de banda unidireccional) o interfaces USB 3.0. Tanto RK1820 como RK1828 comparten el mismo ID de dispositivo PCI (1d87:182a). El framework de desarrollo consiste en la herramienta de conversión de modelos del lado del PC (RKNN3 Toolkit) y el entorno de ejecución del lado de la placa (RKNN3 Runtime).

Opción A: despliegue automatizado rápido (recomendado) Usar el paquete instalador automatizado precompilado del SDK permite un despliegue con un solo clic del driver del kernel, el firmware del dispositivo, las bibliotecas de runtime, las herramientas de depuración y los servicios de autoarranque del sistema.

# Push the package via ADB from PC to Board
# Optional packages include:
#   - rknn3_rk182x_m2_installer_arm64.tgz (M.2 Module)
adb push rknn3_rk182x_m2_installer_arm64.tgz /tmp/installer.tgz
adb shell "cd /tmp && tar xzf installer.tgz && ./install.sh"

# Note: A hard power cycle (physical power off) is MANDATORY to ensure proper hardware and firmware loading.
sudo poweroff

Si se requiere control manual sobre la vinculación del driver durante el desarrollo y la depuración, o al operar en un entorno sin el paquete automatizado instalado, ejecuta los siguientes comandos del bus del sistema en orden. Nota: RK1820 requiere la activación manual explícita de BusMaster después de la detección del driver.

# Force driver override and trigger binding
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

# Enable the BusMaster register to activate accelerator card bus mastering
sudo setpci -s 01:00.0 COMMAND=0x0406

El sistema host ejecuta Python 3.11 de forma predeterminada. Antes del despliegue, asegúrate de haber convertido tus modelos en una máquina x86 usando RKNN3 Toolkit al formato dedicado .rknn (tanto para LLM como para CNN) y de haber subido los archivos resultantes (por ejemplo, qwen2_5_1_5b_rk1820.rknn) al host.

# 1. Create workspace
mkdir -p ~/rk_182x_work && cd ~/rk_182x_work

# 2. Clone Model Zoo and Toolkit repositories
git clone --recursive https://github.com/airockchip/rknn3-model-zoo.git
git clone https://github.com/airockchip/rknn3-toolkit.git

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

# 4. Install dependencies
pip3 install -r requirements.txt

Ranura Mini-PCIe

La placa base cuenta con una ranura estándar Mini-PCIe (Mini PCI Express), diseñada principalmente para la expansión de módulos de comunicación inalámbrica de grado industrial como 4G LTE, LoRaWAN o Wi-Fi HaLow.

Arquitectura de señal y bus La ranura Mini-PCIe expone señales PCIe y USB. La compatibilidad de un módulo también depende de sus requisitos eléctricos y del controlador de Linux; que el conector encaje no garantiza por sí solo la compatibilidad.

• Expansión celular: Junto con la ranura para tarjeta Nano SIM integrada, permite la inserción directa de módulos 4G LTE para habilitar la conectividad de red celular.

Tipos de módulos tratados a continuación Las siguientes secciones cubren estas categorías de módulos. Revisa el módulo específico y el controlador utilizado en cada ejemplo:

• Red celular 4G
  • Módulo Mini-PCIe 4G LTE oficialmente recomendado
• LoRaWAN e IoT inalámbrico
  • Módulos de gateway LoRaWAN basados en USB/SPI
  • Módulos inalámbricos de largo alcance y bajo consumo Wi-Fi HaLow (802.11ah)

Nota:

Integración de tarjeta SIM: Al usar un módulo 4G LTE, inserta la tarjeta Nano SIM en la ranura integrada con el dispositivo apagado. El hot-plugging de la tarjeta SIM puede provocar fallos de reconocimiento del módulo o daños permanentes.

Enrutamiento de antena: Dado que los gabinetes industriales pueden bloquear las señales inalámbricas, conecta siempre pigtails IPEX a SMA para enrutar las antenas fuera del chasis al desplegar módulos 4G o LoRaWAN.

Configuración de driver y red: La mayoría de los módulos 4G industriales requieren drivers seriales USB específicos (como el driver option) en Armbian OS. Los desarrolladores pueden usar NetworkManager o pppd para establecer conexiones celulares.

Guía de configuración y prueba del módulo 4G (EC25)

Configuración celular mediante comandos AT Conecta el módulo 4G con la tarjeta SIM IoT, arranca el sistema y verifica los dispositivos seriales USB:

lsusb
ls /dev/ttyUSB*

Instala e inicia minicom para comunicarte con el módulo:

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

Referencia rápida de comandos AT principales

Inspección detallada del estado y flujo de trabajo de marcado Verificación del estado de la tarjeta SIM: Envía AT+CPIN? para verificar el estado de la SIM.

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

Verificación de calidad de señal (RSSI): Envía AT+CSQ para evaluar el entorno inalámbrico.

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

Verificación de registro de red: Envía AT+CGREG? y AT+CREG? para verificar la vinculación celular.

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.

Consulta del operador actual: Envía AT+COPS? para verificar el operador y el modo de red.

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.

Activación del contexto de datos: Consulta mediante AT+QIACT?, luego activa el contexto usando AT+QIACT=1.

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.

Nota: Las llamadas de voz pueden iniciarse mediante ATD<number>; si el hardware y el plan del operador admiten voz/datos simultáneos.

Prueba de ping integrada: Ejecuta AT+QPING para verificar la conectividad a nivel IP directamente desde el módulo.

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.

Solución de problemas

Guía de configuración y prueba del módulo LoRa

USB

Verificar el reconocimiento del dispositivo

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

La salida esperada incluye:

E: ID_MODEL=STM32_Virtual_ComPort
E: ID_VENDOR=STMicroelectronics

Comando de prueba TX

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

Salida esperada

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

Errores comunes y soluciones

Nota: No ejecutes reset_lgw.sh antes de probar módulos en modo USB. El script de reinicio alterna pines GPIO que ciclan la alimentación del módulo y provocan la desconexión USB. El MCU STM32 gestiona internamente el reinicio del SX1302.

SPI

Verificar el reconocimiento del dispositivo

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

La salida esperada incluye:

E: ID_MODEL=STM32_Virtual_ComPort
E: ID_VENDOR=STMicroelectronics

Comando de prueba TX

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

Salida esperada

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

Guía de configuración y prueba del módulo Wi-Fi HaLow

Wi-Fi HaLow requiere un device tree overlay para exponer el bus SPI y la configuración GPIO del chip MM6108.

Añade el overlay a la configuración del entorno de Armbian:

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

Verifica el archivo antes de reiniciar:

tail -2 /boot/armbianEnv.txt

Salida esperada:

Reinicia para aplicar el overlay:

sudo reboot

Después de reiniciar, confirma que el driver se cargó y que la interfaz apareció:

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

Salida esperada:

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

Los binarios morse-hostapd y morse-wpa_supplicant llaman internamente a morse_cli, pero el binario instalado se llama morsectrl. Se requiere un enlace simbólico.

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

Esto solo necesita hacerse una vez.

Comprueba las interfaces:

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

Modo AP Crea la configuración:

sudo nano /etc/morse-hostapd.conf

Configuración mínima funcional:

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

Baja la interfaz e inicia el AP:

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

Salida esperada (éxito):

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

Nota: Las advertencias Unable to set RAW no son fatales. Aparecen porque la versión del driver instalado no admite RAW (Restricted Access Window). El AP se inicia con normalidad.

Verifica el estado del AP:

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

Modo Station Crea la configuración:

sudo nano /etc/morse-wpa_supplicant.conf

Configuración mínima:

ctrl_interface=/var/run/wpa_supplicant
country=AU

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

Conéctate:

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

Verifica la conexión:

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

Ethernet RJ45

La placa dispone de dos puertos Gigabit Ethernet (RJ45). Conecta cualquiera de los dos a la red para la configuración inicial; para crear un puente o enrutar entre ambos puertos se requiere configuración de software adicional.

Definiciones y características de los puertos:

• 1x Ethernet Gigabit estándar (GbE): Admite conexión Ethernet con autonegociación de 10/100/1000 Mbps.
• 1x Ethernet Gigabit con PoE (GbE con PoE PD): Además de la red Gigabit estándar, este puerto admite el protocolo PoE PD (Powered Device).

Nota: Como dispositivo alimentado por PoE (PD), esta placa base RK3576 puede recibir alimentación directamente a través del cable Ethernet desde un switch PoE (PSE), eliminando la necesidad de un adaptador de corriente DC independiente.

Nota:

Requisito de módulo PoE: La función de recepción de alimentación PoE no está integrada directamente en la placa base. Requiere un módulo adicional PoE, adquirido por separado. Sin este módulo instalado, el puerto funciona únicamente como un puerto Ethernet Gigabit estándar.

Aclaración PD vs. PSE: Ten en cuenta que este dispositivo actúa como PoE PD (receptor de alimentación). NO admite salida PoE (PSE), lo que significa que no puede suministrar energía a dispositivos externos como cámaras IP PoE.

Configuración de red del sistema: En Armbian OS, estos dos puertos físicos normalmente se enumeran como eth0 y eth1. Recomendamos usar la herramienta estándar NetworkManager de Linux (mediante nmtui o nmcli) o systemd-networkd para configurar direcciones IP estáticas, puentes de red o agregación de enlaces (bonding).

DSI

La placa base está equipada con una interfaz de pantalla MIPI DSI de 4 carriles (22 pines), diseñada específicamente para conectar LCD embebidos de alta resolución o paneles táctiles industriales.

Características de la interfaz

• Transmisión de alto ancho de banda: Utiliza un diseño de enlace físico de 4 carriles, ofreciendo un rendimiento de datos significativamente superior en comparación con las interfaces tradicionales de 2 carriles. Puede controlar sin problemas pantallas HD de resolución 1080P o incluso 2K.
• Factor de forma físico: Usa un conector FPC (Flexible Printed Circuit) de 22 pines con paso de 0,5 mm con mecanismo de bloqueo abatible.
• Selección de pantalla: Usa el cable y el overlay correspondientes al panel exacto del ejemplo. Verifica el pinout y la compatibilidad del controlador antes de conectar otra pantalla de Raspberry Pi.

Guía de configuración y prueba de DSI

En el reComputer-RK3576, la interfaz MIPI DSI se gestiona mediante Device Tree Overlays (DTBO). Los usuarios deben cargar manualmente el archivo overlay requerido según el periférico de pantalla conectado. Abre la terminal y edita el archivo de configuración del entorno de Armbian:

sudo nano /boot/armbianEnv.txt

Añade la siguiente línea al final del archivo para especificar el overlay de la pantalla DSI:

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

Guarda y sal (presiona Ctrl + O, luego Enter para guardar en nano, y Ctrl + X para salir). Actualiza las listas de paquetes y asegúrate de que los complementos multimedia y de pantalla necesarios estén instalados:

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

Reinicia el sistema para aplicar los cambios:

sudo reboot

Después de reiniciar, verifica si el sistema inicializó correctamente el entorno de escritorio gráfico:

echo $XDG_SESSION_TYPE

Nota:

x11 o wayland identifica la sesión de escritorio actual. Esto no verifica por sí solo la pantalla DSI; confirma también que el panel muestra imagen y, si aplica, que la entrada táctil funciona.

Orientación del cable FPC: Al insertar el cable FPC, presta especial atención a la orientación de los contactos dorados. Deben mirar hacia los pines de contacto dentro del conector. Insertar el cable al revés puede causar un cortocircuito o impedir que la pantalla se encienda. Asegúrate de que el bloqueo abatible quede firmemente cerrado tras la inserción.

Drivers y device tree: Las pantallas MIPI no son "plug-and-play". Después de conectar una pantalla, debes habilitar el driver de panel correspondiente y los nodos de control de retroiluminación en Armbian OS aplicando los Device Tree Overlays adecuados (por ejemplo, usando armbian-add-overlay) o modificando los archivos DTB en /boot.

Soporte táctil: Esta interfaz de 22 pines normalmente integra pines de señal I2C para retroalimentación táctil. Si usas una pantalla táctil MIPI, asegúrate de que tanto el driver de la pantalla como el driver del controlador táctil I2C (por ejemplo, GT911) estén cargados en el sistema operativo.

CSI

La placa tiene dos conectores de cámara MIPI CSI de 4 carriles (22 pines). El ejemplo siguiente configura módulos Raspberry Pi Camera V3. Usa el cable, el controlador de cámara y el overlay adecuados para tu sensor.

Características de la interfaz

• Arquitectura dual de 4 carriles: Proporciona dos puertos físicos (CSI_0 y CSI_1), cada uno equipado con un canal de datos completo de 4 carriles, capaz de manejar simultáneamente dos módulos de cámara industrial de alta resolución o alta velocidad de fotogramas.
• Factor de forma físico: Usa un conector FPC de 22 pines con paso de 0,5 mm.
• Selección de cámara: Verifica el pinout, la orientación del cable, el controlador del sensor y la compatibilidad de imagen para la cámara exacta. Un conector de 22 pines coincidente no es suficiente para confirmar la compatibilidad.

Nota:

Compatibilidad y selección: Recomendamos encarecidamente usar módulos de cámara verificados oficialmente por Seeed Studio. Las cámaras no verificadas o no estándar pueden requerir que los desarrolladores porten manualmente los drivers V4L2 (Video for Linux 2) de Linux.

Estándares de conexión del cable: Presta especial atención a la orientación de los contactos dorados del cable FPC. Además, durante el despliegue industrial o la integración con frameworks de robótica, ten en cuenta que las señales MIPI son altamente sensibles a la interferencia electromagnética (EMI). Se recomienda mantener la longitud del cable plano de la cámara por debajo de 30 cm (12 pulgadas).

Captura simultánea multi-cámara: En Linux, las dos cámaras normalmente se enumeran como /dev/video0 y /dev/video1. Si tu aplicación de IA o framework multimedia (como GStreamer u OpenCV) necesita capturar ambos flujos simultáneamente, asegúrate de una asignación adecuada del ancho de banda de memoria y utiliza complementos acelerados por hardware para un rendimiento óptimo.

Guía de configuración y prueba de CSI

Esta sección te guía a través de la habilitación simultánea de dos cámaras MIPI CSI (usando la Raspberry Pi Camera V3 como ejemplo). Edita el archivo de configuración del entorno:

sudo nano /boot/armbianEnv.txt

Añade la siguiente línea al final del archivo para habilitar los drivers de la cámara V3 tanto para CAM0 como para CAM1:

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

Nota: Varios overlays deben separarse con un único espacio. Guarda el archivo y reinicia el dispositivo:

sudo reboot

Después de reiniciar, usa la cadena de herramientas v4l-utils para verificar y probar el estado de la cámara. Lista los dispositivos y nodos de cámara disponibles:

v4l2-ctl --list-devices

Muestra los formatos de píxel y resoluciones compatibles para una cámara específica (por ejemplo, /dev/video22):

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

Prueba de referencia de la velocidad de fotogramas de la cámara: prueba el rendimiento de la transmisión bajo una resolución y formato de píxel específicos (por ejemplo, 3280x2464 MJPG):

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

Instala las herramientas de línea de comandos de GStreamer:

sudo apt install gstreamer1.0-tools -y

Ejecuta el siguiente pipeline para previsualizar la transmisión de la cámara en tiempo real (reemplaza device=/dev/video11 con el índice real del nodo de video obtenido de v4l2-ctl --list-devices):

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

HDMI

La placa base cuenta con un puerto estándar HDMI (Type-A), diseñado principalmente para conectar monitores externos, televisores o pantallas de control industrial, proporcionando salida de audio y video sincronizados en alta definición.

Características de la interfaz

• Resolución Ultra-HD: Impulsada por las robustas capacidades multimedia del RK3576, esta interfaz admite salida de video en ultra alta definición hasta 4K, ideal para renderizar dashboards de GUI nítidos o múltiples flujos de video de vigilancia.
• Sincronización de audio y video: El puerto HDMI transmite simultáneamente señales de video y audio digital. Si tu monitor conectado tiene altavoces integrados, el audio del sistema se reproducirá directamente a través de la conexión HDMI sin necesidad de un cable de audio de 3,5 mm adicional.
• Soporte multipantalla: Este puerto HDMI puede funcionar simultáneamente con las interfaces integradas Type-C (DP 1.4) y MIPI DSI. Los desarrolladores pueden configurar pantallas clonadas o modos de escritorio extendido en hasta tres pantallas dentro del SO Linux.

Nota:

Estándares de cable: Para garantizar la estabilidad y evitar parpadeos de pantalla en resoluciones 4K, utiliza estrictamente cables de alta calidad que cumplan con las especificaciones HDMI 2.0 o superiores.

Autodetección de EDID y resolución: El sistema operativo (por ejemplo, Armbian/Ubuntu) lee automáticamente la información EDID del monitor al arrancar para aplicar la resolución óptima. Si encuentras un problema de "Sin señal", puedes iniciar sesión mediante SSH y usar el comando xrandr para depurar el estado de salida de la pantalla.

Operaciones en modo headless: Si estás desplegando el dispositivo puramente como un nodo de computación en el edge sin un monitor físico, el SO puede suspender el renderizado de la interfaz de escritorio para ahorrar recursos. Si aún necesitas acceso a escritorio remoto VNC en una configuración headless, recomendamos conectar un "Dummy HDMI Plug (emulador de pantalla)" al puerto.