Forum Replies Created
-
Posts
-
Hi,
This could happen if you switched the language standard in the Makefile manually and did not let VisualGDB retest the settings so that it could query the correct __cplusplus version from your gcc. If you are not sure, please let us know if you are using MSBuild or Make and how exactly you changed the project to C++11.
Hi,
This depends whether you are using MSBuild, GNU Make or CMake. For MSBuild you can achieve this via VS Project Properties, for other build systems you would need to manually edit the configuration files (e.g. Makefile) and explicitly specify the debugged executable via VisualGDB Project Properties as automatic detection won’t work anymore.
Hi,
You can achieve the same effect by manually adding the source files and preprocessor macros listed in the framework definition. E.g. for the ‘fixed stack/heap’ they are defined in the BSP.XML file as follows:
<AdditionalSourceFiles> <string>$$SYS:BSP_ROOT$$/StackAndHeap/StackAndHeap.c</string> </AdditionalSourceFiles> <AdditionalPreprocessorMacros> <string>FIXED_STACK_SIZE=$$com.sysprogs.bspoptions.stackheap.stacksize$$</string> <string>FIXED_HEAP_SIZE=$$com.sysprogs.bspoptions.stackheap.heapsize$$</string> </AdditionalPreprocessorMacros>
If you are not sure, let us know and we will provide more detailed steps.
Hi,
Could be an antivirus bug or a corrupt filesystem. If you encounter this problem again, feel free to let us know and we will help you resolve it.
Hi,
This could happen if the property used to store the location of the .vgdbsettings file was set incorrectly. Please try holding Shift while right-clicking on the project and VisualGDB will display the corresponding menu item even if it cannot confirm that it’s a valid VisualGDB Project. It may then display an error that will help locate the root cause for this.
If it does not help, please let us know if it’s an MSBuild-based project or not and we will suggest further diagnostic steps.
We are aware of this and are gradually switching our GUI to the newer WPF framework that handles high resolution better. We have also received feedback that the old WinForms-based GUI scales better after installing Windows 10 Creator Update.
Hi,
Sorry, not fully sure we understood you correctly. Do you mean that some of the VisualGDB GUI does not display Chinese characters correctly or that VisualGDB is not translated to Chinese?
Hi,
Unoptimized debug builds are expected to result in much slower execution time; this is by design. This is needed because the optimizer would try to place as many variables as possible into registers and will reuse the same register for a different variable once the old one is no longer needed, making it only possible to evaluate its value while it is still needed by other code. Other optimizations would make stepping less intuitive by combining reusable code fragments like the code for the ‘return’ statements. Our best advice would be to play around with the optimization setting, changing it between -O0, -Og-, -O1, -O2 and -O3. Increasing optimization will increase the speed, but make the debugging experience harder.
Regarding unstable code, most likely your code either contains a bug that corrupts memory (but is not reproduced without optimization) or relies on some assumption that does not hold with full optimization. E.g. the following code may hang in the release build because the optimizer will try to move reading of ‘done’ outside of the loop:
int done; void InterruptHandler() { done = 1; } int main() { //... while (!done) { } printf("done\n"); }Declaring the ‘done’ variable with the ‘volatile’ keyword will solve the problem.
ESP-IDF is for ESP32; if you are using ESP8266, it’s either RTOS SDK, or non-OS SDK. Both can be downloaded from here: https://espressif.com/en/support/download/sdks-demos
You can also simply post your test program here and we could quickly check if the problem is reproduced with the original command-line build tools.
Hi,
If you had to add a line manually, there could be a version mismatch between your system file and the HAL library and that could cause further cryptic errors. We would strongly encourage double-checking this and getting the correct version rather than just adding a missing line, as it would help avoid really tough-to-pinpoint problems.
Hi,
If both building and IntelliSense is slow, perhaps something is using the CPU? Could you please check the CPU usage via Task Manager? This could also happen if the RAM utilization was too high or too much background disk activity was slowing down the access to the source files.
