Forum Replies Created
-
Posts
-
Hi,
You should be able to resolve it via VisualGDB Project Properties -> Path Mapping. Simply try mapping the incorrect path e.g. (C:\proj\bf\C:\proj) to the correct one (C:\proj) and VisualGDB will automatically adjust the paths reported by GDB.
Sorry about that. We have double-checked everything and confirmed that the download page was listing auxiliary packages in the backward-compatible format that indeed would not install via VisualGDB Package Manager (it would work just fine for other package types). We have updated the page to link to the advanced packages that will work just fine. Please try downloading and installing CMake again using the updated link.
Hi,
No problem. We have double-checked it and confirmed the problem. The new ESP-IDF is using the composite statement format for idf_component_register() that is formatted using different rules.
We have added a setting controlling this behavior. Please try this build: VisualGDB-5.6.5.4406.msi
You can achieve the desired behavior by setting Tools->Options->VisualGDB->CMake->Max. Composite Statement Length to 0.
Hi,
Strange. Normally, the WSL projects should use a different type of path mapping and should not allow selecting the incorrect one in the first place. Please double-check that you select the WSL radio button on the target selection page of the wizard, rather than selecting a generic “Build on Linux” option and picking WSL in it. This helps ensure that the correct path mappings are set.
Hi,
No problem, we can gladly look into this. Do you mind sharing a screenshot of the entire Visual Studio window demonstrating the issue? The screenshot should also show the Solution Explorer and at least one source file (it’s important for checking for common module loading issues).
Hi,
No problem. VisualGDB comes with out-of-the-box support for FreeRTOS, RTX and Zephyr (NRFConnect SDK only). If you would like to target an RTOS that is not currently supported, you would need to fork our FreeRTOS plugin, and update it to handle the RTOS you are using.
As uC/OS III has a much smaller user base compared to FreeRTOS, we are not planning to support it out-of-the-box, unless some of our customers agrees to directly cover the associated porting costs.
Hi,
Indeed, the Clang-based IntelliSense engine used by VisualGDB does not rely on the .editorconfig files. It instead uses either the registry settings (when using the legacy formatter) or the .clang-format files when using clang-format.
Please refer to the following page for detailed documentation: https://visualgdb.com/documentation/intellisense/#formatting
Hi,
Please refer to the emails from our support on 2021-10-02 and 2021-10-03 for a detailed explanation on what to expect from VisualGDB. We handle support inquiries and forum inquiries exactly the same way, so the same rules apply in both cases.
Please also feel free to refer to our project importing documentation for a very detailed explanation. In short, if you would like the import to work 100% automatically, being able to build the project via command line is a requirement.
From the VisualGDB side, there is no difference between these cases. If you can build the project via command line outside VisualGDB, you can import it into VisualGDB as shown in the tutorial. If you cannot build it outside VisualGDB either, simply importing it into VisualGDB will not automatically fix the build issues.
Hi,
Sorry about the confusion. Please consider updating to VisualGDB 5.6 Beta 5. It supports installing the .vgdbpkg files directly from the Package Manager.
Hi,
No problem, we have updated our package list page to show auxiliary packages, such as CMake. You can install the downloaded package files via Tools->VisualGDB->Manage VisualGDB Packages.
Hi,
You can import existing projects into VisualGDB using the “import” mode in the wizard as shown here: https://visualgdb.com/tutorials/arm/import/
This could be related to a VS MEF cache bug. Please try restarting Visual Studio. If it doesn’t help, please try right-clicking on the tab header of the source file that is not loading, and select “copy full path”. Please share the full path here, and we will help you get it working.
We usually answer most inquiries within 1-2 business days. There is no need to create multiple tickets for the same issue, as they go through the same queue anyway.
Please note that the exact logic for recompilation it managed by ESP-IDF and not by VisualGDB. As far as our support goes, we can help if VisualGDB working on top of ESP-IDF produces different results from using ESP-IDF directly. For all issues that are also present in the ESP-IDF itself, please contact Espressif.
Regarding the max. items per CMakeLists line, VisualGDB picks it up automatically. For each statement, it detects and preserves:
- The indentation of the 1st line
- The indentation of other lines
- The number of items on the 1st line
- The max. number of items on other lines
Hence, there is no need to change any settings. Simply format the statement the way you prefer, and VisualGDB will preserve it when updating the statement.
Thanks for the detailed description. This looks like an issue with the environment variable expansion that was fixed in VisualGDB 5.6.
The stack trace looks like VisualGDB is trying to read the contents of one of the source files on the remote machine. It could freeze VS if the project contained files called aux.c or com[1-4].c, although VisualGDB 5.6 contains a check for this. Either way, please try updating to the latest Beta (or VisualGDB-5.6.5.4391.msi) and let us know if the problem persists.
