No it doens' really matter how you do it and yes your code is probably easier to maintain, the only reason I do this is that I wanted to get the thing up and running with the Keil IDE and I could't seem to figure out how to get the peripheral lib by ST to get compiled into that project.
...
I am still looking for some good explanation on how to get Keil to use the ST peripheral lib so if you have any information on how to set up Keil correctly then I'd appreciate it
The toolchain situation would be a good enough reason, yes.
No explanations on Keil from me I'm afraid.... Under linux I use the obligatory eclipse + arm-none-eabi combo. And on windoze I use Atollic, which is based on eclipse. That way I can use inspiration gleaned from the atollic install on the linux install. Out of sheer frustration I caved in and installed atollic, which at least worked out of the box. Then when I slowly got the hang of it I moved to linux again...
I guess my point is, you could try Atollic. That worked straight away without any crazy library setup required. You can install the Lite version (making sure to [X] check the ST-Link install). After that you can do Import => Example from Teh Internets => your fav demo board => Blinkenlights, etc. That got me up and running fairly quick.
As for this code snippet:
GPIOD->BSRRL |= (1<<15); // set PD15 high
GPIOD->BSRRH |= (1<<14); // set PD14 low
You may want to do this:
GPIOD->BSRRL = (1<<15); // set PD15 low
GPIOD->BSRRH = (1<<14); // set PD14 high
Note that the low/high situation is precisely opposed to what was in your comments. You probably grabbed some random googled code, but just so you know. In case you didn't know, then this serves as a nice example of "optimization" vs "the illusion of optimization". Because even the crappy ST lib results in something faster than the inadvertent |= based code. Your code with the bit-wise or results in a read-modify-write, which results in waaay too many instructions. The above does it's thing in 4 instructions as you'd expect.
Personally I am still perfectly happy to use this equivalent:
GPIO_ResetBits(GPIOD, GPIO_Pin_15 | GPIO_Pin_14);
GPIO_SetBits(GPIOD, GPIO_Pin_13 | GPIO_Pin_12);
... certainly for non-critical things as blink-the-led.
The rationale for using the GPIOx->ODR notation for bit-banging is only partially rational IMO. One of the reasons why I picked the stm32f4 is because it has a nice set of peripherals,
precisely so I would not have to do any bit-banging to do trivial mundane boring stuff like i2c or spi.
All the stuff I've used so far on it could either be handled by the onboard peripherals, OR was slow enough that I didn't really care too much about optimizing it to the ns.
Incidentally, if you are going the optimization route you might as well do this for the previous bit of code:
*((__IO uint32_t *)&GPIOD->BSRRL) = 0xC0003000; // PD15=PD14 = 0 , PD13=PD12=1
That does a 32-bit write to the BSRRL and BSRRH registers in one go. I was curious if the BSRR register accepts 32-bit writes, and indeed it does. It even gives the right result.
I just checked it on my discovery board and 1) the leds go blinkie as intended, and 2) the resulting asm for it is 3 instructions. Two for the constant loads, and one for the write. That's with -O1 optimization.
And no, I don't advocate using that code. But if you want to optimize like that, might as well go all the way and shave of 25% of your execution time.