Re: [avr-gcc-list] Fixed, external function "pointers"

[Dave Hylands]

HI Erik,

On 1/11/06, Erik Walthinsen <address@hidden> wrote:
> Dave Hylands wrote:
> > One of the linker options is --just-symbols=filename which will import
> > the symbols from an objet file.
>
> Hmm, I should have paid a bit more attention, you did say "obje[c]t
> file"... ;-)

Actually, I'd use the .elf file (which has fully resolved addresses).
Technically, the .o and .elf files are both object files, its just
that the .elf file has no unresolved references (or that's the typical
convention).

>
> OK, that works nicely, even for the variables holding callback pointers.
>   Requires stuff on the linker line, but I guess there's really no way
> around that.  I have a section for the application signature bytes, and
> I have to shove the start of appliation RAM up 8 bytes for the
> bootloader's non-volatile storage.
>
> There's no chance that I can both shove RAM start up and force a section
> to a given address entirely from within a .c or .h file, is there?
> Pretty sure the answer is a solid NO, but worth asking...

All you can do from within a c file is to use inline assembler to
force a particular alignment. Putting stuff at a particular location
is normally linker related.

I use the following options in my Makefile:
CFLAGS += -mshort-calls
LDFLAGS += 
-Wl,--section-start=.text=$(BOOT_START),-T,BootLoader.lds,--entry=start
-nostdlib
LDLIBS  += -lc

and I provide my own vector.S file and I use my own .lds file (which
I've attached). I'm just about finished my i2c bootloader, but it's
more in the 2k size rather than the 512 byte size. My vector.S allows
me to use the vector table for interrupts at bootloader time as well
as use some of the unused vector entries for data storage.

By providing my own vector.S I was also able to make the startup code
a bit smaller by removing some of the stuff I didn't want.

Something to consider is whether you want your i2c messages (or
commands or transactions or whatever terminology you're using) to be
stateful or stateless.

Scenario 1 (stateful)
- register which contains the current address to write to (which autoincrements)

Scenario 2 (stateless)
- the address is contained in the message, along with the data

Scenario 1 can cause some interesting problems if the master decides
to retry due to some timeout. In borderline cases the master could
wind up sending the same message twice. With a stateful interface this
can cause problems, whereas with a stateless interface sending the
same thing twice cause no problems.

I've tripped over some of these issues so I just tought I'd mention
them for your consideration.

--
Dave Hylands
Vancouver, BC, Canada
http://www.DaveHylands.com/

BootLoader.lds
Description: Binary data

vectors.S
Description: Binary data