1. Información general
Este artículo presenta la solución de AliOS Things para conectar chips WAN externos USB a la nube. La solución de red de dispositivos de Internet de las cosas se puede dividir en un método OpenCPU y un método de chip de comunicación externo. La capa de aplicación y la capa de red de OpenCPU se ejecutan en el mismo chip. Este método tiene un alto grado de integración, pero hace que las aplicaciones y los protocolos estén acoplados en términos de interfaz, configuración, rendimiento, etc., lo que no favorece la portabilidad y promoción de la solución.
El uso de un método de conexión externa puede separar la capa de aplicación y la capa de red, reducir mejor el acoplamiento y mejorar la flexibilidad de la solución de red. Por ejemplo, la MCU ejecuta el protocolo de capa de aplicación MQTT y el chip de comunicación externo (como Wi-Fi, LTE) completa la conexión TCP / IP y la transmisión de la capa de red. Por supuesto, el costo de un chip de comunicación externo es el mayor costo de interacción entre la MCU y el chip de comunicación, y los desarrolladores deben elegir un método de conexión externo adecuado para el escenario de la aplicación.
AliOS Things admite múltiples métodos de conexión entre MCU y chip de comunicación, como UART, SPI, SDIO, USB. Estos métodos de conexión no solo amplían las soluciones de red opcionales desarrolladas en base a AliOS Things, sino que también cumplen con los requisitos de velocidad de transmisión de diferentes escenarios de aplicación, como se muestra en la Tabla 1. Entre ellos, HAAS100 se conecta a LTE a través de USB, lo que puede realizar un reemplazo perfecto entre diferentes módulos del mismo fabricante, como EC20 y EC200S.
| interfaz | Tasa máxima (Mbps) | Ejemplos de escenarios de aplicación | Chip de comunicación MCU + | |
| 1 | UART | 1,5 | Developerkit, WiFi | STM32L496 + BK7231 |
| 2 | SPI | 20 | HAAS100, Ethernet | HAAS1000 + CH395 |
| 4 | USB | 12 | HAAS100 ， LTE | HAAS1000 + EC20 |
Tabla 1 Métodos externos y escenarios de aplicación compatibles con AliOS Things
2. Ventajas del chip de comunicación externo USB
El USB en sí tiene las ventajas de un uso conveniente, transmisión de datos confiable, bajo costo y ahorro de energía. El uso de USB como canal para un chip de comunicación externo conservará estas ventajas, específicamente las siguientes:
2.1, fácil de usar
- Se puede usar una interfaz para conectar varios dispositivos, y los usuarios pueden reemplazar fácilmente el chip de comunicación para conectarse sin usar diferentes conectores y cables para diferentes chips de comunicación.
- Configuración automática: después de conectar el chip de comunicación, el lado de la MCU puede identificar automáticamente el chip de comunicación y cargar el controlador correspondiente.
- Admite intercambio en caliente, los usuarios pueden acceder o desconectar el chip de comunicación en cualquier momento sin dañar el dispositivo de hardware o reiniciar el dispositivo.
- No se requiere fuente de alimentación adicional. La interfaz USB proporciona un voltaje de + 5 V y una corriente por debajo de 500 mA. Generalmente, el chip de comunicación no necesita una fuente de alimentación adicional.
2.2, transmisión de datos confiable
- Las especificaciones de hardware del receptor y del cable garantizan que la transmisión de datos se realice en un entorno eléctrico de interfaz tranquilo, evitando la mayor parte de las interferencias de ruido que provocan errores de datos.
- El modo de transmisión diferencial, USB 1.1 / 2.0 adopta el modo de cuatro cables, donde D + / D- es el canal de transmisión de datos, y se adopta el modo de transmisión de la señal diferencial. D + / D- debe cumplir con las condiciones de nivel al mismo tiempo para ser juzgado como 0 o 1, lo que reduce el factor La posibilidad de salto de bits causado por interferencias.
- Comprobación CRC, el hardware USB viene con comprobación CRC, que puede detectar errores durante la transmisión.
- El protocolo confirma la retransmisión USB proporciona un mecanismo de reconocimiento (ACK / NACK) y retransmisión a nivel de protocolo para recuperarse de errores de transmisión.
2.3. Bajo costo y ahorro de energía
- El costo de los componentes USB es bajo, ya sea que se utilice un controlador independiente o una solución IP integrada, el costo se puede controlar dentro de un rango razonable. Y desde la perspectiva de la escalabilidad, USB puede admitir más tipos de conexiones de dispositivos sin cambios de hardware.
- El USB utiliza circuitos y protocolos de ahorro de energía, combinados con las funciones de suspensión y activación del chip de comunicación, para lograr un bajo consumo de energía en general.
3. Realice un chip de comunicación externo basado en el canal USB
Para realizar el chip de comunicación externo basado en el canal USB, además de garantizar que la MCU tenga la capacidad de hardware de conexión USB, el lado de la MCU también necesita implementar la pila de protocolos de host USB para completar
- Identificación del dispositivo
- Carga del controlador
- transmisión de datos
Figura 1 La estructura de la pila de protocolos de host USB en el lado de la MCU, incluida la capa de controlador de host, la capa de núcleo de host, la capa de clase de host y la capa de controlador de dispositivo USB
La pila de protocolos de host USB en el lado de la MCU se divide aproximadamente en cuatro capas: capa de controlador de host, capa de núcleo de host, capa de clase de host y capa de controlador de dispositivo USB. Entre ellos, Host Controlle es la capa inferior de la pila de protocolos de host USB, responsable de interactuar directamente con el hardware, leer y escribir registros y procesar interrupciones; Host Core es la capa central de la pila de protocolos, responsable de administrar los controladores, dispositivos, interfaces y puntos finales del host, y responsable de los dispositivos. La enumeración es responsable del registro de la clase de host, la configuración del dispositivo y el procesamiento de solicitudes de transmisión; la capa de clase de host es la capa de implementación de cada clase de host USB, como HID, CDC, UVC, etc. Finalmente, la capa de controlador de dispositivo se utiliza para implementar la lógica de interacción de la aplicación con el dispositivo USB, como interactuar con el EC20 a través de comandos AT. Los detalles de diseño de cada capa se introducirán en detalle en otro artículo y no se ampliarán aquí. Esta sección presentará la implementación del chip de comunicación externo USB en torno a la identificación de dispositivos, la carga de controladores y la transmisión de datos.
3.1, identificación del equipo
Cuando el chip de comunicación está conectado a la MCU a través de USB, se producirá el siguiente diálogo entre los dos.
Host：你是什么设备？
Device: 12 01 0100... /* Device Descriptor */
Host：你有几种功能？
Device：09 02 09... /* Configuration Descriptor */
Host：每个功能有几个接口？
Device: 09 04 00... /* Interface Descriptor */
Host：每个接口使用哪几个端点？
Device: 06 05 82... /* Endpoint Descriptor */
Host: 我知道你是谁了，开始传输
Device: OK
....El propósito de estas preguntas y respuestas es ayudar al host USB a identificar con precisión el dispositivo conectado. La información interactiva incluye principalmente descriptores de dispositivo, descriptores de configuración, descriptores de interfaz y descriptores de punto final.
3.2, carga de clases
Al final del proceso de enumeración, el controlador se cargará según la clase del dispositivo. Hay dos métodos de carga, uno se carga por dispositivo y el otro se carga por interfaz. Tomando EC20 como ejemplo, sus interfaces son todas clases de proveedores y no se pueden cargar de acuerdo con las clases de interfaces. Por lo tanto, es necesario cargar la clase correspondiente de acuerdo con el ID de proveedor (VID) y el ID de producto (PID) del dispositivo.
De hecho, para este tipo de dispositivo USB WAN personalizado por el proveedor, la solución del controlador USB de Linux utiliza un archivo especial (usb / serial / option.c) para almacenar la lista de VID y PID del proveedor; durante la enumeración, Si el VID del dispositivo USB coincide con el PID, cargue el controlador correspondiente (usb / serial / wwan.c) para su procesamiento. Como se mencionó anteriormente, EC20 tiene 5 interfaces, entre las cuales la interfaz 0 es una interfaz DM, la interfaz 1 es una interfaz GPS, la interfaz 2 es una interfaz AT, la interfaz 3 es una interfaz PPP y la interfaz 4 es una interfaz NDIS, como se muestra en la Figura 5. Dado que los recursos del lado de la PC son suficientes, Linux USB Host puede crear los puntos finales correspondientes para cada interfaz al enumerar EC20 y permitir a los usuarios operar estas interfaces (abrir / leer / escribir) al mismo tiempo.
Figura 4 Funciones de la interfaz USB EC20
Sin embargo, los recursos del controlador USB en el chip MCU que ejecuta RTOS son limitados y los puntos finales requeridos por tantas interfaces no se pueden crear al mismo tiempo. Tomando HAAS1000 como ejemplo, además del punto final de control 0, su controlador USB tiene solo 4 puntos finales disponibles para su uso. Por lo tanto, es necesario considerar las limitaciones de recursos de hardware subyacentes durante el proceso de enumeración en la MCU; de lo contrario, el controlador no se cargará. La estrategia adoptada aquí es reutilizar los puntos finales. Al cargar el controlador, seleccione la interfaz de una manera específica: primero asigne los recursos del punto final para la interfaz 2 para la interacción del comando AT para asegurarse de que el módulo 4G esté conectado a la red y obtenga la IP; luego, cuando sea necesario utilizar otras interfaces, se liberan los recursos del punto final del punto final 2.
3.3, interacción de datos
Una vez cargada la clase, la capa superior puede recibir y enviar datos a través del canal USB. Tomando la interfaz AT de EC20 como ejemplo, el marco del controlador AT (SAL + AT Utility) de AliOS Things puede ejecutarse sin problemas en la pila de protocolos USB.
Figura 5 Canal AT basado en la pila de protocolos USB
Lo que hay que hacer es utilizar la API de clase USB para implementar el HAL (at_dev_ops_t) requerido por AT Utility, como se muestra a continuación.
/*
* AT dev operation type
*/
typedef struct {
at_dev_type_t type;
/**
* AT device init
*
* @return 0 - success, -1 - failure
*/
int (*init)(void *dev);
/**
* Receive data from AT device
*
* @return 0 - success, -1 - failure
*/
int (*recv)(void *dev,
void *data,
uint32_t expect_size,
uint32_t *recv_size,
uint32_t timeout);
/**
* Send data to AT device.
*
* @return 0 - success, -1 - failure
*/
int (*send)(void *dev,
void *data,
uint32_t size,
uint32_t timeout);
/**
* AT deviec deinit
*
* @return 0 - success, -1 - failure
*/
int (*deinit)(void *dev);
} at_dev_ops_t;Sobre esta base, utilice AT Utility API para implementar el HAL (sal_op_t) requerido por SAL, como se muestra a continuación.
typedef struct sal_op_s {
struct sal_op_s * next; //<! Next sal_op_t structure
char *version; //<! Reserved for furture use.
char *name; //<! Drvier name
/* Add sal device */
int (*add_dev)(void*);
/**
* Module low level init so that it's ready to setup socket connection.
*
* @return 0 - success, -1 - failure
*/
int (*init)(void);
/**
* Start a socket connection via module.
*
* @param[in] c - connect parameters which are used to setup
* the socket connection.
*
* @return 0 - success, -1 - failure
*/
int (*start)(sal_conn_t *c);
/**
* Send data via module.
* This function does not return until all data sent.
*
*/
int (*send_data)(int fd, uint8_t *data, uint32_t len,
char remote_ip[16], int32_t remote_port, int32_t timeout);
/**
* Get IP information of the corresponding domain.
* Currently only one IP string is returned (even when the domain
* coresponses to mutliple IPs). Note: only IPv4 is supported.
*
*
* @return 0 - success, -1 - failure
*/
int (*domain_to_ip)(char *domain, char ip[16]);
/**
* Close the socket connection.
*
* @return 0 - success, -1 - failure
*/
int (*finish)(int fd, int32_t remote_port);
/**
* Destroy SAL or exit low level state if necessary.
*
* @return 0 - success, -1 - failure
*/
int (*deinit)(void);
/**
* Register network connection data input function
* Input data from module.
* This callback should be called when the data is received from the module
* It should tell the sal where the data comes from.
*
* @return 0 - success, -1 - failure
*/
int (*register_netconn_data_input_cb)(netconn_data_input_cb_t cb);
} sal_op_t;Después de completar el acoplamiento anterior, la aplicación superior se puede programar según la API de socket estándar, lo que reduce el costo de migración de la capa de aplicación. Para la introducción de componentes relacionados con el variador AT, consulte el documento de ayuda de AliOS Things sobre los componentes SAL y los componentes AT .
4. Ejemplo de módulo 4G externo HaaS100
Figura 6 HaaS100 se conecta a EC20 a través de USB
Figura 7 Cableado de encabezado de clavija utilizado por USB
El encabezado de clavijas en la placa HaaS100 proporciona clavijas USB, que se pueden conectar al cable de extensión del puerto USB hembra para conectarse al módulo de comunicación, como se muestra en las Figuras 6 y 7.
Paso 1: configurar
aos make linkkit_demo@haas100 -c config
Paso 2: selección de la configuración
aos make menuconfigConfiguración
Paso 3: compila
aos make
Paso 4: grabar
Consulte HaaS para comenzar rápidamente .
Paso cinco: empezar
La aplicación ejecuta la demostración de Linkkit. Una vez que la enumeración USB se realiza correctamente, se puede conectar a la plataforma Alibaba Cloud IoT a través del canal AT.
5. Resumen
Los módulos de comunicación WAN generalmente proporcionan canales USB y admiten métodos de comunicación como AT, PPP, RNDIS y ECM. Por lo tanto, la pila de protocolos USB se admite en el lado de la MCU, que puede identificar y enumerar automáticamente varios dispositivos de comunicación y cargar los controladores necesarios para facilitar el desarrollo de nivel superior del usuario. Este artículo presenta brevemente la pila de protocolos USB Host de AliOS Things, y utiliza EC20 como ejemplo para describir el proceso de reconocimiento de enumeración. Al mismo tiempo, también muestra la forma de conectar el canal AT tradicional de AliOS Things en el canal USB. En la serie de artículos de seguimiento relacionados, presentaremos los métodos PPP, RNDIS y ECM basados en el canal USB y brindaremos los datos de comparación correspondientes. Manténganse al tanto.
Si necesita más soporte técnico, puede unirse al Grupo de desarrolladores de Dingding
Para obtener más información sobre la tecnología y la introducción de soluciones, visite la página de inicio de Aliyun AIoT https://iot.aliyun.com/