I have a running project based on 20202 (I actually upgrade it already from 201906) and I want to switch to 202012 but I see that there is a lot of changes in the API as well as other changes and I’m looking for a porting guide for this, is there any?
Thanks
Hi @EyalG,
We do not have a porting guide for the move to the current APIs, although we have included a compatibility layer to allow you to use the latest version with your current API calls.
For the move to the latest MQTT, I can provide some information on equivalent structures and functions for the move from the older MQTT API (v4 of the Embedded C SDK) to the current one:
Removed Features:
-
Taskpool
Version 4 uses a taskpool for scheduling MQTT operations in the background. Version 202011.00 and subsequent releases do not spawn any threads and have no need for a taskpool. -
Thread support
Version 4 relies on a platform’s threading capabilities for multi-threading use cases. Version 202011.00 and subsequent releases do not spawn any threads and therefore, do not require the use of a platform’s multithreading. If threading support or connection sharing is desired, please see our connection sharing demo for an example of using the MQTT library in a multithreaded environment.
Data Types:
Version 4 | Version 202011.00 and subsequent releases | Notes |
---|---|---|
IotMqttQos_t | MQTTQoS_t | MQTT Quality of service. |
IotMqttError_t | MQTTStatus_t | Return codes of API functions. |
IotMqttConnection_t | MQTTContext_t | MQTT connection handle. |
IotMqttPublishInfo_t | MQTTPublishInfo_t | Parameters of an MQTT publish. |
IotMqttConnectInfo_t | MQTTConnectInfo_t | Parameters of an MQTT connect. |
IotMqttSubscription_t | None | Version 202011.00 and subsequent releases leave subscription tracking to the application. |
IotMqttPacketInfo_t | MQTTPacketInfo_t MQTTDeserializedInfo_t | Deserialized MQTT Packet information. |
IotMqttCallbackInfo_t | MQTTEventCallback_t | Function pointer of application callback to receive incoming data. |
Functions:
Version 4 | Version 202011.00 and subsequent releases | Notes |
---|---|---|
IotMqtt_Init | MQTT_Init | In v4, this function initializes the entire library. In 202011.00 and subsequent releases, it initializes a single client. |
IotMqtt_Cleanup | None | 202011.00 and subsequent releases does not allocate any memory and therefore, has nothing to free. |
IotMqtt_Connect | MQTT_Connect | |
IotMqtt_PublishAsync IotMqtt_PublishSync | MQTT_Publish | From the perspective of the v4 library, all of version 202011.00’s publishes are asynchronous. To receive any expected acknowledgment packet, MQTT_ProcessLoop must be called. |
IotMqtt_SubscribeAsync IotMqtt_SubscribeSync | MQTT_Subscribe | From the perspective of the v4 library, all of version 202011.00’s subscribe operations are asynchronous. To receive the acknowledgment packet, MQTT_ProcessLoop must be called. |
IotMqtt_UnsubscribeAsync IotMqtt_UnsubscribeSync | MQTT_Unsubscribe | From the perspective of the v4 library, all of version 202011.00’s unsubscribe operations are asynchronous. To receive the acknowledgment packet, MQTT_ProcessLoop must be called. |
IotMqtt_Disconnect | MQTT_Disconnect | |
None | MQTT_ProcessLoop | MQTT_ReceiveLoop is the equivalent function without any keep-alive mechanism. |
Let us know if you need any further assistance in migrating to the latest version
Thank you very much for this detailed answer.
I’ll appreciate if you can elaborate on the connection sharing in respect the a previous question I asked (and did not get any response yet) - Sharing MQTT connection between a shadow and OTA
Thanks
Hi @EyalG,
We have a demo for connection sharing as well an MQTT Agent project in FreeRTOS Labs. Note that as the latter is a Labs project its implementation and API are not finalized, though you should be able to use it in your application for sharing the connection between shadow and OTA.