Startup files for STM32F4xx

Rikki Cattermole via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Sat Apr 25 01:30:10 PDT 2015


On 25/04/2015 7:31 p.m., Jens Bauer wrote:
> On Saturday, 25 April 2015 at 07:08:26 UTC, Rikki Cattermole wrote:
>>
>> I was referring to package.d files. And publically importing all below
>> modules/packages.
>
> 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. Thus the
> final binary will be huge, if all of those interfaces are imported.
>
> NXP made some #ifdef in their header files and it was terrible working
> with these. You couldn't build one library, which would work with all
> your projects, because then you would have a big lump containing
> everything, including all the stuff you wouldn't need.

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.

>> I wonder if you can get e.g. interfaces and classes working.
>
> I hope I will. ;)
> I think classes are really a must. The only thing that I (currently) see
> that could perhaps block this from working, would be missing support for
> static constructors and a missing memory allocator.
> The missing memory allocator would be entirely because I would have
> disabled it; this might be necessary on very small devices (such as 1K
> RAM devices or worse).
> Devices that have 64K on-chip memory might be big enough for using new
> and delete on a regular basis (this is just guesswork). If the
> programmer is instantiating classes carefully, it should be possible to
> avoid too many problems.
> My current startup.d files do not support static constructors. static
> destructors are obsolete, because a microcontroller never 'exits'. If
> it's turned off, the constructed data gets deallocated automatically
> when the power drops too low anyway. ;)
> In other words: Normally main() never exits.

You could definitely allocate the memory during linking. After all e.g. 
drivers will be singleton right?


More information about the Digitalmars-d-learn mailing list