How do I setup an IDF independent project that uses Espressif's tools and libraries. (IDFGH-13707)

[Joebeazelman]

Answers checklist.

• [X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• [X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• [X] I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report

I'm working on a project to provide Ada development support for Espressif's SoCs. I would like to use as much of Espressif's resources as needed without reinventing the wheel. I've been moderately successful at using Espressif's C libraries and bootloader scripts; however, I had to make several modifications as well as supply additional parameters for it to work.

Unfortunately, IDF is proving to be a major barrier. I am having difficulty using it for debugging, flashing, and monitoring built-binaries. IDF.py depends on CMake and Ninja files in the project's directory in order to run. Adding them to an Ada project adds needless bulk and complexity.

Ideally, it would greatly simplify my job if I could work with a sample project without all the CMake files and IDF specific configuration. I'm not versed in CMake, but I believe there's a way to have it preprocess it into a generic make project containing only preconfigured configuration files and build steps. Is there a way to achieve this?

[igrr]

Hi @Joebeazelman,

I'm not versed in CMake, but I believe there's a way to have it preprocess it into a generic make project containing only preconfigured configuration files and build steps. Is there a way to achieve this?

CMake can indeed generate GNU Make makefiles, but for various reasons described in CMake manual, these files contain absolute paths to the source and build directories. This means that it's not possible to redistribute the resulting makefile as part of your project.

We do have a few examples of reusing code originally written for ESP-IDF in other projects:

• esp32c3-direct-boot-example — a simple bare metal example which uses some of ESP-IDF's libraries (HAL layer) and runs on ESP32-C3 and ESP32-H2.
• Support for ESP chips in Zephyr RTOS is based on https://github.com/zephyrproject-rtos/hal_espressif repository, which contains many of ESP-IDF's source files.
• Support for newer ESP chips in NuttX RTOS uses a similar concept, with files extracted from ESP-IDF provided by https://github.com/espressif/esp-hal-3rdparty repository.

I am not familiar enough with Ada ecosystem to understand which exact parts of ESP-IDF you actually need. Perhaps starting from something simpler (like the esp32c3-direct-boot-example or Rust's esp-hal) could help you get a minimal functional environment, to which you can later start adding peripheral drivers as needed.

Is your current project (with an ESP-IDF dependency) public? If yes, I could try it and possibly offer more concrete suggestions.

[Joebeazelman]

Thanks for getting back to me so fast. I really appreciate it.

Rust's esp-hal project is nearly identical to ours except for its target language. Unfortunately, our team lacks expertise with Rust to use effectively as reference material. However, we would like to achieve the same native, friction-free developer experience for Ada.

Currently, our early code base consist of three projects that depend on IDF in some form or another: esp32s3_hal, light_xtensa_esp, and esp32s3_blinky. The first is a HAL library for the esp32s3 SoC and provides support for its built-in peripherals such as GPIO. It also contains boot loader and startup scripts. The second provides a lightweight runtime for Ada's built-in features such as standard IO, timing, memory allocation, etc. Finally, the third is the equivalent of IDF's blink example and depends on the previous two projects. It's normally built first.

As you may already know, Ada is an established and prominent programming language in embedded development with strong usage in a wide range of industries, including avionics, medical, and energy. As a result, our project, combined with Espressif's technical assistance, is of considerable value to both Espressif and Ada communities.

If you're intrigued by our project, I encourage you to give it a try by following the instructions provided in light_xtensa_esp project's readme file. Feel free to ask me any questions in the appropriate repo.

I will follow up with another issue we're having.

Thanks.

[Joebeazelman]

I forgot to mention we're targeting the esp32s3 first, due to its popular request in the Ada community.