It's mentioned here, but in the context of integrating with an existing CMake build system: https://docs.espressif.com/projects/esp-idf/en/release-v3.3/api-guides/build-system-cmake.html#using-esp-idf-in-custom-cmake-projects Just a note - that link is currently dead (404), yet linked from the curr...

In case this is useful to anyone in the future (including future me): With ESP IDF v3.2, I had the following in my top-level CMakeLists.txt file: execute_process(COMMAND "git" "describe" "--match=NeVeRmAtCh" "--always" "--abbrev=14" "--dirty" RESULT_VARIABLE git_result OUTPUT_VARIABLE git_output OUT...

It looks like v3.2's project.cmake used the directory of the component that contained the main() function as the name of the target executable, whereas v3.3 uses $IDF_PROJECT_EXECUTABLE instead. So I was able to fix this by changing my rules such as this: target_compile_options(main PRIVATE -Wno-unk...

I have a CMakeLists.txt that works fine with ESP IDF v3.2, but when I try to build it (from clean check-out) with ESP IDF v3.3 I get the following CMake error: $ $IDF_PATH/tools/idf.py build [...] -- Component paths: [...];/home/me/my-project/main [...] -- Component libraries: CMake Error at CMakeLi...

Now that the ESP-IDF is moving away from Make to Ninja (and Clion doesn't support Ninja) do any of the ESP engineers have any tips to get this to work with IDF v4.x+ please? I'm not an ESP engineer, but CMake supports numerous build tools and I'd be very surprised if the ESP-IDF CMake config does s...

Fair enough - my workaround was a consolidation of other comments to support a single client and multiple reconnections. Two unique non-concurrent clients will need a different solution.

blippy wrote: ↑

Tue Sep 17, 2019 8:01 am

meowsqueak wrote: ↑

Mon Sep 16, 2019 11:20 pm

Did you try the PR I linked to? I didn't have any problems with it, but my use case may be different.

Please provide the link, as it's not on this thread.

It is, but here it is again anyway

https://github.com/espressif/esp-idf/pull/3597

blippy wrote: ↑

Mon Sep 16, 2019 5:52 pm

Comments?

Did you try the PR I linked to? I didn't have any problems with it, but my use case may be different.

I think you might be better off just connecting each LED to a GPIO and using interrupts to catch the state changes, and polling to monitor levels. 5 Hz is absolutely nothing to a microcontroller like the ESP32. It would be a lot easier than using RMT! RMT is better suited to fast signals where you n...

As you're probably aware already, that example just looks at a single signal incoming on a single GPI. The main constraint is the size of the RMT buffers - as the GPI is sampled, a new value is added to the RMT buffer. The size of the buffer required is therefore related to the required sample rate,...