Is it reasonable to think that the following components make up the AVR CPU of the ATmega328P Microcontroller?
(deleted)
I respect your answer/comment as it exactly represents your message:
If you don't like my answers, realize : I'm not being cheeky, I'm Just trying to prompt you to use your own brain/google etc.
In many situations/cases, we need to hear from the experienced people because our brains sometimes become reluctant to accept 'something' without double verification!
(deleted)
(deleted)
The 7-component image that I have posted is a slightly simplified version of the one that belongs to ATmega32(L) data sheets (Figure 2, Page-3). The ATmega328P data sheets (Figure-4.1, P13) has just shown a block with an inscription -- AVR CPU. Therefore, I decided to poll opinions in favor of to be said that the indicated 7-component do represent the CPU of the ATmega328P as well.
Moreover, in the old PCXT, the single motherboard containing everything (MPU, RAM, ROM, IO, ...) was being called the 'CPU'. Data sheets of both ATmega32 and ATmega328 have excluded the flash and SRAM from the CPU subsystem. This apparent difference has also created a confusion within me as to the generally accepted definition of the CPU subsystem.
(deleted)
The ATmega328P data sheets (Figure-4.1, P13) has just shown a block with an inscription -- AVR CPU.
That's the overall chip diagram. You want to go to section 11 ("AVR CPU Core"), where they have figure 11-1:
Older versions of the datasheet have somewhat different diagrams, perhaps with some useful labels on the data paths...
As for your original diagram, I think it is an odd combination of incomplete (no interconnections or buses, for example) and overly-specified (12bit stack pointer? Are you sure?)
1. Motivation for my Original Post
Very often, during discussion, we use the words MPU, MCU, and CPU interchangeably to refer to Processor. However, sometimes demands come to have them defined specifically; particularly, which components do form the CPU Core for the ATmega328P.
From my experience on ATmega32, I mention that the following 7-component (within dotted box) do form the AVR CPU.
Figure-1: AVR CPU of ATmega32
What's about the AVR CPU of ATmega328P?
I have come across the following diagram in the data sheets where the AVR CPU is a block and it has clearly excluded Flash, SRAM, and EEPROM.
Figure-2: AVR CPU of ATmega328P
Now, another diagram (Ref: Post#7) which (I think!) is the AVR Architecture and not the CPU Architecture!
Figure-3: AVR Architecture of ATmega328P
2. 12-Bit Stack Pointer
(a) According to ATmega32 data sheets, the Stack Pointer (Register) is 12-bit which is good enough to access the TOS (Top-of-Stack) at 0x8FF of the available RAM space: 0x100 - 0x8FF.
Figure-4: SP Register of ATmega32
(b) According to ATmega328P data sheets, the Stack Pointer (Register) is 11-bit. I have just seen it now. How could it be when the available RAM space is 0x100 - 0x8FF, and the TOS could be placed at 0x8FF? (I think it is a printing mistake.)
Figure-5: SP Register of ATmega328P
Figure-6: SRAM Data Memory Map of Atmega328P
another diagram (Ref: Post#7) which (I think!) is the AVR Architecture and not the CPU Architecture!
You're basing the distinction on the fact that it includes boxes for the memories in addition to the CPU components? Otherwise I'm not sure what the difference is...
The CPU Architecture needs to show which buses the CPU is connected to. Whether it labels those as "data bus" and "instruction bus" or puts them in boxes labeled "data memory" and "program memory" doesn't really matter.
It does look like the SP is actually 12 bits; But I'm not sure that that's important, and it can change from chip to chip. It only matters that it is "big enough" to access all of the data memory.
before = SP;
SP = 0xFFFF; //store 16bita
after = SP;
SP = before; // see how many bits we get back!
sei();
Serial.println(before, HEX);
Serial.println(after, HEX);
// see how many bits we get back!
void setup()
{
Serial.begin(9600);
uint16_t before = SP;
SP = 0xFFFF; //store 16bita
uint16_t after = SP;
SP = before; // see how many bits we get back!
sei();
Serial.println(before, HEX); //shows: 8FD = 100011111101
Serial.println(after, HEX); //shows: FFF = 111111111111
}
void loop()
{
}
Serial.println(before, HEX); //shows: 8FD = 100011111101
Serial.println(after, HEX); //shows: FFF = 111111111111
Yep; that's what I got as well on a m328. Are you certain you'd get the same thing on an ATmega168 or ATmega88? They're variants of the same chip, so they surely have the same "CPU Architecture" What about the ATmega1284 with significantly more RAM? It's not that I'm disagreeing with you, or saying that the SP doesn't have 12bits; I'm trying to point that the exact length (8 to 16bits) is essentially irrelevant to the "architecture." (unlike the 12bit address in 8bit PIC processors, or unlike the changes that would be needed to go bigger than 8bits. All the operations that use the SP don't care about the actual number of bits in the register...)
We wrote 0xFFFF (1111 1111 1111 1111) into SP Register. We read it back and displayed on the Serial Monitor which has shown us 1111 1111 1111 (FFF). How can we be sure that we have not read 0000 1111 1111 1111 (0FFF) from the SP Register as the Serial Monitor suppresses the leading 0s while displaying data?
Moreover, the data sheets has shown a 16-bit layout for SP Register (SPH, SPL) with 12 active bits; this fact may lead someone to ask the question: Is the the actual construction of the SP Register is 12-bit or 16-bit with upper 4-bit always 0s? (The data sheets has shown dashes/shades in these bit positions.)
My original saying of '12-bit Stack Pointer' came not from the data sheets; it came from my this understanding -- whence the 14-bit PC is good enough to address all the word-organized locations of the flash (00 0000 0000 0000 - 11 1111 1111 1111) thence a 12-bit Stack Pointer should also be good enough to access all the locations of the user created stack space (say: 1000 0000 0000 - 1000 1111 1111 in SRAM). (In my m32A ASM Programming, I had been always writing like this: ldi r17, 0x08; out sph, r17; ldi r17, 0xFF; out spl, r17. I never wrote ldi r17, 0x8.)
Post#7 deserves to receive +1 as it has pushed encouraged me to delve further through the question 'Are you sure?'.
How can we be sure that we have not read 0000 1111 1111 1111 (0FFF) from the SP Register
How would that (actual bits that always read zero and can't be written) be different (than non-existent bits that read as zero)?
I'm thinking that a chip with external RAM capability (ATmega1284) will have a full 16bit SP.
This is funny:
The atmega1284(p) datasheet specifies sp is 14 bits wide.
The top of sram is 0x40FF, so you would need 15 bits to address that location.
The above sketch prints:
40F9
7FFF
Which seems to confirm 15 bits.
Typo in the data sheet?
Yes, that must be a typo, take e.g. the 644(p): the data sheet says sp is 13 bits, this matches with the top of sram being 0x10FF.