Startup files for STM32F4xx

[Jens Bauer via Digitalmars-d-learn]

On Saturday, 25 April 2015 at 17:11:22 UTC, Johannes Pfau wrote:
> Am Sat, 25 Apr 2015 11:38:45 +0000
> schrieb "Martin Nowak" <code at dawg.eu>:
>
>> On Saturday, 25 April 2015 at 05:07:04 UTC, Jens Bauer wrote:
>> >
>> > import mcu.stm32f439.all
>> 
>> I think that belongs in the makefile/dub.json as 
>> -version=STM32F439.
>> Then you could simply import mcu.gpio or mcu.spi.
>
> We need a better / clever generic approach to solve 'board
> configuration' issues. Here version blocks work but you might 
> also
> want to specify other configuration options (clock speed if
> static, ...) and we don't have -D to define constants.

I actually attempted to use version on the exception vector list, 
but as you cannot do this ...

@isr_vector VectorFunc[] g_pfnVectors = [
	cast(VectorFunc)&_stack,
	&Reset_Handler,
version(USB){
	&USBActivity_IRQHandler,
} version(CAN){
	&CANActivity_IRQHandler,
}
	];

... I ditched the idea. There might be a good way for doing this, 
so that the number of startup files can be reduced, and perhaps 
allow for increased convenience.

One thing that's tedious, is when the vendor replaces a single 
handler in a later device implementation.
I can't seem to make a chain of weak aliases, eg..

SPI0_Interrupt() defaults to defaultExceptionHandler()
SPI_Interrupt() defaults to SPI0_Interrupt()

implementing SPI_Interrupt() would then automatically use this in 
the exception vector, but if also implementing SPI0_Interrupt(), 
thene SPI0_Interrupt() would have higher priority and 
SPI_Interrupt() should be discarded.
If neither SPI0_Interrupt() nor SPI_Interrupt() is implemented, 
then they would fallback to defaultExceptionHandler().

-I could not get such an 'alias-chain' working; perhaps it's just 
because I got confused, perhaps it's because the compiler does 
not support it. - I don't know yet. ;)

If an alias-chain was possible, I think the startup files could 
become fairly pretty, and there wouldn't be problems with using 
the wrong handler name on chips where the vendors decided to 
rename the handler functions within one chip-family (I won't tell 
anyone who you are, NXP - I promise!).