Forum Replies Created
-
Posts
-
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.
Hi,
The -std=c++11 is a compiler option, not a preprocessor macro. Please add it to CXXFLAGS instead and everything should work.
The main reason why MCU settings are global for the project is because they define which sources from the SDK are put into the project. If we wanted to make it per-configuration, we would have to combine those lists from different configurations and exclude some of the files from some configurations, making the entire process significantly more complicated. So we decided to make the MCU-specific settings global and the usual settings like extra include paths per-configuration.
Thanks for letting us know. In this case you do indeed need the old BSP. If you want to use both ones at the same time, you can simply relocate the old one via GUI and change its ID in the bsp.xml file.
We will most likely to that after VisualGDB 5.2 is out around the end of summer. As a workaround you can launch SmarTTY that is built into VisualGDB via VisualGDB.exe /ssh:<connection settings file>.
The connection settings files are located in %APPDATA%\SmarTTY.
Hi,
Yes, you can launch it manually by running “make Debug/<file>.o”. This will force GNU Make to build just one file. The reason why VisualGDB cannot do that conveniently via Ctrl-F7 is that VS does not offer a straight-forward way of doing that for Makefile projects.Hi,
No problem. “Similar, but not quite the same” is the most annoying type of problem.
The “cannot detect target name” message means that VisualGDB was unable to locate the “TARGETNAME := xxx” line in the Makefile and it won’t be able to automatically add the project output to the list of inputs of another project that is referencing it. If you have modified Makefiles manually, this makes sense. If you don’t rely on this feature, you can simply ignore the warning.
