Closed emintz closed 4 months ago
Probable root cause ESP is a very special platform and there are currently quite a bit of problems with the "discovery phase". If the project builds fine but the indexer gives problems that is caused by a failing "discovery" For the discover the compile commands are run and provide include folders and defines. If it fails you should have at least 2 errors in the error log (because the discovery is run for both c and cpp command). The failing happens because Sloeber is not yet completely initialized and does not expand/provide the commands properly.
workaround: Unfortunately there is no button to restart the discovery and CDT behavior in this area is different between different versions. What is cumbersome but always worked for me is changing the "discovery command" (in project properties). in many cases changing the board (FI to uno "apply and close" and back to ESP) will work as well.
To change the discovery command Add/remove a space and select apply close
Other thoughts:
1) #include <freertos/FreeRTOS.h> should that not be #include
Update: downgrading from ESP library 3.0.2 to 2.0.17 resolves the issue. The new library is not backward compatible.
The IDE editor marks included headers as not found when they exist. The program compiles just fine.
For example, one of my experimental sketches includes three headers:
The editor recognizes
Arduino.h
, but marksfreertos/FreeRTOS.h
andtusb.h
unresolved.Environment:
IDE: Sloeber application version 4.4.3.202402070201 Target: ESP32 S3 Development Module ESP32 Library Version: 3.0.2
I have set
build.fqbn
,build.variant
, andruntime.os
as directed in issue 1652I had to disable automatic include resolution to prevent Sloeber from automatically including the nI2C_master library in my project.
I'd love to help with this if you can get me started. I'll look at the code, but probably will need a bit of orientation to get me going.