The xMEGA 24/32 bit pointer question

Go To Last Post
13 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am now well aware that the AVR-GCC (at least version 4.3.x) does not support the full possible width of the X/Y/Z registers with RAM memory accesses on devices with an extended memory range (xmega).

Besides using an assembly level crutch in order to copy objects from beyond the 64k boundary, or switching compilers to a commercial offering, is there another option or future plans?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Threads here have certainly hinted as this being in "future plans". As the devices increase in size (as they almost inevitably will) then long pointers are going to become an increasing requirement. IN the meantime it's DIY asm.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cliff is pretty much correct. Yes there are future plans. However, it probably won't be available for the AVR until either GCC 4.5 or 4.6. I'm certainly pushing to make it available earlier, but work hasn't started on it yet for the AVR.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you need someone to do testing for any patches, let me know when there is something available. I haven't done any GCC hacking in years, so I'm less useful there.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Today is 2012 year...
Dear programmers, Is there available support of the 24/32bits pointers for XMEGA devices in AVR GCC for today?

Soon I will need to write firmware for the board with ATxmega128A1 microcontroller and 512Kb SRAM. To be honestly I do not need all of this 512Kb, but I will need of about 128-256Kb. And now it would be great to know is there such feature or not :) If not, I will begin to write some kind of the "smart pointer" template for C++ compiler...

Please, anyone, let me know.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Johann Lay should be along soon to talk about it, but he's been doing work in GCC 4.7 to provide 24-bit pointer support. I'm not sure what the status is on that support, if it's ready to be used yet... He'll let us know.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'd start with this thread:

https://www.avrfreaks.net/index.p...

then a more general search for anything by SprinterSB

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks to all.

As I understood there is no stable support of the 24/32bit pointers yet.
It's a little sad but not a problem.
I went to reinvent the wheel :idea: :D

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

no stable support

I guess "stable" is in the eye of the tester. Certainly Georg-Johann's changes add the infrastucture and only time will tell if there are then faults.

Personally I'm just waiting for Eric to issue a new WinAVR or Atmel to issue a new Toolchain based on this 4.7.x code.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For the documentation of 24-bit pointer support read the "AVR Named Address Spaces" section in the GCC documentation.

You may also want to have a look at the "Handling of the RAMPD, RAMPX, RAMPY and RAMPZ Special Function Registers" section of the GCC documentation.

If there still remain questions after reading the documentation, please ask.

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Note:
This work (apparently to be officially released as part of GCC version 4.7.1) has been done specifically to provide native support for working with data within the entire internal Flash storage using mostly-vanilla C (avoiding reliance on avr-libc's pgmspace.h macros), and to natively work with parts containing greater than 64 KiB of Flash.

For the time being, there still won't be native support for using external SRAM or SDRAM larger than 64 KiB. You will still need to write your own support functions for manually working with SRAM address spaces beyond 64 KiB, and you will need to take heed of the documentation SprinterSB referenced above, to safely write those support functions such that they avoid causing undesirable side-effects with the compiler's normal behaviour.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

I guess "stable" is in the eye of the tester. Certainly Georg-Johann's changes add the infrastucture and only time will tell if there are then faults.

Personally I'm just waiting for Eric to issue a new WinAVR or Atmel to issue a new Toolchain based on this 4.7.x code.


Agree and agree :)
Thanks.

lfmorrison
You destroyed all of my doubts) Thank you!

SprinterSB
Thank you for the reference. It wasn't new for me but it certainly helped me to clarify the some details.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
only time will tell if there are then faults.
No, time won't tell nothing.

Only users that test and report problems will tell anything.

Users nagging the most for new features or better optimizations, sometimes for several years, writing tons of complaints in that forum here or that blog there, not filing bug reports, often are the fist to piss off if it's up to use the new, enhanced tools...

avrfreaks does not support Opera. Profile inactive.