Forum Replies Created
-
AuthorPosts
-
support
KeymasterHi,
Perhaps some of the data gets overwritten? Please try setting a breakpoint right after initializing them with zero and use the Watch window to check whether they actually contain zeros. If not, check that those variables actually fit in the RAM area of your device. If yes, try setting a data breakpoint on one of them to see what code modifies it.
January 23, 2016 at 06:13 in reply to: Use constructor library on Raspberry Pi using VisualGDB : #7518support
KeymasterHi,
Not sure what do you mean by the constructor library, but we actually have a tutorial showing how to access Raspberry Pi camera from your VisualGDB projects: http://visualgdb.com/tutorials/raspberry/camera/
And another one with OpenCV: http://visualgdb.com/tutorials/raspberry/opencv/camera/
Consider following those to get basic understanding of using external libraries with VisualGDB.
support
KeymasterHi,
Thanks for reporting this, we have fixed it in the upcoming Preview 2.
support
KeymasterAccording to this thread, it looks like this is no longer possible in VS2015. Consider leaving feedback there so the VS guys could consider fixing this.
support
KeymasterHi,
Most likely the passphrase did not get removed properly or the libssh2 library that VisualGDB is using fails to recognize it.
We recommend checking the “setup public key automatically” button to let VisualGDB generate a private key, store it in a Windows key container (automatically protected by your Windows account password) and use it automatically.
support
KeymasterHi,
You can diagnose this by adding a new function to your library (e.g. testfunc()), calling it from your code and then checking whether the library on Raspberry Pi contains the new function by running the following command:
nm <library path> | grep <function name>
You can find out the path of the library loaded into your application by running the “info shared” command in the GDB Session window.
support
Keymastersupport
KeymasterHi,
Did you get any toolchain testing errors while creating your project? Normally IntelliSense is configured based on the results of a toolchain test.
support
KeymasterHi,
We expect a preview build this week. We are going to support the latest version from github.
support
KeymasterHi,
Here’s an example of modifying the Makefile to copy your .so file in the ..\AllLibraries directory (it assumes that you are building on Windows with a cross-compiler):
../AllLibraries: mkdir ..\AllLibraries ifeq ($(TARGETTYPE),SHARED) $(BINARYDIR)/$(TARGETNAME): $(all_objs) $(EXTERNAL_LIBS) ../AllLibraries $(LD) -shared -o $@ $(LDFLAGS) $(START_GROUP) $(all_objs) $(LIBRARY_LDFLAGS) $(END_GROUP) copy /y $(subst /,\,$@) ..\AllLibraries\$(notdir $@) endif
VisualGDB does not overwrite the Makefile, it carefully adjusts parts of it (e.g. the SOURCEFILES assignment line and the lines below the #VisualGDB: GeneratedRules marker).
Normally VisualGDB should add the -Wl,–rpath=’$$ORIGIN’ flag to linker flags and that should add an attribute to the linked file telling the library loader to check the directory of the executable for missing library dependencies. Do you see this flag in your build log?
January 16, 2016 at 04:04 in reply to: Unable to debug std::map when cmake is configured with flag -std=c++11 #7485support
KeymasterHi,
Thanks for the log files. It looks like Qt Creator is using Python extensions to extract meaningful values from the STL variables. VisualGDB does the type matching on the Visual Studio side in order to support gdb builds without Python support. As a side effect of it, it cannot automatically resolve typedefs without issuing further commands.
The upcoming VisualGDB 5.1 supports Natvis, so we could add an extension to its format in order to explicitly specify typedefed types and map them to STL containers. Would that be a reasonable option?
support
KeymasterHi,
Please try using the Embedded Memory Explorer to see what exact code occupies the IRAM memory. Then try moving some of it to FLASH or modify the linker script to place the default code sections to FLASH instead of IRAM (that may impact performance/stability).
support
KeymasterHi,
We are planning to add mbed support in the next preview build of VisualGDB 5.1. We will be adding a tutorial in the next few weeks.
support
KeymasterHi,
There was a bug in our latest Raspberry Pi toolchain. Please re-download the toolchain from http://gnutoolchains.com/raspberry/
support
KeymasterHi,
The binary size explains the delay. You can add a custom post-build step to deploy your binary and disable the automatic deployment in Debug settings. As the build process always runs in the background, this will move the deployment to the background as well.
Regarding “searching for a matching source file”, VisualGDB does that when it’s searching for a .cpp file that includes the .h file being opened. Normally it quickly scans all source files for unconditional include directives and picks the first matching one, however if none of the files include your header file unconditionally, VisualGDB will try fully parsing some of the files to find which of them actually includes the header. Is your header directly included from one of the files? Is the include directive surrounded by #ifdef or #if?
-
AuthorPosts