1 Introduction[edit source]
Azure® RTOS NetX Duo is a dual IPv4 and IPv6 TCP/IP network stack designed specifically for deeply embedded, real-time, and IoT applications. It has various sets of features. Alongside the TCP/IP IPv4/IPv6 network stack, it provides a crypto library implementing the standard crypto and hash methods, and a TLS/DTLS library to support secure network connections.
- The NetX Duo core offers a full TCP/IP IPv4IPV6 compliant stack with 3 types of API: TCP/IP, UDP/IP and RAW API.
- The Crypto core implements the common crypto cipher suites and hashing algorithms useful for securing connections and exchanging encrypted data: AES, 3DES, HMAC, RSA, SHA1, SHA224, SHA256, SHA384, SHA512, MD5, HMAC-SHA1, and so on (each algorithm has its own implementation file .c and header file .h, which facilitate the selection and the integration of the required algorithms by applications).
- The TLS core implements the secure connection API. Based on both the Crypto core and NetX Duo core, it supports the TLS and DTLS protocols with their different variants. (TLS 1.0 TLS 1.2, TLS 1.3).
It also supports the X509 public signed certificates protocol.
- Addon protocols are a pre-supported set of network applicative protocols that ease the integration of the networking feature in the end user application. The main supported protocols are the following:
DHCP, DNS, mDNS, HTTP, HTTPS, FTP, TELNET, MQTT, SMTP, POP3, SNTP, SNMP, and so on.
Further details are available in the NetX Duo official documentation[1]
NetX Duo folders are organized as described below:
2 STM32 Integration[edit source]
NetX Duo can run on any networking hardware, such as Ethernet, WiFi modules, cellular modems, and so on. It requires a low-level driver to interact between the physical layer already chosen, and the NetX Duo core requests (initialize, transmit data, receive data).
To achieve the interaction between the NetX Duo stack and the required PHY, the software architecture should follow the arborescence below.
The following hardware configurations are currently supported:
- Ethernet: Currently any STM32 board that provides an Ethernet IP, uses the Ethernet PHY microchip LAN874X[2] (driver under Drivers/BSP/Components In the STM32Cube MPU package).
- nx_stm32_eth_config.h: A template config header file to tune the corresponding driver for STM32MP135x-DK Discovery kit
. This file should be copied into the application source tree, then customized according to the driver needs. - nx_stm32_custom_driver.h: A template header file for the defined drivers.
- nx_stm32_custom_driver.c: A template file for defining drivers and data structure.
- nx_stm32_phy_driver.c: this is referenced directly by the application and may be used according depending on the supported features.
Below code shows how to create IP instance using netx network driver:
/* ETHERNET STM32MP13 example: */
ret = nx_ip_create(&IpInstance, "Main Ip instance", NULL_ADDRESS, NULL_ADDRESS, &AppPool,
nx_stm32_eth_driver, pointer, 2* DEFAULT_MEMORY_SIZE, 1);
2.1 Known limitations[edit source]
- The BSD API support is not fully-compliant. This may impact the portability of legacy applications. More details are available in the official NetX Duo documentation[1]
3 How to use NetX Duo[edit source]
The main APIs needed to use NetX Duo are described in the table below: (further details and a full API description are available from the NetX Duo official documentation[1] )
| Function Name | Short Description |
|---|---|
| nx_tcp_socket_create( ) | Create a TCP socket |
| nx_udp_socket_create( ) | Create a UDP socket |
| nx_tcp_server_socket_listen( ) | Set up TCP socket to listen |
| nx_udp_socket_bind( ) | Bind UDP socket to the PORT |
| nx_tcp_server_socket_accept( ) | Accept a TCP remote client socket connection |
| nx_tcp_socket_receive( ) | Receive a packet from a TCP remote client |
| nx_udp_socket_receive( ) | Receive a packet from a UDP remote client |
| nx_tcp_socket_disconnect( ) | Disconnect the TCP server socket |
| nx_tcp_server_socket_unaccept( ) | Reject the TCP server socket |
| nx_tcp_server_socket_relisten( ) | Set up server socket for listening again |
The main steps to use NetX Duo are:
- Define NX_APP_MEM_POOL_SIZE on app_azure_rtos_config.h from MX. For example, 100 Kbytes.
#define NX_APP_MEM_POOL_SIZE 102400
- Create a Byte Pool “nx_app_byte_pool” with a size of NX_APP_MEM_POOL_SIZE in app_azure_rtos.c
if (tx_byte_pool_create(&tx_app_byte_pool, "Tx App memory pool", tx_byte_pool_buffer, TX_APP_MEM_POOL_SIZE) != TX_SUCCESS)
{}
Then in MX_NetXDuo_Init, the user should follow this routine (allocate, create).
- Allocate memory from the byte pool:
/* Allocate the memory for packet_pool. */
if (tx_byte_allocate(byte_pool, (VOID **) &pointer, NX_PACKET_POOL_SIZE, TX_NO_WAIT) != TX_SUCCESS)
{
return TX_POOL_ERROR;
}
- Create a pool AppPool:
/* Create a packet pool. */
ret = nx_packet_pool_create(&AppPool, "Main Packet Pool", PAYLOAD_SIZE, pointer, NX_PACKET_POOL_SIZE);
- Then create and configure an IP instance that belongs to the pool already created.
- Enable the needed NetX Duo components depending on the target application:
| Function Name | Short Description |
|---|---|
| nx_arp_enable( ) | Enable the Address Resolution Protocol (AutoIP Protocol need ARP) (Require memory allocation) |
| nx_icmp_enable( ) | Required for Ping |
| nx_udp_enable( ) | Enable UDP traffic (DNS & DHCP need UDP) |
| nx_tcp_enable( ) | Enable TCP traffic |
4 Migration to NetX Duo[edit source]
In order to migrate a development project from an existing network stack (such as LwIP or others) to NetX Duo, there is no straightforward automatic procedure. However, there are usually some similarities between APIs, and these can be helpful when performing this task. Some comparative examples are provided below.
| Action | NetXDuo | LwIP |
|---|---|---|
| DHCP Service | /* create the DHCP client */
ret = nx_dhcp_create(&DHCPClient, &IpInstance, "DHCP Client");
/* Create an IP @ change callback */
ret = nx_ip_address_change_notify(&IpInstance, ip_address_change_notify_callback, NULL);
/* start DHCP client */
ret = nx_dhcp_start(&DhcpClient);
|
/* Start DHCP process to get IP@*/
dhcp_start(netif);
/* Get Client data */
dhcp = (struct dhcp *)netif_get_client_data(netif, LWIP_NETIF_CLIENT_DATA_INDEX_DHCP);
/* Wait until getting DHCP data */
if (dhcp_supplied_address(netif))
{
DHCP_state = DHCP_ADDRESS_ASSIGNED;
}
|
| HTTP Service | /* Create the HTTP Server. */
ret = nx_web_http_server_create(&HTTPServer, "WEB HTTP Server", &IpInstance, CONNECTION_PORT,&SDMedia, pointer,
SERVER_STACK, &WebServerPool, NX_NULL, webserver_request_notify_callback);
/* Start the WEB HTTP Server. */
status = nx_web_http_server_start(&HTTPServer);
/* Web Server callback when a new request from a web client is triggered */
static UINT webserver_request_notify_callback(NX_WEB_HTTP_SERVER *server_ptr, UINT request_type,
CHAR *resource, NX_PACKET *packet_ptr);
/* Extract the client request type from the client request */
nx_web_http_server_type_get(server_ptr, server_ptr->nx_web_http_server_request_resource,
temp_string, &string_length);
|
/* Create a new TCP connection handle */
conn = netconn_new(NETCONN_TCP);
/* Bind to port 80 (HTTP) with default IP address */
err = netconn_bind(conn, NULL, 80);
/* Put the connection into LISTEN state */
netconn_listen(conn);
/* Accept any incoming connection */
accept_err = netconn_accept(conn, &newconn);
/* Read the data from the port, blocking if nothing yet there.
We assume the request (the part we care about) is in one netbuf */
recv_err = netconn_recv(conn, &inbuf);
/* Get the data pointer and length in netbuf */
netbuf_data(inbuf, (void**)&buf, &buflen);
|
5 References[edit source]