Forum Replies Created
-
Posts
-
Hi,
Yes, the biggest feature from the Custom edition is the integrated unit test support. It also supports advanced real-time watch and many other usability features.
You can find a full list of the Custom edition features here: http://visualgdb.com/buy/custom
Hi,
Sorry, checked the std::printf() instead of std::snprintf(). Yes, our toolchain indeed does not have _GLIBCXX_USE_C99 and _GLIBCXX_USE_C99_MATH_TR1 enabled (which is the default configuration for GCC), so those functions are not available under the std:: namespace.
You should be still able to use them via the regular C syntax (e.g. snprintf(…) or nanf(…)).
Hi,
Sorry, tried reproducing that with “f:\projects\temp\EmbeddedProject-16” and did not get anything to fail. Perhaps the problem is triggered by something else? Could you please clarify which wizard and what other settings were you using?
The new Beta 2 was indeed not handling relative paths in the “NMake output” properly. We have fixed this in the development branch and will include this fix in Beta 3.
Can you verify that the Threads window in Visual Studio is closed when you get the multiple ‘-stack-list-frames’ commands?
Hi,
We have added this feature to the v5.2 version. Please try the latest VisualGDB 5.2 Beta 2. You can switch the toolchain on the Makefile Settings page of your VisualGDB Project Properties.
Hi,
Perhaps this is something auto-generated by the compiler? Please try reverting the settings to a point when the code builds successfully, enable the generation of Map files and check the .map file for any references to ‘_udivmoddi4’. It should mention the .o or .a file that contains the function.
Hi,
You can configure VisualGDB to upload that extra directory by adding a custom pre-build step to your project (requires Custom edition or higher). Alternatively you can create a dummy Linux project that will have that directory selected as the main source directory and won’t actually build anything. Then each time Visual Studio tries to build that project, the directory will be uploaded automatically.
Hi,
Are you using a toolchain shipped with VisualGDB? If not, your toolchain may be too old and have no support for these functions.
If yes, please double-check that the <source file name>.gcc.rsp file in the VisualGDB\<configuration> directory contains the -std setting you have selected. If not, please double-check that you have selected it for the correct project configuration.
Hi,
Most likely this happens because your LinuxApp project specifies the absolute path to MySharedLib in its settings. This is by design – absolute include paths are treated as system paths and are automatically cached.
You can override this by adding a custom path mapping in LinuxApp’s VisualGDB Project Properties or by using relative paths in project properties instead.
Please also note that including the library .cpp files from other .cpp files will not refer to the code in the library, but will instead just copy that code to your application. You can read more about C++ headers and sources here: http://www.cplusplus.com/forum/articles/10627/
Hi,
For release configurations – yes. For debug configurations you should replace -O3 with -O0 as optimized code is hard to debug.
Hi,
Yes, that should do. Please upload the files to a file hosting service like dropbox, as our ticket system has an attachment size limit.
Hi,
You definitely need to check in the .vgdbsettings files as they contain VisualGDB-specific settings. If you are using Make, CMake or QMake, you also need to check in the main project file and the configuration files from that build systems.
Hi,
Good to know it works. Could be antivirus software treating sample.xml as a virus, corrupt filesystem or any other cause. If the problem reoccurs, feel free to contact us again.
Hi,
This looks like a bug. The v5.2 uses a different internal mechanism for locating the .vgdbsettings files (using the name from NMake Project Properties for all cases). Perhaps there is a typo somewhere or some special character in the project name is causing trouble? Would you be able to share your .vcxproj and .vgdbsettings files so that we could quickly check what is causing this and fix it?
VisualGDB always tries to check that the toolchain can build valid code when you create a new project. You can simply ignore any errors it discovers and proceed with the project creation if you don’t care about building. We did not change any logic related to this in v5.2. Please feel free to send us the project file (and the .vgdbsettings file) so that we could help you resolve this.
Hi,
Strange. Please double-check that you select the device and sample as shown below:
If the sample does not appear, please check if you have the following file:
%LOCALAPPDATA%\VisualGDB\EmbeddedBSPs\arm-eabi\com.sysprogs.arm.stm32\samples\LEDBlink_STM32F0X\sample.xml
If yes, could you please check if the StdPeriph sample appears for other device families?
