Forum Replies Created
-
Posts
-
Hi,
We have just published a tutorial showing how to use the header discovery: http://visualgdb.com/tutorials/intellisense/headers/
If this does not help, please attach a screenshot of your Visual Studio showing the Errors pane and the text editor for the source file that has the missing headers.
Please note that the new feature only works if you are using the Clang IntelliSense.
Hi,
Thanks for the log. It looks like you have modified the main source file and then tried reparsing one of the header files. This does look like a bottleneck and we could optimize this further.
Can you confirm that code completion within the main .cpp file works reasonably fast after the trick with explicitly ending the preamble?
Hi,
The include directories are handled separately from the .h files in Solution Explorer.
The easiest way to resolve this is to update to VisualGDB 5.2 Beta 4 and let it find the missing header files automatically.
Hi,
Thanks for clarifying this. Normally the FLASH programming is handled by OpenOCD, so supporting special programming modes would involve creating an OpenOCD patch.
As this feature looks like something very specific to certain bootloader types, we would not be able to give it enough priority to push it into one of the next releases. Sorry about that.
Our best advice would be to submit a feature request to the OpenOCD community.
Hi,
No, Live Profiling uses the regular SWD/JTAG lines and does not require any extra connections. It relies on the fact that you can read/write target memory over JTAG/SWD without stopping the target and uses a simple memory buffer for communication.
Hi,
Resharper uses a separate IntelliSense engine, so unless JetBrains explicitly adds support for parsing VisualGDB projects, it may not work properly.
We do recommend using our Clang IntelliSense engine for VisualGDB projects as it is especially optimized for GCC-specific code and provides many improvements compared to the regular Visual C++ IntelliSense.
If you miss some of the features with it, please let us know and we will consider adding them.
Hi,
Thanks, we have located and fixed the problem. It was caused by a conflict between an internal target called ‘build’ and build.c in your project. Please try this build: VisualGDB-5.2.12.1269.msi
OK, we have added support for this to VisualGDB 5.2 Beta 4.
You can find a detailed tutorial here: http://visualgdb.com/tutorials/linux/win10/
Hi,
No problem. Could you provide an example of the copy-modify-writeback function you mentioned? Do you mean software breakpoints in FLASH memory?
Hi,
This looks like a known bug of Resharper. Please try disabling it and ensure that you have Visual C++ installed.
Hi,
Sorry, looks like you are using v5.1. Please try the latest v5.2 beta. It uses separate internal environments to handle the long reparse and critical operations like code completion, so it should be much faster.
Hi,
If the bootloader expects the non-bootloader code to be placed at a specific address (e.g. 0x8005000), the easiest way to achieve this is to add a line like this before the corresponding section in your linker script:
. = <offset to place subsequent code/data>
You can double-check the addresses of the code and variables by enabling the map file generation and looking through the map file once the build is done.
Hi,
Sorry, not fully automatically yet. You can either re-create a project, or manually create a new platform “VisualGDB” via the Configuration manager and set the VS properties like .vgdbsettings file, toolchain, etc. manually. If you encounter any problems, feel free to let us know and we will provide help.
We will consider adding automatic conversion to v5.3.
Hi,
The easiest way would be to modify the Makefile to remove the references to EXTERNAL_LIBS so that the variable is simply ignored.
A better solution would be to try out the new MSBuild backend that comes with VisualGDB 5.2. It’s faster, more flexible and handles project references in a smarter way that does not break with non-default folder names.
