Microcontrollers memory

[nForce]

When a microcontroller executes a program, does it read it from ROM, or does it copy to RAM when it turns on and then execute it reading from RAM?

Thank you.

[martinayotte]

Most microcontrollers are executing directly from code. But it all depends about which microcontroller you are talking, because some others such ESP8266 or ESP32 are fetching ROM code into RAM cache before executing it.

[legacy]

it also depends on architectural's choices. Since having the fetch unit on the same bus of the load/store unit is considered a "structural hazard" for a RISC-pipelined architecture, modern CPUs usually fetch the code from a dedicated bus.

This is called "Harvard Architecture", defined as a computer architecture with physically separate storage and signal pathways for instructions and data, which implies the opcode in ROM is on a different space from the data in RAM. This simplifies the pipeline and makes thing faster, but as a downside, these CPUs then need a "bridge" (a piece of dedicated hardware) to make it possible to read and copy the code from the ROM to the RAM.

Without the "bridge" (or a similar hardware trick) it's physically impossible, and you end by fetching your code from the ROM and that's all you can do.

[Kleinstein]

It depends on the µC: especially the smaller ones usually run the code directly from ROM (flash). Faster ones might be faster running from RAM.  For the modern ARM based µC one often has the choice, depending on the speed needed.  Flash rom is somewhat limited in access speed, while SRAM is more expensive.  Sometimes there is some in between cache to speed up ROM access.

[hans]

To give a more practical answer:

Harvard-type CPU architectures (many micros, like PIC and AVR) have a separate program and data bus. The CPU fetches instruction from ROM, with the program image starting at address zero. The data memory space typically has hardware registers at address 0, and RAM starting at some other value.
Example: PIC24, it has the RAM starting at 0x800 and SFR at 0x0 to 0x7FF. If the firmware wants to load values from ROM, it can use special table read/write instructions to do so. I think on AVR you had to specifically mark/retrieve variables as PGM.
These CPUs don't have the capability of running code from SRAM.

ARM on the other hand, is a von Neumann machine. This means that the code, hardware registers and RAM reside in 1 single memory space. This is needed for the option to execute code from RAM.
One reason why you might do that, is because some FLASH is not that quick, and FLASH accelerators are used to hide that limitation by 'caching' wide lines of the FLASH memory (e.g. read 1024-bits at once, then execute opcodes of 16 or 32 bits). Sometimes execution from RAM consumes less power. Execution from RAM can also be more predictable w.r.t. timing.
Or perhaps you want to run Linux or some other large firmware image, which you could run from an external S(D)RAM chip.

Many microcontrollers stick to the principle the simpler the better, and will probably execute their program directly from FLASH. The previously mentoined scenarios are reason to change, but are a PITA to implement & debug completely from scratch and best to be avoided if you can.

[boB]

To give a more practical answer:

Harvard-type CPU architectures (many micros, like PIC and AVR) have a separate program and data bus.

Wasn't the old intel 8080 and Z80 also Harvard ?

I've used the X86 a lot in the past but today can't remember which it is ?

I suppose that after an instruction is fetched from ROM/Flash/RAM and moved into the decoder and into the ALU, it's then a RAM type register or read only at that point from the user's aspect because only the processor  can see the info at that time (usually) depending on how deep you want to talk about this question's answer

[tsman]

It depends on the uC you're using.

does it copy to RAM when it turns on and then execute it reading from RAM?

The GigaDevices GD32 clones of the STM32 chips do that. They attached a flash die to the uC die inside the package which is read into an additional block of RAM at startup.

[rstofer]

Wasn't the old intel 8080 and Z80 also Harvard ?

No, data and instructions are in the same memory space so they are von Neumann architecture.

I've used the X86 a lot in the past but today can't remember which it is ?

Still von Neumann...
[/quote]

When ARM produced the earlier ARM7TDMI chips (LPC2106, LPC2148, etc), they decided to execute code out of Flash.  What to do about the slow fetch?  How about an old IBM trick and grab a lot more than 32 bits?  In fact, these chips grab 128 bits at a time from Flash.

2d sentence page 3 here:

http://www.keil.com/dd/docs/datashts/philips/user_manual_lpc214x.pdf

There is some memory mapping required for the vectors.  Section 2.2.1 describes the memory mapping.

I haven't really followed the ARM Cortex chips so I have no idea how they deal with code and flash.

[nForce]

What about variables? So if 8-bit PIC or AVR uses Flash ROM for reading, where are stored variables? Because we should use some of RAM if it's there.

[hamster_nz]

The distinction between architecture types get weaker as you get more complex CPUs with seperate instruction and data caches, and multiple levels of cache too.

Perhaps a practical definition (from a programmers point of view) is if the are seperate code and data address spaces. Most general purpose CPUs have just one address space, but in microcontroller it is very common to seperate code and program address spaces 

[rstofer]

What about variables? So if 8-bit PIC or AVR uses Flash ROM for reading, where are stored variables? Because we should use some of RAM if it's there.

Of course the variables have to be in RAM as do all the control registers and anything else that can be written.  These are on an entirely separate address and data bus for chips like the PIC and the ARM7TDMI (and probably all other ARM chips).  But it is architecture dependent whether there are separate memory domains.  Clearly the Z80 has just one address and data bus but the designer can put Flash anywhere in the address space.  That doesn't suddenly change a von Neumann architecture into a Harvard architecture.  If there is only one memory domain, it's von Neumann.  If there are two memory domains (one for program, one for data) then it is Harvard.

The idea was to deconflict instruction fetch from memory from core read/write memory.  Having two separate domains allows both operations to occur simultaneously.

[nForce]

What about the word "8-bit" MCU.  In the old days, there were MCU which had 8-bit instruction word and 8-bit memory word and 8-bit data bus. But today there are some MCU which have maybe 16-bit memory word, or something else but the data bus is still 8-bit. Can we say that this MCU isn't 8-bit anymore?

[JPortici]

Example: PIC24, it has the RAM starting at 0x800 and SFR at 0x0 to 0x7FF. If the firmware wants to load values from ROM, it can use special table read/write instructions to do so.

Actually, 16 bit pics (PIC24 and dSPIC) can map the flash in the upper 32kB of data memory, so it can be accessed as if it was some read-only data memory, but with every addressing mode available and also by the dsp engine.
There are hree caveats though:
- It takes more than one clock cycle, as it is accessing flash
- The flash is mapped in 32kB pages, if your constant map happens to cross the boundary or you have to change the value of the PSVPAG register. Also, you have to explicitely enable arrays of more than 32kB in the compiler for this reason (a check on PSVPAG is done only when required and not before every access, which would slow things down a lot)
- You actually access the lower 16bit, the instruction is 24bit wide, the flash cell is 48bit wide containing two 24 bit instructions. If you need to access the whole word you need to use table read instructions (which still have many addressing modes)

Special mention: in the dsPIC33CH the second core (slave core) is held waiting at reset, you need to excecute a special instruction to load the program memory image for the slave core in SLAVE PRAM (program ram). The master at any moment can halt the slave and load a different image so the slave is effectively running from ram and can run different firmwares.. with much less latency because it's running from RAM. Cool, aye ?

[nctnico]

ARM on the other hand, is a von Neumann machine. This means that the code, hardware registers and RAM reside in 1 single memory space. This is needed for the option to execute code from RAM.

No. This isn't right. ARM is a modified Harvard processor. This means the instruction and data busses are seperate but externally connected to form a single memory space. This means no extra instruction are needed to transfer between various types of memory. This also scales much better when using the C language. On a Harvard CPU with seperated memory spaces you can't use pointers in C (without a major speed penalty or severe limitations). Besides that modern ARM based microcontrollers usually allow to have concurrent flash, DMA and SRAM accesses. As usual the lines have become blurred.

[rstofer]

What about the word "8-bit" MCU.  In the old days, there were MCU which had 8-bit instruction word and 8-bit memory word and 8-bit data bus. But today there are some MCU which have maybe 16-bit memory word, or something else but the data bus is still 8-bit. Can we say that this MCU isn't 8-bit anymore?

The concept of "8-bit" or "16-bit", etc, is usually the width of the arithmetic logic unit (ALU).  The 8085, for example, had a 16 bit address but there were only 8 address lines coming out of the chip.  The high 8 address bits were sent out on the address pins and the low 8 bits were sent out on the bidirectional A/D (address/data) bus where they were latched so that the data could be sent over the A/D bus in the next cycle.

See about 3/4 the way down this page for a block diagram:

https://www.quora.com/What-is-function-of-ALE-in-8085

At the time, a 40 pin chip was thought to have a LOT of pins for a DIP package and there weren't many packages larger than this.  The Motorola 68000 used a 64 pin DIP.

[nForce]

The concept of "8-bit" or "16-bit", etc, is usually the width of the arithmetic logic unit (ALU).

You mean the accumulator, which stores an operand for ALU?

[JPortici]

What about the word "8-bit" MCU.

there was a fun thread about this not many months ago
was it this one? https://www.eevblog.com/forum/microcontrollers/8-bit-uc-is-there-even-a-point/
i remember at some point it degenerated in a phylosophical discussion on how to determine the true kind of a mcu

[boB]

Then what was the Harvard architecture processor I used to use ?

I bet it was a DSP then cuz they have a rather unique way about them.  DSP56001  or maybe I'm thinking of the intel 8031 family ?

Can't remember now.  Too old.

[ataradov]

You mean the accumulator, which stores an operand for ALU?

For older architectures with a single accumulator, sure. But there are no modern architectures that use accumulator. It just does not make sense and compilers can't deal with accumulators well.

ALU itself has a certain number of bits regardless of where the operands come from. And the with of the operands is probably the best definition for bitness of the MCU.

[legacy]

I bet it was a DSP then cuz they have a rather unique way about them.  DSP56001  or maybe I'm thinking of the intel 8031 family ?

(my first board, designed and handmade in 1994. It was loaded with Intel basic 51)


(the board was designed by following this book, printed by Intel and offered)



Intel 8051 is Harvard in the meaning it uses a special signal "/psen" for acknowledging the code-area, but data and addresses are shared between the code space and the data space.

See the pic, you can see the memory mapped I drawn years and years ago. Note the two spaces are separated even if addresses numerically collide (except for the trick for the three NVRam Chips that are mapped in both Code space and Ram space thanks to the Intel's trick described in the book).

This is clearly not a "structural hazard", it's simply a way to distinguish the data from the code, and there are tricks (reported by Intel in the above book) for being able to read and write into the code space so a bootloader can be written in a way it can reprogram its own flash. Otherwise ... you cannot on-board reprogram an 8051's flash and you end by programming the chip manually with an external tool (e.g. ROM-emulator, or prom programmer).

The DSP56001 is a "modified Harvard architecture" processor with three memory spaces and on-chip memory banks in some of the models. It allows the contents of the instruction memory to be accessed as if it were data and it's a weird beast with the uncommon data size of 24 bit.

A pure RISC-Harvard machine expresses the need to have the code space and the data space in a way the CPU can fetches opcodes and simultaneously accesses the Ram. In this case, the purpose of being "Harvard" is clearly an attempt to solve the "structural hazard" in a way that fetches and IOs can be performed simultaneously.

This is a need for the pipeline and modern pipelined-RISC-ish CPUs and MPUs are all "modified Harvard architectures" or "pure Harvard architectures with *the bridge*" 

[boB]

A pure RISC-Harvard machine expresses the need to have the code space and the data space in a way the CPU can fetches opcodes and simultaneously accesses the Ram. In this case, the purpose of being "Harvard" is clearly an attempt to solve the "structural hazard" in a way that fetches and IOs can be performed simultaneously.

This is a need for the pipeline and modern pipelined-RISC-ish CPUs and MPUs are all "modified Harvard architectures" or "pure Harvard architectures with *the bridge*" 

Yes !  A very good advantage for Harvard being able to access the opcode flash AND the RAM at the same time.

Kind of like (but not really) dual port RAM.  Remember that ?  Back when I was playing with CRT display processors, I could have used that.
I bet that feature exists in todays' graphics processors but you (or I anyway) cannot have access to that documentation unless we spend
billions of dollars.

And I certainly remember the DSP56001's  X and Y memory.

[ataradov]

Kind of like (but not really) dual port RAM.  Remember that ?  Back when I was playing with CRT display processors, I could have used that.
I bet that feature exists in todays' graphics processors but you (or I anyway) cannot have access to that documentation unless we spend
billions of dollars.

There is dual port RAM in most FPGAs.

[boB]

Kind of like (but not really) dual port RAM.  Remember that ?  Back when I was playing with CRT display processors, I could have used that.
I bet that feature exists in todays' graphics processors but you (or I anyway) cannot have access to that documentation unless we spend
billions of dollars.

There is dual port RAM in most FPGAs.

Really ?  I didn't know that.  But I don't use many FPGAs.  Except for the cheapest versions (Silego) they're just too expensive for what I need (several dollars each)

Do these dual port RAMs have lock-outs or contention management for when two pieces of logic try to write to the same location ?  Maybe that is not as important as when one location is being written while it is also being read.  Or maybe it just doesn't matter.

[ataradov]

Do these dual port RAMs have lock-outs or contention management for when two pieces of logic try to write to the same location ?  Maybe that is not as important as when one location is being written while it is also being read.  Or maybe it just doesn't matter.

It matters and they do either configurable or predictably behaved contention management. Plus you get configurable bypass of the new data to the read ports.

BRAMs are fundamental to even medium-scale FPGAs. Without BRAM most of them will have very limited utility.

[rstofer]

The concept of "8-bit" or "16-bit", etc, is usually the width of the arithmetic logic unit (ALU).

You mean the accumulator, which stores an operand for ALU?

Maybe...

I prefer to think of the ALU width because there could very well be an overwide accumulator.  I won't go into details but the 16 bit IBM 1130 had a 16 bit accumulator with a 16 bit extension.  True, the extension wasn't called the accumulator but it was coupled to the ALU and used for multiply and divide as well as some shifts.

8080 style CPUs have at least 4 double wide registers SP, BC, DE, HL for holding 16 bit values.  Sure, each register of the pair is only 8 bits but the DAD (double add) did a 16 bit addition in 8 bit chunks as in DAD BC which added BC to HL and left the result in HL.  I'm pretty sure the chip used the same 8 bit ALU.