[support]

Hi,

Good to know it works and sorry for the delay: this got triaged as an issue requiring a complex repro on our side, that results in slightly higher turnaround times as we need to recheck everything from scratch. Normally if you are actively working on a solution, please consider sharing more details on your setup and specific problems you encounter and we should be able to answer much faster as we will have more context on the problem.

[support]

The configuration shown on your screenshots should be normally supported out-of-the-box.

Could you please share the exact settings that contain hardcoded paths (either the .vgdbproj file, or a screenshot) and also describe what exactly happens if you remove the settings with those paths?

[support]

 

Thanks for your feedback. We will try to clarify the reasoning behind various supported device families below.

VisualGDB comes with out-of-the-box support for many popular devices and also device families that are getting increased traction. This effectively splits the cost of maintaining support for those device families between many users, helping us offer high product quality at a competitive price.

Unfortunately this also means that we cannot offer support for less popular device families like LPC24xx as a part of our regular products without considerably raising the prices, hence we offer several workarounds:

• First of all, you can easily create a project manually by following the legacy device tutorial: https://visualgdb.com/tutorials/arm/legacy/.
• Second of all we publish sources for our tools responsible for generating BSPs for supported devices, so you can create your own BSP generator based on them.
• Finally, we could do if for you as a part of our paid consulting services. Feel free to write an email to our sales to get a quote.

[support]

Hi,

The error message looks like something shown by Visual Studio itself, not VisualGDB. It might indicate that IntelliSense is not properly initialized for the source file you are editing.

Are you using the Clang IntelliSense? If not, does the problem get solved if you enable it? If yes, please share a screenshot of the entire VS window showing the source file you opened (including any navigation bars on top) so we could check which IntelliSense engine is handling it.

[support]

Hi,

No problem. Please let us know the exact message you get now (after installing pkg-config and resyncing the sysroot). Please also double-check that you have set environment variables mentioned in step #7.

[support]

Hi,

Strange. Could you please try locating the <vector> file manually (both on remote machine and locally in %LOCALAPPDATA%\VisualGDB) and check if the corresponding directory is listed on the IntelliSense Directories page?

[support]

Hi,

Normally you don’t need custom path mappings for ESP32 projects, as long as the general path style is set to “Cygwin” (the new wizard should set it automatically, but it the project was created with an earlier preview build, it could be set incorrectly).

 

If you cannot get the project to work without the custom mappings, please let us know more details (your .vgdbproj file, the exact mapping VisualGDB suggests and more context on where it happens) and we should be able to fix it.

[support]

Hi,

The local MSBuild projects are built directly without the use of GNU Make (for remote projects VisualGDB generates a temporary Makefile with a different structure than the regular Makefiles), so specifying TARGETTYPE won’t have any effect.

Instead please use the VS project properties (not VisualGDB Project Properties) -> Configuration Properties -> General -> Configuration Type.

[support]

Hi,

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.

[support]

Hi,

Thanks for sharing this. We don’t support it yet, but it looks like a good feature to have. We will consider adding it to one of the upcoming releases.

[support]

Hi,

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.

[support]

Hi,

Thanks, looks like one of the recent MSBuild builds changed the internal thread structure, so VisualGDB was not properly detecting the end-of-build event.

Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.4.2436.msi

[support]

Hi,

Sorry, this is not scheduled for any specific release yet. The best workaround currently would be to try creating a basic importer based on the other open-source importers we provide: https://github.com/sysprogs/BSPTools/tree/master/ProjectImporters

Once we will add an official importer for TrueStudio, we will publish its sources in the same repository and will update this thread.

[support]

Hi,

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.

[support]

Hi,

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.:

VisualGDB: 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?

[Author]

Posts