New: Some questions

[G40]

Hello and thanks. VGDB looks like being a really useful tool. I’m using the SysProgs GCC toolchain with VS2012 to try and build a very basic project for an LPC4330 board using some LPCOpen code. JTAG probe is a Segger JLink.

First issue is setting the include directories. I’m trying to do this in the VisualGDB property pages but things are not going smoothly, so apologies for some possibly dumb questions.

1. What drive and path characters does GCC expect? Can I Use r:pathtosomehfiles ?
2. what is correct way to specify multiple paths directly in the edit box? a semi-colon ‘;’ ?
3. The .mak files all warn against editing. Where does VGDB store the project properties? Are they in the project XML file?
4. In debug settings the target device is specified as being an LPC4330_M4 – something keeps appending (SPIFI) to this string which makes Jli

One thing that would really help is a better include path editor. There is no way to paste a path to a folder directly into the dialog list. The only route is to use the painfully slow XP style folder picker.
Also, how about automatically converting absolute paths to project relative ones?

Thanks for any help.

[ket]

Hi,

1. Absolute paths with a forward slash (e.g. e:/dir/file.c) are expected (Windows normally uses the back slash) for include directories in embedded projects.
2. The list editors always put the dividers automatically, so you can use that to see which separator is used in each place. For include directories the divider character is space.
3. The .mak files warn against editing because VisualGDB expects some structure in the .mak files. Basically, it is safe to modify the value of assignments like A := B (VisualGDB will pick that up), but if you add more complex things like ifdef, += or something similar, it could confuse the project properties dialog and end up being overwritten if you edit things through the dialog. In some cases (e.g.) source files list, the values are also set automatically by VisualGDB. You can however edit the makefiles if you keep the above in mind, in general it is also safer to add your own variables and rules instead of editing the existing. The settings set in Makefile settings are stored into the makefiles, all other settings are stored in the VisualGDB project file (.vgdbsettings).
4. Sorry, it’s hard to understand the problem based on your description. Could you please attach a screenshot or provide more details?

One thing that would really help is a better include path editor. There is no way to paste a path to a folder directly into the dialog list. The only route is to use the painfully slow XP style folder picker.

That is actually already in the planned features list. With remote Linux directories we use our own dialog that allows pasting as well, for Windows directories we use the default Windows folder dialog. We are not happy with its usability either and will be making it more usable.

Also, how about automatically converting absolute paths to project relative ones?

In certain VisualGDB settings that is already done. Sometimes we set the paths according to build variables, sometimes relative. For include directories if you use the editor we use the path style from the Path mapping page. For directories that go into makefiles, we usually do not make them automatically relative because toolchains may not like it and we like to leave the choice to the user.

[G40]

Hello Kets.

1. Re GCC include paths. Are these relative to the target source file or the project/solution file?
2. What is the time frame for the improved feature? It’s the kind of thing that drives me bats,
2. What then does .xml do?
3. Attached is a snap showing the JLink target question. What appended the (SPIFI)?

Many thanks

Help much appreciated.

[ket]

Hi,

1. The include paths should be absolute. If you use relative paths in the settings, then the paths should always be relative to the working directory of gcc/make i.e. the project directory. The include statements inside source files should be relative to the source file’s location or to one of the specified include directories.
2. As it is not a blocking issue or a bug, next version of VisualGDB.
3. MCU.xml? It is a helper file for vgdbsettings, it specifies the mcu settings.
4. Thanks for noticing this, it is a gui bug. The target device field lists all the options available as well as allowing to specify the target device manually. As LPC4330_M4 is not listed in the available options, it looks like the closest match is selected next time the settings are loaded. However, this is only a visual bug, the manually specified value is saved correctly. Unless you change anything on the debug settings page, the saved value will not be overwritten with the wrong value. We will be releasing a fix for this soon.

[G40]

Hello Kets.

Thanks. A few more questions …

I’m trying to set up a project using a different toolchain.

Here’s an example. I’ve got an installation of gcc tools from a vendor that I want to use under VGDB. I specify the path to the correct bin folder but leave the ‘Use GNU Make include with VisualGDB’ checked. Press OK. This returns me to the main Project Wizard page. Then when I hit ‘next’ the Wizard tries to validate the toolchain and it appears to fail at make (though I cannot tell as the error message is not very clear). Please see attached files.

[attachment=1:2bmz941y]vgdb-ext-tools.jpg[/attachment:2bmz941y]

[ket]

Hi,

Thanks for noticing this bug. We will include a fix to this in our next r release of VisualGDB, which we will release as soon as possible.

[G40]

Thanks Kets,

I assume the work-around is to specify the full path to VGDB make?

[ket]

Hi,

Please try the newly released VisualGDB version 4.1r10 (http://visualgdb.com/download/).

It includes a fix to third-party toolchain importing. We also added a possibility to edit local folders instead of using the usual Windows folder browser.

[Author]

Posts