compiling my code with no headers (stm32) (?)

[mikewax]

live n learn...
so i didn't know that the libraries supplied by ST are crap, i used cubemx  to create a program (usb.c) for an stm32f070 that would send and receive data over the chip's built-in usb interface. to my surprise, it worked just like they said it would. i got over confident.
i took another pre-existing program (pwm.c) that i had wrote and tested on the same proto board and figured i could integrate the two into a single program (PWMwithUSB.c)
LOL   the instant i took the includes from pwm.c and tried to include them in usb.c, trueStudio literally drew a gun and capped me between the eyes. and it wasn't a little handgun either. it pulled out a laser cannon like they had on the death star and splattered my brains from here to the moon. commence ignition...
ouch....
many hours later i reached the brilliant conclusion that there was no way in hell the cube library and the standard peripheral library (both written by ST) were gonna coexist. this town (Los Angeles, 500 miles^2) just wasn't big enough for both of them.
so, with my brains vaporized, i had to rewrite pwm.c with no headers. several days later, i was only halfway finished, when i realized... wtf?, i inadvertantly de-included the most basic (stm32f0xx.h) header file, and the code still compiled and worked correctly without any macro references at all.
all the assignment statements, like "TIM1->CCR1 = ..." and "GPIOB->MODER |= ....." the macro expansions. they are compiling with no header present to define them.
how can this be? how does gcc know what "TIM1->CCR1" means?

[ataradov]

You must be including them one way or the other. If this is GCC supplied by ST, then it may pre-include header files according to the part number passed on the command line.

Can you extract a Makefile created by whatever IDE you are using?

PS: Stock GCC knows absolutely nothing about peripherals for a specific part from a specific manufacturer. It only knows how to make code for a specified core.

BTW, libraries supplied by all chip vendors are crap. That's the default assumption you should take when starting with a new part, and you will save yourself a lot of wasted time.

[mikewax]

ok the compiler, arm-atollic-eabi-gcc, must be written by Atollic for the TrueStudio IDE, so that may be my answer. i'll see if i can come up with a makefile.

thanx, mike

[DBecker]

You can be certain that it's a stock version of GCC, with a carefully selected set of configuration options and a list of pre-includes.

You can see what the pre-processor option are by passing "-v" (or "-v -v -v") on the command line.  It's probably a "-include ..." option.

[Brutte]

many hours later i reached the brilliant conclusion that there was no way in hell the cube library and the standard peripheral library (both written by ST) were gonna coexist.

So why haven't you connected USB HID from CubeF0 + PWM from CubeF0 as most users would do?
USB HID from SPL + PWM from Cube seems kind of exotic, you must admit.

BTW, I do not think it is impossible to use SPL and Cube in one project (function names do not overlap) but as functionality of both libraries overlap that does not look like the right direction.

BTW, header files discovery rules are precise enough. The pre/compiler won't search the paths that was not asked to.
PEBCAK.