As long as we are talking about tweaking linker scripts...
(dodges incoming missiles...)
The subject of using bootloader routines in application code comes up
fairly frequently, and in fact I've been thinking about how to do that
for my own projects. There are several ways to go about this. The
solutions that seem to me to be the cleanest involve slight tweaks to
the linkage methodology.
Here is one proposal:
1) Build bootloader and application separately.
2) In both, include an entryjumps.S something like the following:
#include <avr/io.h>
.section .entryjumps
.global shared1
shared1:
jmp sf_shared1
.global shared2
shared2:
jmp sf_shared2
.end
3) in bootloader, define and use sf_sharedX() functions
4) in application call sharedX() functions
5) When linking the bootloader, link with entryjumps.S, and place the
.entryjumps section at a well-known location, either by passing a
command line parameter or using a default (I haven't thought that
through completely).
6) When linking the application, link with entryjumps.S, and again place
.entryjumps section at the well-known location. But... the linker
script should discard the actual code. It only needs the entry point
definitions.
It would be nice if all of this could be present in the default linker
script, but be invisible unless the user actually defines a .entryjumps
section. I'm not a real whiz at linker scripts so I'm not quite sure
how to do that. Also, what should the "well-known location" be? Right
after the bootloader's interrupt vectors? At the very end of flash?
Anyway, that is one idea. Thoughts?
-dave
Joerg Wunsch wrote:
As Colin O'Flynn wrote:
Alas, each AVR might have a different default fuse, so we cannot
simply use 0xff as the default value.
If we got the default fuse programmed in the avrdude configuration
file, you could also add a command that brought the AVR back to
"factory" state. Handy if you were prototyping with a device than
wanted to put it away into a drawer, or just pulled a random device
out of a drawer... make the fuse bytes something sane.
The defaults need to go into avr-libc, one way or the other. My
current idea is to add the blurb to gcrt1.S, as this file is
custom-compiled for each and any different AVR, so per-device defaults
(which come in the form of macros from <avr/ioXXX.h>) can easily be
compiled into it. These defaults will then be overwritten by the
user-API macros like LFUSE() etc., replacing the library defaults.
The final load file (as avrdude sees it) will the either see the
library's defaults, or the customized values.
I think the idea might work, but I'm afraid I won't be able to draft a
proof-of-concept implementation of the entire toolchain before leaving
for vacation next week.
_______________________________________________
avrdude-dev mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/avrdude-dev
