Memory model for Microcontrollers

[JPortici]

Maybe there is a tendency for one of the processors, to handle the real-time I/O, and related interrupts and timings.  So, it doesn't need more complicated instructions, such as floating point, nor needing maximum performance.  As a lot of its time, might be 'wasted', in polling loops, waiting for interrupts to occur and other house-keeping tasks.

But the other processor, runs (perhaps) the algorithms and other heavy stuff.  So, needs the best performance, floating-point and other extra bits and pieces.

Exactly.
For example: dsPIC33CH, the slave core has less memory and overall less communication peripherals, but it runs from RAM (needs to be loaded from the master) so it's both faster and has less cycle penalties from branches. Its peripheral set contains multiple ADCs, DACs, comparators and many, many PWMs. The slave core is aimed at digital power / motor control loops.
The master core has a ton of memory, and almost all the communication peripherals (many UARTs, I2C, SPI, SENT, CAN, ...) the master core is thought to be the arbiter and communicate with the rest of the system.

Similarly speaking, the M4/M0 hybrids: the M0 usually having peripherals better suited for IO management (buttons, lights, bit banging...) and the M4 core is both more powerful and it runs the algorythms.

Those CortexA/CortexM (such as STM32MP) use the cortex A for the user interface/embedded linux/communication, obviously, and the cortex M to run real time tasks

[MK14]

Exactly.
For example: dsPIC33CH, the slave core has less memory and overall less communication peripherals, but it runs from RAM (needs to be loaded from the master) so it's both faster and has less cycle penalties from branches. Its peripheral set contains multiple ADCs, DACs, comparators and many, many PWMs. The slave core is aimed at digital power / motor control loops.
The master core has a ton of memory, and almost all the communication peripherals (many UARTs, I2C, SPI, SENT, CAN, ...) the master core is thought to be the arbiter and communicate with the rest of the system.

Similarly speaking, the M4/M0 hybrids: the M0 usually having peripherals better suited for IO management (buttons, lights, bit banging...) and the M4 core is both more powerful and it runs the algorythms.

Those CortexA/CortexM (such as STM32MP) use the cortex A for the user interface/embedded linux/communication, obviously, and the cortex M to run real time tasks

Thanks for a very insightful response.  After chewing over it for a while, I want to comment that..

I suspect, that perhaps it originates, because a long time ago, when things were less integrated than now, many such embedded systems, had a big and powerful DSP on them (if required), and a somewhat powerful microcontroller as well (not always needed, as sometimes the DSP could handle the lot).

So for argument sake, let's say the item was a middle of the road, Hi-Fi unit, from the 1990s/2000s.  The DSP, would act as a powerful sound processing system.  E.g. To improve the sound effects, create special, adjustable room type (simulated) stereo effects, show a frequency bar graph and other things.
Whereas a normal MCU, could handle the HI-FIs, buttons, LEDs, displays, and the control logic/driving for any radios, tape decks, record players, and CD drives, etc.

I think DSPs use to be extremely expensive, so the more of the work, that could be off-loaded to a normal MCU, which were relatively cheap, even quite some time ago.  The cheaper the product could be, to be produced.

These days, they tend to include extra DSP instructions (or similar), on some modern MCU processors.

N.B. Before anyone tries to jump in and correct me.  I'm uncertain of how exactly they use to split the work between DSPs and MCUs, and also how often MCUs were included in past DSP products.

Also the DSPs, could have had considerably better quality peripherals, compared to MCUs, a long while ago, in the past.  Such as very high speed A to D converters, with decent (for that time), resolution.

[Kittu20]

Thank you for the discussions and responses on my post. I want to address any concerns some of you may have about my authenticity. I assure you that I am a real person, not a bot, genuinely interested in learning from this community. I have a background in electronics engineering,  I am interested growing career in the field of embedded systems. I am actively on a learning journey in the field of embedded systems. To enhance my practical understanding, I have purchased microcontrollers, sensors, and other devices to conduct experiments. I am improving my coding skills by writing code on my Windows laptop.

You may have noticed that I ask questions about C programming, microcontrollers, and embedded projects. I strongly believe that having a solid foundation in C programming is essential for success in embedded systems. 

I've noticed some criticism regarding my approach to asking questions, particularly about not being specific enough. I want to clarify that I don't see there's a strict order or specific rulebook dictating how questions should be asked. I ask questions based on what's on my mind and what I'm genuinely curious about.  I seek clarity on topics that I find challenging or unclear. There are no guidelines here specifying what questions should or shouldn't be asked—I simply ask what I need help with.  My goal here is to learn and improve my knowledge. If you can guide me in the right direction, I can improve my questions and interactions.

The reason I posted about C memory layout is because I found this concept challenging to grasp fully.  I was interested in understanding how the concept of memory layout in C programming is practically used,

My specific question was about how experienced individuals in embedded systems utilize memory layout, especially those who have worked with microcontrollers like 8051,PIC and ARM. I wanted to know if anyone here has used it practically, question was simply for sharing knowledge.

I had a general understanding of memory layout and its subsections,  mention reference link in thr first. I was initially confused because each microcontroller has its own unique memory structure, although in general memory layouts are generally divided into four specific sections I realized that memory layout is a general concept and not related to c language rather, it depends entirely on the hardware being used.

To those who believe I am a bot, I have never seen a bot that participates in these hands-on activities such as writing  C programs, Sharing screenshots of program output. Making hardware connections on breadboards and sharing picture on forum, Reading datasheets, Drawing block diagrams and circuit diagrams on paper, Sharing screenshots and pictures of real work on forums.

I actively share my own C programs, connect components on breadboard, write programs for microcontrollers, and share output screenshots—all done by my own hands.These activities reflect my genuine interest and commitment to learning and exploring electronics and programming.

If there are still any doubts in your minds, I would be happy to address them and clarify any concerns. I want to ensure that there is no room for misunderstanding, as I value genuine help and constructive discussions within this community.

I truly value the insights and expertise shared here, and I'm eager to absorb as much knowledge as I can to enhance my skills.

[MK14]

The reason I posted about C memory layout is because I found this concept challenging to grasp fully.  I was interested in understanding how the concept of memory layout in C programming is practically used,

My specific question was about how experienced individuals in embedded systems utilize memory layout, especially those who have worked with microcontrollers like 8051,PIC and ARM. I wanted to know if anyone here has used it practically, question was simply for sharing knowledge.

Speaking in general.  On a desktop PC, 40k of RAM, is 40k of RAM, regardless of which part of main memory, it is.  I.e. If the computer has 8GB of main memory, it is all pretty much the same.  With some excepts, such as if parts of it are allocated to any built in graphics units (iGPUs).

But on a (hypothetical, but vaguely typical), MCU (microcontroller),  the RAM, may have specific hardware features, pertaining to specific segments of it.

E.g. (but still hypothetical, so I don't need to delve into lots of datasheets, to give real life examples).

Only an 8k section, is connected to the low power (battery backed up) section, possibly also supporting a real-time clock feature.  So, that 8k, needs to have any/all of the variables and stuff, which need to retain their contents, even if there is a power-down (assuming the battery backup capabilities are used).

A different 16k section, maybe the only parts of RAM, which are shared between the main processor, and the much lower clock frequency (max), very low power consumption processor (sometimes seen on some RiscV CPUs), in the same chip.

A particular 2k section may be semi-reserved for USB and/or CAN and/or other specialized hardware features.

The DMA and/or cache and/or other features, may similarly be limited to only part(s) of the RAM address space.

Hence the need to get the address map(s) right.  But there can be many other reasons for needing to adjust the maps, some of which have already been mentioned in this thread.

[pcprogrammer]

Speaking in general.  On a desktop PC, 40k of RAM, is 40k of RAM, regardless of which part of main memory, it is.  I.e. If the computer has 8GB of main memory, it is all pretty much the same.  With some excepts, such as if parts of it are allocated to any built in graphics units (iGPUs).

But on a (hypothetical, but vaguely typical), MCU (microcontroller),  the RAM, may have specific hardware features, pertaining to specific segments of it.

There are also microcontrollers that have different types of RAM in it. For instance the Allwinner F1C100s has a small section of SRAM to be used by, at minimum, the boot loader and a large section of DRAM for which the controller has to be initialized first to be able to use it. That is why a boot loader needs to go into the small SRAM and do the needed initialization before the main program can be loaded into the DRAM. It is not capable of running code directly from FLASH memory and it does not have any of that build in.

Another thing with RAM can be how it is coupled to the processor. In ARM based controllers it is possible to have TCM (Tightly Coupled Memory) with a faster access from the core than the SRAM. The TCM part can be divided into instruction and data memory.

[Nominal Animal]

Even on ATmega32U4 (8-bit "old-style" AVR), the native USB peripheral has 832 bytes of dual-ported RAM, but to the AVR core, it's more like a configurable set of FIFOs dedicated for USB.

(It is quite a lot, considering it has only 2560 bytes of SRAM, but it is how it can sustain about 1 Mbytes/sec over USB, about 8 Mbit/s of payload data.)

The most RAM variants I know of on a microcontroller is definitely on Teensy 4.1: normal built-in RAM (OCRAM), tightly-coupled data memory (DTCM), tightly-coupled instruction memory (ITCM), and external RAM (I use an additional 8 or 16 Mbytes of PSRAM).  Plus there is 32k of instruction cache and 32k of data cache, which is transparent to the code (except for cache eviction and prefetch instructions so one can get the maximum use out of them).  All with only one core.

Fortunately, it has a single 32-bit address space, and even PSRAM is accessed without any shenanigans in the very same address space.  Aside from timing differences and architectural details when doing shenanigans (DMA and FlexIO support functions), one doesn't really need to worry about it.  (There are even two GPIO peripherals to choose from for each I/O pin, depending on which interconnect bus you want to use.)

(One reason I like Teensy 4.1 so much is that for USD $42, you can get a Cortex-M7 with hardware FP (32- and 64-bit) running at 600 MHz with 19 MiB (512k + 512k + 8M + 8M = 19,922,944 bytes) of RAM, 8 MiB of Flash, "lockable" with run-time code encryption/decryption support, 100Base-T Ethernet, two high-speed (480 Mbit/s) native USB interfaces (with support for one Host and one Client port currently), almost 50 usable I/O pins with lots of peripherals, and pretty good Teensyduino support library for development in the Arduino environment with sources at GitHub; plus a forum where the developer participates actively.  Very nice for hobbyists like me.  The one proprietary part is the programming/bootloader chip.)

I'm pretty sure the RAM model for tile processors (like XMOS xCore) has even more parts, because there each core has some local RAM, and one or more RAM regions of variously shared RAM.

On architectures with virtual memory support, we can go an order of magnitude more complicated.  Over a decade ago, I created an example of how to use memory-mapped files in Linux for manipulating a terabyte (1,099,511,627,776 bytes) -sized object in memory, as long as you have sufficient disk storage, speed limited only by the storage-RAM bandwidth.  Not to mention things like mapping the same RAM pages twice consecutively, so that you can treat a cyclic buffer (whose size is a multiple of page size) as always having linear data (assuming the cache coherency allows this safely; they often do not).

There definitely is a limit as to how deep one should dive into the details, before actually needing the info and applying it in practice.
I personally only bother to remember the key ideas, and how the different features can be useful; and just look up the details whenever I need them (for example to write this post).

(That is also why I prefer written text over face-to-face for technical discussions.  Face-to-face, I'm always repeating "oh wait, I recall I had read something pertinent about that... now, what was it again.. lemme quickly look it up and review before we continue".  Unless we're doing research or experimenting on a new-to-all thing, so that everyone is interested in those other references, in which case it's fun and pretty effective, too.  Definitely does not impress the administrative types, though!)

[xvr]

C language standard specified for some generic Virtual Machine. This VM would be mapped to real physical architecture of target processor in some processor specific way. VM used in standard to get rid of multiplicity of real CPU architecture - there is impossible define C implementation for each particular processor.

C compiler consumed C source code and generates machine code for particular processor. To do so it would use multiple memory segments for run C VM on real hardware. These segments are [almost] hidden from developer, and handled by C runtime. There are segments for heap, stack, exception tables (for C++), initialization/finalization code (C++) etc.

There is another story for segments which comes from CPU architecture itself. These segments were listed in previous messages. There are RTC memory (including battery backed RAM), interrupt tables, dedicated buffers, such as USB endpoints, Ethernet MAC buffers, CAN mail slots, etc.
These segments directly available to developer, and compiler itself do not managed them at all.

Some architecture has extension to C memory model, such as multiple data spaces (8051 for example has 3 data spaces: near, far, external), code overlay spaces etc. For all of them C compiler provides some dedicated support not only in memory layout, but in code generation and sometimes in extension of C language and runtime support.
Sometime C compiler can even provide different mapping of C VM to physical architecture. For this purpose C compiler introduced 'models' which selected by special command line switches. Such models can change size of pointers (32/64 bit - was used on Itanium), sizes of int/long, default data segments, using special types of pointers (PIC compiler introduced 'universal' pointer that can point to code or data segments, despite the fact that access to that segments required different code sequences)

[MK14]

Thank you for the discussions and responses on my post. I want to address any concerns some of you may have about my authenticity. I assure you that I am a real person, not a bot, genuinely interested in learning from this community. I have a background in electronics engineering,  I am interested growing career in the field of embedded systems. I am actively on a learning journey in the field of embedded systems. To enhance my practical understanding, I have purchased microcontrollers, sensors, and other devices to conduct experiments. I am improving my coding skills by writing code on my Windows laptop.

You may have noticed that I ask questions about C programming, microcontrollers, and embedded projects. I strongly believe that having a solid foundation in C programming is essential for success in embedded systems. 

What I'd suggest, as one of your activities, that could help you achieve your goals.  Is undertaking such project(s).  It can show any current weaknesses, in your skills and strategies, which should improve your experience levels and interest in the subject.

I don't know what you would like or not like.  But it makes more sense to find projects that interest you.

It could be almost anything.  A C program running on a microcontroller, which flashes LEDs, in ever more complicated and interesting flash patterns.

A 6 digit seven segment LED display, 4 function calculator, with keypad.  Written in C or assembly language (if assembly language, perhaps go for integer only, unless the MCU supports built in hardware floating point).

An internet radio, with your own custom human interface screen and keypad, to choose what they want to listen to.  Which can automatically switch off, after a certain number of minutes if desired.