Memory Addres chart

Can anyone tell me what the memory allocation is for the ATMEGA328P-PU

I'm wanting to be able to custom set the memory location of each of the variable I define.

For one what is the range of addresses I can use.
I'm guessing since the microprocessor is 16 bit that would mean (0x0 -> 0xFFFF), I understand just because there is a memory address there, doesn't mean I can or should use it. Second I know all those address are divided into three sections: Flash, SRAM, and EEPROM.

However I don't know where to go to find how the address are divided up between them.

JoshA:
I'm wanting to be able to custom set the memory location of each of the variable I define.

Huh?

JoshA:
However I don't know where to go to find how the address are divided up between them.

Have you tried reading the datasheet?

The 32 "general purpose" registers are aliased starting at 0.
A variable and discontinuous set of "IO Registers" exist from 0x20 to 0xFF. There's a swell summary in the data sheet section titled "Register Summary."
General purpose RAM starts at 0x100 and continues to the end of RAM (2k bytes, or till 0x07FF, on a MEGA328 as used on Uno.)
the larger MEGA2560 cpu can theoretically address external memory as well, which can go up to 0xFFFF (full 16 bit address space.)

FLASH/Program memory has a separate address space that requires special instruction sequences to access. It goes from 0x0 to the end of flash (32k or 0x7FFF on Uno.) 256K on MEGA (using rather unpleasant kludges to get beyond the 16bit limitation you might otherwise expect.)

EEPROM has a separate address space that requires special instruction sequences to access. (DIFFERENT than Flash, mind you!)
It goes from 0 to the end of EEPROM (1k bytes, 0x03FF on Uno.)

I'm wanting to be able to custom set the memory location of each of the variable I define.

optiboot does this, to prevent the usual initialization code and save space; you can look at the source in your hardware/arduino/bootloaders if you want. It only has one RAM variable, though, so it's a pretty trivial example. Doing this for a non-trivial case would be a bad idea, IMO...

An interesting discussion here:

"The memory is the first thing to go."
(I don't remember who told me that)

Memory is the 2nd thing to go.
2nd? What's the first?
I forget....

I've come to a crossroads, I think.

JoshA:
Can anyone tell me what the memory allocation is for the ATMEGA328P-PU

Try the datasheet - it's what they're for.

JoshA:
I'm wanting to be able to custom set the memory location of each of the variable I define.

You'll have to use assembly language for that. I can't think of a single good reason for doing it though.

JoshA:
I'm wanting to be able to custom set the memory location of each of the variable I define.

The compiler and crt0 are very good at doing that for you.

Technically, you can set a pointer to any valid address space if you want to manage your own memory in C. Although, without being VERY aware of how the compiler allocated memory itself, you're likely to pummel something.

I enthusiastically support experimentation, so check out the memory map in the datasheet for whatever device you use. But, keep in mind, unless you're using ASM and managing ALL the memory yourself, there's a good reason those details are usually hidden from you.

Have fun! ]:smiley:

Arrgh! Sounds too much like self-modifying code to me... bad memories from my Fortran '77 days on the Honeywell tso.

Ray

Sounds too much like self-modifying code to me

Good luck with that on a Harvard architecture machine. :smiley:

thanks. for the replies.

I know that I do something along the lines of:

int * value = (int *) some location;

void setup()
{
     *value = (some int);
}

void loop()
{
}

although i'm not sure what that = (int *) means.

I just need to make sure I'm not overwriting some critical data to the boot-loader or program.

(int *) casts the following number from whatever the native integer format is (16-bit signed int on Arduino) to a pointer to a signed int. I don't think it's strictly necessary in this case, but would squash a warning if "some location" were actually a return value or variable of a type that is not a 16-bit signed int, and therefore being cast implicitly.

Otherwise, yes... this code does what you think it does, although will often do something you didn't intend it to. :wink: