Startup files for STM32F4xx

[Jens Bauer via Digitalmars-d-learn]

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.

> 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.

> At worse maybe structs + alias this + meta programming for e.g. 
> drivers?

When you mention drivers, I'm reminded that on some devices, such 
as the STM32F4xx, we have two types of on-chip SRAM: CCMRAM and 
normal local SRAM.
The CCMRAM is not accessible by the DMA for instance. That means 
if objects are allocated here, they cannot be accessed by the DMA.
In some cases, it would be desirable to 'prefer' allocating in 
CCMRAM and if absolutely necessary, allocate in the other local 
SRAM.
That means 'new' and 'delete' / 'malloc' and 'free' must be able 
to handle multiple RAM locations (because there's also external 
SRAM and external SDRAM).