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

Custom Board, Custom Zephyr Devicetree (AirTag Session 3)

Sign up for the AirTag Clone webinar series to watch Golioth build out board definition files for the Orleon board, a Bluetooth sensor platform/playground. The upcoming session on May 23rd will walk through setting up all required build files.

Where’s my (Bluetooth) drill?

We implemented Golioth's Bluetooth-to-Cloud connectivity on a battery pack on a commercial power drill. We not only monitored power usage of the drill, we also looked up the location of the most recent gateway we connected through and attached that to the drill's device record.

Battery Monitoring with Zephyr’s Fuel Gauge Subsystem

Fuel gauge ICs offload effort when it comes to taking reliable battery readings and estimating charge and drain times. Zephyr's support for these components makes using them even easier.

Want to stay up to date with the latest news?

Subscribe to our newsletter and get updates every 2 weeks. Follow the latest blogs and industry trends.