RE: [avr-libc-dev] [task #3693] Add new devices: mega640-1280-1281-2560-2561

[Darcy Watkins]

Hi,

I have a few comments (or perhaps rambling).

I peeked at the wiki and notice that your proposed approach is to retain 16 bit 
pointers but require functions to be on double word boundaries.

Special care will be needed to avoid repeating the same type of bug as below 
that causes me grief while debugging my ATmega128 firmware that is greater than 
64k bytes.

[Bug target/19087] Overflowed address in dwarf debug line information

What I observe is that the line number info for the code greater than 64k is 
associated with code in the bottom 64k after a 16 bit rollover.  To work around 
this, you have to keep the debugged application in the bottom 64k and then 
anything in the top 64k should have debug info stripped (usually libraries, 
etc).

With the ATmega256x, references to program memory for data access will be 18 
bits, the word addressing pointers used for function calls and indirect calls 
will effectively be 17 bits.  These all need to be properly mapped to/from 16 
bit double word boundary pointers.

Another challenge is that ISR vectors will have to be properly fixed up at link 
time.  There will need to be provision in the linker to fixup the extended jump 
/ call instructions as the top half versus bottom half info won't be known 
until link time.

For indirect calls, it will be necessary to take the 16 bit value, extract the 
one bit used to determine top versus bottom half, adjust the rest of the 
vector, and then make the call using the appropriate instruction as determined 
by the extracted bit.

Now for program memory stored data (assuming the same 4 byte alignment scheme), 
it is similar except that now you use 2 bits for the RAMPZ and adjust the 
remaining 14 bits.

I think that we should "conceptually" view the program memory address space as 
24 bits (even though we will only use 18 bits) and work in this realm for all 
the tools and then adjust addresses to the alternate formats at the very last 
minute.  It may prove best to use 24 bit pointers for runtime program memory 
references and allow optimization in the compiler and/or linker to use less 
expensive means whenever possible for compile and link time program memory 
references.

Regardless of the method used, a 24 bit (or at least an 18 bit) "conceptual" 
address space will be needed for DWARF debug information to prevent all debug 
information above 64k from overlaying the first 64k, (or other similar types of 
bugs).

The other problem I ran into while checking into bug 19087 was that when I 
patched and built up a set of tools to use 32 bit DWARF address representation 
(and Torleif provided me with some beta 32 bit DWARF parsers for AVRStudio), 
the 800000 style offsets used for data memory (and EEPROM), instead of being 
stripped off by rollover, were now present which caused other problems in AVR 
Studio.  Regardless of whatever is implemented, it will be necessary to adjust 
the section addresses at the last minute before generating the DWARF file for 
debugging.

My guess is that the first task to get access to the first 128k of the 
ATmega256x devices will have the same limitations as with the ATmega128 since 
it will mainly just deal with the 3 bytes on the stack.

I suppose it may be possible to implement an indirect jump hack by pushing a 
three byte fake "return" address on the stack and then invoking the "return" 
instruction to do the jump.  A scary hack but it may work.  For an indirect 
call hack, you would have to push the real return address and then the fake 
return address and then use "return" to the called routine at the fake return 
address.  Then it would use a normal "return" to the real return location when 
done.


Regards,
 
Darcy
 
--------------------------------------------------------------
Darcy L. Watkins             email: address@hidden
Senior Software Developer++  phone: (604) 455-2000
TASC Systems, Inc.           fax:   (604) 888-2712
9415 - 202 Street,           web:   http://www.tascsystems.com
Langley B.C. Canada V1M 4B5
--------------------------------------------------------------
 


-----Original Message-----
From: address@hidden
[mailto:address@hidden
Behalf Of Uwe Fechner
Sent: Friday, September 16, 2005 6:53 AM
To: address@hidden; Eric Weddington; Marek Michalkiewicz; Anatoly
Sokolov; Uwe Fechner; address@hidden
Subject: [avr-libc-dev] [task #3693] Add new devices:
mega640-1280-1281-2560-2561



Follow-up Comment #8, task #3693 (project avr-libc):

I created a wiki page to log the effort in implementing support for AT
mega2560/AT mega2561.

Look at:

http://www.kieltech.de/uweswiki/ATmega2560_5fsupport

I tried to break the main task into subtasks, to make it easier to start. 

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/task/?func=detailitem&item_id=3693>

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.nongnu.org/



_______________________________________________
AVR-libc-dev mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev