嵌入式工程编译通过以后，程序能不能顺利装进芯片里，其实只是第一步。要弄懂TASKING生成的map文件该怎么去阅读，以及map文件里关于RAM的占用情况应该先看哪几项，就不能光看一个总数，还得把每块内存区域里面已经用掉的空间、被预先留出来的部分、还剩多少空余，以及最大的连续空洞，这几个指标放在一起去判断。TASKING在编译完成之后，通常会把map文件放在当前构建配置对应的输出目录里面，比如Debug或者是Release文件夹下。要是手头用的是那种图形化的mapxml文件，直接双击就能把它打开，然后通过目录去切换不同的表格来查看。

　　一、TASKING map文件怎么看

　　map文件里头的记录内容其实不算少，刚打开的时候，最好不要一行一行地挨着往下翻。比较省事的办法，是先去看一下资源使用情况的汇总，然后再到定位结果和链接结果里面去细查，这么走下来，基本上就能确定内存空间是不是已经很紧张了，以及那些大块的内存，到底是让哪些模块给占住了。

　　1、先打开Used Resources

　　进到【Used Resources】这个视图里面去，找到那个叫做【Memory usage in bytes】的表格。在这个表格当中，它会按照每一块内存区域，分别把Code、Data、Reserved、Free还有Total这几列都给列出来。其中Code这一列，对应的是可执行的那些段占了多少体积，Data这一列呢，对应的是非可执行段的大小，而Free这一列，就是当前还能够拿来用的剩余空间。

　　2、再看Largest gap

　　剩余空间的那个总量，并不能跟你能不能再塞进去一个大数组直接画上等号。因为这个时候，内存很可能已经被切成了好多零零碎碎的小块，所以还得接着去看一看Largest gap这一项，也就是当前最大的一块连续空洞到底还有多大。要是你新添的变量或者段的尺寸，已经超过了这个数值，那链接这一步还是有可能会失败的。

　　3、用Locate Result找具体段

　　当发现某一块RAM的占用突然之间涨上去了，这个时候就可以进到【Locate Result】里面，去查看一下那个段被分配到的地址、段的大小、它属于哪一个Group、是在哪个模块里被定义出来的，还有它被放在了哪一块内存区域上。靠着这些信息，就能很快地分辨出来，这次的上涨到底是来自全局变量、缓存数组、堆栈，还是LSL配置文件里面写死的固定分配。

　　4、用Link Result追到源模块

　　再进到【Link Result】当中，可以按照目标段，反向去把输入的目标文件给查出来。如果有哪一个模块在最近新增了一个很大的数组，或者是一个静态的缓冲区，那么在这里，往往就会比较明显地暴露出来。

　　二、TASKING map文件里RAM占用该先看哪一项

　　在检查RAM的占用情况的时候，不要一上来就去看那个最后一行显示的Total总数。像TriCore这类工程里面，常常会碰到DSPR、PSPR、DLMU这些不同的内存区域，而且有些本地地址和线性地址，它们背后指向的其实是同一块物理内存。所以在判断容量究竟够不够用的时候，应该先去看某一条具体的Memory行，免得把这些映射关系错当成了额外的空间。

　　1、先看Data

　　在RAM相关的那几列里面，首先应该去关注Data这一列。它里面包含的是非可执行段所占用的那些空间，比较常见的来源有那些已经初始化过的全局变量、还没有被初始化的全局变量，以及静态定义的数组。比如说，你把某个缓冲区给加大了，那么Data这一列的数值通常就会跟着直接往上涨。

　　2、再看Reserved

　　Reserved这一列同样是不能被忽略掉的。按照TASKING文档里面的说明，这一列里面所包含的，可能会有预留出来的内存、栈和堆的空间、为了字节对齐而做的保护区域，还有一些特殊的段。有时候Data那一列看上去好像不高，可如果Reserved这一列的数值却非常大，那实际能拿来用的RAM，仍然可能会不够用。

　　3、接着看Free和Largest gap

　　Free这一项是用来帮助判断总共还剩下多少空间的，而Largest gap则是用来判断连续的可用的空余还有多少，这两项一定得配在一起看。如果光盯着Free的数值，就很容易做出错误的判断，以为自己还能再塞进去一个实际上放不下的大数组。

　　4、单独看Stack估算

　　在Used Resources里面，还会给出一个关于栈使用情况的预估值。这个数值是根据函数之间的调用关系分析出来的，要是你的代码里面存在着递归调用，那它给出的结果就可能不太准确了。所以这个数值更适合被拿来当作一个提前预警的参考，而不是直接把它当成运行时候的峰值去用。

　　三、TASKING map文件里的RAM异常怎么复核

　　当RAM的占用量忽然之间增加了不少的时候，先不要着急去动手改链接配置文件。首先要做的事，是确认一下这次的增加，到底是由于代码本身有变动，还是因为LSL布局、栈和堆的配置，以及变量初始化的方式被调整过了而造成的。

　　1、对比前后两份map文件

　　可以把改动之前和改动之后的两份map文件放在一块儿，重点去比较一下Data、Reserved、Free、Largest gap，还有Locate Result里面的内容。要是发现增加的量主要是集中在某一个Group里面，那就可以再回到对应的目标文件当中，去查一查是不是有新的变量被加进去了。

　　2、检查初始化变量

　　那些已经被初始化过的变量，在运行的时候是呆在RAM里的，不过它们的初始值还需要在启动阶段，从ROM里面被拷贝到RAM里面来；而没有被初始化的变量，则会在启动的过程当中被全部清成零。TASKING是通过链接器生成的一张copy table，来把这些初始化的动作给记录下来的。

　　3、检查栈堆是否被放大

　　TASKING的链接器在某些配置下面，会把剩余的最大的空洞拿去给栈和堆来使用。所以当你看到Reserved这一列的数字出现异常的上涨时，就要去检查一下LSL文件里面的stack、heap，还有fixed这些相关的设置，别一门心思只去盯着业务变量查。

　　4、看不到内存表时检查选项

　　假如你在map文件里面怎么也找不到【Memory usage in bytes】这个表格，那就需要去检查一下链接器里关于map-file-format的设置，看看里面的memory这个子选项是不是真的已经被打开了。一般来说，在默认的配置里面，通常都会把这个区域给包含进来的。

　　总结

　　TASKING的map文件要看懂，以及map文件里面关于RAM的占用应该先去查哪几项，实际去看的时候，是可以把顺序给固定下来的：先把Used Resources里头的Data、Reserved、Free还有Largest gap这几项给扫一遍，再进到Locate Result里面去把具体的段给找出来，最后用Link Result一路追到对应的模块上去。要是碰到了RAM出现异常的情况，就再去核对一下初始化变量、栈和堆的设置，还有LSL的布局。这么查下来，可比光盯着一个总的占用百分比去看，要更容易把问题给找出来。