Forum Replies Created
-
Posts
-
Hi,
Please specify the “–sysroot=<SDKTARGETSYSROOT>” argument in COMMONFLAGS in VisualGDB Project Properties.
You can find more details in our Edison tutorial showing how to configure a similar Windows toolchain. The only difference is that in the Edison tutorial the toolchain runs on Windows and in your case it runs on a remote Linux machine.
We did not investigate this yet. VS detection is actually managed by an installer plugin provided by Microsoft (part of the WiX toolset), so by the time of the final release Microsoft will most likely resolve this on their side. Does the HKLM\Software\Wow6432Node\Microsoft\VisualStudio\15.0\InstallDir value point to the installation directory? If not, please try creating it similar to the previous versions. If yes, something more deep is causing the problem, so we would recommend installing the full version until Microsoft fixes the detection.
The script you mentioned defines CC as “
arm-poky-linux-gnueabi-gcc“.Could you try running “which arm-poky-linux-gnueabi-gcc” in the build environment and then checking if there is a
arm-poky-linux-gnueabi-gdbfile in the directory of the gcc binary?Hi,
This is actually a limitation of the algorithm used by VisualGDB to detect compiler/linker settings from the project settings. It does not work for projects with variables like ${OpenCV_LIBS}.
However it should not affect building or IntelliSense as long as you have the ‘configure IntelliSense based on CFLAGS’ flag set, so you can simply press the ‘ignore’ button when VisualGDB reports this.
Hi,
Looks like your VS installation might be missing some components that are required to detect its location. Please try installing the full version.
Hi,
It is possible to build a cross-compiler for Windows, but it’s non-trivial and error-prone. We do provide very basic instructions here, however in many cases things don’t work out-of-the-box and need additional fixing. We could build a Windows cross- toolchain for you as a service (contact our sales to get a quote), or you can just setup VisualGDB to build everything on your Linux machine with the cross-toolchain and deploy it to the ARM board like shown in the tutorial mentioned earlier. The second option does not require building an extra toolchain and once you configure a project, will do everything automatically.
Hi,
This is not supported yet, however we will consider adding a switch to the upcoming update of our OpenOCD package that we expect to release this week.
Hi,
We did not use a level translator; the Olimex debugger worked just fine without it.
If you encounter any driver issues, simply run UsbDriverTool and install the WinUSB driver for your Olimex debugger via right-click.
Hi,
We have just published a tutorial on this: http://visualgdb.com/tutorials/linux/3machine/
Let us know if it leaves any questions unanswered.
Hi,
GDB can do that (and will do it automatically with VisualGDB as well) if the A class contains virtual methods. Otherwise it simply cannot determine the type of the object from the base pointer (even under Qt Creator).
Hi,
You can do that by hacking the Makefile:
- Modify the file rule templates to include file-specific variables:
$(CXX) $(CXXFLAGS) $($(basename $(notdir $<))_FLAGS) -c $< -o $@ -MD -MF $(@:.o=.dep)
- Add file-specific flags defines above the FileSpecificTemplates line:
LEDBlink_FLAGS := -O0
You can modify the $(basename $(notdir …)) expression to use the directory name instead of the file name and apply some flags to entire directories. See the GNU Make function reference for more details.
Hi,
Please try adding a reference to the Fast Semihosting & Profiler framework via VisualGDB Project Properties => Embedded Frameworks. This should include the Sysprogs-provided implementation of semihosting that is faster than the usual one and should work even if the original one does not.
