the biggest issue with the esp32 is the ide and build system..

[ns1668]

I disagree, the market doesn't need another custom IDE. And I'm sure many engineers would agree they don't want to have to deal with another half-baked IDE that doesn't get maintained.

And in regards to Visual Studio Code being a toy, its a toy if you treat it as such.

Espressif should keep focusing on what they have, working on improving the core libraries/API and adding more extensive examples.

[ESP_kondalkolipaka]

Thanks @nonagon for the feedback. We are getting up to the speed and I am sure you will share a different view in a couple of months from now.

Here are our IDEs for VSCode and Eclipse
https://github.com/espressif/idf-eclipse-plugin
https://github.com/espressif/vscode-esp-idf-extension

It would be great if could share the concrete feedback or issue which you're facing so that we could help you with that.

Thanks

[ICONDev]

Seems that the most people with large projects and hundreds of source files (like we have also) have the same problem..
Now we intend to move to the cmake system, and found that each CMakeLists.txt must contain each file name for each source module seperately. Our project has hundreds of source files.


Question 1:
Is there a feasable and propper way to add all .c/ .h files contained in a components folder to a project without listing each file seperately?
(e.g. using asterisks)?

Question 2:
Is it possible to let the IDE (Eclipse + this wonderful Espressif plugin) do the job?

maintaining the CMakeLists.txt manually is a real pain and makes no fun at all, never seen this in modern tool chains.
How is this handled by other developers, are we too stupid to find a proper way to work with an original generated project for legacy make environment with hundreds or source files in components folders with cmake without maually taking care on each source file name ? Would appreciate if somebody could report their experiences.



By the way:
tried to start with "convert_to_cmake.py" generated CMakeLists.txt. The conversation failed although the project is compiling with legacy make.

Then I used a simpe Esspressif "hello World" - Example and tried the same with it, (it was exactly the espressif example, perfectly compiling under msys)
Same result: it failed with the error message that the project name is missing..

Juergen

[BrianP]

I tend to agree with the general comments, namely that there should be an ecosystem. I don't really like Eclipse but I find it to be useable once you can get it set up. Unfortunately, and maybe this is because I am working on the ESP32-C3, the Eclipse plugin does not seem to work properly, OpenOCD does not seem to work properly, and there are all sorts of weird failures accompanied by cryptic messages. Posts asking for help are generally ignored or, if someone is kind enough to reply to the question, does not lead to a useful solution. It doesn't help that often following the documentation verbatim does not lead to the expected results and nobody can explain why.

So I am working with a device which seems to have a built in JTAG I can't reliably use, and I can't get any help with respect to solving the numerous problems. As a result I'll end up plodding along with printfs like it was 2000.

In contrast, I can easily and consistently build, flash, and debug anything from Microchip. I think Espressif has excellent hardware and a wonderful price point. True, I'd prefer a few more I/O pins, but I'd really like to be able to focus on software development to get my product going and not hours and hours trying to get basic functionality out of the tools.

[mbratch]

I'm using the Eclipse plugin with ESP-IDF 4.3 and it appears to work fine. I installed it for the first time a couple if weeks ago, so everything is the latest.

[BrianP]

Are you working with ESP32-C3 and built in JTAG? Because it doesn't work at all with ESP32-C3

[ianr341]

This still seems like the biggest issue with the esp32 line (unless you are doing toy projects with it) - if you have many classes (say over 100) it forces you to name them all one by one which I haven't had to do with any other build system since the early 80's (if then..).
Does anyone know if they are going to do anything about it? It's like nobody at expresif actually programs the esp32, so they haven't developed good tools to do it..

Does indeed work, only leaving the issues of -

listing every source code file individually (thus losing half the power of 'make')
the eclipse addin won't find the system include files (say "esp_log.h") if the source code isn't in the project (or its component directory) directory. This puts errors in the 'Problems' tab even though the compile is fine.
you have to get out of the serial monitor to upload.

It's just all a bit half done. And getting everyone one who has to write code to learn the ins and outs, and manually build, cmake files is silly

[gtjoseph]

This still seems like the biggest issue with the esp32 line (unless you are doing toy projects with it) - if you have many classes (say over 100) it forces you to name them all one by one which I haven't had to do with any other build system since the early 80's (if then..).
Does anyone know if they are going to do anything about it? It's like nobody at expresif actually programs the esp32, so they haven't developed good tools to do it..

This topic mentions using SRC_DIRS instead of SRCS to include an entire directory but if you want more control, you can also using globbing yourself...

Code: [Select all] [Expand/Collapse]

1. FILE(GLOB APP_SOURCES *.cpp)
2.  
3. idf_component_register(SRCS ${APP_SOURCES}
4.      INCLUDE_DIRS "."
5.      )
6.  

GeSHi © Codebox Plus Extension

On a more general note... I've been using Eclipse for more than 10 years for my day-to-day work so I'm used to its "oddities". I'm also used to its power and features so when I tried VSCode I felt like my hands were constantly tied. Neither fact has anything to do with ESP-IDF or the plugins but I am biased. Having said that, I do find some issues with ESP-IDF and the Eclipse plugin to be especially annoying...

1. The plugin hides the normal Eclipse CDT C/C++ Build options for a project so when there's an issue it's hard to figure out what it's doing and why.
2. Sometimes after a successful build, running a "flash" rebuilds the entire project again before flashing for no apparent reason. Now I have a 10 core/20 thread CPU so it only takes a few seconds but it's still annoying.
3. You can't easily switch between projects to do builds. The Build/Run dropdowns in the toolbar aren't always synchronized with the open project. For instance, If you open project A then open project B, a "build" will always build project B (the last opened project) regardless of what the dropdowns say.
4. The C/C++ editor always seem to complain about Codan unresolved symbols or prototype mismatches even when the appropriate header file is in the same directory as the source file and the project builds and runs just fine. You can even ctrl-click on the symbol and Eclipse will open the header and navigate to the symbol definition. It just keeps flagging the symbol. Sometimes re-indexing the project fixes the issue and sometimes it doesn't. If it does fix it, it may come back again in a few minutes.

There are a few more but I can't recall them now. I've been meaning to open issues for these but just haven't had the time.

Has anyone signed up for the feedback session? Have you gotten a response?

[ianr341]

I'll try registering for that - but haven't yet..

I also have been using eclipse off and on for over a decade, and am quite use to it. VS Code is a pain if you are use to eclipse..

However espressif have made a mistake in -

1) making their own vscode extension - which is EXTREMELY easy to break - when they could have just supported the platform one (which works much better at this point).

2) as [gtjoseph] said above, the eclipse addin knackers eclipse.

I've recently - last two weeks - had another go at the espressif vscode addin & eclipse adding, platformio, and visual micro - all with the idf (no ardunio libraries).

The espressif vscode addin & eclipse are just too buggy and don't have the right features. Platformio is vscode based, visual micro is visual studio based - of the two I preferred Platformio.
Unlike the espressif vscode, Platformio just worked, though still had the limitations of vscode - particularly with trying to work on multiple projects at once..

All of the aren't as good as jantje's sloeber eclipse addin - but it currently has problems (and I haven't tried the nightly build to see if they are fixed) and it is esp32-ardunio focused. Espressif should have taken that and done something similar with idf support (as esp32-ardunio lags idf too much, and I don't think I've used an ardunio library for a year or three..).

[gtjoseph]

Platformio is vscode based, ...

PlatformIO has an Eclipse plugin that does work with the ESP-IDF. The only issue I had with it when I tried it was that the version of ESP-IDF it supported had a bug with certificate bundles so you couldn't actually build a project. I may actually go back and give it a shot though.

EDIT: Well it still doesn't have support for the esp32s3 so that's a non-starter.