Let the single-chip running speed faster
Author: ■ Tsinghua University Lin Bin Beijing University of Posts and Telecommunications
Speech:
1 question
1.1 Hardware Technology Background
The frequency of the single-chip microcontroller is getting higher and higher, and the access speed of the RAM is also fast, but the efficiency of the single-chip system is not a proportional increase.
At present, the mainstream microcontroller used is 80386EX (50MHz, external address / data bus 16), MPC860T (66MHz, external address / data bus 32) and DS80C32 (25MHz, external address / data bus 8); used SDRAM The HY57 series, the K416 series (access speed is 100 MHz or 133MHz); the SRAM used is used, such as IDT71024, IDT7256 (50 MHz); used, the Flash used, AT29C512, SST39VF040, AT29C010 (8 MHz or 15 MHz), and the like. It can be seen that the speed of SDRAM, SRAM and the microcontroller are matched, even more faster than the speed of the microcontroller, and do not require a single-chip insertion to wait. The frequency of FLASH is 2 ~ 6 times higher than the single chip microcontroller, and the microcontroller often needs to match it with it, and the flash is more than 8 bits, and the current single-chip is mostly 16,32 bits, more reduced The working performance of the microcontroller.
According to the above analysis, if the access speed of flash is improved, the expansion of the Flash is 16 or 32 bits, then the speed of the program execute is fast, and the performance of the microcontroller is improved. If you can turn this idea into truth, and if the cost is low, it is the best thing. In fact, the 8-bit Flash is extended to 16 bits, or even 32 bits, but there is a cost of 2 to 4 times. Due to the Flash structure and process reasons, it is impossible to have commercialization and low price of Flash. Therefore, it can only be used to improve the running speed of the microcontroller.
1.2 software technology background
First, look at the principle of operation of the traditional single-chip program, in order to facilitate explanation, it is assumed that the hardware platform is 860T, the clock is 50MHz; the SDRAM space is 4m × 32bit, the address ranges from 0x00000000 ~ 0x00FFFFF, access time 10ns; Flash space 512K × 8bit, access time For 100ns, the address range is from 0x02800000 ~ 0x0287FFFF (as for other single chip, the operating principle is substantially the same, can be pushed). 860T After power-on, the PC Counter = 0x2800100, the program is executed from the PC, first performing the initialization code, and then execute the main program (AppCode). The program reads the instruction (code) from the flash to complete the data transmission - may be the transfer of SDRAM and internal registers, transmission, SDRAM, and peripheral transmission, interrupt processing and other work. It can be seen that when the program is running, a large part of the time is read from the FLASH, and this process is very time. Take the assumed 860T hardware platform as an example, because the flash access time is 100ns, so the time to read a directive is at least 100ns, that is, to wait 100ns when the 860t reads a directive. (In the way Cache is prefetted, the actual instruction time can be shorter, but the effect of this method is not obvious, and many single-chip has not ordered cache.)
The memory allocation of the 860T platform is shown in Figure 1.
2 Principles of the code from Flash into SDRAM
Through the above analysis, the initialization code bootcode is only executed when the program is started, it is slower, or acceptable. Really affecting the performance is the main program (AppCode) because the code here is not repeatedly executed, and if it can shorten its instruction time, the idle time of the microcontroller will greatly decrease, and performance has increased much. The SDRAM is faster. If the code is transported into the SDRAM, the instruction time is reduced a lot; and the SDRAM space is large, and the performance will affect performance because the code occupies a part of the space. But this is not just a simple handling process, but changes in physical memory addresses are involved in this process. Convert software source code into an executable binary image includes three steps: First, each source file must be compiled or assembled into a target file (Object file); step 2, all target files are to be connected to a goal File, it is called a reset program; Finally, in a process called a reactive address, you must specify the physical memory address to each relative offset in the retainable program, generate one Executable binary image file. If you run in Flash, all physical memory addresses should be in the address space of Flash. If you want to run in the RAM, all physical memory addresses should be in the address space of Flash. That is, if you want to move from the code from the flash to the SDRAM, you must change the physical memory address of the handled code. 3 implementation method for handling code
The following combination of the assumed hardware platform, detail the principle and process of the physical memory address calibration, the code handling. We write two C files --ROMTOOL.C, RAMAPP.C.
ROMTOOL.C completes 860T initialization, SDRAM's refresh, interrupt and peripheral initialization; Flash to SDRAM code handling drive module and jump module. The corresponding binary image file is ROMTOOL.BIN.
RAMAPP.C is actual application, the corresponding binary image file is RAMAPP .bin. Ramapp.bin is running in SDRAM after being transported.
3.1 Physical Memory Address Mapping Rules
The physical address mapping rules of ROMTOOL.C are: data is placed in the SDRAM space that is 0x3000, the size is 0xF0000; the code is sintered in the Flash space of 0x02800000, the size is 0x10000, will not be handled, This space is running.
So the positioning rules specified in ROMTOOL.LNX should also be this address range, as follows:
Memory
{
Ram1: Origin = 0x00003000, Length = 0xF000
Flash: Origin = 0x02800000, Length = 0x1000
}
Sections
{
.data: {}> RAM1
.Text: {}> Flash
}
The physical address mapping rules of Ramapp.c are:
The data is placed in a space that is 0x3000, the size is 0xF0000; the code is sintered in the beginning of the 0x02810000, the size is 0x02810000, which is handed to the start of 0x00F00000, SDRAM space of 0x70000, ie Ramapp.bin is actually running in SDRAM.
So, the positioning rules specified in RAMAPP.LNX should be in SDRAM, as follows:
Memory
{
Ram1: Origin = 0x00003000, Length = 0xF000
Ram: Origin = 0x00F00000, Length = 0x7000}
Sections
{
.data: {}> RAM1
.Text: {}> RAM
}
Finally, the address mapping rules of the 860 single-chip system are shown in Figure 2. By the comparison of Figure 1, it is possible to observe that this is very different from the conventional program address mapping.
3.2 Process of carrying
860T power-on reset, ROMTOOL.BIN is first executed, after the initialization work, run the code handling function, carry RAMAPP.BIN to SDRAM, then change the value of PC (Program Counter), unconditional transfer to SDRAM Run Ramapp.bin ,As shown in Figure 3.
3.3 Drive module and jump module source code
(1) Code of handling code drive module
Void Movecodef_to_RAM (Uword * rashcode_add, uword * ramcode_add, uword codelen) {
Do {
* RAMCODE_ADD = * flashcode_add ;
Codelen?
While (Codelen! = 0)
}
This section code is to carry the start address as flashcode_add, the length of the Flash code to the start address is ramcode_add, and the length is the SDRAM of Codelen.
(2) Main function and jump module
#define flashcode_add_v 0x02810000
#define ramcode_add_v 0x00f00000
#define codelen_v 0x00070000 / 4
Void main () {
UWORD * I = (uWord *) Flashcode_ADD_V;
UWORD * J = (UWORD *) RAMCODE_ADD_V;
UWORD * K = (UWORD *) Codelen_V;
MoveCodef_to_RAM ((UWORD *) I, (UWORD *) J, (UWORD *) K);
# 跳 模 模
ASM ("Addis R2, 0, 0x00F0");
ASM ("Ori R2, R2, 0x0000"); # code start address 0x00F00000
ASM ("MTSPR LR, R2");
ASM ("BCLR 20, 0"); # unconditional temporal to the link register
Address in # (lr)
}
Flashcode_add_v: The first address of the handling code is in Flash.
RAMCODE_ADD_V: The target address of the handling code is in the RAM.
Codelen_v: The length of the handling code is calculated at 32-bit.
This function is transferred to the SDRAM after calling the code handling the MoveCodef_to_RAM function, and transfer the program pointer to the SDRAM. Note that the address of the jump must be consistent with RAMCODE_ADD_V.
4 small knot
It can be seen that the key to correctly completing the code handling is:
1 Determine the physical address mapping rule of the handled code, the physical address must be in SDRAM;
2 The handled code is sintered in Flash, which is later handled into SDRAM;
3 Unconditioned transfer to SDRAM, run the handling code (application code).
For other models, the method can be pushed according to the principles, the method is the same, but the specific code is different. I believe that your microcontroller system has been treated after such treatment, and it will be much higher.
