Develop for constrained devices using Azure IoT C SDK

Azure IoT Hub C SDK is written in ANSI C (C99), which makes it well-suited to operate a variety of platforms with small disk and memory footprint. The recommended RAM is at least 64 KB, but the exact memory footprint depends on the protocol used, the number of connections opened, as well as the platform targeted.

C SDK is available in package form from apt-get, NuGet, and MBED. To target constrained devices, you may want to build the SDK locally for your target platform. This documentation demonstrates how to remove certain features to shrink the footprint of the C SDK using cmake. In addition, this documentation discusses the best practice programming models for working with constrained devices.

Building the C SDK for constrained devices

Build the C SDK for constrained devices.

Prerequisites

Follow this C SDK setup guide to prepare your development environment for building the C SDK. Before you get to the step for building with cmake, you can invoke cmake flags to remove unused features.

Remove additional protocol libraries

C SDK supports five protocols today: MQTT, MQTT over WebSocket, AMQPs, AMQP over WebSocket, and HTTPS. Most scenarios require one to two protocols running on a client, hence you can remove the protocol library you are not using from the SDK. Additional information about choosing the appropriate communication protocol for your scenario can be found in Choose an IoT Hub communication protocol. For example, MQTT is a lightweight protocol that is often better suited for constrained devices.

You can remove the AMQP and HTTP libraries using the following cmake command:

cmake -Duse_amqp=OFF -Duse_http=OFF <Path_to_cmake>

Remove SDK logging capability

The C SDK provides extensive logging throughout to help with debugging. You can remove the logging capability for production devices using the following cmake command:

cmake -Dno_logging=OFF <Path_to_cmake>

Remove upload to blob capability

You can upload large files to Azure Storage using the built-in capability in the SDK. Azure IoT Hub acts as a dispatcher to an associated Azure Storage account. You can use this feature to send media files, large telemetry batches, and logs. You can get more information in uploading files with IoT Hub. If your application does not require this functionality, you can remove this feature using the following cmake command:

cmake -Ddont_use_uploadtoblob=ON <Path_to_cmake>

Running strip on Linux environment

If your binaries run on Linux system, you can leverage the strip command to reduce the size of the final application after compiling.

strip -s <Path_to_executable>

Programming models for constrained devices

Next, look at programming models for constrained devices.

Avoid using the Serializer

The C SDK has an optional C SDK serializer, which allows you to use declarative mapping tables to define methods and device twin properties. The serializer is designed to simplify development, but it adds overhead, which is not optimal for constrained devices. In this case, consider using primitive client APIs and parse JSON by using a lightweight parser such as parson.

Use the lower layer (LL)

The C SDK supports two programming models. One set has APIs with an LL infix, which stands for lower layer. This set of APIs is lighter weight and do not spin up worker threads, which means the user must manually control scheduling. For example, for the device client, the LL APIs can be found in this header file.

Another set of APIs without the LL index is called the convenience layer, where a worker thread is spun automatically. For example, the convenience layer APIs for the device client can be found in this IoT Device Client header file. For constrained devices where each extra thread can take a substantial percentage of system resources, consider using LL APIs.

Next steps

To learn more about Azure IoT C SDK architecture:

• Azure IoT C SDK source code
• Azure IoT device SDK for C introduction