目錄
實驗緣由
和裸機開發不同，在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的重新賦值，兩者都在用之前的“備份”值，產生混亂。