[support]

Hi,

We looked more into this. Actually, you can simply use the COMPUTERNAME variable that is available on Windows XP and newer versions. Use $(COMPUTERNAME) in your commands in VisualGDB settings.
Note that you can also use any other environment variables of the current Windows user (if a build variable with the same name exists, it will override the environment variable).

[support]

Hi,

You could exclude some source files by replacing this line in Makefile:

all_source_files := $(SOURCEFILES)

with this:

all_source_files := $(filter-out $(EXCLUDED_FILES),$(SOURCEFILES))

Then you can define EXCLUDED_FILES in your per-configuration .mak files to have those files excluded from build.

Regarding configuration reuse, unfortunately there is no direct way. VisualGDB Project Properties editor is way more sophisticated than Visual Studio configuration editor and it heavily relies on the ‘current configuration’ concept (e.g. it substitutes configuration variables on-the-fly, allows browsing files on the currently selected remote machine, etc).
However, you can use the following techniques to reuse some of the settings:
1. VisualGDB Make Settings editor edits the .mak file for the current configuration, it does not regenerate it. You can move the common settings to a separate .mak file (e.g. CFLAGS += -ggdb) and include it from the configuration files.
2. All VisualGDB settings are stored in -.vgdbsettings files. Those files are XML files generated by .Net serializer from public objects inside VisualGDB.EXE assembly. If you are dealing with plenty of configurations you may want to generate those on-the-fly. Using the .Net serializer it’s a very straight-forward process.
3. VisualGDB supports an project extension mechanism that allows creating .Net extensions to automate things not directly supported by VisualGDB. We could extend it with a method to patch the project settings on-the-fly before building or debugging so that you could have only one .vgdbsettings file and a basic extension DLL that sets the architecture-specific parameters based on the platform.

[support]

In order for Visual Studio to edit your project files, the files need to be accessible from the Windows machine. You can either create a local copy and re-upload modified files each time, or share your project directory on Linux with Samba and mount it on Windows so that Visual Studio accesses them directly.

Both options are available via the VisualGDB Project Wizard:
1. On the first page select “Import a project built with command-line tools”
2. On the third page select “The sources are already on “
3. On the fourth page select how do you want to access the sources.

[support]

Hi,

Looks like the project your are trying to build depends on some Linux-style tools.
You can actually install Cygwin, add Cygwin directories to PATH and try building it again using make.exe from cygwin. This should normally work, as cygwin provides most of Linux tools on Windows (ensure that you install the necessary packages).

[support]

Hi,

Unfortunately it’s not currently supported, however we will add this feature in the upcoming maintenance release (4.1r8). Thanks for your feedback.

[support]

Hi,

We are aware of the first issue and will be releasing a fix in the next r release. It is safe to ignore the toolchain test fail and save the settings anyway as the issue is only with toolchain testing.

For the second issue, in the Qt pro file both library names and directories are stored in the same location. VisualGDB displays them in different fields to allow custom editors such as folder browsing. In the debug.pro file, what is the value of the LIBS variable?

[support]

Hi,

We tried your project, for us the breakpoints were set both in the project and library files. Have you tried rebuilding the project?

If you still experience issues with breakpoints, try the Android breakpoint issues tutorial for hints or submit us a full gdb log.

[support]

Hi,

It looks like the project is successfully built but fails to be deployed to Raspberry Pi. Try deploying manually to see if it fixes the problem.
To do it, in Visual Studio go to Tools->SSH Host Manager and open a console using the Raspberry Pi connection. You can use the SCP menu to transfer the project’s executable from C:inetpubwwwrootFlashGrowDBFlashGrowDBDebug” to /tmp on Raspberry Pi.

[support]

Hi,

Thanks for finding that out. It looks like your GCC does not create a valid binary when being tested, but also does not return any error code and that confuses VisualGDB. Could you please press the “ignore” button in the error dialog and see whether a buildable project is created?

[support]

Hi,

This looks like a bug in our toolchain. Thanks for reporting it, we will fix it in the next release. In the meanwhile please use the following workaround:
1. Download mv.exe to SysGCCRaspberrybin
2. Modify SysGCCRaspberryarm-linux-gnueabihfsysrootusrshareqt4mkspecsarm-linux-gnueabihfqmake.conf so that QMAKE_MOVE is set to mv:

QMAKE_MOVE				= mv

3. Create a file called ln.bat in SysGCCRaspberry with the following contents:

copy /y %2 %3

[support]

Hi,

Could you please verify that the /tmp directory on your Raspberry PI device exists and is writable? You can check it by connecting to your Raspberry PI via SmarTTY and running the following command:

ls -l / | grep tmp

[support]

Hi,

Unfortunately VisualGDB only functions as a Visual Studio add-in and cannot be used separately from it. If you want to make your own build/debug setup that is not dependent on VisualGDB, please consider OpenOCD manuals/forums, STM32 community and GCC community for further information.

[support]

Hi,

Thanks for your feedback. Unfortunately we were not able to reproduce your problem on our side.
Does this happen on one specific project or even on our ‘LED blink’ demo generated by the wizard? Are you using the latest GCC 4.8.2 or an older version?

[support]

Hi,

You can use either NFS shares or SMB shares (via samba) to setup folder sharing between two Linux computers. VisualGDB currently does not support configuring those automatically, however there are numerous tutorials on doing that, simply search online for the one relevant for your Linux distro.

Once you have setup the share simply go to VisualGDB Project Properties, Debug page, update the deployment path and enable the “don’t auto-deploy” checkbox. VisualGDB will then assume that the deployment is done by some other tool and will simply launch debugging using the path you have specified.

[support]

Hi,

Unfortunately we have not tested our tool with Phonon. If it does not work for you, you can either try starting it manually from the console and then attaching to it (select ‘attach’ in VisualGDB Project Properties) or look into the Phonon source to understand what API it is using to interact with the hardware and why it is not working over SSH. You can try selecting ‘Show X11 windows on the remote computer’ in VisualGDB Project Properties to see if it solves the problem.

[Author]

Posts