当前的生活节奏越来越快，对计算处理器的要求也越来越高。即使是有摩尔定律的限制，人们仍然希望在单个芯片中塞入尽可能多的晶体管。尽管现在的MCU动不动就可以跑到几十上百兆，比如NXP高能效的LPC54100系列已破100MHz大关，通用型的LPC54600系列飚到210MHz，i.MX RT1050跨界处理器甚至飞到了怪兽级的600MHz，可是在当下应付图像处理和机器学习等计算大户时，仍然免不了出现“卡”的窘境。这个时候，如果能清楚地知道最消耗性能的具体函数，就有机会制定优化性能的策略。这也是圈子里常说的“profiling”（性能分析）。

有些价格相当昂贵的专业软硬件开发工具，都会提到它们有多么超强的profiling能力，这仿佛让人觉得profiling是有钱人才能玩得起，难道作为广大工程师我们就只能缩手缩脚吗？其实不然，在软件上想一点变通的办法，使用最便宜的仿真器，就完全可以在极小的开销下，做到好用够用的强大profiling利器，丑小鸭秒变金凤凰。

性能分析新思路

下面要介绍的方法的基本思想，就是密集地定期采集PC寄存器的值，从它的概率分布上估计最占CPU的函数。采集得越久，就越接近真实情况（大数定率）。

其原理是，在Cortex-M系MCU进入中断/异常时，会自动把被打断的位置(PC)存储在堆栈中。这样我们可以用汇编写一小段入口程序，读取出入栈的PC数值，作为参数传递给处理程序的C程序主体，在主体中统计PC样本的规律。只要采集了足够久的样本，在概率论的大数定理支持下，咱们就有信心估计程序中PC最常出现的位置，也就是最占CPU时间的函数。

为了贯彻这个思想，需要准备的只有：

1.工具链产生的 .map文件。无论是KEIL, IAR, GCC，在成功构建程序后，都会产生一个map文件来记录各函数和变量的位置。从采集的PC位置，查map文件判定是什么函数。

2.系统中有一个定期产生中断的时基。常见的就是SysTick定时器的周期中断，别的timer也可以。这个中断需要优先级比较高。

3.扩写定时器中断服务程序，按照前面的思路，加入这个屌丝神器。

这样，我们就可以把占CPU最多的计算型函数请到VIP区，它们与CPU有绿色快速通道，加速它们的执行。其实这个VIP区也是分等级的，从小V到大V，特权待遇相差还是明显的，小编今后再专开一文介绍不同VIP的特权。

要想让这个思路能可靠工作，还有几个关键的小坑不要踩：

1.PC最常在的位置并非一定就是最计算密集的位置。比如，程序中经常会出现等候外设寄存器的情况，CPU几万几亿遍地查看一个外设标志。这类IO忙等的代码即使放在大V区，也无济于事。

2.定时器中断的优先级不够高。如果有高优先级的中断服务程序占用了大量CPU时间，定时器中断就没有机会采集到它们，反而是在这些中断返回时定时器中断才得到服务，结果反而冤枉了被高优先级中断给打断的位置。

3.某个函数的工作频率与相位恰好和定时器中断产生“共振”，经常有机会在进入定时器中断的前夕在这个函数中，也会误以为这个函数是最占CPU时间的。这个情况一般是罕见的。

4.CPU负载比较轻，结果大量PC都采集到idle函数中。可能有小伙伴要问了，CPU都这么咸（闲）了，还淡操什么心？这个其实要以发展的眼光来看。比如，有可能随着功能集成的增加CPU终将有不堪重负的时候，或者系统负载不均匀而表现出明显的峰谷性，又可能希望让CPU尽管做完事好进低功耗模式。