HI Erik, On 1/11/06, Erik Walthinsen <[EMAIL PROTECTED]> 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
_______________________________________________ AVR-GCC-list mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
