ROM: (Read Only Memory) Program memory
Used to store program data and constant data or variable data in the microcontroller. All codes in c files and h files, global variables, local variables, constant data defined by the 'const' qualifier, and codes in the startup.asm file (similar to the bootloader in ARM or the BIOS in X86, some low-end microcontrollers do not have this) are all stored in ROM.
RAM: (Random Access Memory) Random Access Memory
Used to store variables used in the program. All the quantities used in the entire program that need to be rewritten are stored in RAM. The "changed quantities" include global variables, local variables, and stack segments.
After the program is compiled, assembled, and linked, a hex file is generated. Use special burning software to burn the hex file into ROM through the burner (how to transfer the hex file to the ROM inside the MCU?). Therefore, the ROM at this time contains all the program contents: whether it is line by line of program code, local variables used in functions, global variables declared in header files, and read-only constants declared by const, all are generated into binary data, included in the hex file, and all burned into the ROM. At this time, the ROM contains all the information of the program, and it is precisely because of this information that all the actions of the CPU are "guided".
Some people may have questions. Since all the data is in ROM, where does the data in RAM come from? When does the CPU load the data into RAM? Is it possible that the data that needs to be placed in RAM has been burned into RAM during the burning process?
To answer this question, we must first make one thing clear: ROM is a read-only memory. The CPU can only read data from it, but not write data into it. The data is still saved in the memory after power failure; RAM is a random access memory. The CPU can both read data from it and write data into it. The data is not saved after power failure. This is an eternal truth and should always be kept in mind.
After clarifying the above questions, it is easy to think that the data in RAM is not written during the burning process, because after the burning is completed, the power is unplugged. When the MCU is powered on again, the CPU can execute the action normally, and there is still data in the RAM. This shows that the data in the RAM is not written during the burning process, and it also shows that the data has been written into the RAM when the CPU is running. The key is here: this data is not written manually, but written by the CPU. So when did the CPU write it? Let me tell you.
As mentioned last time, ROM contains all the program contents. When the MCU is powered on, the CPU starts to execute instructions from the first line of code. The work done here is to prepare for the smooth operation of the entire program, or to initialize the RAM (Note: ROM is read-only and not write-only). There are several work tasks:
1. Allocate address space for global variables---àIf the global variable has been assigned an initial value, the initial value is copied from ROM to RAM. If it has not been assigned an initial value, the initial value of the address corresponding to this global variable is 0 or uncertain. Of course, if the address space of the variable has been specified, it is enough to directly locate the corresponding address. In this case, the task of allocating and locating the address here is completed by the "connector".
2. Set the length and address of the stack segment---àIn the microcontroller program developed in C language, the stack segment length setting is generally not involved, but this does not mean that it does not need to be set. The stack segment is mainly used to "save the scene" and "restore the scene" during interrupt processing. Its importance is self-evident. Such important content is also included in the content preset by the compiler. It is indeed convenient, but not necessarily worry-free. How come I didn't notice it before? Strange.
3. Allocate the starting addresses of the data segment data, constant segment const, and code segment code. The addresses of the code segment and constant segment can be ignored, as they are fixed in the ROM. No matter how they are arranged, they will not affect the program. But the address of the data segment must be taken care of. The data of the data segment must be copied from the ROM to the RAM, and in the RAM, there are both data segments data, stack segments stack, and general working register groups. Usually, the address of the working register group is fixed, which requires that when the data segment is absolutely addressed, the data segment cannot cover the address of all working register groups. Serious attention must be paid. The
"first line of code" mentioned here is not necessarily the program code you wrote yourself. Most of them are done by the compiler, or the demo program file that comes with the compiler. Because the program you wrote yourself (C language program) does not contain these contents. For more advanced microcontrollers, these contents are all in the startup file. Read carefully, it will be helpful.
The usual practice is: when the ordinary flash MCU is powered on or reset, the PC pointer stores "0000", which means that the CPU starts to execute instructions from the 0000 address of the ROM. A jump instruction is placed at this address to make the program jump to the _main function, and then according to different instructions, it is executed one by one. When an interrupt occurs (the number of interrupts is also limited, 2 to 5 interrupts), according to the interrupt vector table address assigned by the system, an instruction to jump to the interrupt service program is placed in the interrupt vector. In this way, the whole program runs. The decision of the CPU to do this is caused by this ROM structure.
In fact, the C language compiler has done a lot of work here, but you just don't know it. If you read the help file that comes with the compiler carefully, you will know a lot of things. This is the best way to understand the compiler.
I/O port register:
It is also a quantity that can be changed. It is arranged at a special RAM address and is accessed by the system, and other variables cannot be defined at these locations.
Interrupt vector table:
The interrupt vector table is fixed in the ROM address inside the MCU, and different addresses correspond to different interrupts. Each time an interrupt occurs, the corresponding interrupt service subroutine is called directly, and the entry address of the program is placed in the interrupt vector table.
ROM size issue:
For flash type MCUs, the size of the ROM space is usually a whole byte, that is, ak*8bits. This is easy to understand, and you can tell at a glance that the ROM space is aK. However, for some OTP type microcontrollers, such as holtek or sonix microcontrollers, you often see "OTP progarming ROM 2k*15bit..." written on the data sheet, which may cause confusion. This "15bit" is considered to be more than 1 byte and less than 2 bytes. So is this ROM space 2k, more than 2k, or 4k but a little less?
There are two concepts to be clarified here: one is the bit width of the instruction, and the other is the length of the instruction. The bit width of the instruction refers to the width of the data bits occupied by an instruction; some are 8 bits wide, and some are 15 bits wide. The instruction length refers to the storage space occupied by each instruction, which can be 1 byte, 2 bytes, 3 bytes or even 4 bytes. This can be illustrated by a vivid analogy: when we do radio gymnastics, there are many movements to do, but each complex movement can be decomposed into several simple movements. For example, when doing stretching exercises, we only hear the radio calling "2, 2, 3, 4, 5, 6, 7, 8", and each number here represents an instruction. After hearing the instruction "3", our head, hands, waist, legs, and feet make different movements: look forward with both eyes, put the left hand on the waist, raise the right hand up, stretch the five fingers naturally together and open, straighten the right leg, and make a lunge with the left leg... and so on. There is only one instruction "3" to complete these movements, but there are many movements to be executed, so multiple decomposed movements are combined into one instruction, and the "bit width" of each decomposed movement is 15 bits. In fact, this is indeed the case. When disassembling or assembling, you can see that compound instructions are indeed composed of simple instructions.
At this point, answering the previous question, the ROM space of this OTP should be 2K, and the instruction bit width is 15 bits. Generally, when the instruction bit width is not a multiple of 8, it means that most of the instructions of the MCU are one byte long (note: the byte width is 15 bits, not 8 bits), and very few are 2 or more bytes. Although the total space is small, the space it can accommodate is not small for data.
Keywords:ROM
Reference address:ROM and RAM How does the microcontroller execute step by step after power is turned on?
Used to store program data and constant data or variable data in the microcontroller. All codes in c files and h files, global variables, local variables, constant data defined by the 'const' qualifier, and codes in the startup.asm file (similar to the bootloader in ARM or the BIOS in X86, some low-end microcontrollers do not have this) are all stored in ROM.
RAM: (Random Access Memory) Random Access Memory
Used to store variables used in the program. All the quantities used in the entire program that need to be rewritten are stored in RAM. The "changed quantities" include global variables, local variables, and stack segments.
After the program is compiled, assembled, and linked, a hex file is generated. Use special burning software to burn the hex file into ROM through the burner (how to transfer the hex file to the ROM inside the MCU?). Therefore, the ROM at this time contains all the program contents: whether it is line by line of program code, local variables used in functions, global variables declared in header files, and read-only constants declared by const, all are generated into binary data, included in the hex file, and all burned into the ROM. At this time, the ROM contains all the information of the program, and it is precisely because of this information that all the actions of the CPU are "guided".
Some people may have questions. Since all the data is in ROM, where does the data in RAM come from? When does the CPU load the data into RAM? Is it possible that the data that needs to be placed in RAM has been burned into RAM during the burning process?
To answer this question, we must first make one thing clear: ROM is a read-only memory. The CPU can only read data from it, but not write data into it. The data is still saved in the memory after power failure; RAM is a random access memory. The CPU can both read data from it and write data into it. The data is not saved after power failure. This is an eternal truth and should always be kept in mind.
After clarifying the above questions, it is easy to think that the data in RAM is not written during the burning process, because after the burning is completed, the power is unplugged. When the MCU is powered on again, the CPU can execute the action normally, and there is still data in the RAM. This shows that the data in the RAM is not written during the burning process, and it also shows that the data has been written into the RAM when the CPU is running. The key is here: this data is not written manually, but written by the CPU. So when did the CPU write it? Let me tell you.
As mentioned last time, ROM contains all the program contents. When the MCU is powered on, the CPU starts to execute instructions from the first line of code. The work done here is to prepare for the smooth operation of the entire program, or to initialize the RAM (Note: ROM is read-only and not write-only). There are several work tasks:
1. Allocate address space for global variables---àIf the global variable has been assigned an initial value, the initial value is copied from ROM to RAM. If it has not been assigned an initial value, the initial value of the address corresponding to this global variable is 0 or uncertain. Of course, if the address space of the variable has been specified, it is enough to directly locate the corresponding address. In this case, the task of allocating and locating the address here is completed by the "connector".
2. Set the length and address of the stack segment---àIn the microcontroller program developed in C language, the stack segment length setting is generally not involved, but this does not mean that it does not need to be set. The stack segment is mainly used to "save the scene" and "restore the scene" during interrupt processing. Its importance is self-evident. Such important content is also included in the content preset by the compiler. It is indeed convenient, but not necessarily worry-free. How come I didn't notice it before? Strange.
3. Allocate the starting addresses of the data segment data, constant segment const, and code segment code. The addresses of the code segment and constant segment can be ignored, as they are fixed in the ROM. No matter how they are arranged, they will not affect the program. But the address of the data segment must be taken care of. The data of the data segment must be copied from the ROM to the RAM, and in the RAM, there are both data segments data, stack segments stack, and general working register groups. Usually, the address of the working register group is fixed, which requires that when the data segment is absolutely addressed, the data segment cannot cover the address of all working register groups. Serious attention must be paid. The
"first line of code" mentioned here is not necessarily the program code you wrote yourself. Most of them are done by the compiler, or the demo program file that comes with the compiler. Because the program you wrote yourself (C language program) does not contain these contents. For more advanced microcontrollers, these contents are all in the startup file. Read carefully, it will be helpful.
The usual practice is: when the ordinary flash MCU is powered on or reset, the PC pointer stores "0000", which means that the CPU starts to execute instructions from the 0000 address of the ROM. A jump instruction is placed at this address to make the program jump to the _main function, and then according to different instructions, it is executed one by one. When an interrupt occurs (the number of interrupts is also limited, 2 to 5 interrupts), according to the interrupt vector table address assigned by the system, an instruction to jump to the interrupt service program is placed in the interrupt vector. In this way, the whole program runs. The decision of the CPU to do this is caused by this ROM structure.
In fact, the C language compiler has done a lot of work here, but you just don't know it. If you read the help file that comes with the compiler carefully, you will know a lot of things. This is the best way to understand the compiler.
I/O port register:
It is also a quantity that can be changed. It is arranged at a special RAM address and is accessed by the system, and other variables cannot be defined at these locations.
Interrupt vector table:
The interrupt vector table is fixed in the ROM address inside the MCU, and different addresses correspond to different interrupts. Each time an interrupt occurs, the corresponding interrupt service subroutine is called directly, and the entry address of the program is placed in the interrupt vector table.
ROM size issue:
For flash type MCUs, the size of the ROM space is usually a whole byte, that is, ak*8bits. This is easy to understand, and you can tell at a glance that the ROM space is aK. However, for some OTP type microcontrollers, such as holtek or sonix microcontrollers, you often see "OTP progarming ROM 2k*15bit..." written on the data sheet, which may cause confusion. This "15bit" is considered to be more than 1 byte and less than 2 bytes. So is this ROM space 2k, more than 2k, or 4k but a little less?
There are two concepts to be clarified here: one is the bit width of the instruction, and the other is the length of the instruction. The bit width of the instruction refers to the width of the data bits occupied by an instruction; some are 8 bits wide, and some are 15 bits wide. The instruction length refers to the storage space occupied by each instruction, which can be 1 byte, 2 bytes, 3 bytes or even 4 bytes. This can be illustrated by a vivid analogy: when we do radio gymnastics, there are many movements to do, but each complex movement can be decomposed into several simple movements. For example, when doing stretching exercises, we only hear the radio calling "2, 2, 3, 4, 5, 6, 7, 8", and each number here represents an instruction. After hearing the instruction "3", our head, hands, waist, legs, and feet make different movements: look forward with both eyes, put the left hand on the waist, raise the right hand up, stretch the five fingers naturally together and open, straighten the right leg, and make a lunge with the left leg... and so on. There is only one instruction "3" to complete these movements, but there are many movements to be executed, so multiple decomposed movements are combined into one instruction, and the "bit width" of each decomposed movement is 15 bits. In fact, this is indeed the case. When disassembling or assembling, you can see that compound instructions are indeed composed of simple instructions.
At this point, answering the previous question, the ROM space of this OTP should be 2K, and the instruction bit width is 15 bits. Generally, when the instruction bit width is not a multiple of 8, it means that most of the instructions of the MCU are one byte long (note: the byte width is 15 bits, not 8 bits), and very few are 2 or more bytes. Although the total space is small, the space it can accommodate is not small for data.
Previous article:SPI, IIC, IIS, UART, 232,485 Summary
Next article:Share the explanation of the volatile keyword by an expert
- Popular Resources
- Popular amplifiers
Recommended Content
Latest Microcontroller Articles
- Learn ARM development(16)
- Learn ARM development(17)
- Learn ARM development(18)
- Embedded system debugging simulation tool
- A small question that has been bothering me recently has finally been solved~~
- Learn ARM development (1)
- Learn ARM development (2)
- Learn ARM development (4)
- Learn ARM development (6)
He Limin Column
Microcontroller and Embedded Systems Bible
Professor at Beihang University, dedicated to promoting microcontrollers and embedded systems for over 20 years.
MoreSelected Circuit Diagrams
MorePopular Articles
- LED chemical incompatibility test to see which chemicals LEDs can be used with
- Application of ARM9 hardware coprocessor on WinCE embedded motherboard
- What are the key points for selecting rotor flowmeter?
- LM317 high power charger circuit
- A brief analysis of Embest's application and development of embedded medical devices
- Single-phase RC protection circuit
- stm32 PVD programmable voltage monitor
- Introduction and measurement of edge trigger and level trigger of 51 single chip microcomputer
- Improved design of Linux system software shell protection technology
- What to do if the ABB robot protection device stops
MoreDaily News
- CGD and Qorvo to jointly revolutionize motor control solutions
- CGD and Qorvo to jointly revolutionize motor control solutions
- Keysight Technologies FieldFox handheld analyzer with VDI spread spectrum module to achieve millimeter wave analysis function
- Infineon's PASCO2V15 XENSIV PAS CO2 5V Sensor Now Available at Mouser for Accurate CO2 Level Measurement
- Advanced gameplay, Harting takes your PCB board connection to a new level!
- Advanced gameplay, Harting takes your PCB board connection to a new level!
- A new chapter in Great Wall Motors R&D: solid-state battery technology leads the future
- Naxin Micro provides full-scenario GaN driver IC solutions
- Interpreting Huawei’s new solid-state battery patent, will it challenge CATL in 2030?
- Are pure electric/plug-in hybrid vehicles going crazy? A Chinese company has launched the world's first -40℃ dischargeable hybrid battery that is not afraid of cold
Guess you like
- Please help analyze this circuit.
- kicad-eda_6-layer-pcb_A64-OlinuXino_Rev_D
- MSP432 learning experience: system tick timer
- Sigma-Delta ADC Digital Filter Types
- Remote upgrade of HuaDa MCU HC32L110
- Explanation of the stack pointer register SP of msp430
- Qorvo at CES 2020: Innovative Solutions for 5G, IoT, Wi-Fi 6 and V2X
- dsp28335 Ecap Summary
- AD automatically adds test points
- iTOP-3399 development board Linux system modify boot LOGO