Descripción de las interfaces

Ventilador

El reComputer RK3576 expone el control del ventilador a través del subsistema hwmon de Linux. La velocidad del ventilador puede leerse en tiempo real, y el ciclo de trabajo PWM puede configurarse manualmente o dejarse en manos del gobernador térmico automático.

Rutas del monitor de hardware

Zonas térmicas

Los valores de temperatura están en milésimas de grado Celsius; divide entre 1000 para obtener °C.

Lectura de la velocidad del ventilador

cat /sys/class/hwmon/hwmon6/fan1_input

La salida está en RPM. Ejemplo: 2161

Leer todas las temperaturas a la vez:

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

Control de la velocidad del ventilador

1. Cambia al modo manual:

echo 1 | sudo tee /sys/class/hwmon/hwmon6/pwm1_enable

2. Configura el valor PWM (0–255):

# Configurar al 50%
echo 128 | sudo tee /sys/class/hwmon/hwmon6/pwm1

3. Restaura el control térmico automático:

echo 2 | sudo tee /sys/class/hwmon/hwmon6/pwm1_enable

Script de control térmico automático

Este script ajusta la velocidad del ventilador según la temperatura del SoC y se ejecuta de forma continua en segundo plano.

#!/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

Guárdalo como fan-control.sh y ejecútalo:

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

Ejecutar en segundo plano:

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

Servicio systemd

1. Copia el script:

sudo cp fan-control.sh /usr/local/bin/fan-control.sh
sudo chmod +x /usr/local/bin/fan-control.sh

2. Crea el archivo de servicio:

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

3. Habilítalo e inícialo:

sudo systemctl daemon-reload
sudo systemctl enable fan-control
sudo systemctl start fan-control
sudo systemctl status fan-control

Referencia rápida

# Leer RPM del ventilador
cat /sys/class/hwmon/hwmon6/fan1_input

# Leer temperatura del SoC
echo "$(( $(cat /sys/class/thermal/thermal_zone0/temp) / 1000 ))°C"

# Velocidad máxima
echo 1 | sudo tee /sys/class/hwmon/hwmon6/pwm1_enable
echo 255 | sudo tee /sys/class/hwmon/hwmon6/pwm1

# Velocidad baja
echo 1 | sudo tee /sys/class/hwmon/hwmon6/pwm1_enable
echo 64 | sudo tee /sys/class/hwmon/hwmon6/pwm1

# Restaurar automático
echo 2 | sudo tee /sys/class/hwmon/hwmon6/pwm1_enable

Entorno probado

Indicador LED

Este dispositivo cuenta con tres indicadores LED integrados (Power, Status y User) en el panel frontal. Estos LED permiten a los usuarios monitorear la secuencia de encendido del hardware, observar el comportamiento del sistema en tiempo de ejecución y utilizar una interfaz totalmente programable para interacciones personalizadas de software.

• Estados de los LED y comportamiento predeterminado del hardware Bajo el firmware predeterminado del sistema, los LED presentan los siguientes comportamientos estándar durante el arranque y las operaciones posteriores al arranque:

• Esencial para desarrolladores: límites de control Antes de comenzar con el desarrollo secundario, es fundamental entender el enrutamiento de hardware subyacente de cada LED para evitar problemas de resolución innecesarios:

• ❌ LED Power (rojo): Control puramente por hardware. Este LED está cableado directamente al riel de alimentación principal. No existe ninguna GPIO ni interfaz del kernel conectada a él. No se puede controlar mediante software o comandos.

• ❌ LED Status (verde): Control por hardware a nivel de sistema. Este LED es gestionado físicamente por la lógica de gestión de energía del hardware subyacente o por el firmware del PMIC para reflejar la estabilidad del núcleo del sistema. No expone ninguna interfaz al espacio de usuario de Linux y no se puede controlar mediante software o comandos.

• LED User (RGB tricolor): ¡Totalmente controlable por el desarrollador! Se trata de una cápsula LED RGB conectada al expansor GPIO integrado (gpiochip6). Es el único indicador del dispositivo abierto a la programación personalizada y la automatización por software. De forma predeterminada, el sistema reserva el canal azul (USER_LED_B) como indicador de latido (heartbeat), dejando libres los canales rojo y verde.

• 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

# Encender
echo 1 | sudo tee /sys/class/leds/user-led/brightness
# Apagar
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.

# Modo Heartbeat
echo heartbeat | sudo tee /sys/class/leds/user-led/trigger
# Modo de temporizador personalizado (parpadeo)
# Habilitar el temporizador
echo timer | sudo tee /sys/class/leds/user-led/trigger
# Configurar los intervalos
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

La placa base proporciona un cabezal de expansión estándar de 40 pines en la parte superior, ofreciendo a los desarrolladores un conjunto completo de interfaces de hardware de bajo nivel. Estas incluyen alimentación, depuración y buses de comunicación industrial comunes (I2C, UART, SPI, CAN, etc.), lo que facilita la conexión de sensores externos, placas controladoras o la depuración a nivel de sistema.

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.

Experiencia lista para usar El dispositivo se entrega de serie con una tarjeta Micro SD Clase 10 de 32 GB incluida. Esta tarjeta ha pasado rigurosas pruebas de compatibilidad realizadas por Seeed Studio y es perfectamente capaz de gestionar las operaciones diarias de Armbian OS, las configuraciones básicas de red y las validaciones ligeras de algoritmos de IA en el edge, permitiendo a los desarrolladores empezar de inmediato.

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.

# Instalar el controlador PCIe
sudo dpkg -i hailort-pcie-driver_4.23.0_all.deb

# Reiniciar el sistema
sudo reboot

# Después del reinicio, verificar que el controlador esté cargado
lsmod | grep hailo

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

# Escanear y verificar el estado del dispositivo
hailortcli scan

# Crear y activar un entorno virtual
python3 -m venv hailo_env
source hailo_env/bin/activate

# Instalar la biblioteca Python de HailoRT
pip install hailort-4.23.0-cp311-cp311-linux_aarch64.whl

# Verificar la instalación y la conexión del dispositivo
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. Instalar las bibliotecas del sistema requeridas
sudo apt update
sudo apt install -y git libglib2.0-0 libgl1-mesa-glx

# 2. Clonar el repositorio oficial (se recomienda la rama más reciente)
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)

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

# Etiquetas de las 80 clases del dataset COCO
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.

# Enviar el paquete por ADB desde la PC a la placa
# Los paquetes opcionales incluyen:
#   - rknn3_rk182x_m2_installer_arm64.tgz (Módulo M.2)
adb push rknn3_rk182x_m2_installer_arm64.tgz /tmp/installer.tgz
adb shell "cd /tmp && tar xzf installer.tgz && ./install.sh"

# Nota: Un ciclo de apagado completo (apagado físico) es OBLIGATORIO para garantizar la carga correcta del hardware y el firmware.
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.

# Forzar la anulación del controlador y activar la vinculación
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

# Habilitar el registro BusMaster para activar el bus mastering de la tarjeta aceleradora
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. Crear espacio de trabajo
mkdir -p ~/rk_182x_work && cd ~/rk_182x_work

# 2. Clonar los repositorios Model Zoo y Toolkit
git clone --recursive https://github.com/airockchip/rknn3-model-zoo.git
git clone https://github.com/airockchip/rknn3-toolkit.git

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

# 4. Instalar dependencias
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 Esta ranura Mini-PCIe enruta internamente tanto las señales PCIe como USB, garantizando una excelente compatibilidad con la gran mayoría de los módulos de comunicación inalámbrica del mercado.

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

Dispositivos probados y verificados Para garantizar una compatibilidad y estabilidad del sistema óptimas, recomendamos encarecidamente usar los módulos Mini-PCIe que han sido completamente probados y verificados por Seeed Studio:

• 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 base cuenta con dos puertos independientes de Ethernet Gigabit (RJ45). El diseño de doble LAN la hace ideal para construir gateways industriales de edge, implementar aislamiento físico de red (intranet/extranet) o configurar enrutamiento de red complejo.

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.
• Compatibilidad con el ecosistema Raspberry Pi: La interfaz es físicamente retrocompatible, admitiendo conexiones directas a pantallas DSI estándar de Raspberry Pi, reduciendo significativamente el costo y el esfuerzo de conseguir accesorios para los desarrolladores.

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:

Si muestra x11 o wayland, la pantalla DSI funciona correctamente y ha entrado en la interfaz gráfica.

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 base cuenta con dos interfaces de cámara independientes MIPI CSI de 4 carriles (22 pines). Impulsado por el robusto ISP (Image Signal Processor) del RK3576 y su NPU integrada, el diseño de doble CSI es perfecto para construir sistemas de visión estéreo, estaciones de inspección de visión artificial o transmitir video de alta velocidad de fotogramas directamente para la inferencia de modelos de IA en el edge.

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.
• Compatibilidad con el ecosistema Raspberry Pi: El conector de 22 pines es física y mayormente compatible en cuanto a pines, admitiendo conexiones directas a cámaras CSI estándar de Raspberry Pi (como módulos oficiales o de terceros basados en sensores IMX219/IMX477). Esto permite a los desarrolladores validar rápidamente sus algoritmos de visión.

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.