[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
AW: AW: AW: [avr-gcc-list] Using current avr-gcc for target ATmega2561
From: |
Haase Bjoern (PT-BEU/EMT) * |
Subject: |
AW: AW: AW: [avr-gcc-list] Using current avr-gcc for target ATmega2561 |
Date: |
Tue, 4 Oct 2005 12:03:09 +0200 |
After reading your message I conclude that you will probably not be having any
problem unless that you are planing to use pointers to functions in your
bootloader code. The jump stubs will be used *only* in case that you are using
a function pointer because this way, we could stick to 2-byte function pointers.
The second restriction for your boot-loader code would probably be that you
must disable table jump instructions by the appropriate compiler switch because
these address tables usually do not end up in the bootloader section. This,
however, probably is a restriction that applies already now.
IMO any other solution (3-byte pointers, alignment etc.) would be both, very
difficult to implement not scalable and IMO less efficient.
Bjoern.
-----Ursprüngliche Nachricht-----
Von: Bernard Fouché [mailto:address@hidden
Gesendet: Dienstag, 4. Oktober 2005 11:57
An: Haase Bjoern (PT-BEU/EMT) *
Cc: Martijn van Balen; address@hidden
Betreff: Re: AW: AW: [avr-gcc-list] Using current avr-gcc for target ATmega2561
Haase Bjoern (PT-BEU/EMT) * wrote:
>At which address does the bootloader code end up?
>
>
>
Always at the end of the flash... from 4 to 32 pages of 256 bytes
reserved from the end.
Now one may need more than 8K bytes of program size for a complex
bootloader and so extend its size downward from the end the memory, by
adding one or more sections. One would not expect to have also data
already at the beginning of the memory or somewhere in the middle. We
have done that at my company at least to be able to store debugging code
while testing a bootloader (for instance by storing printf just under
the bootloader). Also when a bootloader works, it will usually copy
everything from a feeding point into the MCU memory. Having to manage a
'bootloader jump stub section' somewhere and not scratch it will be
difficult.
In the bootloader case, the jump stubs lose its meaning since if the
stubs are moved in the bootloader section, then we are already jumping
from and to an upper section address.
I did not follow all the exchanges about the different solutions, but
the 4 bytes alignment seem to me the cleanest one since one will loose
at most 2 bytes per defined function and there is no difference in code
production between application and bootloader section. Now I have no
idea about the required work in gcc.
Bernard
- AW: AW: AW: [avr-gcc-list] Using current avr-gcc for target ATmega2561,
Haase Bjoern (PT-BEU/EMT) * <=