AliOS Things is based on the USB channel external 4G module solution

1 Overview

This article introduces AliOS Things's solution for connecting USB external WAN chips to the cloud. The Internet of Things device networking solution can be divided into an OpenCPU method and an external communication chip method. The application layer and network layer of OpenCPU run on the same chip. This method has a high degree of integration, but it makes applications and protocols coupled in terms of interface, configuration, performance, etc., which is not conducive to the porting and promotion of the solution.

 

Using an external connection method can separate the application layer and the network layer, better reduce the coupling, and improve the flexibility of the networking solution. For example, the MCU runs the MQTT application layer protocol, and the external communication chip (such as Wi-Fi, LTE) completes the TCP/IP connection and transmission of the network layer. Of course, the cost of an external communication chip is the increased interaction cost between the MCU and the communication chip, and developers need to choose an external connection method suitable for the application scenario.

 

AliOS Things supports multiple connection methods between MCU and communication chip, such as UART, SPI, SDIO, USB. These connection methods not only expand the optional networking solutions developed based on AliOS Things, but also meet the transmission rate requirements of different application scenarios, as shown in Table 1. Among them, HAAS100 connects to LTE via USB, which can realize seamless replacement between different modules of the same manufacturer, such as EC20 and EC200S.

 

	interface	Maximum rate (Mbps)	Examples of application scenarios	MCU + communication chip
1	UART	1.5	Developerkit，WiFi	STM32L496 + BK7231
2	SPI	20	HAAS100，Ethernet	HAAS1000 + CH395
4	USB	12	HAAS100 ， LTE	HAAS1000 + EC20

Table 1 External methods and application scenarios supported by AliOS Things

 

2. Advantages of USB external communication chip

USB itself has the advantages of convenient use, reliable data transmission, low cost, and power saving. The use of USB as a channel for an external communication chip will retain these advantages, specifically as follows:

2.1, easy to use

• One interface can be used to connect multiple devices, and users can easily replace the communication chip to be connected without using different connectors and cables for different communication chips.
• Automatic configuration. After the communication chip is connected, the MCU side can automatically identify the communication chip and load the corresponding driver.
• Supports hot swapping, users can access or unplug the communication chip at any time without damaging the hardware device or restarting the device.
• No additional power supply is required. The USB interface provides a +5V voltage and a current below 500mA. In general, the communication chip does not need an additional power supply.

2.2, reliable data transmission

• The receiver and cable hardware specifications ensure that the data transmission is in a calm interface electrical environment, avoiding most of the noise interference that causes data errors.
• Differential transmission mode, USB 1.1/2.0 adopts four-wire mode, where D+/D- is the data transmission channel, and the transmission mode of differential signal is adopted. D+/D- needs to meet the level conditions at the same time to be judged as 0 or 1, which reduces the factor The possibility of bit hopping caused by interference.
• CRC check, USB hardware comes with CRC check, which can detect errors during transmission.
• The protocol confirms the retransmission. USB provides an acknowledgment (ACK/NACK) and retransmission mechanism at the protocol level to recover from transmission errors.

2.3. Low cost and power saving

• The cost of USB components is low, whether it is using an independent controller or an integrated IP solution, the cost can be controlled within a reasonable range. And from the perspective of scalability, USB can support more types of device connections without hardware changes.
• USB uses power saving circuits and protocols, combined with the sleep and wake-up functions of the communication chip, to achieve overall low power consumption.

 

3. Realize external communication chip based on USB channel

In order to realize the external communication chip based on the USB channel, in addition to ensuring that the MCU has the USB connection hardware capability, the MCU side also needs to implement the USB host protocol stack to complete

• Device identification
• Driver loading
• data transmission

Figure 1 The structure of the USB Host protocol stack on the MCU side, including the Host controller layer, Host Core layer, Host Class layer, and USB Device Driver layer

The USB host protocol stack on the MCU side is roughly divided into four layers: Host Controller layer, Host Core layer, Host Class layer, and USB Device Driver layer. Among them, Host Controlle is the bottom layer of the USB host protocol stack, responsible for directly interacting with hardware, reading and writing registers, and interrupt processing; Host Core is the core layer of the protocol stack, responsible for managing Host controllers, devices, interfaces, and endpoints, and responsible for devices Enumeration is responsible for host class registration, device configuration and transmission request processing; Host Class layer is the implementation layer of each USB host class, such as HID, CDC, UVC, etc. Finally, the device driver layer is used to implement the application interaction logic with the USB device, such as interacting with the EC20 through AT commands. The design details of each layer will be introduced in detail in another article and will not be expanded here. This section will introduce the implementation of USB external communication chip around device identification, driver loading, and data transmission.

3.1, equipment identification

When the communication chip is connected to the MCU via USB, the following dialogue will occur between the two.

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

The purpose of these questions and answers is to help the USB Host to accurately identify the connected device. The interactive information mainly includes device descriptors, configuration descriptors, interface descriptors, and endpoint descriptors.

 

3.2, class loading

At the end of the enumeration process, the driver will be loaded according to the class of the device. There are two loading methods, one is loading by device, and the other is loading by interface. Taking EC20 as an example, its interfaces are all vendor classes and cannot be loaded according to the interface classes. Therefore, it is necessary to load the corresponding class according to the Vendor ID (VID) and Product ID (PID) of the device.

In fact, for this type of vendor-customized WAN USB device, the Linux USB driver solution uses a special file (usb/serial/option.c) to store the vendor’s VID and PID list; during enumeration, If the VID of the USB device matches the PID, load the corresponding driver (usb/serial/wwan.c) for processing. As mentioned above, EC20 has 5 interfaces, among which interface 0 is a DM interface, interface 1 is a GPS interface, interface 2 is an AT interface, interface 3 is a PPP interface, and interface 4 is an NDIS interface, as shown in Figure 5. Since the PC side resources are sufficient, Linux USB Host can create corresponding endpoints for each interface when enumerating EC20, and allow users to operate these interfaces (open/read/write) at the same time.

Figure 4 EC20 USB interface functions

However, the resources of the USB controller on the MCU chip running RTOS are limited, and the endpoints required by so many interfaces cannot be created at the same time. Taking HAAS1000 as an example, in addition to control endpoint 0, its USB controller has only 4 endpoints available for use. Therefore, it is necessary to consider the underlying hardware resource limitations during the enumeration process on the MCU, otherwise it will cause the driver to fail to load. The strategy adopted here is to reuse endpoints. When loading the driver, select the interface in a targeted manner: first allocate endpoint resources for interface 2 for AT command interaction to ensure that the 4G module is connected to the network and obtain IP; then, when other interfaces need to be used, the endpoint resources of endpoint 2 are released.

3.3, data interaction

After the class is loaded, the upper layer can receive and send data through the USB channel. Taking the AT interface of EC20 as an example, the AT driver framework (SAL + AT Utility) of AliOS Things can run seamlessly on the USB protocol stack.

Figure 5 AT channel based on USB protocol stack

What needs to be done is to use the USB Class API to implement the HAL (at_dev_ops_t) required by AT Utility, as shown below.

/*
* 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;

On this basis, use the AT Utility API to implement the HAL (sal_op_t) required by SAL, as shown below.

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;

After completing the above docking, the upper application can be programmed based on the standard socket API, which reduces the application layer migration cost. For the introduction of related AT drive components, please refer to the AliOS Things help document  SAL components and AT components .

 

4. Example of HaaS100 external 4G module

Figure 6 HaaS100 connects to EC20 via USB

Figure 7 Pin header wiring used by USB

The pin header on the HaaS100 board provides USB pins, which can be connected to the USB female port extension cable to connect to the communication module, as shown in Figures 6 and 7.

 

Step 1: Configure

 aos make linkkit_demo@haas100 -c config

 

Step 2: Configuration selection

aos make menuconfig

Configuration

 

 

 

Step 3: Compile

aos make

 

Step 4: Burn

Please refer to HaaS to get started quickly .

 

Step Five: Start

The application runs the Linkkit demo. After the USB enumeration is successful, it can be connected to the Alibaba Cloud IoT platform through the AT channel.

 

5. Summary

WAN communication modules usually provide USB channels and support communication methods such as AT, PPP, RNDIS, and ECM. Therefore, the USB protocol stack is supported on the MCU side, which can automatically identify and enumerate various communication devices, and load the required drivers to facilitate the user's upper-level development. This article briefly introduces the USB Host protocol stack of AliOS Things, and uses EC20 as an example to describe the enumeration recognition process. At the same time, it also shows the way to connect the traditional AT channel of AliOS Things on the USB channel. In the follow-up related series of articles, we will introduce the PPP, RNDIS, and ECM methods based on the USB channel and give corresponding comparison data. Stay tuned.

 

If you need more technical support, you can join the Dingding Developer Group

For more technology and solution introduction, please visit the Aliyun AIoT homepage https://iot.aliyun.com/