Startup files for STM32F4xx

[Jens Bauer via Digitalmars-d-learn]

On Saturday, 25 April 2015 at 08:30:10 UTC, Rikki Cattermole 
wrote:
> On 25/04/2015 7:31 p.m., Jens Bauer wrote:
>>
>> Normally, one would want to import only the most necessary 
>> parts. Let's take an example: A microcontroller has USB, LCD 
>> controller, Ethernet, U(s)ART, SPI, CAN, I2S, I2C and also
>> supports SDRAM. -But the program being developed only
>> needs the LCD controller and the USART, so the Ethernet
>> should not be imported, because if it's seen by the linker,
>> the linker will include it in the final binary.

This is because some drivers implement interrupt routines, which 
are weak+alias by default and *always* referenced by the 
exception vectors.
Thus: In C: If you compile the C file containing the driver, the 
symbol will be found, and thus the code will be included in the 
final binary.

> If you have problems with too large a binaries, in D then it is 
> a bug in the compiler. Never used code, should not hit the 
> linker.
> Okay okay, it does happen. There is a trick with empty template 
> bracket which allows for this. But it is a work around.

It *should* happen (in this case).

Consider void ETH_Handler() to be referenced by my exception 
vector (which is just an array of function pointers).
If I do not import mcu.stm32f429.ethernet - then I will not get 
the driver.
If, however, I do import mcu.stm32f429.ethernet, then the 
function 'void ETH_Handler()' will be bulit and the linker will 
see it in one of the .o files, and it will include it in the 
final binary.

The developer can choose to use his own driver, because he's 
clever enough to write a better one than the one supplied by the 
vendor in this case. He then implements his own void 
ETH_Handler().

>> My current startup.d files do not support static constructors. 
>> static destructors are obsolete {...} main() never exits.
>
> You could definitely allocate the memory during linking. After 
> all e.g. drivers will be singleton right?

I think they will; I don't know if it will always be the case, 
but I currently can't think of a case where one would allocate a 
driver and then deallocate it, unless it's used only once for a 
short while.
This would be a rare case, and in such cases, I believe the user 
could probably solve it. ;)