之前在使用nucleo STM32F091RCT6进行项目实验时，代码编译链接无报错。最近需要将代码移植到nucleo STM32F072RBT6上，在更改Options中device芯片以及C++define后，再次编译链接，出现了几十个相同类型的错误，均为No space in execution regions with .ANY selector matching xxx.o(.data)。字面上是指执行区域无空间。那么这个无空间可能包含两种情况：
1. Flash无空间；
2. RAM无空间。
首先我们来看一下出现错误的原因。由于代码中包含了FreeRTOS，因此代码量非常大，在Options->Utilities->Settings中我们会发现，在芯片选择STM32F091RCT6后，Device Size为256k(k指kbytes)，但是在芯片选择为STM32F072RBT6后，Device Size为128k。在ST官网中可以看到：
STM32F091RCT6, Flash: 256k, RAM 32k.
STM32F072RBT6, Flash: 128k, RAM 16k.
因此同样的代码从STM32F091RCT6移植到STM32F072RBT6后出现报错是非常可能的。
接下来先判断是哪种类型的错误：
如果你的代码可以在某种芯片上成功编译链接，那么可以看看RO-data、RW-data、ZI-data来计算移植后是否会有可能内存溢出。比如我这里的代码在STM32F091RCT6上可以链接成功，信息显示：
Program Size: Code=57220 RO-data=13088 RW-data=556 ZI-data=24796
这里，
Code值代码大小，包含内联数据；
RO-data为只读常量数据，如const类型的数据；
RW-data为可读写变量的大小，即程序中初始化的变量大小；
ZI-data为程序中为初始化变量的大小，即程序中已经定义但是初始化为0或者未初始化赋值的变量（编译器会默认把没有赋值的变量自动赋值为0）。
从这里可以看出，下载烧录到Flash中的数据大小为Code + RO-data + RW-data，这里是70864字节即69k，烧录到RAM中是程序运行时所需要的空间，即RW-data + ZI-data，这里是25352字节即约24.76k。从这里可以看出，代码移植后STM32F072RBT6的RAM为16k是肯定不够用的，因此为RAM溢出。
我们也可以将代码中较大的函数挂载数组定义为const，const数组是存放于Flash中的，如果不报错，则证明是RAM溢出，如果仍报错，那依旧是两种都有可能。判断错误类型的意义，其实是为了告诉自己代码是否有优化的余地。
此后，是对于两种溢出类型的通用优化方案：
1. 使用微库，以更精简短小的C库替代标准C库，减小代码大小：
Options->Target->Code Generation->勾选Use MicroLIB
2. 修改链接脚本：
Options->Linker->勾选Use Memory Layout from Target Dialog
3. 修改优化级别：
Options->C/C++->Language/Code Generation->Optimization->选择Level 3 (-O3)
四种优化等级含义如下：
- -O0
最少的优化，可以最大程度上配合产生代码调试信息，可以在任何代码行打断点，特别是死代码处。
- -O1
有限的优化，去除无用的inline和无用的static函数、死代码消除等，在影响到调试信息的地方均不进行优化。在适当的代码体积和充分的调试之间平衡，代码编写阶段最常用的优化等级。
- -O2
高度优化，调试信息不友好，有可能会修改代码和函数调用执行流程，自动对函数进行内联等。
- -O3
最大程度优化，产生极少量的调试信息。会进行更多代码优化，例如循环展开，更激进的函数内联等。
经过上述优化（包含挂载数组转为常量，通用的三种优化等），基本可以解决大量的报错问题，至少我的问题是解决了。
学习嵌入式是个复杂但有意思的过程，继续努力。
文章中部分参考并引用了如下科普文章链接：
1. “gengyiping5”博主的https://blog.csdn.net/gengyiping18/article/details/52640806/，提供了优化方案汇总
2. “王小军”的知乎https://zhuanlan.zhihu.com/p/24402180，提供了Keil中四种优化方案的不同总结
3. “yl浪迹天涯”博主的https://blog.csdn.net/ylzmm/article/details/79233560，提供了Keil5生成的Program Size的含义解答
