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" <c...@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!).
