[En-Nut-Discussion] Building NutOS for ATMega2561

[Rob van Lieshout (PragmaLab)]

During the (long) porting process of my application from the Mega128 to the
brandnew Mega2561 I allready solved quite a few problems. 

A few problems remain:

a) the imagecraft compiler/linker does not (yet) support long calls (calls
have to take the 128KB boundery into account)
Good news: Imagecraft is working on that one and a new Beta version
(probably '7.04C' will soon be released)
(don't let the phrase on the Imagecraft website "support for ATMega256' fool
you, it doesn't support the full 256KB, only the lower 128KB)

b) building NutOS for target ATMega2561
I know this target can be selected in the configurator (4.1.3), but since
buildtime the 'iom128v.h' is still included, the generated code will
definite NOT work. The main issue here is that Atmell has remapped and
changed a LOT of registers and even bit-locations in the new 2561 . Building
NutOS for the ATMega2561 should result in including 'iom2561v.h' (which I
did by modifying the .nut files for the configurator)and that again will
result in lots of 'undeclared identifiers' since most registernames no
longer exist in the new 2561 (which btw is based on the same core as the new
1280, 1281 and 2560).

Question: did somebody allready took the effort to translate the register
names and bitnames to be able to build NutOS for the 2561 (or for the 1280,
1281 or 2560 since they all use the same names now)?

If not, what should be the best way to let the build-structure reflect this
new target? 
The 'arch' structure not really reflects the target, just the architecture
(there is a 'arch\avr' and a 'arch\arm' but not a 'arch\avr\mega128' or
'arch\avr\mega2561 or whatever). Or should I just remap all registernames to
the new ones like the way it is done in 'icc.h' for the mega103 vs mega128?
In that case, where should the startup file 'extram.s' be located since that
assembly file uses hardcoded addresses to enable external RAM (which bit is
located in an other register with a different address in the new 2561)? And
how in that case should I threat registers that no longer exist in the new
Mega256 (like the ASSR-register). That cannot be solved by just remapping,
for that, some code has to be rewritten I guess.....

Thanks in advance for your input!

regards,

Rob van Lieshout