Skip to content

What can be learned from adding Robusto as a PlatformIO-dependency in an ESP-IDF project?

Notifications You must be signed in to change notification settings

RobustoFramework/robusto_platformio_espidf_demo

Repository files navigation

Robusto/ESP-IDF/PlatformIO-dependencies

To just get going with hacking, a more logical way is to create an Robusto + ESP-IDF project and an idf_component.yml.
Then, a managed_components-folder would appear with all the components brought in by the ESP-IDF dependency management.
But then we wouldn't learn much.

So what do we do?

Instead, this project creates a running system by using the PlatformIO-dependency management:

  1. Create a normal PlatformIO project (Done. This is that project.)
  2. Edit the main.c (Done)
  3. Create a folder called Components (Done, but from here you continue)
  4. In platform.ini - change to the ESP32 you want to update. Find it in Devices.
  5. Install Robusto - Run pio pkg install --storage-dir ./components --library "robusto/robusto"
  6. Click the "General->Run menuconfig" task in the PlatformIO task bar.
  7. In Robusto configuration -> Memory, check "Do memory monitoring", just to have something happen.
  8. Click "s" and enter to save the configuration.
  9. The sdkconfig.az-delivery-devkit-v4 config file is created and will be used in your build.
  10. Run the Upload and Monitor task.
  11. If there is an ESP32 (of any kind, probably) connected, it will start reporting boot up available memory and warn, as the warning level has been set low.
  12. It may take a short while as while the esp32_exception_decoder is good in that it reports what line the error happened, it is kind of slow to start.

Why, and what does it show

Lots.

  1. Because we specified --storage-dir ./componentsin step 4, the dependencies didn't end up in .pio/libdeps/az-delivery-devkit-v4, but in the components folder.
  2. We did this, because the menuconfig implementation in PlatformIO for ESP-IDF does not look in .pio/libdeps/az-delivery-devkit-v4 for KConfig (menu items) and KConfig.projbuild (top menu items) -files.
  3. So if we hadn't done this, the esp_modem component would have failed to build.
  4. This because it requires the CONFIG_ESP_MODEM_CMUX_DELAY_AFTER_DLCI_SETUP1 setting to be set to something.
    And the menuconfig application is what is generating those settings, step 8 above.
  5. But wait, a managed_components folder appeared with RadioLib in it even though no PlatformIO dependency was there?
    That, friends is actually a mystery. Perhaps the ESP-IDF subsystem reacts to the presence of the idf_component.yml.

Footnotes

  1. Note that menuconfig adds CONFIG_ to all defines it..defines.

About

What can be learned from adding Robusto as a PlatformIO-dependency in an ESP-IDF project?

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published