Forum Replies Created
-
Posts
-
Hi,
Sorry, although it is called “Visual Studio”, it is a completely different product based on a different technology stack. So “extending” VisualGDB to support it would require rewriting it from scratch using a different technology. As of today we don’t have such plans, sorry.
That said, Microsoft is working on a GUI framework that will support building modern cross-platform GUI using the .Net technology, so we might be able to support Visual Studio for Mac and Visual Studio code once this framework matures.
Hi,
This looks like the build tools you are using are not compatible with the target system. Please try checking the ‘dmesg’ output for more details (e.g. wrong kernel version, incompatible architecture, etc). If nothing helps, please try building and loading the module manually. Once VisualKernel detects that it is loaded, it won’t try to rebuild it anymore.
Hi,
Looks like the internal structure of the ESP-IDF slightly changed in version 3.1 and VisualGDB fails to detect the application FLASH offset. We have fixed this internally and will publish it in the upcoming v5.4 Preview 4.
Hi,
Strange. The partition table should be handled by the ESP-IDF directly with no interference from VisualGDB.
Please try rechecking if the problem could be reproduced on a basic project built from command line. If this is the case, please try comparing it with one of the ESP-IDF samples that works.
Hi,
Please try installing this version of the Segger debug package: https://sysprogs.com/files/tmp/segger-dmsp-5.1preview1.vgdbxedp
Hi,
Legally the license is bound to the person specified in the purchase form. Technically, VisualGDB is licensed per seat (i.e. computer/user configuration).
You can find more in our EULA that is displayed during the product installation.
Hope this helps. Let us know if you have any further questions.
Hi,
Just wanted to share an update that we have a preliminary version of the Nordic BSP based on SDK 15.0 available here: https://sysprogs.com/files/tmp/nrf5x-15.0.vgdbxbsp
As the internal structure of the linker scripts in this SDK has changed, please use this VisualGDB build in order to ensure the correct linker scripts are selected: https://sysprogs.com/files/tmp/VisualGDB-5.4.3.2358.msi
Hi,
Thanks for clarifying the constructor initialization list issue and providing detailed screenshots. As the clang-format logic comes directly from the clang codebase, we won’t be able to maintain a parallel formatting engine with an extended set of formatting rules/options. However if you could convince the Clang maintainers to add the advanced options you require to their codebase (e.g. by sending them a merge request), we should be able to update our engine promptly.
The “preprocessor keywords” indeed looks like our bug. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.3.2358.msi
For user types in templates VisualGDB uses a separate setting – C++ Template Type Parameters. Please consider changing it additionally to C++ User Types.
Hi,
Thanks for checking that SmarTTY works, however this is unfortunately insufficient to track this down. Please try running xterm via SmarTTY and let us know if it shows the window on the Windows side correctly.
Hi,
Please try clicking the round expander button in the progress window and then check for the build error messages (or use View->Other Windows->VisualKernel Diagnostics Console).
Most likely your kernel is missing some of the configuration options required for the optimized module handling logic.
Hi,
Sorry about that, looks like one of the caches wasn’t properly updated on our server. Please try updating your BSP again, now it should show 4.7R2.
Hi,
This looks like an issue that is already fixed in the STM32 BSP v4.7R2. Please ensure you update to this version.
Hi,
No problem. We have rechecked our profiler framework in the maximum warning mode and took care of the most issues. Please update to the latest 2.17 package.
If you would like to resolve any further advanced warnings, please send us a patch based on the v2.17 package source and we should be able to integrate it into our source tree (as long as it doesn’t break any functionality).
Hi,
VisualGDB uses a different approach when dealing with CMake projects. Instead of generating a second project from the CMakeLists.txt files, VisualGDB can open the CMake project directly as a regular Visual Studio project. This is fully supported for Linux targets (see this tutorial) and is partially supported for embedded targets (importing existing code is supported, but features like Embedded Frameworks won’t work yet).
We would advise trying VisualGDB 5.4 Preview 3 and importing your project by selecting “Create a project built with command-line tools” -> “Import a CMake project” -> “Use the advanced CMake Project Subsystem”. If this doesn’t work, please let us know more about the errors you encounter and we can help you resolve them.
