Atmel Studio 7 Memory Window OSCCAL dropdown option - why is offset 0x31?

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

 

Hi,

I'm a newbie with Atmel Studio, ATtiny85 and AVR assembler, but I do have 40 years experience of hardware & embedded software development.

I'm working my way through the ATtiny85 datasheet and experimenting with anything that I don't understand.

I'm currently experimenting with OSCCAL using Atmel Studio 7.0.2397

This confused me:

Until I worked out that the offset of the OSCCAL register in memory is 0x0051 (0x0031+0x20) not 0x0031.

I'm not even sure whether the OSCCAL option in the drop down is standard or something I accidentally added.

I've not been able to find anything about adding options to the dropdown.

Could someone kindly tell me whether it's a standard entry?

If it is standard, is the offset of 0x0031 in the address field of the above screen snip a mistake?

TIA

Dave

 

This topic has a solution.
Last Edited: Sat. Apr 18, 2020 - 08:35 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I/O address space v.s. SRAM address space.

 

The first 64 I/O addresses (which on the t85 is all of them) are accessible via in/out/sbi/cbi/sbic/cbic instructions at their I/O addresses.  They are also accessible in the SRAM address space, mapped starting at 0x20.  So 0x31 is the I/O address, and 0x51 is the SRAM-mapped address.

 

EDIT:  See sections 4.2 and 5.4 in the datasheet.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Fri. Apr 17, 2020 - 06:23 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dave Lowther wrote:
Until I worked out that the offset of the OSCCAL register in memory is 0x0051 (0x0031+0x20) not 0x0031.

Welcome to the wonder world of AVR memories! 

So the address depends on the addressing mode, I/O memory addresses take the offset into consideration...

while ram addresses do not, since the first 0x20 addresses are the internal register stack, you have to add the offset youself when using this mode.

Life is so much easier when you use that wonder Macro Assembler know as a C compiler, it takes care of all that!!! smiley

It also takes care of the correct register read/write order when accessing 16 bit reg's.

 

Jim

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

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


Thanks for the feedback so far. What I was questioning is why the option selects offset 0x31 but the location of the register is 0x51

 

 

I think I understand the memory mapping but I don't understand why the OSCCAL option in the drop down doesn't select offset 0x51, unless of course I added that entry by mistake.

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

 

OSCCAL is 0x31 see datasheet

 

Your looking at it from "Memory Space", so it has an offset applied of 0x20, making it appear at 0x51!

If you open an I/O window, you would see the same thing at 0x31.

Jim

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

Last Edited: Fri. Apr 17, 2020 - 06:50 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:
Jim
What he said :-)

 

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

Thanks guys,

I'm obviously not explaining myself very well.

I understand why it appears at 0x51 in memory space.

What I don't understand, re the screen shot in my OP, is why the dropdown option for OSCCAL selects memory space + offset 0x0031 rather than 0x0051

AFAIK the OSCSCAL option in the dropdown is a standard option in vanilla Atmel Studio, but I can't be certain I didn't somehow accidentally add that entry to the dropdown options myself.

If I added it myself I understand why the offset isn't 0x0051.

I think the questions in my OP stand, i.e. is it a standard option and if so is the offset it uses of 0x0031 a mistake.

 

> Life is so much easier when you use that wonder Macro Assembler know as a C compiler, it takes care of all that!!!

I didn't say I wanted life to be easy :-) But seriously, the reason I'm using assembler ATM is it gets me closer to the hardware and I'm trying to learn about the hardware including all its foibles.

If I wanted to easily create quick code I'd have continued using the Arduino IDE. I've been using that for part time home projects for a couple of years, but I got to the stage where I wanted a deeper understanding of the hardware.

Many thanks for your quick responses and your patience so far.

Dave

 

 

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

Dave Lowther wrote:
why the dropdown option for OSCCAL selects memory space + offset 0x0031 rather than 0x0051

who knows, that would be a question for the IDE writers (MicroChip support), we are just users like you.

It's just one of those quirks of the memory addressing you have to get used to.  As shown in the DS OSCCAL's address is 0x31, so that is what it shows in the dropdown, but the ram address is 0x51, you just have to know that for all I/O space registers.

Jim

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

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

Things like that drop lust are auto generated from the XML in the ATDF. So the curious thing is why the XML author apparently specified "OSCCAL " as a separate "memory space". J short of know what they mean. Most AVR can have as many as 4 bytes set aside for oscillator calibration values ( the thing you ultimately write into OSCCAL). But the nomenclature seems wrong.

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for all the feedback. FWIW I just checked an ATmega328P project and the OSCCAL option is there too, at "0x0066,data" and 0x0066 is the offset in I/O space. At least it's consistent. If I'd written the code for the option I'd regard it as a mistake to use an I/O space offset as a data space offset. The 'check if I need to add 0x20' is firmly fixed in my mind now. I'll mark this as solved after posting this.

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

Dave Lowther wrote:

Thanks for all the feedback. FWIW I just checked an ATmega328P project and the OSCCAL option is there too, at "0x0066,data" and 0x0066 is the offset in I/O space. At least it's consistent. If I'd written the code for the option I'd regard it as a mistake to use an I/O space offset as a data space offset. The 'check if I need to add 0x20' is firmly fixed in my mind now. I'll mark this as solved after posting this.

You'll note that, in the m328p, OSCCAL is accessible >>only<< via SRAM-mapped memory.  I/O memory extends only to 0x3F (0x5F when SRAM-mapped), so it stands to reason that any register above 0x5F in the SRAM-mapped address space can only be referred to by that address.  There is no corresponding I/O space address.  So your example is somewhat misleading.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

Thanks for explaining that and sorry for my oversight.