ESP-Azure include in existing project

[zipfelchaeppli]

Dear all,

I would like to include esp-azure into an existing idf-project.

The structure is as follows:
components
--drv
----drv1.c
----drv1.h
--com
----wlan.c
----wlan.h
esp-azure
---- [All files/folders from https://github.com/espressif/esp-azure]
main
--main.c

If I compile, an example inside esp-azure, it compiles with no problems.
However, if I compile my project as above and include "iothub_client.h" in my main.c., I get the error, that the h-file could not be found.

How do I need to include the esp-azure component such that I can use "iothub_client.h" in my project?

Thank you in advance for any help or hint!

Best,
Jonas

[jsam589]

I have just been doing this same thing. Here are several findings that help me.

1. If you are using CMake, for example with v4.x of IDF, try adding this EXTRA_COMPONENT_DIRS line in the project top-level CMakeLists.txt file. I got this from one of the esp-azure examples and just changed the relative path. Without this line I was seeing the same #include errors you mention.

Code: Select all

include($ENV{IDF_PATH}/tools/cmake/project.cmake)
set (EXTRA_COMPONENT_DIRS "${CMAKE_CURRENT_BINARY_DIR}/../components/esp-azure/port")
project(wifi_station)

2. If you need provisioning client code to be included (by #defining USE_PROV_MODULE), the "correct" way to define this is to define CONFIG_DEVICE_COMMON_NAME. I did this by adding file Kconfig.projbuild in main/ folder with this content.

Code: Select all

    config DEVICE_COMMON_NAME
        bool "Azure x509 Support"
        default y
        help
            Select this, Azure port lib will define HSM x509.

If you add it, these lines in the esp-azure top-level component.mk file will be affected by that change:

Code: Select all

ifdef CONFIG_DEVICE_COMMON_NAME
CFLAGS += -DUSE_PROV_MODULE
endif

3. I use symbolic links to include esp-azure in my project directory. I like to keep the very large esp-azure directory out of my actual repository. Sym links work well on Linux and Windows. To the IDF build tools, symbolic links look like any other folder under components/.

4. I use the "1.0" ESP Azure port and have not had to change anything in it. I do have some runtime issues when building against v4.x IDF, but not when building against v3.3, so I don't think it's a problem with the esp-azure port. I am about to post a forum question on that issue.

5. Finally, the library created for the entire esp-azure is call libport.a, a very innocuous name not indicative that this is for the huge azure component. But if you are perusing your map file, this is where all the esp-azure stuff resides.

Code: Select all

./build/esp-idf/port/libport.a

[jsam589]

Link to my description re: provisioning handshaking problem when using v4.x IDF. Even if you get yours to build, it might not fully communicate if you are building against 4.x IDF.

viewtopic.php?f=22&t=13533