September 12, 2018 at 14:46 #21941
I have been using VisualGDB for a few years now on the Embeded Linux platforms. It is by far the best thing since sliced bread for that. Its simply awesome.
Having said that, its also one of the worst for the ESP32. I created a video to show the just some of the issues compared to a free IDE like PlatformIO.September 13, 2018 at 00:07 #21943
Thanks for uploading the video and sharing your concerns. We will try to explain what is going on.
Unlike many conventional ARM-based devices that are supported through our optimized MSBuild backend and a collection of tested BSP packages, the Advanced ESP32 projects are built directly by the ESP-IDF framework (official ESP32 SDK by Espressif). We decided to handle the ESP32 platform this way in order to accommodate the rapid release cycle of the ESP-IDF that often releases updates introducing new features, large structural changes and breaking backward compatibility.
I.e. instead of an optimized VisualGDB package based on a specific version of ESP-IDF (that would get obsoleted very quickly), VisualGDB can run on top of any recent ESP-IDF release of your choice and produce exactly the same results as meant by Espressif. It will inherit the original ESP-IDF build system and the configuration settings.
PlatformIO likely uses a different approach – includes a subset of ESP-IDF with its own build subsystem that is faster and requires less configuration settings, but is not equivalent to the latest ESP-IDF framework. Hence most of the differences you mentioned are rather the differences between ESP-IDF (full-scale ESP32 SDK) and PlatformIO (a lightweight SDK for smaller projects) and are not actually related to VisualGDB itself.
Although VisualGDB doesn’t support PlatformIO out-of-the-box yet, it does support the ESP32 Arduino core (see the new Arduino project wizard) that provides similar lightweight experience at a cost of offering fewer features. Espressif itself is also addressing the build speed issue by switching their IDF to CMake+Ninja. Once this switch is complete, the ESP-IDF projects will build much faster.
Regarding the other issues mentioned in the video, it looks like you did not specify valid debug settings when creating the project. If you don’t have a JTAG probe, simply select a COM port. VisualGDB will warn that no actual debugging will be possible, but will still allow programming the device via the COM port. You can change it for an existing project via VisualGDB Project Properties -> Debug Settings. Alternatively, please try right-clicking on the project node in Solution Explorer and select “Program FLASH Memory”. This will run the same FLASH programming routine as used by PlatformIO.
The COM port syntax (/dev/ttyS<port number – 1>) is to be expected – this is a valid Cygwin COM port syntax, so please do not change it. Please also note that changing the programming speed from 115200 might break programming, depending on the capabilities of the specific COM2USB chip used on your board.
Hope this helps. Let us know if you have any further questions.September 13, 2018 at 03:09 #21946
I am glad your staying on the latest release. However, even when using ESP-IDF mingw32 as they suggest.
I.E. “make -j8 app” will still compile much, much faster than VGDB.September 13, 2018 at 05:52 #21947
Strange, normally VisualGDB should run the same command. Could you please try checking the build output for the exact command line used by VisualGDB (in the very beginning of the output)? E.g.:C++1VisualGDB: Run "e:\SysGCC\esp32\bin\bash.exe --login -c "export IDF_PATH=/esp-idf/v3.1 && export BATCH_BUILD=1 && export -n PYTHONHOME && export LANG=en_US && cd /cygdrive/e/projects/temp/EmbeddedProject8 && make -j16 BUILD_DIR_BASE='/cygdrive/e/projects/temp/EmbeddedProject8/Debug' SDKCONFIG='/cygdrive/e/projects/temp/EmbeddedProject8/sdkconfig-debug' V=0"" in directory "" on local computer
Do you observe anything similar? Is the thread count set properly to the amount of CPU cores? Does it run faster when you run exactly the same command (including the bash.exe part) manually?September 13, 2018 at 14:59 #21958
I checked as suggested and they are the same. I made another video showing compiling the “Hello World” example in VGDB vs MINGW32.
In a nut shell MINGW32 took 4 minutes and change, whereas VGDB took 8 minutes and change.
September 13, 2018 at 17:38 #21960
- This reply was modified 3 months ago by mikemoy.
Thanks for the second comparison. Unfortunately a few things are still unclear. Do you get 4 or 8 minutes when running the Cygwin command line from our toolchain manually with the same -j8 flag as with your toolchain? What time would you get by running “mintty.exe -” and then manually navigating to the project folder and building it with “make -j8”?
Also are both toolchains using the same version of ESP-IDF? We had noticed a substantial increase of build time in v3.0 compared to v2.x.September 13, 2018 at 21:18 #21964
Sorry, I dont know enough about the all the build stuff to do this for you. I can tell you I was comparing to v3.1
I just wanted to point this issue, and the project properties issues out to you, as I am sure others are seeing this and not taking the time to show you and just moving on to another platform. It would be great to see a serial terminal icon so we can have that open when its done flashing. I suggest to install PlatformIO for yourself, and give it a spin to see how it performs. I would MUCH rather use yours than theirs, but with all these issues its just unusable.September 13, 2018 at 23:32 #21970
Thanks for your input. We have rechecked the build times on ESP-IDF on the Msys2 toolchain vs our Cygwin-based toolchain on our side. Although we were not able to reproduce the 8 minute build times, we did measure 47 seconds for the Msys2-based toolchain vs. 65 seconds for our Cygwin-based toolchain. Using the Msys2 toolchain also results in a higher CPU utilization, so it looks like the version of GNU Make used in our toolchain works slower than the one in Msys2.
It also looks like Espressif has backported the CMake support to ESP-IDF 3.1, so we should be able to officially support it in one of the next VisualGDB preview builds. CMake paired with ninja provides much better build times than the original GNU Make.
Regarding the serial terminal, it is only provided in the VisualGDB Custom Edition or higher, however we made a special exception for Arduino projects as they are often used without a debugger and heavily rely on the serial terminal. Please consider using the new Arduino Project Subsystem with ESP32 support.
We also understand that PlatformIO is faster than ESP-IDF and will consider supporting it directly via a dedicated project subsystem in one of the next VisualGDB releases.September 14, 2018 at 05:47 #21972
You must have a really insane system there to build a new project for the first time 47-65 seconds!!!
I’m running a i7-4770R @ 3.20GHZ with 16 GB ram, and a Samsung SSD. I can’t even come close to those numbers.
Thanks for the tips about the Arduino Project Subsystem. But I dont plan on using ESP-Arduino. If I was I’d just use PlatformIO, or the visualmicro plugin for VS.
Any other suggestion then why my system would be so slow?September 14, 2018 at 07:38 #21973
We tested it on an i7-5960X system with 64GB RAM and 4 Intel 730 Series SSDs in RAID0. Although it’s indeed a very fast box, the difference should not be a factor of 8. Generally we would advise running the build manually on the msys2 toolchain and on our toolchain (you can run the “time make -j8” command to record the run time of make) and comparing the timing.
- If the msys2 toolchain is considerably faster than our Cygwin-based toolchain, we can help you configure VisualGDB to use it.
- If the Cygwin toolchain builds the project faster from command line, than from VisualGDB, it could be a VisualGDB bug and we should be able to fix it (although we routinely compare the build times during our tests and have never observed any difference unless you use verbose mode).
Trying to use a different machine/disk, or disabling real-time antivirus protection might also improve the build time. You could also wait a couple of weeks until we release the preliminary CMake support for ESP-IDF.September 26, 2018 at 05:20 #22081
Just wanted to share an update that we have created a repackaged version of the MSYS2-based toolchain that is 100% compatible with VisualGDB and is faster than our Cygwin-based toolchain. You can download the new toolchain release here: http://sysprogs.com/files/gnutoolchains/esp32/esp32-gcc5.2.0-r13.exe
Please use the following VisualGDB build: http://sysprogs.com/files/tmp/VisualGDB-220.127.116.116.msi (note that it contains incomplete CMake support for ESP-IDF that is even faster than the regular Make-based build, but is not 100% feature-complete yet).
You must be logged in to reply to this topic.