What is going on here – GCC flags, BSP's and shared files?

[tonofsteel]

I am trying out VisualGDB and I have run into some questions.  I am not very familiar with GCC as I have mainly used other vendor supplied compilers, I apologize if these are basic questions but I cannot find any answers using Google.

– I see there are “Device-specific files” folders in Visual Studio Solution Explorer.  If I go to the file system_stm32f10x.c and then open it in file explorer I see it is in a shared location.  So I am guessing I do not want to edit anything in these files and the settings are all chosen by GCC flags?  What if I wanted to change SystemInit?  This file should not be modified since it is in a common location, would you create a local copy and include that one?

– I see in this file that it shows STM32F10X_MD_FL is defined, if I right click and go to definition I end up in gcc_Debug.h.  There is a note at the top that says this is only used by intellisense and the file lists the preprocessor macros extracted from your GCC.  Where are these macros?  I have searched every file in the project folder and I cannot find this define anywhere.

Where is all this hidden stuff located?  There are options for what you want to use for the clock and how fast you want to run that you can configure during startup.  How would you go about that using the VisualGDB tools?  There are #ifdef’s all over the place and they all lead back to the gcc_Debug.h file, if I want to see/change/discover these define’s where do I go?  I can only find folder settings in the VisualGDB project settings.

The tutorials on the VisualGDB site are good for getting started but I cannot find much on the more advanced details, is there a good place to go for this?  If I wanted to use a different GCC toolchain and had to know about these preprocessor macros where do I find out more?  If I want to modify a common file like mentioned above what is the best way to do it as to not affect other projects using the same file?

[GPIB]

I also have some other related questions:

– If I wanted to use source control with these projects how would you go about setting this up?  It references library files that are part of the install.  What would be the easiest way to copy/move these so they are all in a common root folder that can be commited?

– How would you use other compilers like IAR with this?  I saw another forum post that was replied to that stated this is possible but you would probably need to setup the flags properly.  So as in the above question, where are the flags originally defined?  Or is it all in the gcc_xxx.h files?

– Using other tools there is usually a system startup file that allows for the configuration of clocks and other parts as well.  Also there is a file to define the interrupt handling routines.  It looks like as long as you define the appropriate handler routine then GCC automatically links in your implementation instead of the default one?  The system startup file appears to be in a common library location shared among all projects.  If I had two different development boards with two different clock sources for testing how would you create these two configurations without messing up the included libraries from SysProgs since they are commonly referenced in a single location?

[support]

Hi,

You can convert your project to a stand-alone project to copy all shared files to the project directory. Alternatively you can remove the startup file from the device-specific files and add a local copy instead. VisualGDB project system is quite resilient and will not be broken by changes like that. The original startup file will be re-inserted into the project only if you change the MCU type (or MCU properties) via VisualGDB Project Properties forcing it to regenerate the settings files.

The gcc_Debug.h file contains macros that are defined by GCC itself (e.g. GCC version) and the macros specified via command line. The STM32F10X_MD_FL macro defines the current MCU family and comes from the stm32.mak file the stm32.mak file is generated from data in %LOCALAPPDATA%\VisualGDB\EmbeddedBSPs\arm-eabi\com.sysprogs.arm.stm32\BSP.XML and contains the basic settings expected by the STM32 code. When you change the current MCU type, VisualGDB will recompute the flags necessary to build the code for it and will regenerate stm32.mak. If you want to add your own preprocessor macros (e.g. controlling the clock settings), use the VisualGDB Project Properties dialog (Makefile Settings page) that will save them to the debug.mak file instead.

The source control integration should work transparently as long as your check in the .vgdbsettings files from your project directory. You can reference your external libraries using relative paths on the Makefile Settings page and check in them as well.

Setting up a different compiler like IAR would be a bit more complicated. VisualGDB uses the GNU Make tool to build the projects. The GNU Make reads the rules from Makefile and files included from it and uses them to determine which files are outdated and what commands are used to rebuild them. In order to use IAR you will need to replace the Make rules that invoke GCC with Make rules that invoke IAR. This will involve changing the GCC-specific command-line arguments to IAR-specific command-line arguments and updating regular expressions that VisualGDB uses to parse error messages.

The interrupt handlers are supported via the GCC “weak reference” mechanism. The shared startup_stm32xxx.c file contains definitions like this:

void NMI_Handler() __attribute__ ((weak, alias ("Default_Handler")));

Then it builds the interrupt vector table that is placed to the specified location in FLASH:

void * g_pfnVectors[0x6b] __attribute__ ((section (".isr_vector"))) = 
{
 &_estack,
 &Reset_Handler,
 &NMI_Handler,

If your project defines another implementation of NMI_Handler, the linker will replace the default “weak alias” with it and the interrupt vector table will point to it instead. Hence there is no need to modify the shared startup_stm32fxxx.c  file – simply ensure that each project provides its own replacement of all necessary handlers.

If you want to have several different projects using different modifications of the startup file, simply modify it this way:

#ifdef USING_BOARD_1
//Code specific to board 1
#elif defined(USING_BOARD_2)
//Code specific to board 2
#else
#error Board not defined
#endif

Then define USING_BOARD_1 or USING_BOARD_2 on the Makefile Settings page of your project settings. As different projects will have different macros defined, the same shared startup file will work differently for each of the projects.

[Author]

Posts