在Cortex-M系列上如何准确地做us级延时？

前几天刚好同事问起在Cortex-M上延时不准的问题，在网上也没找到比较满意的答案，干脆自己对这个问题做一个总结。

根据我们的经验，最容易想到的大概通过计算指令周期来解决。该思路在Cortex上并不是很适用：一方面MCU从Flash取指是有延时的，另一方面Cortex的指令集不是固定周期的，特别从M3加入分支预测后，分支指令在Cortex-M不同型号上的结果都不相同。因此除了指令周期外，我们需要考虑的东西还有很多，才能得到正确的结果。

不带分支预测器的情况

仍然先从不带分支预测器的Cortex-M0开始，通过计算指令周期延时的实现代码如下：

void delay_us(us) {
     delay_ntimes((us * sysclk - 8) / 4);
}
__asm void delay_ntimes(unsigned int n)
{
L1
               SUBS R0, #1
               BCS L1
               BX LR
}

从这段代码可发现两个主要问题：

一、delay_us里的公式是怎么来的：

假如想延时us微秒，系统时钟为48MHz，即sysclk=48，那么周期数period_count满足以下公式：

period_count = us * sysclk;

然后再delay_ntimes这个函数，又能推出period_count还满足以下公式（见第二个问题的分析）：

period_count = 8 + 4 *n

于是：

n = (us * sysclk - 8 ) / 4;

这就解决了第一个问题，需要注意的是：该公式忽略了跳转到delay_us和(us * sysclk -8 )/4的几个固定周期。

二、delay_ntimes的周期数怎么算：

它的周期数满足以下公式：

period_count = 8 + 4 * n;

这个要根据指令集的周期数来确定，请看下表：

操作	描述	汇编命令	周期
Subtract	Lo to Lo	SUBS Rd,Rn,Rm	1
	3-bit immediate	SUBS Rd,Rn,#<imm>	1
	8-bit immediate	SUBS Rd,Rd,#<imm>	1
Branch	Conditional	B<cc> <label>	1或3
	Unconditional	B<label>	3
	With link	BL<label>	4
	With exchange	BX Rm	3
	With link and exchange	BLX Rm	3

先考虑n为0的情况，

SUBS为1周期+BCS为1周期+BX为3周期+外层调用delay_times（相当于BLX指令）的3周期=8周期。

当n不为0时，将再执行n次SUBS和BCS执行，SUBS仍为1周期，BCS有跳转3周期，所以是4n个周期，因此该函数的执行周期数为：

period_count=8+4n;

好了，在了解了原理之后，是时候到真正的板子上去测试了。

然而在MCU上的实测结果却不如预期，延时5MS，实测为7.5MS；延时10MS，实测15MS。为什么会出现这样的现象？

这个跟MCU的设计有关。一般代码都放在FLASH上，MCU中Cortex核要从FLASH上先取出指令，然后才能将指令放到指令流水线上执行。而上面的分析忽略了Cortex核从FLASH取出指令的时间，因此实测值与理论值分析不一致。

不同的MCU从FLASH读取指令的时间消耗各不相同，因此需要根据不同MCU去调整公式，这是一个比较繁琐的过程，比如这款MCU，将公式修改为(us * sysclk - 8) / 6就得到了正确结果。

另外一个做法是不修改公式，将延时代码放到RAM中，许多MCU从RAM取出指令没有等待周期。使用该方法再次测试，延时结果与理论计算一致。

但值得注意的是，不是所有MCU都满足RAM取值零等待周期的条件，因此一定要做测试。

读者若对MCU如何从FLASH读取指令感兴趣，参考资料[4]的分析是比较清楚的。

带分支预测器的情况

将上面的代码放到Cortex-M3和Cortex-M4的芯片上测试，测试结果是错误的，不论在FLASH还是在RAM中，这个是由于Cortex-M3，Cortex-M4上的指令流水线带有分支预测器引起的。

要了解分支预测器，就不得不提指令流水线。Cortex-M3是三级流水线：取指，解码，执行。但是没找到CORTEX方面较好的图，以下讨论就基于下图的4级流水线，该图多了一步：写回。这并不影响我们的讨论。

（该图引用自参考资料[1])

假设一条指令从执行开始到执行结束需要4个时钟周期，在没有流水线的情况下，需要等待第一条指令执行结束，才能取第二条指令，这时两条指令就用了8个周期，效率是很低的。

引入4级流水线将指令拆成4个步骤：取指、解码、执行、写回。当第一条指令处于解码时，同时对第二条指令取指；对第一条指令执行时，同时对第二条指令解码，对第三条指令取指；对第一条指令写回时，同时对第二条执行，第三条解码，第四条取指；如此这般。最终达到的效果就如上图所示，只有第一条指令需要4个周期，其他后续的指令都只需要1个周期，极大地提高了处理效率。

流水线的高效率是基于指令顺序执行的前提，在执行跳转指令时，流水线将被清空，又回到了上图中的第一步，跳转后的第一条指令要执行仍然需要4周期。因此如果程序频繁跳转，流水线的作用就大打折扣。

为了解决这个问题，就引入了分支预测器：它会提前检测到跳转指令，并根据预判结果取指。如果预判结果是不跳转，就按顺序取下一条指令；如果预判结果是跳转，就从跳转的目的地址取下一条指令。假如预测对了，那么流水线就不会被清空，仍然可以一条指令1个周期；如果预测错了，下一条指令仍然要4周期。从这里看出，分支预测器对于提高流水线效率是有帮助的。值得一提的是，预判对了能减少指令延迟，但是否是零延迟取决于MCU的设计；预判错了清空流水线也未必是唯一的做法，同样取决于MCU的设计。

回到Cortex-M3的延时问题，网络上找到的资料提到分支预测器将延迟减小到1个周期，没有找到更详细的说明。那么理论上计算公式就应该调整为(us * sysclk - 8) / 3，在两款Cortex-M3和两款Cortex-M4上测试，测试结果与理论值一致。

微秒级精确延时的其他方法

对于Cortex而微秒级延时最通用的方法，大概便是通过比较SysTick的SYST_CVR寄存器来做延时，理论误差在1us内(基于48MHz主频)。以下为实现代码：

/*
* 使用SysTick的CVR实现微秒级精确延时，一般SysTick周期设置为10MS，因此该方法适用于10MS以内的延时
*/
void delay_us(int us) {
	unsigned t1, t2, count, delta, sysclk;
	sysclk = 48;//假设为48MHz主频

	t1 = SYST_CVR;
	while (1) {
		t2 = SYST_CVR;
		delta = t2 < t1 ? (t1 - t2) : (SYST_RVR - t2 + t1) ;
		if (delta >= us * sysclk)
			break;
	}
}

其他补充点

1. 本文假设在延时过程中没有产生任何中断，如果有中断产生，将影响延时精确性。
2. 这部分的内容属于计算机体系结构。
3. 以上测试时间范围在[0，10MS)，该范围之外未详细测试，建议采用其他方法。
4. 覆盖测试的MCU：1款Cortex-M0，2款Cortex-M3，2款Cortex-M4。
5. 在我测试的两款Cortex-M3 MCU上，将代码都放RAM上，测试结果比放在FLASH差，而在Cortex-M4 MCU上，测试结果都一样，目前没有找到合理的解释。

参考资料

1. 浅谈分支预测、流水线与条件转移
2. Cortex-M0指令集
3. CPU性能衡量参数-主频，MIPS，CPI，时钟周期，机器周期，指令周期
4. Cortex-M3的周期判断的依据是什么
5. 计算机体系结构——流水线中的相关——延迟分支方法