目录
实验缘由
和裸机开发不同，在RTOS实时操作系统中，我们需要选取一个定时器作为单片机时基源，成为系统“跑”起来的心跳。在这里，选取M4内核的Systick系统定时器来保持RTOS的心跳，当然，也可以选用其他定时器作为RTOS的心跳，目前许多官方源码和软件都是基于Systick系统定时器做的BSP板级支持包，为了移植的方便，我们就老老实实选它作为单片机的时基源。
同时问题也来了：Systick系统定时器拿去做RTOS的心跳了，原本基于Systick系统定时器的delay_us函数已经不能用了，delay_ms函数也被做成了软件延时，精度和稳定性都下降了一些。STM32的TIM定时器那么多，我们一般不可能全部用上，完全可以像裸机开发那样，把TIM拿来硬件定时，做到和Systick一样的效果。通用定时器和高级定时器功能强大，用来写延时函数太浪费了，故本篇文章选取基本定时器TIM7(TIM6亦可)。
一、什么是晶振？晶振频率与外设时钟频率？
这里抛开那种无意义的介绍不谈。单片机可以产生各种各样的信号，但是，这些信号的产生源头到底是谁？？？是它相应的时钟源！在CubeMX的图形化界面配置时，可以很清楚地看到，单片机可以选择自己的系统时钟源，对它进行各种倍频，分频，再分支管理，分配给各个总线上的外设来达到自己的功能需求，没有时钟，无论哪个外设都跑不起来。外设的时钟源来源于系统时钟源，是其分支管理后的结果。单片机有自己的内部时钟源，但当选择外部时钟来作为自己的时钟源时，这个角色就是晶振，说白了，晶振就是个时钟源，与外设时钟源不同，他是整个系统的时钟源。
倍频和分频，它调整的属性正是频率。这里频率的概念就是物理上频率的概念，f=1/T,即1s钟内进行单次操作的次数，T就是进行一次完整操作所需的时间，f越大，T就越小，意味着单片机某个外设进行单次完整操作所需的时间就越少，干活就越快。
注意：本文所说的单位操作是指在特定外设下的运行。
这和我们人体活动类似，人运动越剧烈，心跳就会越快，但人没有心脏，就没有生命运作的前提，更不用谈运动的快慢了，所以我们常比喻晶振就是单片机的心脏。
时钟树配置情况
M(兆)在数字上是指10的6次方。
在了解上述重要概念的基础上，Systick系统定时器和TIM定时器的运行速度取决于它最终被分配到的时钟的频率。Systick系统定时器挂载在AHB总线上,最终得到的时钟频率是在168M下进行分频获得的，这里不分频，得到的就是168M的时钟频率。
而TIM基本定时器挂载在APB1，是在AP1时钟频率下通过倍频得到的，这里得到了2倍的倍频系数，最终得到84M的时钟频率。显然Systick系统定时器的运行速度比基本定时器快。
二、TIM7基本定时器
1.设计思想
上文已经提到TIM7获得的时钟频率是84MHz，意味着什么？它1s可以进行单位操作84000 000次！换句话说就是延时1s需要计数84000 000次！而计数一次就是芯片的单位操作之一。如果要做1ms的延时，我们必须让他计数84000；1us延时，只需要计数84次。
然而基本定时器计数值存储的寄存器是低16位有效的，意味着65535以上的计数不可行，怎么实现1ms延时？没事，我们还可以对他进行分频(通过PSC预分频器)。
假如我们把84MHz分频8400，最终得到的就是10000Hz的频率,那他计数一次不就是100us吗？计数10次不就是1ms吗？
在此强调:了解好外设的时钟分配，运行机制，并进行自主的数学运算非常重要。
其他种类芯片的定时器计算也是按照这个思想进行。
在计数值为10的倍数的原则下，ms的延时函数我们采取8400分频，计数10次来设计以1ms为单位的毫秒延时；us的延时函数我们采取84分频，计数1次来设计以1us为单位的微秒延时函数。
这里不需要使用定时器的中断。理论上若开启中断，通过设计可以作为单片机的副时基源，用来解决其他需求。但在这里我们只是为了解决延时函数的空缺。
TIM初始化情况
2.代码
TIM7的初始化
void MX_TIM7_Init(void)
{
TIM_MasterConfigTypeDef sMasterConfig = {
0};
htim7.Instance = TIM7;
htim7.Init.Prescaler = 84-1; /*初始化时候的分频*/
htim7.Init.CounterMode = TIM_COUNTERMODE_UP; /*基本定时器只能向上计数*/
htim7.Init.Period = 65535; /*初始化时ARR为65535*/
htim7.Init.AutoReloadPreload = TIM_AUTORELOAD_PRELOAD_ENABLE;
if (HAL_TIM_Base_Init(&htim7) != HAL_OK)
{
Error_Handler();
}
sMasterConfig.MasterOutputTrigger = TIM_TRGO_RESET;
sMasterConfig.MasterSlaveMode = TIM_MASTERSLAVEMODE_DISABLE;
if (HAL_TIMEx_MasterConfigSynchronization(&htim7, &sMasterConfig) != HAL_OK)
{
Error_Handler();
}
HAL_TIM_Base_Stop(&htim7); //TIM7只在要进行延时操作的时候运行
}
us延时函数
void delay_us(uint16_t us)
{
uint16_t compare=(0XFFFF-us-5);
__HAL_TIM_SET_PRESCALER(&htim7,84-1); //重置为84分频
htim7.Instance->EGR|=0x0001; //软件触发更新事件，将重配的分频值同步到影子寄存器
__HAL_TIM_SetCounter(&htim7,compare); //重置计数值
HAL_TIM_Base_Start(&htim7);
while(compare<0XFFFF-5)
{
compare=__HAL_TIM_GetCounter(&htim7); //轮询检查
}
HAL_TIM_Base_Stop(&htim7);
}
为什么是赋值0XFFFF-us-5这个奇怪的数字呢？这就取决于基本定时器的计数方式了，他只能向上计数，这里我们选择65530(0XFFFF-5)作为基准值,往前倒减所产生的间隔us，就是我们要延时的us时间。
ms延时函数
void delay_ms(uint16_t ms)
{
uint16_t compare=(0XFFFF-10*ms-5);
__HAL_TIM_SET_PRESCALER(&htim7,8400-1); //重置为8400分频
htim7.Instance->EGR|=0x0001; //软件触发更新事件，将重配的分频值同步到影子寄存器
__HAL_TIM_SetCounter(&htim7,compare); //重置计数值
HAL_TIM_Base_Start(&htim7);
while(compare<0XFFFF-5)
{
compare=__HAL_TIM_GetCounter(&htim7); //轮询检查
}
HAL_TIM_Base_Stop(&htim7);
}
这里同样以65530(0XFFFF-5)作为基准值。但要注意：在8400分频下，计数一次是100us，计数10次才算1ms，所以这里我们规定以计数10次为单位，所以这个往前倒减的间隔是10*ms;
3.那些坑~
1.为什么分频比要减1？
硬件是从0开始计数的，而我们人却习惯于从1开始计数，难免刚开始思想会转不过来。
试想我们的要求是数10次。从1开始计，到10才算数了10次；
如果从0开始数到10呢？就数了11次，就不满足数10次的要求，所以要-1
2.要在TIM停止运作时再对它的寄存器值进行修改
3.何为影子寄存器？
预分频器寄存器 (TIMx_PSC)和自动重载寄存器 (TIMx_ARR)都是影子寄存器。
影子寄存器这个名字取得真是不好理解。我来自定义一下吧：
通俗来说，以PSC预分频器举例，它有一个存值寄存器，一个是生效寄存器；生效寄存器不可写，存值寄存器可写。生效寄存器他存的值可以立即让硬件生效工作，而存值寄存器只是存值和供生效寄存器更新(复制过来);在调用:
__HAL_TIM_SET_PRESCALER(&htim7,8400-1);
或
__HAL_TIM_SET_PRESCALER(&htim7,84-1);
时，只是更改了存值寄存器的值，生效寄存器的值没有变，所以即使用了这个函数，TIM还是没有按照新的分频比运作。那咋办？
原来要产生更新事件。但更新事件怎么产生？
从官方手册可知，要么等待他上溢，要么软件触发，但是延时函数我们要即改即用，不能先用原来的分频等他上溢后再更新，这样造成的误差太大了。因此我们自己动手，丰衣足食:
htim7.Instance->EGR|=0x0001; //软件触发更新事件，将重配的分频值同步到影子寄存器
__HAL_TIM_SetCounter(&htim7,compare); //重置计数值
注意：更新事件产生后CNT会自动清0，所以这两段代码不能调换位置。
4.演示效果
选取两个IO进行高低电平跳转,上下分别为延时100us和30ms的效果
三、SysTick系统定时器
1.配置项
Serial Wire表示SW调试，如果你的下载接口是JTAG就需要更改。
时基源Timebase Source选择SysTick.
2.CubeMX的设计思想
<1>.SysTick系统定时器概述
上文已经介绍到本例SysTick系统定时器获得的时钟频率是168Mhz,与基本定时器不一样，它向下计数，没有预分频器，不能自由选择自己喜好的分频系数；而SysTick系统定时器的重装载寄存器LOAD和计数寄存器VAL是24位的，最大存值为16777215。在LOAD存满的情况下，最大每进行一次单位操作可达约0.1s。在定时器每次都从LOAD满值计到0的情况下，根据数学计算，如果单位操作的时间只需要1us，那么LOAD只需要存168即可；要达到单位操作时间长达1ms，LOAD需要存值168000，它小于16777215，所以存得下，对比基本定时器只有16位的有效存值，这里就方便多了。
<2>.初始化
在HAL库自动生成的代码中，SysTick系统定时器的初始化是这样的路径:
HAL_Init()——>HAL_InitTick(形参)——>HAL_SYSTICK_Config(形参) ——>SysTick_Config(形参)
我们看SysTick_Config就一步到位。
__STATIC_INLINE uint32_t SysTick_Config(uint32_t ticks)
{
if ((ticks - 1UL) > SysTick_LOAD_RELOAD_Msk)
{
return (1UL); /* Reload value impossible */
}
SysTick->LOAD = (uint32_t)(ticks - 1UL); /* set reload register */
NVIC_SetPriority (SysTick_IRQn, (1UL << __NVIC_PRIO_BITS) - 1UL); /* set Priority for Systick Interrupt */
SysTick->VAL = 0UL; /* Load the SysTick Counter Value */
SysTick->CTRL = SysTick_CTRL_CLKSOURCE_Msk |
SysTick_CTRL_TICKINT_Msk |
SysTick_CTRL_ENABLE_Msk; /* Enable SysTick IRQ and SysTick Timer */
return (0UL); /* Function successful */
}
这里我们只关注LOAD和VAL的值，LOAD决定了他的计算周期，进而可以计算出单位操作一次所需的时间；而VAL就是当前的计数值，是我们可以操纵的量。
我们来看默认对他的配置：
SystemCoreClock=168000000; //系统时钟频率
uwTickFreq=1;//节拍频率
HAL_SYSTICK_Config(SystemCoreClock / (1000U / uwTickFreq))
显然通过这个函数最终传递给SysTick_Config的值是168000，所以CubeMX默认生成的SysTick代码里面设置计数周期为1ms，uwTickFreq节拍频率的值也会影响计数周期，但我们一般默认让它为1.
<3>.时基？系统心跳？
我们要选取一款定时器作为时基源，然后用这个定时器产生时基，晶振给单片机提供了心脏，而心脏的心跳，就从时基中来。
上面这句话是不是听得云里雾里？没事，听我慢慢道来：
①节拍
在基本定时器中，没有开启中断，只是拿来做延时函数。而SysTick系统定时器作为时基源，与基本定时器最大的不同，就是开启了中断。
问题显而易见，中断拿来干什么？？？
/**
* @brief This function handles System tick timer.
*/
void SysTick_Handler(void)
{
/* USER CODE BEGIN SysTick_IRQn 0 */
/* USER CODE END SysTick_IRQn 0 */
HAL_IncTick();
/* USER CODE BEGIN SysTick_IRQn 1 */
/* USER CODE END SysTick_IRQn 1 */
}
void HAL_IncTick(void)
{
uwTick += uwTickFreq;//uwTick是节拍变量
}
SysTick的中断里面对uwTick进行了以uwTickFreq为单位的累加；一次完整的计数周期是1ms，每1ms产生一次中断，对uwTick进行累加，可以理解为节拍就是记录系统到达一个计数周期次数的量，对，它是一个量；
uwTickFreq是节拍频率，上文已经提到uwTickFreq=1，节拍uwTick累加的幅度取决于节拍频率uwTickFreq。
普通定时器和时基源，两者相差的，仅有一个中断和节拍计算
系统心跳:定时器开启中断，并在中断函数里面记录它的节拍，节拍的值就是它心跳的次数
②节拍频率
节拍频率决定了系统心跳的快慢，它的含义完全可以从频率的定义去分析
3.HAL_Delay函数
#define HAL_MAX_DELAY 0xFFFFFFFFU
void HAL_Delay(uint32_t Delay)
{
uint32_t tickstart = HAL_GetTick();
uint32_t wait = Delay;
/* Add a freq to guarantee minimum wait */
if (wait < HAL_MAX_DELAY)
{
wait += (uint32_t)(uwTickFreq);//若Delay=0，至少让他延时一个节拍
}
while((HAL_GetTick() - tickstart) < wait)
{
}
}
CubeMX生成的HAL_Delay(uint32_t Delay)以实时获取节拍来延时，所以最短延时时间就是它的计数周期，这里为1ms
4.试写SysTick的us延时函数
①对比野火官方的us延时例程
static __IO u32 TimingDelay;
/**
* @brief 启动系统滴答定时器, 10us中断一次
* @param 无
* @retval 无
*/
void SysTick_Init(void)
{
/* SystemFrequency / 1000 1ms中断一次
* SystemFrequency / 100000 10us中断一次
* SystemFrequency / 1000000 1us中断一次
*/
if (HAL_SYSTICK_Config(SystemCoreClock / 100000))
{
/* Capture error */
while (1);
}
}
/**
* @brief us延时程序,10us为一个单位
* @param
* @arg nTime: Delay_us( 1 ) 则实现的延时为 1 * 10us = 10us
* @retval 无
*/
void Delay_us(__IO u32 nTime)
{
TimingDelay = nTime;
while(TimingDelay != 0);
}
/**
* @brief 获取节拍程序
* @param 无
* @retval 无
* @attention 在 SysTick 中断函数 SysTick_Handler()调用
*/
void TimingDelay_Decrement(void)
{
if (TimingDelay != 0x00)
{
TimingDelay--;
}
}
/**
* @brief 中断服务函数
* @param 无
* @retval 无
* @attention
*/
void SysTick_Handler(void)
{
TimingDelay_Decrement();
}
野火的官方代码设计思想和HAL库生成的代码设计思想并无二异，不同的只是节拍计数的情景和计数方式；野火的代码只有在运行延时函数时才进行节拍的计数，而节拍是向下递减的。但是这样的设计思想容易误导新人，下面我们理所当然地试想这样设计ms延时函数是不是很容易？
/**
* @brief ms延时程序,1ms为一个单位
* @param 无
* @retval 无
*/
void Delay_ms(__IO u32 nTime)
{
while(nTime--)
Delay_us(100);//10*100us=1ms
}
上面的代码是很典型的阻塞式嵌套，是非常占用CPU的，极易出现系统“卡死”现象
因此这样的设计思想不可取,试想:Delay_us函数要每10us运行一次，我阻塞了100次才到此1ms.现在我还要进行嵌套阻塞，CPU在Delay_ms函数运行时间的占比就会大大提高，其他操作经常被中断打断，导致其他操作的现象出不来，就是这个原因，因为其他操作的运行时间的占比被强制拉低了，还经常被打断，影响到其他设备的时序初始化也不奇怪。
我们要做的，就是避免纯软件阻塞式的嵌套
②设计思想
1ms延时函数CubeMX默认生成的代码已经帮我们实现了。为了避免不必要的麻烦，我们不动重装载寄存器LOAD的值，仅通过修改计数寄存器VAL的值来达到目的。
我们类比上述基本定时器us延时函数的设计思想：168Mhz的频率下，我们只需要让SysTick定时器计数168次就可以达到1us的延时效果了。结合它向下计数的特性，我们把最开始获得的VAL计数值作为基准，在这个值的基础上往前倒推168的正整数倍，其间隔就是实际总计数值，倍数就是用户设置的us延时值。
③代码
void SysTick_us(uint32_t us)
{
uint32_t start_val,real_val,JianGe;
start_val=SysTick->VAL; //把最开始获得的计数值作为基准值
do{
real_val=SysTick->VAL; //获取当前值
if(start_val>real_val) //应对计时器提前下溢
{
JianGe=start_val-real_val;
}
else
{
JianGe=SysTick->LOAD+start_val-real_val;
}
}while(JianGe<us*168); //判断是否到达间隔
}
最后再来看看RT-Thread官方是怎么处理us函数，思路是不是完全一样？？？
void rt_hw_us_delay(rt_uint32_t us)
{
rt_uint32_t start, now, delta, reload, us_tick;
start = SysTick->VAL;
reload = SysTick->LOAD;
us_tick = SystemCoreClock / 1000000UL;
do {
now = SysTick->VAL;
delta = start > now ? start - now : reload + start - now;
} while(delta < us_tick * us);
}
④注意事项: 计时下溢
假如我们要延时5us，那么计数间隔就是168×5，但当前计数值是168(作为基准VAL)，从168减到0只有168×1个间隔，当计数到0时VAL的值又回到了LOAD的值，这就是计时器提前下溢，那怎么办？
首先我们不能放弃原本已经记下168×1个间隔，在回到LOAD值的场景下，实际VAL=LOAD-168×4，这两个间隔累加起来就是168×5；
实际间隔=基准VAL-实际VAL=168-(LOAD-168×4)=168×5-LOAD，
目标间隔=实际间隔+LOAD
在这里可见数学运算的魅力，太直观了！我们轻易就能知道把LOAD加上就能得到想要的间隔！
脑子瞎想没用，一张纸一支笔就能解决你的困惑！
⑤演示效果
以下是延时30us IO口电平跳变的效果
知识小卡片
1.U,L,UL:
U：无符号型数据
L：长整型数据
UL：无符号长整型数据
例如：10UL，说明10这个值是无符号长整型
2.__IO修饰符
__IO其实就是volatile特征修饰符。
在了解这个修饰符之前我们要知道一个事实: 访问寄存器比直接访问内存快
通常编译器会对程序进行优化，把变量(如char i)所在内存的值先存到单片机的特殊寄存器中，当程序在已知的情况发现变量的值改变时，就会把值重新更新到内部特殊寄存器中，这样以后我们对变量的读取就直接从寄存器读取。
但是遇到未知的情况时，变量值发生了改变，检测变量的函数却无法得知，访问的还是寄存器里的值，也就是变量原来的“备份”，就容易出问题。而中断函数，就属于位置情况；RTOS中的线程，也会成为未知情况。这时候变量就要做修饰，如 volatile char i;
/**
* @brief us延时程序,10us为一个单位
* @param
* @arg nTime: Delay_us( 1 ) 则实现的延时为 1 * 10us = 10us
* @retval 无
*/
void Delay_us(__IO u32 nTime)
{
TimingDelay = nTime;
while(TimingDelay != 0);
}
/**
* @brief 获取节拍程序
* @param 无
* @retval 无
* @attention 在 SysTick 中断函数 SysTick_Handler()调用
*/
void TimingDelay_Decrement(void)
{
if (TimingDelay != 0x00)
{
TimingDelay--;
}
}
/**
* @brief 中断服务函数
* @param 无
* @retval 无
* @attention
*/
void SysTick_Handler(void)
{
TimingDelay_Decrement();
}
上述代码中，TimingDelay_Decrement()函数在对TimingDelay检测前并没有对TimingDelay进行任何写操作，如果不加__IO修饰，在产生中断后，TimingDelay递减后的值不会实时同步到Delay_us()函数中，而在另一个文件的SysTick_Handler()中断函数，也不会知道另一个文件Delay_us()函数对TimingDelay的重新赋值，两者都在用之前的“备份”值，产生混乱。