Where is the memory tab?

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

Hello, I'm new to Atmel products and AVR studio. I'm using Studio 5 with an AT32UC3A0512, and I seem to be missing something very fundamental. Normally I would expect to be able to set things like: the initial stack address, the load address for code (so I could have more than one application burned into the flash), any regions of memory that are off-limits, how to tell the programmer (JTAGICE-II) where to burn the code (perhaps that's included in the binary file), etc. The documentation indicates there's a "Memory" tab in project properties. This is the kind of thing I was expecting, except it's not there. Can someone clue me in on where I might find these settings? They're rather important.

Thanks.

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

Well, I answered my own question. Seems everything I'm looking for is in the linker command script (lds) file. It would be nice if Atmel would finish the job and put a decent user interface in front of this script file. It's a mess (imho) and undoubtedly the source of strange problems and obscure errors if you don't get it right.

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

CDaniel_MT wrote:
It would be nice if Atmel would finish the job and put a decent user interface in front of this script file. It's a mess (imho) and undoubtedly the source of strange problems and obscure errors if you don't get it right.

I think it's a bad idea. The linker file steers so much information, that you cannot put it all in a user interface. And the most important MEMORY variables are easy to change in the linker file. So why mess up an elegant design?

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

I disagree. Everything in that GNU linker command file certainly could be reflected in a GUI. And it would be SO much easier to understand. I suspect that a large fraction of applications written in this environment do not require any special tweaking of the linker file, other than perhaps load address and moving the data and stack around. A GUI should expose the basic functions that most people might need, and hide all the minutia that few people need (or want) to mess with – leaving that for the “advanced” properties.