In this video we will look at the different program memory segments that get stored into our various memory technologies on an embedded system. Embedded systems contain many different physical memories. These include SRAM, Flash, and Register Memory and we need them all in order to make an embedded application to work. These memories are used in different ways. Flash usually contains the code memory, SRAM contains our data memory, and registers usually help configure and track the state of a microcontroller application and its systems. Register memory differs from SRAM and Flash as it will always have a set interface not dependent on applications. Applications are free to use these memories in whatever capacity they need to accomplish their task. This means that programs need to know some details about these memories before they can be installed and executed. The linker accomplishes this by taking a high level program and separating it out into multiple components and these blocks are then installed on the physical memory. We begin to distinguish between the target architecture and the target platform. A platform in this case refers to the underlying Integrated Circuit and the components surrounding the CPU. A compiler can be platform independent, but it must know details about the target architecture it is compiling for. The linker cannot be platform independent because it needs to know something about the available memory space of the platform. In addition, when source files are compiled into a program executable, the linker needs to combine many different object files together into a single executable. This executable is then mapped into physical memory of the system through the process of locating. Much of this memory is in a physically different part of the chip or platform but access the same way. This is referred to as an address space. One way to organize this memory is to use a memory map. A memory map provides us a way to map different segments and sub-segments to the target memory. These are mapped by assigning certain addresses in an address space. By utilizing a single address space, it allows an architecture to use a unified access method to memory via software and addresses. Unfortunately, not all the R memories use this one address space. The general purpose and the special purpose registers of the CPU have their own address space and access method. Outside of these registers code, data, system configuration, device information and peripheral functionality are all represented through different segments but one address space. Let's first look at an example of register memory and the associated segments with the cortex m arm architecture processing core. The processor has specific rules about how general purpose and special purpose registers in the CPU are used. Nearly all operations in the CPU utilize the general purpose registers to hold operand data. Or the inputs and outputs of operations specified in assembly. The status and progress of the program operations gets stored in special purpose registers in the CPU. These registers are accessed via special keywords in assembly. Few examples include the general purpose registers of R0 through R12. In special purpose registers, like, the stack pointer, and the program counter. To complicate this further, different architectures, like, AVR, from Atmel, may use keywords to interact these registers, but include them in the unified address space. The instantaneous values of these registers can change regularly, as the program processes the instructions, and data of the program. A compiler needs to know ahead of time how to manipulate these registers at compile time to make sure the process and interactions with these registers coincide with an architecture's binary interface, or ABI. The ABI helps give rules on how a compiler will perform a translation from high level language to architecture specific machine code. This includes details on how to appropriately use the CPU and its registers. We will look more into what an ABI is later in the course. Outside the CPU system device and peripheral registers are on the platform. Different chips that is in the microcontroller family uses the same CPU architecture but with varying amounts of platform capability. This may mean more peripherals, increase memory, or more advanced system control. You can think of system and device memory as a method to track and configure high level information like debug, interrupts, calibration data and power motes. The addresses of memory segments may be kept in system across different chips in a family but do not guarantee these memories maintain the same addresses. Luckily the segments and he use of an address space to interact with these components allow the compiler to represent these in a unified mechanism. The compiler does not need to know anything related to the platform just the addresses that it needs to read and write to access these peripherals. Dependencies to map these platform specific registers to code occurs at compile time with something called a register definition file. This file allows address translation for external CPU segments to occur before linking. We'll go into more detail on this later in the course. The last two segments that you will see are the code segment and the data segment. The linker file provides information to a compilation process about how an executable is to be installed into a platform. Since the assigning of addresses, the last step of the build process, the compiled executable, or the relocatable, is created in a way that it references memory sections. By using symbols, and offsets, code and data sections can be moved around easily, and represented by a generic subsegment name. The locator then takes these generic sections and gives them real addresses within a larger segment. Different applications should use varying amounts and sizes of the code and data segment. Any leftover memory in these regions just stays unused. Here we have the same linker file contents that we looked at before. We have a list of memory segments and memory sections. I will refer to these memory sections as sub segments within a larger code and data segment. Some typical data sub segments are the stack, heap, the data and the bss. Some typical code segments include the interavectors, the text, read only data, and the boot loader. We will go into more detail about each of these sub segments in follow up videos. Compiling and installing a C program is a very complicated process. Any given embedded C program contains references to all kinds of different types of memory that are micro controller has. However, we need to know details about the memory both at run time and compile time to be effective with this.
