實驗緣由
一、什么是晶振？晶振頻率與外設時鐘頻率？
二、TIM7基本定時器
- 1.設計思想
- 2.代碼
- 3.那些坑~
- 4.演示效果
三、SysTick系統定時器
- 1.配置項
- 2.CubeMX的設計思想
- - <1>.SysTick系統定時器概述
  - <2>.初始化
  - <3>.時基？系統心跳？
  - - ①節拍
    - ②節拍頻率
- 3.HAL_Delay函式
- 4.試寫SysTick的us延時函式
- - ①對比野火官方的us延時例程
  - ②設計思想
  - ③代碼
  - ④注意事項: 計時下溢
  - ⑤演示效果
知識小卡片

實驗緣由

和裸機開發不同，在RTOS實時作業系統中，我們需要選取一個定時器作為單片機時基源，成為系統“跑”起來的心跳，在這里，選取M4內核的Systick系統定時器來保持RTOS的心跳，當然，也可以選用其他定時器作為RTOS的心跳，目前許多官方原始碼和軟體都是基于Systick系統定時器做的BSP板級支持包，為了移植的方便，我們就老老實實選它作為單片機的時基源，
同時問題也來了：Systick系統定時器拿去做RTOS的心跳了，原本基于Systick系統定時器的delay_us函式已經不能用了，delay_ms函式也被做成了軟體延時，精度和穩定性都下降了一些，STM32的TIM定時器那么多，我們一般不可能全部用上，完全可以像裸機開發那樣，把TIM拿來硬體定時，做到和Systick一樣的效果，通用定時器和高級定時器功能強大，用來寫延時函式太浪費了，故本篇文章選取基本定時器TIM7(TIM6亦可)，

本篇以STM32F407VET6為基礎進行論述，

一、什么是晶振？晶振頻率與外設時鐘頻率？

這里拋開那種無意義的介紹不談，單片機可以產生各種各樣的信號，但是，這些信號的產生源頭到底是誰？？？是它相應的時鐘源！在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的重新賦值，兩者都在用之前的“備份”值，產生混亂，

轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/249102.html

標籤：其他

上一篇：【每日藍橋】5、一三年省賽JavaC組真題“有理數類”

下一篇：結構體中怎樣進行記憶體對齊：帶你學習1+4=8的情況

[RTOS前期準備]以Systick作為時基源+基本定時器撰寫延時函式（基于STM32F407+CubeMX+HAL）

目錄