Forum Replies Created
-
Posts
-
Hi,
This is actually supported through a different mechanism – custom per-user variables (see this tutorial and also host aliases). You will still need to check in the .vgdbcmake file into source control, but you won’t need to hardcode any per-user settings there. If this doesn’t work, please let us know and we will try to suggest a better way to achieve this.
Hi,
Yes, the Linux edition includes all of the features of the Embedded edition.
You can find a list of VisualGDB editions and features here: http://visualgdb.com/buy/
You can try using the Synchronized Directories page of VisualGDB Project Properties (Custom edition and higher). It allows linking a specific Linux directory to a specific Windows directory and defining the exact files that will be synchronized and the conditions for it.
However, the “go to definition” will only work for files that are a part of the project (VisualGDB cannot find a definition of a function in the .cpp file unless it knows the flags the file is built with so it can fully parse it). The easiest way to fix that would be to import the SDK sources into another VisualGDB-based project in the same solution (it doesn’t have to be fully buildable; as long as the source files are included into it and you specified the correct header directories, or let VisualGDB discover them with header discovery, it will be able to index the file contents).
Hi,
The importing settings look correct, so the macros should get imported properly. Please send your project file via our support form and we will check what is going on.
Hi,
Please use the context menu in Solution Explorer (right mouse click on the project name in the right part of the Visual Studio window). You can open Solution Explorer via View->Solution Explorer.
If you still cannot find it, please attach a screenshot of the entire VS window showing your project and we will highlight it for you.
Hi,
Sorry for the delay. We have fixed the SSH console problem (and many other stability issues) in this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.100.2728.msi
Regarding the source files, please try closing the disassembly window and double-click in the call stack. Is the source shown correctly? If not, could you please attach a gdb log so that we could see what is going on?
Hi,
The behavior you are describing might have several different causes, so we would advise simplifying the project as much as possible in order to pinpoint this:
- First of all, try creating a fresh “LEDBlink” project for the same MCU/RTOS/compiler and check if the problem persists. If not, recheck your linker script, hardware settings (e.g. the use of timers) and special initialization functions.
- If you are using the Keil compiler, try checking if the problem persists with GCC.
- If you are using a RTOS (e.g. RTX), try checking if a similar project with no RTOS still has the problem.
- Try creating a single test() function that will wait for a second, call it in a loop and disable instrumentation of ALL other functions.
Let us know your findings and we will help you fix this.
No problem, we have fixed the formatting of your post.
The clang code analysis output is indeed only shown for the current file. The main use case for it is to detect common errors as you write new code and suggest the fixes similar to the regular IntelliSense errors/warnings.
We do have long-term plans for scanning the entire project for warnings and showing an easy-to-use searchable report, however this won’t make it into v5.4 due to our release schedule constraints.
Hi,
No problem and good to know it works. VisualGDB doesn’t add the locations of all headers to the header search list as it would cause very hard-to-track errors with some libraries (e.g. the ones with separate private/public headers). We do support this for advanced mbed projects and MSBuild-based projects, but unfortunately we won’t be able to support this on Android projects as it might cause more problems than it would solve.
As for the upgrade, we have loaded VisualGDB 5.4 with support for many new platforms, redesigned GUI, better custom actions, advanced code navigation and other features that make it easier to use, but ultimately it’s up to you to decide whether the upgrade is worth it based on your project types and requirements. Feel free to contact our sales if you would like to get a trial extension voucher to try out the new version.
Hi,
Thanks, we have fixed the expanded list height in VisualGDB Project Properties in this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.100.2728.msi
Unfortunately we were not able to reproduce the second problem. Most likely it is caused by some specific properties of your .filters file. If you could share a basic repro project, we should be able to fix it.
VisualGDB uses the VS filters do distinguish between the files automatically added from the BSP (that will be overwritten next time you regenerate the files, change the MCU or update the BSP) and your project files that are not changed. Hence there is no option to disable them. You could try converting your project to a stand-alone one that doesn’t reference any files from the BSPs and reorganizing the sources manually.
In the next major version we are planning to support the advanced CMake project subsystem as the primary build system for embedded projects. VisualGDB will then fully control what is shown in Solution Explorer and will be able to provide a higher degree of customization.
Hi,
No problem. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.100.2728.msi
It will remember the last used host selected via the “Find” button and the “nostop” flag. You will be also able to add/remove the “,nostop” part manually just as before.
Hi,
This looks like a bug that was recently fixed in the Espressif’s OpenOCD implementation. We have updated our packages to include this fix.
Please try installing the latest ESP32 toolchain via VisualGDB Package Manager and (also install the “ESP32 Debug Methods” package or create a new project via the ESP32 project wizard). This should get the latest OpenOCD with the most recent fixes.
Hi,
No problem. We can help you get this to work.
When determining IntelliSense include paths, VisualGDB doesn’t use the GCC compiler path from the toolchain file. Instead it uses the path specified when importing the toolchain. You can configure it via VisualGDB Project Properties -> CMake project settings -> Toolchain -> (button with the wrench icon).
Then try closing the solution, deleting the ImplicitCompilerFlags.xml file from the VisualGDBCache directory and opening the VisualGDB Diagnostic Console.
Next time you open the project, VisualGDB will run the gcc from the toolchain definition with the flags reported by CMake and will detect the include directories based on that.
If this doesn’t help, please attach your ImplicitCompilerFlags.xml file, a screenshot of the toolchain definition and, the output from the diagnostics console and the CodeModel.json file from the VisualGDB\Debug directory and we will check what is going on.
Hi,
Do you use the “Find” button to find the target? If yes, we could make it remember the last state of the flags for each target.
