Forum Replies Created
-
Posts
-
Hi,
Yes, we will consider doing that if ST continues actively developing/supporting TrueStudio.
Either way, we have made our project importing plugins open-source to help our users import formats that are not directly supported by VisualGDB yet. This way you might be able to create a basic importing plugin that will automate most of the work you need before we officially support it.
Hi,
Normally it should work automatically if you are using the latest VisualGDB 5.4 Preview 3, however setting it manually is a reasonable workaround if it doesn’t.
If you can confirm that the setting is not automatically picked up with the latest VisualGDB, please feel free to post a repro project here and we will investigate/fix this.
Hi,
It will basically restrict discovery of references to the main source file only. E.g. if you have a template function inside the main file, but it’s instantiated somewhere in a header file, that instantiation will be ignored and the function body won’t be colored properly (that only affects template functions and only if they are not used inside the main file itself).
It might also interfere with the ‘find all references’ functionality for translation unit-scoped entities (e.g. static functions), that are declared inside the main file, but used from headers (this won’t affect finding references for regular functions/classes, as it involves scanning the entire project using a different mechanism that is not affected by this setting).
Hi,
Thanks, this looks like a known issue. Please try clicking on the timer icon in the upper right corner of the document and click “enable lightweight references” (or enable it via VisualGDB Project Properties -> IntelliSense). This should significantly reduce the parse time.
Hi,
This might be happening because the FreeRTOS in the ESP8266 SDK is pre-compiled and hence won’t be updated, although there might be some workaround. Either way, please double-check this with Espressif, as they are the vendor of the SDK and know its internals better than we do.
Hi,
We are currently working on the new Advanced Arduino Project Subsystem that will make it possible (and very easy and intuitive) to manage Arduino projects with Visual Studio. If you would like to get notified about the new releases, please consider following us on Twitter.
Hi,
Yes, please edit the HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\SxS\VS7\15.0 value in registry to point to the VS Professional folder and then uninstall VisualGDB and install it back. This should get VisualGDB to recognize the correct VS instance.
Hi,
No problem, we rechecked the Raspberry Pi support for OpenOCD and can try to clarify this. First of all, please try reading this article – it provides detailed steps with screenshots.
Basically, you would need to build OpenOCD on your Raspberry Pi and run it there (our OpenOCD executable runs on Windows and hence it doesn’t indeed include the drivers that only make sense when running on Raspberry Pi).
On the VisualGDB side, the “custom gdb stub” mode won’t work as it would expect the stub to run on Windows. Instead, please set the following options:
Command <default GDB path> Arguments ——interpreter mi $(TargetPath) Target selection command target remote raspberrypi:<port> Start command continue Please note the double dash before “interpreter mi”.
Hi,
If you have imported the project as an externally built custom project, you can change the main executable path on the Build Settings page of VisualGDB Project Properties.
Hi,
The easiest way would be to use the “custom gdb stub mode” instead of the “full-custom” one. VisualGDB would then automatically configure the GDB arguments (the problem you are describing looks like a missing “–interpreter mi” argument to gdb).
Another option would be replace the OpenOCD binary in the %LOCALAPPDATA%\VisualGDB\EmbeddedDebugPackages\…openocd\bin with the one you built and manually pick the Rasberry Pi interface file.
It is strange that VisualGDB did not support some JTAG programmers; our OpenOCD build uses default build settings, so all programmers that are normally supported, should work. Feel free to share more details about this and we can help you figure it out.
Also Segger J-Link is recommended only if you are looking for 100% out-of-the-box experience for a wide variety of devices. If you are OK playing around with OpenOCD scripts (or are only using popular devices like STM32), getting an inexpensive Olimex probe should do the job as it works very well with OpenOCD.
Hi,
Please try attaching to your device as shown in this tutorial. It should show what exactly the CPU is doing. Please also use the “Verify memory” button in the GDB Session window to check whether the FLASH memory was programmed correctly.
Hi,
Thanks for confirming this. For MSBuild projects the setting should be under VS Project Properties (not VisualGDB Project Properties) -> Embedded Project -> Generate Binary File.
Hi,
Yes, please let us know your project type (MSBuild or GNU Make) and we can point to the specific location of this setting.
Hi,
Yes, as long as you have the “Generate Binary file” enabled in VisualGDB Project Properties (or VS Project Properties for MSBuild-based projects), VisualGDB should generate .bin files that can be simply programmed to the FLASH memory (offset 0 from the beginning of FLASH).
Hi,
OK, thanks for clarifying this. This indeed looks like the parsing itself is taking a lot of time. If you are opening the project for the first time, this is to be expected – VisualGDB will build various caches and the subsequent operations should take much less time. If anything else is slow beyond the initial delay, please let us know and we can help you pinpoint it.
