AVR Freaks

being mapped into the same address space as the SRAM doesn't make them SRAM.

 

In particular, the IO Registers (aka "Special Function Registers", SFRs) are not just RAM - they are control signals connected to the peripheral hardware

 

not really.

Why does it matter?

 

Just treat the SFRs and the r-registers as SRAM with special properties (and some instructions that operate on them, and no-where else) and be done with it!

 

Jim

Note also that in some processors, certain registers may be completely inaccessible to your code.

They could exist in a walled off area of sram, or live as a small island of 8 flip flop bits in some inaccessible area of the processor (and you won't be told one way or another, none the wiser).

 

For example, I believe some PIC chips will give you no direct access whatsoever to the stack pointer (register), yet you can push & pop  ...maybe you won't call it a register...hmm...knock knock ---who's hiding in there?      

 

Next up:  You will ask about the Xmega's virtual IO registers 

A 'traditional' CPU design will likely have register to register move instructions, often moved via the ALU but sometimes moved directly depending on the hardware design. That usually needs you to operate both reading and writing of different registers in the same clock cycle. That requires dual ported ram which has independent read and write addresses, so the output of one selected register can be applied to the input of another register. In practice that requires two address decoders.

 

Normal static ram is either reading or writing; it can't do both at the same time, so you can't do memory to memory transfers without using a temporary register. So it's almost certain that while the registers may be mapped to ram, that's not where they physically live on the chip; it's a function of the address decoding which makes them visible in this way, not their physical construction.

 

There is at least one register which is always going to be different because it requires the setting of individual bits - the flag register holding the processor status flags. You need to be able to read and write it in one hit - to save it to the stack in interrupts, at a minimum - and you not only need to be able to set selected bits but they need to be available to other parts of the circuitry on a permanent basis without reading the register itself. The same logic applies to hardware control registers such as IO ports.

 

To really confuse the issue: while AVR maps the registers to ram, older processors such as the 8080 (and all its descendants) do the reverse: all of memory is mapped to a single register - the M register. Reading or writing to that register accesses the memory addressed by a couple of other registers and that memory location can be used as if it were another register. And a hidden advantage of that is that the same physical mechanism can be used to access external memory at any stage in the instruction cycle: microcode selects whether HL, the program counter, the stack pointer, or perhaps a specialised memory access register is used to provide the address, but in every case the internal access requires a read or write of the M register.

 

(More recent processors do the same thing in an even more horrible and convoluted way. Don't even start thinking about prefetch and pipeline queues and cache memory...)

 

Neil

Just picking a random datasheet (this 328P) you find things like:

 

In this the the 32 GPRs clearly are not the same thing as the "Data SRAM". You also find:

 

Again the mapping of the 32 registers into SRAM and the access to the Internal SRAM may be within the same "Data Memory" but they are completely separate elements of the thing. (as are the SFRs/ext-SFRs)

 

As time went on AVR design changed and the Xmega series (of which all recent releases have been derivatives) came along and they changed the memory map (this from Atxmega128A1U datasheet):

 

 

Note now how you can no longer see or gain access the 32 GPRs in this. Down at 0 is simply SFRs (of which there is room for considerably more than Tiny/Mega!) - the CPU register access is no longer there.

 

In traditional AVR (well after about 2005) Atmel put a scattering if "GPIO" (effectively "scratchpad", quick access) registers in early memory. What they then did in Xmega was to put 16 of these down near 0. They then mapped "VPORT"s above these to also be in a fast access area.

Not sure what you mean by that - I don't think that's what I'm saying.

 

See, for example, #6 and #16

 

Yes, it does - that is how ARM-based chips commonly behave, and AVR is much the same.

 

For example, see https://www.avrfreaks.net/commen... - where you have separate Set/Clear/Toggle registers, which act to affect another register (and this example is about an ARM-based  chip).

 

 

 

 

 

Again, the SFRs are different - they are not "memory"; they are control connections to hardware.

 

transistors/flip-flops on SRAM? 

At the end of the day, everything just boils down to transistors!

Flip-flops are built of transistors;

SRAM is built of flip-flops.

 

As the diagram posted by clawson in #15 shows, one of the big differences between CPU registers and SRAM is that the CPU registers are directly connected to the ALU - so don't have to be accessed via the data bus:

 

 

As the page linked by  N.Winterbottom   says,

• The Register File of the AVR CPU contains 32 x 8 bit mostly Orthogonal (or identical) General Purpose Registers Ã¢â‚¬â€œ instructions can use any register; therefore, simplifying compiler design.
  
   
• Load-store memory access. Before you can do anything to data, you must first load it from memory into one of the general-purpose registers. You then use register-register instructions to operate on the data. Finally, you store your answer back into memory.

 

and shows that 'REGS' and SRAM are physically separate areas:

 

 

EDIT

 

remove duplicate diagram

 

EDIT 2

 

also from the ATmega238P datasheet:

 

I think the Block Diagram is slightly simplified, in that it doesn't show the direct output from ALU to Register File ?

In AVR are the 32 CPU registers mainly used for arithmetic work and the rest of IO registers (SFRs) essentially the same type? I.e transistors/flip-flops on SRAM? they are just located on different places on the bus?

You need to study those datasheet diagrams. I assume you understand CPU architecture? Traditionally CPUs had an "accumulator", often just 1 or 2 registers. They were the only things that had direct access to the Arithmetic Logic Unit (ALU) at the core of the CPU. You might do things like "ADD A, B" which might feed A and B into the ALU, perform "ADD" and return the result to A (for example).

 

The AVR is pretty unusual in this sense (and accounts for part of its popularity) as it co-designed between two guys at Atmel and the IAR compiler company (who write C/C++ compilers). They analysed typical compiler code generation and determined that a really efficient processor for implementing C code would have THIRTY-TWO accumulators. So the AVR has R0..R31 (the real low end ones just R16..R31).

 

Sure they are "8 bit gates" at the end of the day but the point is that they are 8 bit gates that can be switched as inputs to the ALU which is why you can do all the LSL, ROR, ADD, EOR,AND, ... operations on them. They are not RAM and they are not peripheral control registers ("Special Function registers" = SFR) either.

 

To understand what an SFR is take a peripheral like a UART:

 

 

The bits you can read/write using CPU opcodes are those blocks I have circled in red. Some bit in some registers are read/write, some are write only and some are read only. So, yeah they are transistor gates but they are not "storage locations" like RAM. What's more (the point Andy made above) some of them aren't even just one register. You will see "UDR" in this twice. I have put the letters W and R next to the two instances. If you Write then it goes to the top set of latches. If you Read you get what is in the bottom latch. So "UDR" is an SFR that is accessible at some address for the AVR to read/write but it is TWO separate registers. You can only write (but not read) the top one and you can only read (but not write) the bottom one. This is why Andy said some folks are surprised when debugging when they have their code write to "UDR" but the debug display (or even code to immediately read it back) does NOT read the value just written - that is on a one way journey out of the chip (shifted up the TXD line). Some beginners see this happening and claim "the chip is faulty". 

 

But all this stuff IS explained in the datasheet (often via diagrams such as this so you must read/look and absorb every last detail if you want to understand how the AVR works).

 

 

As Andy says at the end of the day everything in the chip is just transistors (well OK, some areas of silicon might be used to create resistors and capacitors too). But if you have done the full throry from combinatorial logic upwards you will know that by different wiring 1/2/4 transistors can make NOT, AND, OR, EOR, NAND, NOR gates. Then those gates (often NAND in fact) can themselves be combined to make things like Latches. Then latches can be combined to make things like half-adders then they can be combined to make full adders and so it goes on. So transistors and gates will be placed to perform whatever specific operation some area of the chip needs them to do. In RAM (and CPU general purpose registers) it may be as simple as groups (8 wide) of latches. But various kinds of transistor/gates/etc might be combined elsewhere to make the shift register or parity generator within a whole block that is the "UART" or whatever.

 

The common pattern at the very bottom of the heap is that they are all transistors. After that it is just a question of how the transistors are combined and then how gates made from transistors are combined and so on.

 

You might want to explore things like CPLDs and FPGAs and "structural languages" like Verilog and VHDL if the way the internals of a CPU are built from raw transistors and logic gates.

 

(or you could just read every post that "barnacle" (Neil Barnes) has ever posted to freaks - he's mad enough to build whole CPUs just by combining separate logic gates though I don't think he's gone the whole hog and done it at the individual transistor level - but there's even some engineers who've done that - YouTube can be illuminating!).

 

EDIT: this is fun! https://www.megaprocessor.com/

also: https://www.youtube.com/watch?v=...

and: https://www.youtube.com/watch?v=...

(the list continues - there are a lot of dedicated (odd?) people in this world!!)

Yes:

• writing accesses the Transmit hardware buffer;
• reading accesses the Receive hardware buffer.

 

Essentially GPRs are generic storage locations used by the ALU to do arithmetic/logic work.

yes.

 

And SFRs are also "registers" but could behave differently and are used for specific tasks as explained above.

Yes - "special function" = "specific tasks"

 

 

And neither of them are just "memory", they are only address mapped.

The Register File is just memory - all it does is store data; nothing else - nothing "special" 

 

 

 

typically, what an address decoder gives you is an 'enable', plus the read/write control:

 

The 'Enable' says, "this is us!";

The read/write can simply be used as a logic signal.

 

Using this, we could create a very simple (simplistic) memory-mapped Red/Green LED:

• Accessing the assigned address enables the LED;
• a Read could turn on the Red colour;
• a Write could turn on the Green colour.

 

As far as the CPU is concerned, it's just accessing an address in its memory space - it neither knows nor cares that there isn't actually any memory here.

 

(in practice, this is not very useful, as the LED would only light for the very brief period while its assigned address is active; you would probably add some sort of latch to persist the state)

 

 

 

Which is what this does!

can you think of a better name?

 

Again, as far as the CPU is concerned, it can't tell the difference; the behaviour it sees is exactly that of a register - so, in that respect, the name fits ...

 

From the `UDR` example I can see that it's a box

It's actually two distinct boxes - one is write-only, and the other is read-only

 

 

I don't really understand the picture in #27, which part of it is a register?

As above, it behaves as a register as far as the CPU can see.

Yes.

 

I gave the example of the set/Clear/Toggle registers earlier - those registers don't actually store anything.

 

There are also SFRs where writing to a bit simply triggers an action; eg, ADSC in the  ADC Control and Status Register A:

Usually registers imply the storing of information:  A location, and bits of information.  

Where the bits of information are physically stored is hidden and could be anywhere--in an array with other registers, or out in the wild with its own location.

You have no idea of where electronically it is truly stored & that is the whole point of the logic circuitry abstraction--you don't need to know.

 

The bits may be read (by code), or simply used (by the processor), or both.  

Since there are opcodes and address decoding mechanisms in place (either for reading, writing, or both), it is convenient to use them to establish other "registers" that might not permanently store anything.

For example, there could be a 'register' established using these means that merely generates an immediate internal system reset pulse. 

You used register addressing modes & addresses to interact with this "register", is is that enough to declare it a register? Probably (register 752, system reset register)

Is that what you want to know?

I like that analogy. 

Yup, as I say, completely stark, staring bonkers! 

 

:-) 

I hope you were typing that with a pencil inserted into each nostril! 

then is there a way for code to access instruction memory at runtim

Yes code can certainly modify the flash (program area)....you want some self-modfying code, perhaps?  That's where the real fun is. 

In "von Neumann" architecture processors like x86 there's basically one linear address space and everything maps into it. Back in the original 8088/8086 it could address 1MB. IBM left room for RAM up to the 640KB mark - first PC had just 64KB fitted then after that often 512KB, it was a bit of a luxury to have the full 640KB as this actually involved fitting one lot of 512KB and one lot of 128KB (RAM comes in "binary sizes"). IBM then put things like graphic adapter memory above 640KB.

 

But it was one address space. There only was one location 0.

 

But AVR are "Harvard" architecture. This means a lot of separate address spaces and each one starts from its own 0 location. So you have address spaces like flash, ram/IO, EEPROM, fuses, lock bytes, signature row. Flash location 0 is not RAM location 0 (is not EEPROM location 0 etc etc) . They each have their own addressing system and are accessed in different ways. Ram is accessed using LDS/STS/LD/ST and small sections of it with IN/OUT. Flash is read using LPM and sometimes written using SPM. EEPROM is accessed via EEAR/EEDR and controlled with EECR.

 

The CPU core can only do opcode fetches from the flash space (indexed by the PC register). It cannot fetch opcode from RAM. 

 

So this is not like x86 (or many ARM for that matter) in which everything can be accessed in one space with one set of read/write opcode and in the one space you can find RAM, ROM, IO/SFR registers, etc, etc

 

Again the AVR datasheet explain all this. 

 

Oh and if you are looking at GCC ELF files with a tool like objdump note that there's a bit of a "trick" applied because GCC/ELF are only designed for von Neumann (the main targets being x86 and ARM) with one address range. So, yes, the ELF has separate memory sections called things like ".text" (flash), ".data" (RAM), ". eeprom" (EEPROM). But they cannot all be placed at 0. So in fact artificial offsets are added. The one at true 0 is "text" , "data" is offset to 0x800000, "eeprom" is offset to 0x810000, "lock" /"fuse" /others are offset to further increments above here (0x820000, 0x830000, etc) though I can never remember the order (you can see it in the .x file - linker script) 

Indeed - that was my example in #27