|
Azure IoT middleware for FreeRTOS
|
Porting from Amazon FreeRTOS applications can be done using the following sections. There are several topics to cover including building, porting, authentication, and feature set.
Like the Amazon FreeRTOS library, we use CMake to build the middleware. You may use the directions here to correctly set up the build environment for your project to generate and compile.
To see the detailed diff showing the changes in the CMake to get the sample building with the Azure IoT middleware for FreeRTOS, please see here.
If starting from a basic CoreMQTT implementation, such as here, the porting process is pretty straight forward. The network context of the Azure IoT middleware for FreeRTOS maps similarly to the usage of the CoreMQTT library as shown here.
For a detailed diff showing how to get telemetry data sending to Azure IoT Hub using the mqtt_demo_mutual_auth.c sample, please see here.
To see the combination diff of building and porting, please see here. While this diff shows some specific changes for the STM32L475 Discovery board, many of the configuration values can be translated to other boards and platforms by finding their equivalent values in other board's configuration files.
Azure IoT supports x509 certificate and SAS key authentication. For details on which to use, you can refer to this document going over the pros and cons of each.
If using x509 authentication, the integration process happens at the networking layer of the project (outside the scope of the SDK). For an example on how to add them in our samples, please see this code snippet here which uses a NetworkContext_t struct to pass to the chosen TLS stack layer (in this case mbedTLS). The equivalent spot to add x509 credentials in Amazon FreeRTOS would be here.
For more details on the TLS requirements of Azure IoT (TLS versions, certificate requirements, supported crypto algorithms, etc), please see this document here. To see how your solution certificate requirements might need to change, please see (here for the Amazon specs.)
Using SAS keys provides another option for your IoT solution. While we recommend x509 certificates over the use of SAS keys, SAS keys can provide their own benefits especially in prototyping. To use SAS keys, you only need to provide the symmetric key via the AzureIoTHubClient_SetSymmetricKey() API listed here and the necessary HMAC function to use in generating the keys. The SAS key will be automatically refreshed when needed if it expires during the connection.
Direct comparisons between feature sets of Amazon and Azure IoT is not the purpose of this document. Application code logic would need to be ported over to use Azure IoT concepts.
Below is a high level explanation of functional features
Standard MQTT telemetry capability. Send messages with a payload to a pre-determined topic. Custom topics are not available at this time. Details for this feature can be found here.
Essentially telemetry in the reverse direction. The cloud can send messages on a pre-determined MQTT topic for the device to process. Details for this feature can be found here.
Otherwise known as direct methods, commands/functions which one can invoke from the cloud and run on the device. These are composed of an intended function to run (name) and a possible payload to pass to the function. Any response payload and return value are then sent back to the service. Details for this feature can be found here.
JSON documents that store device state information including metadata, configurations, and conditions. Azure IoT Hub maintains a device twin for each device that you connect to IoT Hub. Details for this feature can be found here.
1.9.0