ARM Cortex-M Microcontroller startup files

[Jens Bauer via Digitalmars-d]

On Thursday, 30 April 2015 at 23:03:48 UTC, Mike wrote:
> On Thursday, 30 April 2015 at 20:45:28 UTC, Martin Nowak wrote:
>
>>> * Is data and bss initialization part of  the runtime, or 
>>> delegated to toolchain, silicon, and BSP vendors?
>>
>> We should provide appropriate linker scripts and do the 
>> initialization.
>
> The linker script can give the location of the data and bss 
> segments.  My question is really about whether or not the 
> druntime implementation should assume responsibility for 
> loading the data segment from flash and zeroing bss.  I suppose 
> that should be left to the vendor's BSP, not part of druntime 
> itself.

How about providing functions for copying data and zeroing bss ?
-In my startup file, I use functions for that, because they're 
optimized pretty well.
The code is very similar to my optimized #define in C.

Most Cortex-M microcontrollers allow you to set the clock 
frequency.
It's a good idea to do this before you start copying a large 
block of data, because that means the startup time is quicker.
The drawback is that ... CMSIS wants to write in the BSS (the 
CoreClockFrequency variable, for instance), and that's just 
erased when BSS is cleared - I wish they had just reserved a 
hardware register for these 4 variables.

Anyway, personally, I like the startup file to contain the 
data/bss init, because I might want to customize it. My startup 
files allow you to override Reset_Handler and each exception, 
which means you don't even have to modify the startup file. That 
means one less template-file to copy to every project.

> I guess what I'm trying to articulate is that currently when 
> you download an MCU toolchain, it contains a collection of 
> things from many different vendors (GCC, binutils, newlib, 
> startup files, linker scripts, multilibs, etc...), all in one 
> package.  I recommend, not doing that with this druntime.  
> druntime should just be the implementation of D language 
> features for microcontrollers.

Agree.

> Once a minimal druntime is created, some other effort can take 
> that druntime and package it with a compiler, linker, startup 
> files, linker scripts, c standard library, debugger, flash 
> programmer, etc... and make a convenient 
> downloadable/installable package for immediate use.

Agree.
Linker-scripts can usually be written so they work well with 
multiple devices from the same vendor. I'm not talking about 
specific RAM and Flash settings, but the main body of the linker 
script. Small 3 .. 8 line scripts can then include the body, 
which provides all the standard stuff. So here I'm talking about 
a body linker-script could be provided for each vendor (not each 
device family or each device). If each device family or device 
requires different attention, then I suggest something like 
Vendor:DeviceFamily:DeviceSpecific.
Thus it would not be overwhelming writing one linker script per 
vendor and it would be fairly straight-forward for the casual 
user to add a new device or even a device family if needed.
I'd also prefer having the linker-script in a location, outside 
each project (because I have many projects and I hate duplicates 
and updating each duplicate each time I find something that needs 
to be changed).

> Assuming that is an appropriate strategy, what does the first 
> druntime release look like.
> * For example: What will `assert` do?  Is that just a stub to 
> be implemented by the programmer?

Most asserts on microcontrollers I've seen are just implemented 
as while(1){}
-But one could probably also trigger the debugger (BKPT), 
HardFault or RESET if necessary.
Perhaps the default could be while(1){} and then 
version(ASSERT_BKPT) could be used to add a breakpoint before 
that while(1){}. Thus --version=ASSERT_BKPT could be specified on 
the command-line.
Would it be possible to 'extend' an existing assert; eg. the user 
might want to be notified via the U(S)ART ?