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

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

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

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

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

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

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

上面代碼是ST提供的LL庫里關(guān)于那個(gè)延時(shí)函數(shù)的寫法，看看HAL庫的寫法是不是一樣的，不妨順便看看?！鞠旅娼貓D便是Hal_Delay()函數(shù)代碼】

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

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

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

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

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

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

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

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

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

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

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

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

對(duì)于這個(gè)結(jié)果，意外，但也意料之中。因?yàn)槲以谔砑幽莻€(gè)256周期值時(shí)心里就在犯嘀咕，有所警覺了。我現(xiàn)在是兩個(gè)8位數(shù)的加減，加個(gè)256按理是不會(huì)影響結(jié)果的，這樣推理下來，兩行代碼的結(jié)果就本該一樣。

我們?cè)倩仡^看看上面HAL庫函數(shù)中延時(shí)函數(shù)：

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

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

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

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

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

以現(xiàn)在測試為例。A行程序代碼在微處理里完成的就是數(shù)學(xué)表達(dá)式NowValue 加上 溢出周期值 減去 StartValue的結(jié)果，我們不妨將A行代碼的計(jì)算過程做個(gè)翻譯解讀就看得出來。只是B行代碼里再多加1個(gè)溢出周期值也不影響計(jì)算結(jié)果?！咀ⅲ呵懊鎯蓚€(gè)測試的溢出周期值剛好等于各自所用數(shù)據(jù)寬度的模值?！?/p>

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

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

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

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

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

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

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

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

t1 = Val2+ ARR+1 - Val1;

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

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

審核編輯：湯梓紅