Re: [avr-chat] Startup code.

[Erik Christiansen]

On Wed, Sep 22, 2010 at 12:47:29PM +0200, Robert von Knobloch wrote:

> I assume a .deb file is a Debian package?

Yep, sorry for the distro-ism.

> I use Suse and compile the toolchain  from source (so I 'know' what I'm
> getting :-)

Yes, I did that for a long time, and probably will again if I'm actively
developing on AVR again. I just needed an avr-gcc quickly, when advising
on those linker scripts.

> I couldn't find the startup code as source in the sources, only as an
> object file which confused me - there is be no crttn13.S, only crttn13.0.

Ah, I thought I had a vague recollection of the object files being
built, but it is now several years since I last built avr-gcc, so the
memory must be false.

Still, you don't need the source, because there is no heap code to
optimise, and __stack can be set wherever you like, AFAICT.

You could define __stack with a -D on the avr-gcc command line, even.
To avoid a make target for each application * alternatives combination,
it might be convenient to have someting like:

$ make chips_are_xxx    # To set up for this week's silicon.
$ make my_app_42        # Build an application accordingly.

> I really wanted to see what exactly occurs in the various .initx files
> as the docs only describe function, not actual code and I want to see
> what I can change ;-)

They are an ordered sequence of initially empty initialisation sections,
and you are free to link your initialisations into individual sections,
to control the order of their execution. And .init9 jumps to the entry
point, __start. Have a look at:

$ avr-objdump -d crttn13.o > /tmp/crttn13

Because the object file is relocatable, the SP (0x3d) line doesn't
have a value:

   4: c0 e0          ldi   r28, 0x00   ; 0
   6: cd bf          out   0x3d, r28   ; 61

until the linker has done its job, and

$ avr-objdump -t /usr/avr/lib/crttn13.o

tells us that __stack is a symbol used here, and it is a weak one.
(So you can cheerfully overwrite it, if it also is weak where defined,
as a default.)
 
> It may be that there is no heap, as such, allocated, but the standard
> startup puts the stack pointer in the middle of ram (expecting a heap?),
> which doesn't seem right for me.

Since I find no __stack in the default linker script:

$ avr-gcc -Wl,-verbose > /tmp/ld_script

I'm not immediately sure what it's using. But since you're using custom
linker scripts, if the above simpler method doesn't appeal, you're free
to plonk in something similar to what I've used. Here's one for an
ATmega64:

/* ATmega64 Constants */
__ramend = 0x20 + 0xE0 + 0x1000 - 1 ;   /* Registers + I/O + RAM */

__stack = __ramend                      /* If that's what suits. */

> I also sometimes have to use 'alternative' processors due to supply
> problems (the world seems still to be cathching up after throttling back
> manufacturing due the financial crisis) and letting the stack pointer be
> reset by hardware to top of ram (as the chips natively do) would let me
> use common code for (some) different avrs. This why I don't really want
> to set __stack to a value.

Ah, then it might be more convenient to replace the previous suggestion
with this line just before "MEMORY" in the linker script:

INCLUDE chip_specifics.ld

Then, at chip-specific makefile targets, [echo | cat] the __ramend and
__stack guff for this week's batch of silicon into the chip_specifics.ld
file, much as in the example for using -D instead.

> Thanks to your help I have a linker script which could easily set this,
> but I don't feel that it's the 'right' answer.

No, with your 'alternative' processors, it is more convenient to set it
at a make target, so it's all automatic when you build for the silicon
which has rolled in the door.

> I could also remove .ini1 or .init2 in this script, but forst I need
> to know exactly what they contain.

The ten .inits are standard linker output sections for avr-gcc. They are
just like egg-carton cups in a row, into which we can link initialisation
code, so that they are executed in deliberate sequence, even though the
source often remains in the same file as the .text which relies on that
initialisation. (i.e. it allows a degree of OO in our coding approach.
Even an assembler source file can have "constructors", kept together
with the "methods".)

> I have no problem maintaining a non-standard avr-libc, I have already
> modified parts of it to suit my needs (open source is wonderful isn't
> it?).

Isn't it just? :-)

> Oh, BTW I use tiny 13, 24, 25, 45 etc. (VERY SMALL RAM).

I have a few tiny 15s. I need to dig one out and play with it.

So, in summary, there no longer seems to be a need for the crttn13.o
source code.

You could just define it in assembler or C !

Erik