Adding Golioth Example Code to Your ESP-IDF Project

In our previous blog post, we demonstrated how to add the Golioth Firmware SDK to an ESP-IDF project. As you start integrating Golioth into your projects, you’ll likely want to build upon the examples we’ve provided and reuse the same utility functions from the common code.

The common code is a great starting point to help you quickly evaluate Golioth, but it’s important to keep its intended use in mind. It’s designed for demonstration and prototyping, not for production. The API is subject to change without notice, so relying on it long-term could introduce breaking changes. Additionally, certain features, like WiFi management, are kept simple for ease of use but may not cover all edge cases, such as handling multiple connection retries. When you’re ready to move toward production, plan to replace the common code with a more robust and tailored implementation.

Building on the Previous Blog Post

In the last blog post, we started with the Wi-Fi station example, added the Firmware SDK, and sent some logs to the cloud. Now, we’ll take it a step further by integrating Firmware SDK common code into your application.

The first step is to make your project aware of the ESP-IDF common code included in the Firmware SDK.

To include it in your project, update your main/CMakeLists.txt file with the following:

set(esp_idf_common "../submodules/golioth-firmware-sdk/examples/esp_idf/common")

This line defines a macro named esp_idf_common, which simplifies referencing the location of the common code in your build system.

Next, we need to include the directories where the header files for the common code reside.

Add the following to main/CMakeLists.txt:

set(includes
    "${esp_idf_common}"
)

Here, ${esp_idf_common} points to the folder containing the header files, where the function declarations you’ll use in your application are defined.

Adding Source Files to the Build System

Now, let’s point the build system (CMake) to the source files needed for your project.

Update your main/CMakeLists.txt with:

set(srcs
    "station_example_main.c"
    "${esp_idf_common}/shell.c"
    "${esp_idf_common}/wifi.c"
    "${esp_idf_common}/nvs.c"
    "${esp_idf_common}/sample_credentials.c"
)

The station_example_main.c is the source file for your application.
The other files (shell.c, wifi.c, etc.) are part of the Firmware SDK common code used in our examples.

Updating the Dependencies

In the last blog post, we listed golioth_sdk as a dependency. However, since the common code uses additional libraries,  we must expand the dependencies list.

Update main/CMakeLists.txt as follows:

set(deps
    "golioth_sdk"
    "console"
    "spi_flash"
    "nvs_flash"
    "json"
    "driver"
    "esp_hw_support"
    "esp_wifi"
)

Completing the Build Configuration

Finally, use the idf_component_register function to register your components with the build system.

Update main/CMakeLists.txt with the following:

idf_component_register(
    INCLUDE_DIRS "${includes}"
    SRCS "${srcs}"
    PRIV_REQUIRES "${deps}"
)
list(APPEND EXTRA_C_FLAGS_LIST
    -Werror
)

component_compile_options(${EXTRA_C_FLAGS_LIST})

idf_component_register tells ESP-IDF how to compile your project, specifying include directories, source files, and dependencies. The -Werror flag ensures that all warnings are treated as errors during compilation, enforcing strict code quality.

Conclusion

With these updates, your project is now set up to use Golioth’s ESP-IDF common code.
You can continue building on this foundation, reusing the utility functions provided by the SDK while focusing on  the unique aspects of your application.

Marko Puric
Marko Puric
Marko is a Field Applications Engineer (FAE) at Golioth. He helps Golioth customers bring their proofs-of-concept to life, and works with them to overcome initial integration challenges. This effort ensures successful integration of the Golioth Platform into new development and production environments.

Post Comments

No comments yet! Start the discussion at forum.golioth.io

More from this author

Related posts

spot_img

Latest posts

Manufacturing A Mini-fleet: Provisioning And Updating 10 Thingy91’s

Golioth demonstrates one approach to provisioning IoT devices during manufacturing. Learn some of the challenges you will face with flashing test firmware, generating and passing x.509 certificates to the devices, and using OTA to load final production firmware.

Golioth Can Now Run Entirely on Qualcomm Modems

Today marks the first implementation of running the entire Golioth firmware stack on a modem processor. This dramatically reduces resource consumption on the external MCU processor, and makes it easier to add Golioth to any hardware or platform.

Enhanced IoT Dashboards with Golioth, InfluxDB, and Grafana

We co-hosted a webinar with InfluxDB demonstrating how Golioth Pipelines make it simple to stream data from a microcontroller with environmental sensors directly into...

Want to stay up to date with the latest news?

We would love to hear from you! Please fill in your details and we will stay in touch. It's that simple!