When I write data into a Reserved SRAM address it sometimes works out well, sometimes influence on periferals.
Are there lists available what is behind a Reserved address on each AVR device?
Are all registers doing something even when you do not notice? Seems like there is more in there.
sts 0x00, XL sts 0x01, XH
Does work. (but maybe not when you use the ADC, or another timer or PIN.)
wek 
sts 0x00, XL sts 0x01, XHDoes work. (but maybe not when you use the ADC, or another timer or PIN.)
JW
theusch 
What is a "Reserved" SRAM address on an AVR? Where did you see that term used for an AVR?
What part of the answer to your question is >>not<< in the datasheet? Please be specific. In particular, note which, if any, parts of the answer to your question are >>not<< addressed in the small picture titled Data Memory Map. I can see where this might be obscure, being in the "SRAM Data Memory" section and all. :roll:
I guess you are a bit lonely on this Sunday and needed to try to construct an off-the-wall stumper for us as is your wont from time to time.
Lee
Out of SRAM on this homebrew project and see a lot of Reserved registers.
wek "Reserved" means "don't touch". There may be ANYTHING behind it.
JW
clawson 
While I can tell that's an AT90PWM it's not certain which one it but I just picked any AVR datasheet at random and it contains:
For compatibility with future devices, reserved bits should be written to zero if accessed. Reserved I/O memory addresses should never be written.
(EDIT: looking at some of your previous posts I guess it may be an AT90PWM3B you are using - that datasheet contains exactly the same quote as above)
I think there is nothing behind a reserved address. Data written goes to /dev/null and attempting to read it probably returns junk.
If your out of SRAM you should find ways to reduce SRAM requirements, use an device with more RAM, add external RAM, or give up.
wek I think there is nothing behind a reserved address. Data written goes to /dev/null and attempting to read it probably returns junk.
Reserved is simply a no-no, fullstop.
JW
We cannot say with any confidence what might and might not happen. Therefore, RES should follow the datasheet recommendations and not use reserved locations.
glitch 
reserved addresses are not likely fully decoded. As a result, it may or may not influence some real register. What it affects is undocumented, and likely changes from device to device, and even generation to generation of the same device.
Simply put, don't write to them, don't read from them. And don't worry "what's behind" them. There is no point in knowing, as what you "know" could change on the next rev of the silicon.
clawson If it's really true that Sim2 is based on the real chip models then one might be able observe the secondary effect of writing to reserved addresses. Though this is definitely nothing more than an intellectual exercise as no one would really go against the dire warning in the datasheet.
(I guess you could use it to obfuscate code for security purposes if such an odd thing were possible? - until the next rev of silicon broke the code that is!)
RES could use some registers of peripherals he does not use in this project.
clawson
RES could use some registers of peripherals he does not use in this project.
wek
Especially the ones between 0x00..0x3F (IO), 0x20..0x5F (RAM) as these can be accessed with SBI/CBI and make great bit vars. Often replacing eight uint8_t's at a time.
A programmer of small embedded systems who cannot effectively use all the resources available - including bit variables, whether used through masks or through bitfields - deserves to run out of RAM soon.
If he has some sort of a higher education degree, he should also be subjected to public revocation of his diplomas.
JW
glitch
Especially the ones between 0x00..0x3F (IO), 0x20..0x5F (RAM) as these can be accessed with SBI/CBI and make great bit vars. Often replacing eight uint8_t's at a time.
Well for starters, SBI/CBI are only good for the range 0x00 and 0x1F [0-31]. After that any bit vars being poked in 0x20..0x5F are no different than using a single 8 bit var anywhere in RAM to hold 8 bit flags. [there is no need to use 8 separate uint8_t's] Simply use LDS/STS and SBR/CBR. [though there is a 1 cycle speed advantage of using the I/O registers from 0x20-0x3F since IN/OUT can be used to read/write them]
reserved addresses are not likely fully decoded. As a result, it may or may not influence some real register. What it affects is undocumented, and likely changes from device to device, and even generation to generation of the same device.Simply put, don't write to them, don't read from them. And don't worry "what's behind" them. There is no point in knowing, as what you "know" could change on the next rev of the silicon.
clawson
Well for starters, SBI/CBI are only good for the range 0x00 and 0x1F [0-31]. After that any bit vars being poked in 0x20..0x5F are no different than using a single 8 bit var anywhere in RAM to hold 8 bit flags.
my bad, I meant 0x00..0x1F (IO) which is 0x20..0x3F (RAM)
Cliff
