 |
Synergy Software Package User's Manual
|
|
Synergy Software Package User's Manual
|
The MQTT (Message Queue Telemetry Transport) is a communication protocol based on a publisher/subscriber model. A data producer can publish information to other clients through a broker. Multiple data consumers, if interested in a topic, can subscribe to the topic through the broker. The broker is responsible for authentication and authorization of the clients and delivering published messages to its topic subscribers. In this publisher/subscriber model, multiple clients may publish data with the same topic. A client will receive the messages it publishes if the client subscribes to the same topic.
The NetX Duo MQTT Client Support module defines APIs for creating the MQTT Client, connecting to a broker, setting up TLS security and receiving MQTT messages. A complete list of the available APIs, an example API call and a short description of each can be found in the following table. A table of status return values follows the API summary table.
NetX Duo MQTT Client Module API Summary
| Function Name | Example API Call and Description |
|---|---|
| nxd_mqtt_client_create | nxd_mqtt_client_create(&mqtt_client_secure, "my_client", CLIENT_ID_STRING, strlen(CLIENT_ID_STRING), ip_ptr, pool_ptr, (VOID*)mqtt_client_stack, sizeof(mqtt_client_stack), mqtt_thread_priority, (UCHAR*)client_memory, sizeof(client_memory));Create an MQTT client with the specified Client ID, stack memory and stack size, and message block memory. |
| nxd_mqtt_client_connect | nxd_mqtt_client_connect(&mqtt_client, &server_ip, NXD_MQTT_PORT, MQTT_KEEP_ALIVE_TIMER, 0, NX_WAIT_FOREVER)Non-secure connect to the MQTT broker specifying broker IP address and port, keep alive timer, and disabling the clean session option |
| nxd_mqtt_client_secure_connect | nxd_mqtt_client_secure_connect(&mqtt_client_secure, &server_ip, NXD_MQTT_TLS_PORT, tls_setup_amazon, 600, 1, NX_WAIT_FOREVER)Connect to broker with TLS security using the tls_setup_amazon, which is a user-defined function, to set up TLS and set TLS parameters. The clean session option is enabled. This is only available if the NetX Duo library is built with NX_SECURE_ENABLE set, and if the MQTT client property NX Secure is set. |
| nxd_mqtt_client_login_set | nxd_mqtt_client_login_set(mqtt_client_ptr,"Username", strlen("Username"), "Password", strlen("Password");Set the optional MQTT username and password. This must be called before the nxd_mqtt_client_connect or nxd_mqtt_client_secure_connect call if the broker requires username and password. |
| nxd_mqtt_client_message_get | nxd_mqtt_client_message_get(&mqtt_client_secure, &topic, &topic_length, &message, &message_length, &packet_ptr);Retreive a published MQTT message for the specified topic. |
| nxd_mqtt_client_receive_notify_set | nxd_mqtt_client_receive_notify_set(&mqtt_client_secure, my_notify_func);Specify the function the MQTT Client thread task calls when an MQTT message is received. |
| nxd_mqtt_client_subscribe | nxd_mqtt_client_subscribe(&mqtt_client_secure, TEST_SUBSCRIBE_TOPIC_NAME, strlen(TEST_SUBSCRIBE_TOPIC_NAME), 0);Send a subscriber message to the broker for the specified topic for QoS (quality of service) level 0. |
| nxd_mqtt_client_unsubscribe | nxd_mqtt_client_unsubscribe(NXD_MQTT_CLIENT *mqtt_client_pr,CHAR *topic_name, UINT topic_name_length); Send an unsubscriber message to the broker for the specified topic. |
| nxd_mqtt_client_publish | nxd_mqtt_client_publish(&mqtt_client_secure, TEST_SUBSCRIBE_TOPIC_NAME, strlen(TEST_SUBSCRIBE_TOPIC_NAME), message_buffer, strlen(message_buffer), 0, 1, NX_WAIT_FOREVER);Send a message to the broker for the specified topic previously subscribed to for QoS (quality of service) level 1, and the retain message option disabled. |
| nxd_mqtt_client_disconnect | nxd_mqtt_client_disconnect(&mqtt_client);Disconnect from the MQTT broker. |
| nxd_mqtt_client_disconnect_notify_set | nxd_mqtt_client_disconnect_notify_set(mqtt_client_ptr, my_disconnect_notify);Specify the user defined function for the MQTT Client thread task to call if the broker initiates disconnecting from the client. |
| nxd_mqtt_client_delete | nxd_mqtt_client_delete(mqtt_client_ptr);Delete the MQTT instance, clear transmit and message queue messages |
| nxd_mqtt_client_will_message_set | nxd_mqtt_client_will_message_set(mqtt_client_ptr, will_topic, will_topic_length, "will_message", strlen("will_message"), 0, 1);Set the optional MQTT Client will message without the retain will message option, for QOS 1. If a will message is needed, this must be called before connecting to the broker. |
The MQTT (Message Queue Telemetry Transport) is a protocol based on the NetX Duo TCP/IP stack and a publisher-subscriber model. A client can publish information to other clients through an MQTT Server (broker). A client, if interested in a topic, can subscribe to the topic through the broker. A broker is responsible for delivering published messages to its clients who subscribe to the topic. In this publisher-subscriber model, multiple clients may publish data with the same topic. A client will receive a message it publishes if the client subscribes to the same topic.
The following figure provides an overview of the MQTT Client publish/subscribe model:
NetX Duo MQTT Client Module Publish/Subscribe Model
The NetX Duo MQTT client module can be used in the normal mode or the secure mode.
NetX Duo MQTT Client Module Normal Mode Operational Description
In normal mode, the communication between the MQTT client and broker is not secure.
NetX Duo MQTT Client Module Secure Mode Operational Description
In Secure mode, the communication between the MQTT client and broker is secured using the TLS protocol. In the thread pane, the TLS protocol is represented by "Add NetX Duo TLS common [Optional]" block.
Depending on the use case, a client may choose one of the 3 QoS levels when publishing a message:
QoS 0: The message is delivered at most once. Messages sent with QoS 0 may be lost.
QoS 1: The message is delivered at least once. Messages sent with QoS 1 may be delivered more than once.
QoS 2: The message is delivered exactly once. Messages sent with QoS 2 is guaranteed to be delivered, with no duplication.
Since QoS 1 and QoS 2 are guaranteed to be delivered, the broker keeps track the state of QoS 1 and QoS 2 messages sent to each client. This is particularly important for clients that expect QoS1 or QoS 2 messages. The client may be disconnected from the broker (for example when the client reboots, or the communication link is temporarily lost). The broker must store QoS 1 and QoS 2 messages so the messages can be delivered later once the client is reconnected to the broker.
However, the client may choose not to receive any stale messages from the broker after reconnection. The client can do so by initiating the connection with the clean_session flag set to NX_TRUE (1) in the nxd_mqtt_client_connect API. In this case, upon receiving the MQTT CONNECT message, the broker shall discard any session information associated with this client, including undelivered or unconfirmed QoS 1 or QoS 2 messages.
If the clean_session flag is to NX_FALSE, the server shall resend the QoS 1 and QoS 2 messages. The MQTT Client also resends any un-acknowledged messages if clean_session is set to NX_TRUE. This acknowledgment is different from the TCP socket layer ACK, although that happens as well. The MQTT client sends an MQTT acknowledgment message to the broker upon receipt of a message, and gets one back when it publishes a message.
Incoming MQTT messages are stored in the receive queue of the MQTT client instance. The application retrieves these messages by calling the nxd_mqtt_client_message_get API which returns both the topic and the topic message. The application must ensure to provide a large enough buffer for each. The oldest message in the queue is returned to the caller first. The nxd_mqtt_client_message_get is non-blocking. If the MQTT client receive queue is empty, it returns immediately with an NXD_MQTT_NO_MESSAGE (0x1000A) status. This should not be handled as an error, but that the receive queue is empty.
To avoid polling the receive queue for incoming messages, the application can register a receive message callback function with the MQTT client by calling the nxd_mqtt_client_recieve_notify_set API. The callback function is defined as:
VOID (*receive_notify_callback)(NXD_MQTT_CLIENT *client_ptr, UINT message_count);
As the MQTT client receives messages from the broker, it invokes the callback function if the function is set. The callback function passes the pointer to the client control block and a message count value. The message count value indicates the number of MQTT messages in the receive queue. Note that this callback function executes in the MQTT client thread context. Therefore, the callback function should not execute any procedures that may block the MQTT client thread. The callback function should trigger the application thread to call the nxd_mqtt_client_message_get API to retrieve the messages. This is demonstrated in the module guide project.
To disconnect the MQTT client service, the application shall use the service nxd_mqtt_client_disconnect and nxd_mqtt_client_delete, APIs respectively. Calling nxd_mqtt_client_disconnect disconnects the TCP connection to the broker. It releases messages already received and stored in the receive queue. However, it does not release QoS level 1 messages in the transmit queue. QoS level 1 messages are retransmitted upon connection, assuming the clean_session flag is set to NX_FALSE.
The broker may initiate the disconnect from the client. The application can be notified of the disconnect request by registering a disconnect notify function with the MQTT Client. This is done by calling the nxd_mqtt_client_disconnect_notify_set API.
To delete an MQTT Client, call the nxd_mqtt_client_delete API. This releases all message blocks in the transmit queue and the receive queue. Unacknowledged QoS level 1 messages are also deleted.
Using Secure Communication
To secure the communication between MQTT client and broker, TLS protocol is required. In the thread pane, TLS protocol is represented by "Add NetX Duo TLS common \[Optional]" block. Adding NetX Duo TLS Common block enables the TLS support.
MQTT with TLS/NetX Duo Secure
When using TLS with MQTT Client, it is strongly recommended that the TLS setup callback in the nxd_mqtt_client_secure_connect call contain all of the TLS set up, including creating the TLS instance, defining the local certificates, allocating memory for remote certificate processing, and optional callbacks such as timestamp and certificate authentication. Once the callback has completed its operation successfully it should return Success. If the TLS setup callback returns a failure, the nxd_mqtt_client_secure_connect API also returns a failure to the application program.
Regardless if the MQTT Client was able to connect via TCP successfully or not, or whether the TLS session was successfully started, the application MUST call nxd_mqtt_client_disconnect to properly clear and reset the TLS session before attempting to reconnect again.
If the session was terminated improperly, nxd_mqtt_client_disconnect must still be called for the same reason.
For SSP 1.3.x, the TLS setup callback will need to call a memset on the NXD_SECURE_TLS_SESSION data block before (re)creating a TLS session (nxd_secure_tls_session_create).
The definition of the nxd_mqtt_client_secure_connect API with the TLS setup input is:
Add this logic to the tls_setup callback function (assuming the MQTT Client instance name is g_mqtt_client0):
If memset is not called, the TLS nxd_secure_tls_session_create call may not succeed. In SSP 1.4.0 it will no longer be necessary to call memset, but it is still strongly recommended to put all TLS setup, including TLS creation in the callback. It may seem wasteful to completely delete and recreate a TLS session. But the manner in which TLS is integrated into MQTT Client makes this the most sensible and reliable method to guarantee successful reconnection attempts.
For more details about TLS protocol, please see the NetX Duo TLS Secure Module Guide.
Multiple Instances of MQTT Client Per Device
For SSP 1.4.0 and earlier, a device cannot safely run multiple instances of the MQTT Client because the MQTT Client in these releases assumes global variables. That should be remedied in a subsequent release.
The NetX Duo MQTT Client component is added by clicking on the (+) sign in the thread pane window -> Azure RTOS -> NetX Duo -> Protocols -> NetX Duo MQTT Client.
Adding the NetX Duo MQTT Client component to a project automatically adds the option to add the NetX Duo TLS component required for secure MQTT.
The MQTT Client properties are listed in the following table:
In the figure above, "Common" properties are those configurable options in the NetX Duo MQTT Client that are common to all instances of the MQTT client in the project. The "Module" properties are specific to each instance of MQTT Client in the project.
Common Properties
Module Properties
mqtt_client_init0.nxd_mqtt_client_create API. If Auto Initialization is disabled, this has no effect. If it is, Synergy will create this function automatically.nxd_mqtt_client_create API before using any NetX Duo MQTT Client services.Setting a Unique Client ID
As mentioned previously, an MQTT client instance is created using nxd_mqtt_client_create() API. If the MQTT Client application is letting the ISDE create the MQTT client, then it must define the Client ID Callback. This will be called before the ISDE calls nxd_mqtt_client_create internally with a defined Client ID string. The MQTT Client component allows you to set the Client ID Callback and Client ID Max Length in the list of MQTT Client properties (see above Module Properties).
The Client ID should be unique and is one of the parameters the MQTT broker uses to identify the client.
The prototype for Client ID callback is as follows:
p_client_id is a pointer to the Client ID to obtain, thus it is an output parameter which will be filled in by this callback function. p_client_id_length is a pointer to the length of the Client ID, thus it is an input and output parameter. This mechanism enables the Client ID to be determined at run time instead of at compile time.
If Client ID Callback is left empty in the properties pane of e2 studio, a compiler error occurs. NULL is an acceptable entry. If your application prefers to create the MQTT Client directly, set this callback to NULL and set Auto Initialization to Disabled. Then when your application calls the nxd_mqtt_client_create API, provide the Client ID string directly, and the length of it as the input parameters:
Below is the sample reference implementation of the Client ID callback function which copies MAC address to a Client ID:
nxd_mqtt_client_connect API to NX_TRUE (1) as per the MQTT protocol. If the Client supplies a zero-byte Client ID with clean_session set to NX_FALSE (0), the Server will respond to the CONNECT Packet with a CONNACK return code 0x02 (Identifier rejected) and then close the Network Connection.This section describes how to include either or both the NetX Duo MQTT Client module in an application using the SSP configurator.
To add the NetX Duo MQTT Client module to an application, simply add it to a thread using the stacks selection sequence given in the following table.
NetX Duo MQTT Client Module Selection Sequence
| Resource | ISDE Tab | Stacks Selection Sequence |
|---|---|---|
| g_mqtt_client0NetXDuo MQTT Client | Threads | New Stack> X-Ware> NetX Duo> Protocols> NetXDuo MQTT Client |
When the NetX Duo MQTT Client module is added to the thread stack as shown in the following figure, the configurator automatically adds any needed lower‑level modules. Any modules needing additional configuration information have the box text highlighted in Red. Modules with a Gray band are individual modules that stand alone. Modules with a Blue band are shared or common; they need only be added once and can be used by multiple stacks. Modules with a Pink band can require the selection of lower-level modules; these are either optional or recommended. (This is indicated in the block with the inclusion of this text.) If the addition of lower-level modules is required, the module description include Add in the text. Clicking on any Pink banded modules brings up the New icon and displays possible choices.
In the stack above, the NetX Network Driver (or NetX Duo Network Driver in a NetX Duo stack) has not been populated yet. There are multiple possible selections for the Network Driver; they are not all provided so as not to needlessly complicate the figure and the following configuration tables. The available options depend on the MCU target, but some typical options include:
The NetX Duo MQTT Client module must be configured by the user for the desired operation. The SSP configuration window automatically identifies (by highlighting the block in red) any required configuration selections, such as interrupts or operating modes, which must be configured for lower-level modules for successful operation. Only properties that can be changed without causing conflicts are available for modification. Other properties are locked and not available for changes and are identified with a lock icon for the locked property in the Properties window in the ISDE. This approach simplifies the configuration process and makes it much less error-prone than previous manual approaches to configuration. The available configuration settings and defaults for all the user-accessible properties are given in the Properties tab within the SSP Configurator and are shown in the following tables for easy reference.
Configuration Settings for the NetX Duo MQTT Client Module
| ISDE Property | Value | Description |
|---|---|---|
| NX Secure | Enable, Disable Default: Enable | This enables/disables TLS support. If this property is set to Enabled, the MQTT Client is built with TLS support. Note: enabling the property requires adding the NetX Duo TLS component to the project to supply the necessary source code to the project, or the project will not build. If set to Disabled, adding the NetX Duo TLS component has no effect though the project will still build and run. |
| Topic Name Max Length | 12 | The maximum topic length (in bytes) the application is going to subscribe to. The default is 12 bytes. |
| Message Max Length | 32 | The maximum message length (in bytes) the application is going to send or receive. The default is 32 bytes. |
| Keepalive Timer Rate(s) | 1 | This timer is used to keep track of the time since last MQTT control message was sent, and sends out an MQTT PINGREQ message before the keep-alive time expires. The default value is 1 second. |
| Ping Timeout Delay(s) | 1 | The time MQTT client waits for PINGRESP from the broker for after it sends out MQTT PINGREQ. The default value is 1 second. |
| Name | g_mqtt_client0 | Name of the MQTT client instance. |
| Client ID Callback | mqtt_client_id_callback | Callback function provided by user for the MQTT Client thread task to obtain a unique client ID. If Auto Initialization is disabled, this and the Client ID length have no effect. |
| Client ID Max Length | 12 | Maximum Length in bytes of the client ID. |
| Client Thread Stack Size | 4096 | MQTT Client thread stack size in bytes. |
| Number of Messages to be stored in memory | 1 | MQTT client uses memory area to store messages. The memory needed for MQTT client operation depends on the amount of data being sent or received. The minimal memory size is the size of a single MQTT_MESSAGE_BLOCK instance which is 60 bytes. The default value is 1 MQTT_MESSAGE_BLOCK or 60 bytes. However, this it not a good choice if there will be multiple messages received before the application can receive them. Transmitted messages cannot be released until thee TCP socket receives an ACK for the data, or if the QoS level is 1 or higher and the MQTT Client has received an ACK from the MQTT server. So the module guide project uses 6 message blocks. That number can probably be reduced to 3 or 4. |
| Client thread priority | 2 | MQTT Client thread priority. |
| Name of generated initialization function | mqtt_client_init0 | Name of the function that will call the nxd_mqtt_client_create API. If Auto Initialization is disabled, this has no effect. If it is, Synergy will create this function automatically |
| Auto Initialization | Enable, Disable Default: Enable | This determines if the function specified in the Name of Generated Initialization function option is called. If set to Enable, it will invoke this function. Otherwise if set to Disable, the application must call the nxd_mqtt_client_create API before using any NetX Duo MQTT Client services. |
In some cases, settings other than the defaults for stack modules can be desirable. For example, you may require a longer Client ID string or to disable NX Secure. The configurable properties for the lower-level stack modules are given in the following sections for completeness and as a reference.
Note: Most of the property settings for lower-level modules are intuitive and usually can be determined by inspection of the associated properties window from the SSP configurator.
Only a small number of settings must be modified from the default for the IP layer and lower-level drivers as indicated via the red text in the thread stack block. Notice that some of the configuration properties must be set to a certain value for proper framework operation and are locked to prevent user modification. The following table identifies all the settings within the properties section for the module:
Configuration Settings for the NetX Duo IP Instance
| ISDE Property | Value | Description |
|---|---|---|
| Name | g_ip0 | Module name |
| IPv4 Address (use commas for separation) | 0,0,0,0 | IPv4 Address selection |
| Subnet Mask (use commas for separation) | 255,255,255,0 | Subnet Mask selection |
| IPv6 Global Address (use commas for separation) | 0x2001, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x1 | IPv6 global address selection |
| IPv6 Link Local Address (use commas for separation, All zeros means use MAC address) | 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 | IPv6 link local address selection |
| IP Helper Thread Stack Size (bytes) | 2048 | IP Helper Thread Stack Size (bytes) selection |
| IP Helper Thread Priority | 3 | IP Helper Thread Priority selection |
| ARP | Enable | ARP selection |
| ARP cache storage units | Bytes, Entries Default: Bytes | ARP cache storage units selection |
| ARP Cache cache Size (in Bytes or storage units) | 520 | ARP Cache Size in Bytes/Entries selection. Must be a multiple of 52 Bytes. Note: 1 Entry = 52 Bytes |
| Reverse ARP | Enable, Disable Default: Disable | Reverse ARP selection |
| TCP | Enable, Disable Default: Enable | TCP selection |
| UDP | Enable, Disable Default: Enable | UDP selection |
| ICMP | Enable, Disable Default: Enable | ICMP selection |
| IGMP | Enable, Disable Default: Enable | IGMP selection |
| IP fragmentation | Enable, Disable Default: Disable | IP fragmentation selection |
| Name of generated initialization function | ip_init0 | Name of generated initialization function selection |
| Auto Initialization | Enable, Disable Default: Enable | Auto initialization selection |
Configuration Settings for the NetX Duo Common Instance
| ISDE Property | Value | Description |
|---|---|---|
| Name of generated initialization function | nx_common_init0 | Name of generated initialization function selection |
| Auto Initialization | Enable, Disable Default: Enable | Auto initialization selection |
Configuration Settings for the NetX Duo Packet Pool Instance
| ISDE Property | Value | Description |
|---|---|---|
| Name | g_packet_pool0 | Module name |
| Packet Size in Bytes | 1568 | Packet size selection |
| Number of Packets in Pool | 16 | Number of packets in pool selection |
| Name of generated initialization function | packet_pool_init0 | Name of generated initialization function selection |
| Auto Initialization | Enable, Disable Default: Enable | Auto initialization selection |
Configuration Settings for the NetX Duo TLS Common
| ISDE Property | Value | Description |
|---|---|---|
| Crypto Engine | Hardware | Crypto engine selection |
| Self Signed Certificates | Enable, Disable Default: Disable | Self signed certificates selection |
| PSK Cipher Suite | Enable, Disable Default: Disable | PSK cipher suite selection |
| ECC Cipher Suite | Enable, Disable Default: Disable | ECC cipher suite selection |
| X509 Strict Name Compare | Enable, Disable Default: Disable | X509 strict name compare selection |
| X509 Extended Distinguished Names | Enable, Disable Default: Disable | X509 extended distinguished names selection |
| Maximum RSA Modulus size (bits) | 1024, 2048, 3072, 4096 Default: 4096 | Maximum RSA modulus size (bits) selection |
| Server Mode | Enable, Disable Default: Enable | Server mode selection |
| Client Mode | Enable, Disable Default: Enable | Client mode selection |
| Name of generated initialization function | nx_secure_common_init | Name of generated initialization function selection |
| Auto Initialization | Enable, Disable Default: Enable | Auto initialization selection |
Configuration Settings for the NetX Duo Software Crypto
| ISDE Property | Value | Description |
|---|---|---|
| Name | g_crypto_generic | Module name |
Configuration Settings for the NetX Crypto Hardware Accelerator
| ISDE Property | Value | Description |
|---|---|---|
| Name | g_sf_el_nx_crypto | Module name |
Configuration Settings for the SCE Common Driver
| ISDE Property | Value | Description |
|---|---|---|
| Name | g_sce_0 | Module name |
| Endian Flag | CRYPTO_WORD_ENDIAN_BIG, CRYPTO_WORD_ENDIAN_LITTLE Default: CRYPT_WORD_ENDIAN_BIG | Endian flag selection |
| Interfaces available from the InterfaceGet API | ||
| AES<subset> | Enable, Disable Default: Enable | Enable or disable available interface (Plain-text ECB 128-bit, CBC 128-bit, etc. See configuration properties in the SSP Configurator for a complete list of those available for the target MCU) |
| RSA<subset> | Enable, Disable Default: Enable | Enable or disable available interface (Plain-text 1024-bit, 2048-bit, etc. See configuration properties in the SSP Configurator for a complete list of those available for the target MCU) |
| ECC<subset> | Enable, Disable Default: Enable | Enable or disable available interface (Plain-text 192-bit, 256-bit, etc. See configuration properties in the SSP Configurator for a complete list of those available for the target MCU) |
| HASH<subset> | Enable, Disable Default: Enable | Enable or disable available interface (SHA1, SHA224, etc. See configuration properties in the SSP Configurator for a complete list of those available for the target MCU) |
| True Random Number Generator | Enable, Disable Default: Enable | Enable or Disable True Random Number Generator interface |
The ETHERC peripheral module uses PCLKA as its clock source. The PCLKA frequency is set using the SSP configurator clock tab prior to a build, or by using the CGC interface at run-time.
The ETHERC peripheral module uses pins on the MCU device to communicate to external devices. I/O pins must be selected and configured by the external device as required. The following table illustrates the method for selecting the pins within the SSP configuration window and the subsequent table illustrates an example selection for the I2C pins.
Pin Selection for the ETHERC Module
| Resource | ISDE Tab | Pin selection Sequence |
|---|---|---|
| ETHERC | Pins | Select Peripherals > Connectivity:ETHERC > ETHERC1.RMII |
Pin Configuration Settings for the ETHERC1
| Property | Value | Description |
|---|---|---|
| Operation Mode | Disabled, Custom, RMII Default: Disabled | Select RMII as the Operation Mode for ETHERC1 |
| Pin Group Selection | Mixed, _A only Default: _A only | Pin group selection |
| REF50CK | P701 | REF50CK Pin |
| TXD0 | P700 | TXD0 Pin |
| TXD1 | P406 | TXD1 Pin |
| TXD_EN | P405 | TXD_EN Pin |
| RXD0 | P702 | RXD0 Pin |
| RXD1 | P703 | RXD1 Pin |
| RX_ER | P704 | RX_ER Pin |
| CRS_DV | P705 | CRS_DV Pin |
| MDC | P403 | MDC Pin |
| MDIO | P404 | MDIO Pin |
The steps in using the NetX Duo MQTT Client module in a typical application are:
nx_ip_status_check (or if your system has multiple network interfaces, call nx_ip_interface_status_check) with the NX_IP_LINK_ENABLED option.nxd_mqtt_client_connect API.nxd_mqtt_client_receive_notify_set API. The receive callback sets a flag when notified by the underlying NetX Duo socket services that it has received a packet on this connection.nxd_mqtt_client_subscribe API. nxd_mqtt_client_publish API.tx_event_flags_get API.nxd_mqtt_client_message_get API. Note that unlike receiving packets from a socket, the MQTT Client need not be concerned about releasing packets. The MQTT Client thread task handles packet and message block allocate and release.nxd_mqtt_client_unsubscribe API, specifying the topic.nxd_mqtt_client_disconnect API.The following figure illustrates common steps in a typical operational flow diagram:
