External SRAM experiment, allowing STM32 external SRAM operations to be the same as internal SRAM

Source: External SRAM experiment, allowing STM32 external SRAM operations to be the same as internal SRAM

A few days ago to see Open source Electronic forum (openedv.com) Someone asked this question, I deliberately to do this experiment, so with the external SRAM with internal SRAM, do not have to apply for memory, and do not have to consider what memory address, all let the compiler to solve their own.

Needless to say, I took the atomic brother's battleship directly to develop the external SRAM experiment to modify the Board library function version. In the library function system_stm32f10x.c This initialization file actually already has the external SRAM initialization, we just add "#define DATA_IN_EXTSRAM 1" The definition of the macro

#if defined (STM32F10X_HD) | | (defined STM32F10X_XL) | | (defined STM32F10X_HD_VL)  /*  */  #define data_in_extsram 1  #endif

The initialization of the external SRAM will be compiled into the compiler, and the initialization code can see the void systeminit_extmemctl (void) function in the file. Then we add the external SRAM address to the project setup, such as

Modify the 39th line in the startup file to change the __initial_sp to __initial_sp EQU 0x20000000 + stack_size

Then we remove the address from the Testsram in main and let the compiler specify the address itself.

Then comment out the initialization of the external SRAM of the Atom brother, because the System_init has already been initialized in the front. In fact, we can get rid of the atomic sram.c file without it, I did not remove, in fact, just to be able to call Fsmc_sram_test () to test the results of the experiment

Here we can compile, download to the Development Board, we can see the results of the experiment

Let's go further and see testsram[] This large array is compiled everywhere, with IDA64 to disassemble the compiled AXF file

You can see that this large array of Testsram is automatically compiled to the address of the external SRAM 0x68000000. Let's try to define a few large arrays again.

And look at the compiled results.

You can see that each large array is assigned the address of the memory by the compiler itself, without having to define it ourselves.

There is a doubt that the compiler is going to decide what variables to define in the internal SRAM, those defined in the external SRAM. I also study this point, I only know that the compiler will prioritize the variables are external SRAM, when the external SRAM is not enough to be defined in the internal SRAM, and how to let the compiler first use internal SRAM, I do not understand. What I can do now is to put the initialized global variables in SRAM, by modifying the hash file so that RW compiles only on the memory SRAM.

Remove the tick from the Small red box and click Edit to modify the Sram.sct file, which is to compile the hash file

Remove the +RW from the rw_ram1 (that is, the external SRAM) so that the initialized global variable is only compiled into the internal SRAM

Recompile the project, then disassemble it and look at the results of the compilation.

Can see usmart_nametab[] this initialized array compiled on the internal SRAM, adc2[] This uninitialized array, the size of the array and can be compiled in the internal SRAM, but still compiled on the external SRAM.

Finally hash the relevant knowledge, you can see here http://blog.csdn.net/lindabell/article/details/8957968#0-qzone-1-11984-d020d2d2a4e8d1a374a433f596ad1440

There is no modification of the startup file, the other variables in the internal SRAM, the program is not a problem, the program to reduce the time the operation of the array, modify the preceding red Word part, the program can run, but the LCD occasionally normal, occasionally abnormal, debugging under the feeling is delayed, no further debugging

External SRAM experiment, allowing STM32 external SRAM operations to be the same as internal SRAM (RPM)