[supportKeymaster]

Hi,

This is by design. The MSBuild-based projects must be build by invoking either devenv.exe, or msbuild.exe (VisualGDB would internally run msbuild.exe if you try building the .vgdbsettings file, but it looks like something is preventing it from finding the correct .vcxproj file in your case). Please try using the following command line:

C++

msbuild.exe <.vcxproj file> /property:Platform=VisualGDB /property:Configuration=Debug

1	msbuild.exe <.vcxproj file> /property:Platform=VisualGDB /property:Configuration=Debug

[supportKeymaster]

Hi,

We could add an option to specify a list of “system” directory prefixes in the VisualGDB Project Properties and a button in the profiling report pane to hide symbols defined inside those directories. Would that work for you?

[supportKeymaster]

Hi,

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

It supports using clang-format instead of our regular code formatter (it also features a convenient GUI editor for the formatting styles with live preview). You can enable clang-format for VisualGDB projects via Tools->Options->Text Editor->C/C++ (VisualGDB)->Formatting Engine and then use the format icon in the upper right corner of the source editor to launch the interactive style editor.

[supportKeymaster]

Hi,

Good to know it works. BTW, you can avoid renaming the main.cpp file to main.c if you declare all functions that are called from Plain C code with extern “C” as shown in this tutorial: https://visualgdb.com/tutorials/tips/externc/

[supportKeymaster]

Hi,

Sorry, we still don’t have any plans for VSCode support. The biggest problem here is that VSCode is based on a different technology stack, so integrating VisualGDB with it would imply creating and maintaining another product from scratch with not much reuse from the current VisualGDB code base.

That said, Microsoft is working on bringing .Net to the web apps domain. Once the Blazor framework matures, we will reconsider supporting VS Code, as it might make it easier to port existing VisualGDB logic without a complete rewrite.

[supportKeymaster]

Hi,

Most likely you are missing the code responsible for redirecting stdout output to the UART.

Please see this tutorial for a detailed example (you will need to add a similar implemenation for _write() and other similar functions).

[supportKeymaster]

Hi,

You might be running a firewall on the Raspberry Pi side. You could try checking with Wireshark whether there’s any reply from Raspberry Pi when you try connecting to that port. Another option would be to try other ports or use netcat instead of OpenOCD to listen to incoming connections to see if the problem is caused by OpenOCD (it might be listening exclusively on the 127.0.0.1 socket).

[supportKeymaster]

Hi,

Sorry for the delay. We are still planning to add this in the near future, as soon as we complete finalizing the Arduino support. Please expect this to be available in the next 3-6 weeks.

[supportKeymaster]

Hi,

As OpenCV is natively built with CMake, referencing it from a QMake-based project would involve non-trivial amount of manual settings edits.

Instead we would advise creating a CMake-based Qt projects (see this tutorial for details) and then referencing OpenCV using the regular find_package logic (see this tutorial).

If this is not an option, let us know and we can help you understand the logic behind the library paths and names so you could find the correct settings for the QMake project.

[supportKeymaster]

Hi,

Thanks for running this. This build didn’t contain any fix yet – it only contained extra logging that helped us understand what was causing the problem. Turns out the customization to the project made VisualGDB treat the ESPFS pseudo-binary as the primary project output (see second line below):

C++

/cygdrive/c/Users/Don/Documents/esphttpd-freertos/Debug/bootloader/bootloader.elf: 0 inputs, IsStaticLibrary=False /cygdrive/c/Users/Don/Documents/esphttpd-freertos/Debug/libesphttpd/webpages.espfs.o: 0 inputs, IsStaticLibrary=False /cygdrive/c/Users/Don/Documents/esphttpd-freertos/Debug/webserver.elf: 0 inputs, IsStaticLibrary=False

1 2 3

/cygdrive/c/Users/Don/Documents/esphttpd-freertos/Debug/bootloader/bootloader.elf: 0 inputs, IsStaticLibrary=False /cygdrive/c/Users/Don/Documents/esphttpd-freertos/Debug/libesphttpd/webpages.espfs.o: 0 inputs, IsStaticLibrary=False /cygdrive/c/Users/Don/Documents/esphttpd-freertos/Debug/webserver.elf: 0 inputs, IsStaticLibrary=False

Now that we have pinpointed the root cause, we were able to fully fix it. Please try this build, it should work out-of-the-box (you may still need to clean the project): http://sysprogs.com/files/tmp/VisualGDB-5.4.3.2316.msi

[supportKeymaster]

Hi,

No problem, we have fixed the navigation bar issues in this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.3.2315.msi

Please use the Tools->Options->Text Editor->C/C++ (VisualGDB) to configure the tabs/spaces for the VisualGDB projects. Unfortunately the language service design inherited from Visual Studio forces this to be a separate setting from the regular C/C++ tabs/spaces. You can also set the position of the new braces via Tools->Options->Text Editor->C/C++ (VisualGDB)->Formatting->Newline Insertion->New types.

The new build also contains experimental support for clang-format, including an interactive style editor. You can enable it via VisualGDB Project Properties -> IntelliSense Settings. It is a complete drop-in replacement to the regular formatting engine and is heavily optimized to seamlessly run in the background.

[supportKeymaster]

Hi,

Thanks for the log file. Looks like VisualGDB incorrectly determines the path to the main binary built by the project. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.3.2315.msi

Before opening the project, please enable debug logging in View->Other Windows->VisualGDB Diagnostics Console and then attach the debug output produced while opening the project. It should contain lines like “ESP-IDF code model: found xxx targets” listing the targets discovered from the esp-idf log.

[supportKeymaster]

Hi,

Yes, it looks like VisualGDB is checking for modified source/header files in your project and is trying to rebuild the preamble for the newly opened file. This results in reading many header files in a short succession, likely overloading the network connection you are using and delaying the main Visual Studio thread that is trying to access the source file.

Unfortunately there’s not much to optimize on our side though – VisualGDB needs to read all those files in order to build the necessary caches and if the network connection cannot handle this responsively, it would delay everything else. The good news is that VisualGDB only does this once after you open the solution. Once the necessary data is cached, VisualGDB won’t need to recompute/recheck it again.

Also storing the source code on the Windows side (or using the direct SSH access with the Advanced CMake Project Subsystem so that VisualGDB can prioritize file accesses internally) could speed this up.

[supportKeymaster]

Hi,

Good to know it works. We will unify the styles of the pages after we convert most of the settings pages to WPF (they will inherit the Visual Studio color theme just like the new wizards). Before that, the WPF-based pages and WinForms-based pages will indeed look slightly differently, sorry.

[supportKeymaster]

Hi,

No problem, please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.3.2313.msi

[Author]

Posts