我們知道，STM32庫函數(shù)里通常使用來自內(nèi)核的系統(tǒng)定時器SYSTICK作為時基，實現(xiàn)計數(shù)延時。一般來講，ST公司提供的庫函數(shù)里將SYSTICK定時器配置為1ms的定時器中斷，每產(chǎn)生1ms中斷則相關(guān)中斷事件計數(shù)變量加一。具體應用中我們經(jīng)常會調(diào)用那個Delay()函數(shù)以實現(xiàn)計數(shù)定時，做延時或超時管理。

有人在閱讀ST提供的LL庫里的這個延時函數(shù)時，發(fā)現(xiàn)代碼里對延時參數(shù)總是做了個加1操作，代碼如下：

上圖中紅色代碼，程序進來后就對給定的延時參數(shù)做了個加1操作，這不將1ms延時變成2ms了嗎?

其實，這個地方已經(jīng)有做了注釋，就是為了保證有1個最小的延時等待，函數(shù)參數(shù)給定1ms的延時，經(jīng)過這樣加1操作后就能保證至少1ms的實際延時，極限情況的確可能達到2ms，但不會超過2ms。但如果這里不做加1操作，函數(shù)參數(shù)給定1ms的延時，實際延時最短的情況的極限是0，最長的極限是1ms.

我們不妨借助下面圖形一起看看，可能更直觀點。

假設調(diào)用Delay函數(shù)時給定延時參數(shù)為3，首先讀到的滴答中斷計數(shù)值為5，顯然在上圖的綠色區(qū)除了兩個邊界點外的任一時刻讀到的數(shù)據(jù)都是5。如果先不對延時參數(shù)加1，那么實際延時就落在(2ms,3ms)之間;如果對延時參數(shù)先加1，那么實際延時就落在(3ms,4ms)之間。換言之，擬定延時n個ms，若做加一操作，實際延時落在(n,n+1)ms開區(qū)間;若不做加1操作，實際延時落在(n-1,n)ms開區(qū)間。

那這個的加1操作是必須的嗎?我不這么認為，加不加1沒有原則性問題。當我們把該定時器的溢出中斷時間定好后，精度就定了，以1ms中斷為例，我們就得接受1ms內(nèi)的誤差。這個地方知道怎么回事就好，畢竟中斷代碼的編寫、延時參數(shù)的擬定都是我們自己定的。

上面代碼是ST提供的LL庫里關(guān)于那個延時函數(shù)的寫法，看看HAL庫的寫法是不是一樣的，不妨順便看看。【下面截圖便是Hal_Delay()函數(shù)代碼】

顯然，在HAL庫里的Delay函數(shù)里進來后也首先做了加1操作，跟LL庫的做法一樣。

上面HAL庫延時函數(shù)代碼里的Tickstart是調(diào)用Delay()函數(shù)時首次讀到的滴答中斷計數(shù)變量的值，wait是延時值，Hal_GetTick()函數(shù)動態(tài)讀取到的滴答中斷計數(shù)變量的值【uwTick】。對于上面while語句里面的uwTick與Tickstart的比較的寫法，有人可能會產(chǎn)生疑問。當Hal_GetTick()函數(shù)讀取到的滴答中斷累加值uwTick小于或等于Tickstart時還能得出正確的比較結(jié)果嗎?

比方像下面這種情況，某無符號整型變量循環(huán)累加計數(shù)，現(xiàn)在需求得Val2與Val1的差值以測試信號寬度。

假定上面數(shù)據(jù)的計數(shù)周期為T，且Val2與Val1的間隔不超過1T。此時二者的間隔用數(shù)學表達式就是：Val2+T-Val1。這里的代碼似乎沒有考慮這個溢出周期的問題?可是那個uwTick完全可能出現(xiàn)小于tickstart的情況啊。

這是怎么回事呢?我也一度很懷疑這個寫法，當時也做了些簡單測試。對于測試結(jié)果，現(xiàn)在回想起來當時也沒做冷靜的分析而做出了錯誤的判斷。

回過頭來想，按理說這個代碼不該有問題。畢竟是老代碼了，何況之前也沒有人反映這個地方有問題。難道哪里誤會了?

因為當前代碼用到的幾個變量都是32位無符號數(shù)，剛開始測試時也是基于32位數(shù)做的，結(jié)果動不動就很大，不容易判斷正誤。我干脆將相關(guān)數(shù)據(jù)全部改為8位無符號數(shù)，這樣測試起來就方便些。

我先準備了下面的0~255的循環(huán)計數(shù)表格。顯然計數(shù)溢出周期為256。

現(xiàn)在要在任意一個不大于1個計數(shù)周期內(nèi)求取任意2個數(shù)據(jù)之間隔，即求這兩個無符號數(shù)之差。假設計算上圖中第1行數(shù)據(jù)5與第2行數(shù)據(jù)3的間隔值。這里用StartValue表示5，NowValue表示3，Result表示結(jié)果，都定義為8位無符號類型。

參照庫代碼寫法，代碼該這樣寫：Result1=NowValue – StartValue;

按照我的想法，代碼該這樣寫： Result2= NowValue + 256 – StartValue;

經(jīng)過測試，結(jié)果是一樣的，也不難驗證是正確的。

對于這個結(jié)果，意外，但也意料之中。因為我在添加那個256周期值時心里就在犯嘀咕，有所警覺了。我現(xiàn)在是兩個8位數(shù)的加減，加個256按理是不會影響結(jié)果的，這樣推理下來，兩行代碼的結(jié)果就本該一樣。

我們再回頭看看上面HAL庫函數(shù)中延時函數(shù)：

這里tickstart和wait以及函數(shù)HAL_GetTick()讀到的變量是uwTick值都是32位無符號變量，顯然，uwTick與tickstart的延時間隔也不會超過0xfffffff。

如果uwTick小于或等于tickstart,通常我們需要加上溢出周期，這個周期值等于32位數(shù)據(jù)模值，用16進制表示就是1后面跟8個0。經(jīng)過測試發(fā)現(xiàn)下面代碼的兩種寫法在微處理器的計算結(jié)果也是一樣的。【uwTick對應下面截圖代碼中的NowValue, uwTick對應StartValue】

因為都定義成32位數(shù)據(jù)寬度了，結(jié)果很大，但是正確的。很明顯上圖中A行代碼更簡潔?？磥?，庫代碼這里這樣寫是沒問題的。

上面兩次測試除了位寬差別外，其它都一樣。怎么感覺求算不超過1個計量周期寬度內(nèi)任意兩個數(shù)據(jù)的間隔值不用考慮那個溢出周期呢?

其實，只要是任意兩個相同無符號數(shù)據(jù)類型數(shù)據(jù)做減法，且數(shù)據(jù)所能計量的最大值為其滿量程值【比如8位對應255,16位對應65535】，求算任意一個周期內(nèi)兩個數(shù)據(jù)的間隔值時，使用上面A行代碼寫法是沒有問題的，但這并不等于說不用考慮溢出周期的問題。

以現(xiàn)在測試為例。A行程序代碼在微處理里完成的就是數(shù)學表達式NowValue 加上 溢出周期值 減去 StartValue的結(jié)果，我們不妨將A行代碼的計算過程做個翻譯解讀就看得出來。只是B行代碼里再多加1個溢出周期值也不影響計算結(jié)果。【注：前面兩個測試的溢出周期值剛好等于各自所用數(shù)據(jù)寬度的模值。】

但實際應用中，數(shù)據(jù)變量的計數(shù)周期往往并不等于所用數(shù)據(jù)寬度的模值。此時前面A行代碼的寫法就行不通了，而要用B行代碼寫法。即A行代碼寫法只能用在特定場合，B行代碼寫法具有普適性。

我們不妨看看下面表格。這個表格跟前面0~255的表格類似，只是換成由一系列0~99的數(shù)據(jù)周期性排列而成。

同樣，我們求第一行的數(shù)據(jù)5與第2行的數(shù)據(jù)3之間的間隔數(shù)，這里的數(shù)據(jù)都定義成uint8類型。顯然這里計數(shù)周期為100，而非256,此時的代碼就不能采用前面A行代碼寫法。

我們可以看看驗證結(jié)果：【顯然第一種寫法的結(jié)果是錯的，不難判斷正確結(jié)果是98】

我們繼續(xù)看一個實戰(zhàn)性的例子，看一個有關(guān)使用TIMER測量脈沖寬度的例子。

下圖斜線表示計數(shù)器計數(shù)方向，現(xiàn)在利用TIMER的捕獲功能測量下面一段脈沖的高電平寬度。

假設TIMER為16位，計數(shù)器向上單向計數(shù)。于脈沖的上沿和下沿事件分別捕捉到兩個計數(shù)值Val1和Val2，二者都定義成16位無符號整型變量。

結(jié)合圖形可以看出，脈沖雖然跨越了溢出點，但脈沖寬度沒有超過1個計數(shù)周期，Val2的值小于Val1。此時我們求算t1的寬度，正常都會這樣寫：

t1 = Val2+ ARR+1 - Val1;

當然，如果說你把ARR剛好設置為0xfffff, 此時程序代碼就可以簡化成 t1 = Val2 - Val1。

OK,關(guān)于STM32片內(nèi)Systick定時器延時中斷應用的兩個小疑問就聊到這里。問題雖小，但可以牽扯出不少東西供探究。。

審核編輯：湯梓紅