Built-in BSP with custom BSP_ROOT

[bojanpotocnik]

Hello!

1) I created my custom Toolchain, at first it said “Compatible device definitions: 0” but then (after few days) somehow managed to “copy” device support from built-in Sysprog’s Toolchain and now I have the same device support. This is not the problem – actually, this is good feature which I welcome. But, how do you decide which devices are supported?
[attachment=1:f6tg8v3q]Screenshot 2014-10-15 08.08.40.png[/attachment:f6tg8v3q]

2) When I create the project, I can select my device (STM32F303VC) or provide the Makefile flags manually. I choose integrated support and select STM32F303VC because I like all the settings VisualGDB defines and provides in file:

STM32F303VC

C:UsersBojanAppDataLocalVisualGDBEmbeddedBSPsarm-eabicom.sysprogs.arm.stm32devicesSTM32F30xxx.xml

But the problem is that I don’t want to use provided driver files which are included in stm32.mak in project folder:

BSP_ROOT ?= C:/Users/Bojan/AppData/Local/VisualGDB/EmbeddedBSPs/arm-eabi/com.sysprogs.arm.stm32
...
INCLUDE_DIRS += $(BSP_ROOT)/STM32F30xxx/CMSIS/Device/ST/STM32F30x/Include $(BSP_ROOT)/STM32F30xxx/CMSIS/Include $(BSP_ROOT)/STM32F30xxx/CMSIS/RTOS $(BSP_ROOT)/STM32F30xxx/STM32F30x_StdPeriph_Driver/inc

because I have my own drivers and files created with STM32CubeMX. If I edit stm32.mak file, it gets overwritten. I can “backup” the variables before include $(ADDITIONAL_MAKE_FILES) and then restore them, but I think this is not practical.
I created additional project with custom flags and looked at its MCU.xml for BspID tag and then modified stm32.xml in mi original project from:

com.sysprogs.arm.stm32

STM32F303VC

C:UsersBojanAppDataLocalVisualGDBEmbeddedBSPsarm-eabicom.sysprogs.arm.stm32devicesSTM32F30xxx.xml

to

com.visualgdb.bsp.in-place

STM32F303VC

C:UsersBojanAppDataLocalVisualGDBEmbeddedBSPsarm-eabicom.sysprogs.arm.stm32devicesSTM32F30xxx.xml

which only provided error when opening project settings 🙁
[attachment=0:f6tg8v3q]Screenshot 2014-10-15 08.39.53.png[/attachment:f6tg8v3q]

It’s is possible to add some checkbox or XML settings to initially configure project with integrated settings and flags, but later “deatch” it from BSP?

3) Is it possible to add checkbox something like “Use relative paths”? Because now I am using Python script in makefiles to convert all possible paths to relative, as example:

SDK_PATH := $(shell python2.7 -c "import os.path; print os.path.relpath('$(SDK_PATH_REALPATH)', '$(CURDIR)')")/

if I don’t do that, Rebuild is impossible because of error “Multiple make rules” in .dep files (colons in absolute paths are recognized as separate Make rules).

4) Makefile -> Build tools -> Make command. What is the difference between default:
cmd.exe /c “C:cygwinbinmake.exe”
and
C:cygwinbinmake.exe or just make, because I have Cygwin added to my %PATH%. Both are working, why CMD?

Best regards,
Bojan

[support]

Hi,

We have added support for ‘detaching’ projects from BSPs to the upcoming VisualGDB 4.3.
Please switch to a newer version of GNU Make. The one that comes with our toolchains supports the c:/xxx path syntax in .dep files properly.
Running make.exe without cmd used to cause some random crashes in some cases. We did not investigate this further, as it looks like a bug specific to some versions of GNU Make for Windows and using cmd fixes it.

[bojanpotocnik]

Thank you for your answer.

Approximately when will new version be released or is there any option for “Beta updates”? 😛

I am using latest make, but it’s true that I use none of the tools provided with VisualGDB but Cygwin instead

GNU Make 4.0
Built for x86_64-pc-cygwin

I will try using your make instead. Thank you.

[support]

Hi,

You can update for free to any version released within a year from your purchase date (we usually count the date of the first beta). Hence you can start using the beta now and simply install the final release over it once it’s out.

Cygwin build of make is the root cause of the problems you are expecting. It expects the paths in the /cygdrive/c/xxx format, while our toolchains are MinGW-based and report paths in the c:/xxx format. To avoid further problems, ensure that your toolchain and your make executable are built for the same platform.

[bojanpotocnik]

After a few hours of trying and Google-ing I stumbled upon my own topic again. However, now I am using nRF52832 and MSBuild build system (VisualGDB 5.3 Preview 8). I created the embedded project with specifying build flags manually, which is OK. But in this case I have a problem that there is no Makefiles, only MCU.xml,  $(ProjectName)-$(Configuration).vgdbsettings and $(ProjectDir)mcu.props files. If I add a new variable e.g. NRF5_SDK_ROOT in the User variables  section of the VisualGDB Project Properties and then use it in the paths under Embedded Project as $(NRF5_SDK_ROOT)\... it does not work, the variable is always empty.
How does one use variables with MSBuild system?

And about Embedded Project and MSBuild settings sections in the VisualGDB Project Properties – when are those set of settings synchronized (it seems like they’re not at all)? Which e.g. Include directories should I edit?

Thank you.

[support]

Hi,

In order to add MSBuild variables, you would need to edit the .vxcproj file as follows:

  <PropertyGroup>
    <VariableName>VariableValue</VariableName>
  </PropertyGroup>

The settings from Embedded Project page get written to the mcu.props file after you change them (VS would not display those in VS project properties) and apply to all configurations inside a project.

The settings from the MSBuild settings page get saved in the .vcxproj file and are applied to each configuration independently.

[Author]

Posts