ESP32 Development

[jarsudsco]

I've used Eclipse for some time but the last update trashed my installation and the advice I basically got from the CDT team was don't use any plugins - go figure. I'm looking to start developing for the ESP32 so decided to try the Sloeber product and installed 4.4.3. Eventually got it to work after reading about adding missing environment variables which is less than ideal. But now I have the indexing problem where the program compiles ok but the IDE is full of errors. I've seen posts referring to version 5 fixing this, but I haven't seen any advice on how to upgrade from 4 to 5. Am I missing something?

Thanks.

[jantje]

If you use the boards manager to install esp32 packages (like in arduino ide) there are no additional actions needed.

[jarsudsco]

@jantje thanks for the reply, I'm not sure I understand.

Are you saying I should be good to build ESP32 programs in Sloeber 4.4.3.202402080117?

By "boards manager" do you mean Sloeber -> Preferences -> Platforms and Boards ? If so then that's done, I don't know another way. I've got ESP32 version 3.3.1 enabled.

What about the missing environment variables? (build.fqbn = "ESP32:esp32:esp32", build.variant = "esp32", runtime.os = "generic_os") and then having to remove the FreeRTOS library? No matter what I've tried I still have (inconsistent) unresolved symbols even when the code compiles.

Any help would be appreciated.

[jantje]

There is a good tutorial
#1342
quick answers:

Are you saying I should be good to build ESP32 programs in Sloeber 4.4.3.202402080117?
Yes with some special actions but the default ino compiles and is part of the build tests. Many Sloeber use SP32.
By "boards manager" do you mean Sloeber -> Preferences -> Platforms and Boards
yes
What about the missing environment variables? (build.fqbn = "ESP32:esp32:esp32", build.variant = "esp32", runtime.os = "generic_os")
it is a mixed bag. Most code does not use it and there are quoting issues (very complex stuff)
and then having to remove the FreeRTOS library?
this is because esp32 conttains a include "freertos.h" and the CDT indexer seems to miss the casing difference :-(.
Disable automatically adding llibraries or exclude the lib from the build.

[jarsudsco]

@jantje

Thanks again for your reply. The tutorial is good - wish I had seen it a while ago as I kind of gave up on 4.4.3 and installed V5 separately and have had more success with that... no index errors, compiles ok and uploads ok. But I have some code using the ATC_MiThermometer library which uses some standard C++ features like std::string and std::vector. These get flagged as unresolved although again they seem to compile (code crashes on an ESP32 but that may be for another reason, I've not had a chance to check yet.) What is the situation with the C++ standard library?

BTW, I used your YouTube video on installing arduino-esp32 as a GitHub project. I got it working but I didn't notice the pathname suggested by Sloeber contained the literal "%userprofile%" and happily put the project files in a folder named "...%userprofile%..." which only caused a problem when I tried to run "get.exe" - I assume the Windows command interpreter saw the literal as an environment variable and basically just sat there doing nothing. Renaming the folder, and updating the references fixed it. I don' know if the %userprofile% was intended and I just wasn't observant enough.

Thanks

[jantje]

What is the situation with the C++ standard library?

I don't know.
Basically I worked 3 years to rewrite CDT managed build (which is the main change in sloeber V5) to be told CDT would not even look at it. When I expressed my dislike I got reported for "bad behavior". So I stopped watching the CDT and eclipse space.
What I do know is that CDT is moving away from managed build and the indexer (which are crucial for some Sloeber functionality) and multiple configurations (which I use heavily and work way better in V5) towards an external build (like json and xmake).
However as CDT does not have a alternative they can not get away from managed build and the indexer. I guess they will degrade support for it and let it slowly die.

the advice I basically got from the CDT team was don't use any plugins

Do you have a pointer to this advice?

[jarsudsco]

@jantje

I'm sorry to hear that, I like Eclipse and it was a big plus for me to be able to code for numerous targets in the one app.

My exchange with CDT is here: [(https://github.com/eclipse-cdt/cdt/discussions/1314)]

Thanks for your efforts.

[jarsudsco]

I gave up on Sloeber v5 too as my screen was just full of error markers even though the code compiled, so I reluctantly went back to the Arduino IDE and much as I don't like it it just works which was refreshing. Having got what I wanted working I decided to try pasting it into Sloeber - unsurprisingly it didn't work, but I tried again to figure out why.

The basis of my problems appeared to be WiFi.h which I think is fairly fundamental to anything ESP32. So I created a minimal example...

As shown, WiFi.h is included ok, the "WifiClient" type appears in the autocomplete list but the is then marked as "unresolved" - I think this is misleading, the error seems to be that in the "NetworkClient" type that "WiFiClient" is based on (typdef'd in WiFiClient.h) there is an unresolved inclusion of "<memory>" - another standard library header like <vector> and <string> that I mentioned earlier. So is Sloeber simply not finding the standard library headers?

I tried this with both the ESP V3.3.1 through platform manager and through the GitHub project I mentioned above. Same results, so I searched for the vector.h header...

In the platform manager instance I found it in:

C:\Tools\Sloeber5\arduinoPlugin\packages\esp32\tools\esp32-arduino-libs\idf-release_v5.5-129cd0d2-v4\esp32\include\espressif__esp-tflite-micro\third_party\flatbuffers\include\flatbuffers\vector.h

and for the GitHub instance in:

C:\Tools\GIT-ESP\git\arduino-esp32\tools\esp32-arduino-libs\esp32\include\espressif__esp-tflite-micro\third_party\flatbuffers\include\flatbuffers\vector.h

I tried adding these locations to the projects paths but I think I was only adding to the compile options as the unresolved include errors remained.

Incidentally, in Sloeber 4.4.3, the standard library headers are found and indeed std::vector and std::string are correctly found and rendered but WiFiClient still fails for some other reason.

I don't know if this is helpful, I just don't want to go back to the Arduino IDE for anything non-trivial.

[jantje]

pasting it into Sloeber - unsurprisingly it didn't work

It didn't build or the code links didn't work?
Note that in Sloeber you may need to build a couple of times until all libraries are added for the build to work (give the indexer some time as it basically builds the code and ESP32 is a lot of code).
After that the same goes for the indexer (rebuild index) for autocomplete and references to work in the code.

[jantje]

I gave up on Sloeber v5 too as my screen was just full of error markers even though the code compiled

Did you use the LSP editor (in which case I assume this is normal) or the old CDT editor?
Note that in eclipse it is very common to have plenty of problems; you change 1 thing and all of them are gone (that is even in java)

[jantje]

I'm sorry to hear that, I like Eclipse and it was a big plus for me to be able to code for numerous targets in the one app.

Well as long as I'm alive Sloeber will probably be alive as well. So enjoy as long as it lasts.

As to the exchange with CDT

I'm happy to see jonahgraham sees the current eclipse/CDT state -at the technological level- pretty much like I do.
The plugin idea is great but opensource+the flexibility make there are to many combinations to test/maintain/control so your best bet is bundling versions of plugin's and provide them as a product (in eclipse speak a feature is a set of versioned plugin's and a product is a set of plugin's/features with some packaging stuff).
That is why the Sloeber product was created a long time ago and the plugin is officially not supported.

He is a bit dishonest about the following though

I think this is a source of a lot of your problems - 3rd party plug-ins (like Devstyle + ESP-IDF + Sloeber) may be advertising themselves as compatible with much wider ranges of CDT than they are actually compatible with.

As I had the same problem with eclipse provided plug-ins but the problem is probably worse in 3rd party plug-ins.
As to Sloeber compatibility ... Sloeber uses the really old stuff CDT is trying to keep compatible with previous versions so unless CDT removes parts from features/products it should work. However from a CDT perspective Sloeber does not use the "new way" so it is not "compatible".
Very understandable but technically not correct

Unfortunately, there is not much CDT can do if 3rd parties say they are compatible and then aren't really.

Basically nobody can fix someone doing stupid things. However Eclipse could do a way better job at documenting how to do it correctly.
Eclipse simply prefers to finger-point 3rd parties and not look at their own behavior. This is just one of the problem that makes contributors and 3rd parties life difficult for decades now.
Also it is not only 3rd parties that cause this problem. For instance due to the packaging plugin->feature->update sites every change in eclipse inclusion decisions can break a 3rd party plugin because now a plugin the 3rd party code is dependent on may no longer be installed. This is one of the reasons nearly every eclipse release breaks the sloeber build.

For things that can be reproduced with CDT (eg. Eclipse IDE for C/C++ Developers or Eclipse IDE for Embedded C/C++ Developers) are much easier to deal with for the CDT project. For almost all the issues you have discussed here you (unfortunately) have to direct your bug reports to those providers and/or follow what the document (as opposed to enforce) as supported versions.

And here I fully agree with Jonah.
However as a user it is virtually impossible to know who provided the code that causes the bug (even the stack-trace won't do).
Even a simple question like "who provided this dialogue" is not always trivial to answer for me (due to the plugin concept); let alone a end user.

I am not aware of CDT (Eclipse really) updating without prompting you first

I'm not sure how oomph work with this "shared storage" and that is again why I opted to provide the sloeber product as an stand alone archive without oomph.

Not beyond imagination, but beyond our capability. ( to keep a cross referenced list of Eclipse versions versus plugin versions)

Absolutely 100% agree with Jonah here that there is no capability for this.

LSP editor experience

This is the way forward CDT decided upon and which will lead to Sloeber having to switch (I don't see a real problem here) or work with degraded functionality. As far as I understand the LSP editor is no longer using the CDT indexer (it has it's own) and Sloeber uses the indexer for include headers to find libraries to add to the project and to open the serial monitor with the correct baud rate.
Porting these over can only be done when the new indexer has these functionalities (for which I have reasons to think they are not a prime concern of CDT)
Note that Sloeber 5 does not create json files right now so the LSP editor has "degraded" functionality. I did notice that the newest managed build has an option to create the json file so sloeber 4 (with upgraded CDT -which may not work-) may work fine with the new editor.

[jarsudsco]

It didn't build or the code links didn't work?

I couldn't remember, so I had to check. The code compiled and uploaded but showed errors on-screen.

Note that in Sloeber you may need to build a couple of times until all libraries are added for the build to work (give the indexer some time as it basically builds the code and ESP32 is a lot of code).
After that the same goes for the indexer (rebuild index) for autocomplete and references to work in the code.

Lol, at university I was taught that computers were deterministic, finite state machines, now it seems like (to misquote) do the same thing over and over and get different results :-)

Did you use the LSP editor (in which case I assume this is normal) or the old CDT editor?

I didn't realise I had a choice. I'm using V5 as installed. That's CDT, right?

Note that in eclipse it is very common to have plenty of problems; you change 1 thing and all of them are gone (that is even in java)

Yes, I've used Eclipse long enough to know this only too well, but usually it doesn't take this much effort to fix it.

Thanks for your comments on the CDT conversation, I appreciate your time and your efforts on Sloeber.

[jantje]

Lol, at university I was taught that computers were deterministic, finite state machines,

What that means is: same input=> same output; but as there are multiple processes running and build results can trigger actions; the input can change and provide different output.
So they taught you right but in complex systems ....

I didn't realise I had a choice. I'm using V5 as installed. That's CDT, right?

The LSP editor got mentioned in your discussion with Jonah. CDT has been working on this for over 3 years. I think there are now 2 editors but I don't know how to choose which.

doesn't take this much effort to fix it.

I have lost weeks trying to find out why I had errors everywhere. So my experience differs.

Thanks for your comments on the CDT conversation, I appreciate your time and your efforts on Sloeber.

I like a honest conversation. So nice speaking to you.