|
作者：allen_zhan [前言] 在前文"關(guān)于 FREESCALE 的 DEMO 中 PSOR與PCOR 操作的常見錯(cuò)誤 "中, 我們討論了 kinetis L series 的 Sample 中容易出現(xiàn)的, 關(guān)于 PSOR 的常見錯(cuò)誤, 我們分析, 這種錯(cuò)誤, 大致可能與未曾熟讀 RM 有關(guān). 在之后對 kinetis L series 的 samples 繼續(xù)短暫的了解過程中, 我們發(fā)現(xiàn)參考例程其他的較明顯的錯(cuò)誤, 或者說不足疏漏之處. 因其常常表現(xiàn)為 uController 的新生容易發(fā)生的錯(cuò)誤, 故我想稱其為"初學(xué)者錯(cuò)誤", 或者說是"初學(xué)者不足". [例程] 讓我們引 Blinky sample 中的, 開啟 Interrupt 的例程作為例子, 如下圖例1: [圖例1: Blinky sample 中的使能例程] 
這個(gè)例程, 讓我們覺得不能沉默以對. 因?yàn)? 作為 Freescale 官方例程, 可能類似的代碼會被我們國內(nèi)的初學(xué)者諸君, 作為效仿的對象. 從而產(chǎn)生錯(cuò)誤的引導(dǎo)效果, 不利于我們工程師的自我完善和提升. [可能的疏漏或錯(cuò)誤] 這里我們想主要指出, 這段短短的例程中可能出現(xiàn)的 4 個(gè)不足: (1) 首先, 這個(gè) (irq%32) 浪費(fèi)代碼空間并影響效率. -- 其本質(zhì)原因, 可能存在著邏輯上混淆不清. (2) 其次, IRQ的值域?yàn)? [0, 31]. 而該 code sample 卻允許對 32 的計(jì)算. -- 其本質(zhì)原因, 應(yīng)該是未作越界(邊界)檢查. 并未仔細(xì)閱讀 Register bit field定義. (3) 第三, 對 irq=31 時(shí)的可能情況, 也就是 (1<<31) 的情況, 毫無敏感. -- 這里毫無敏感的意思, 大致反應(yīng)為: (a) 對有符號數(shù)與無符號數(shù)區(qū)別不敏感, (b) 對左移操作不敏感. (4) 第四, 正如同我們在 PSOR 中分析到的 |= 錯(cuò)誤, 在這段簡單的例程中, 仍然存在 ICPR 在 bit 被 write 0時(shí)無任何影響, ISER 在 bit 被 write 0 時(shí)無任何影響. 都應(yīng)該改為 =. [討論(1<<31)的特例] 讓我們用例子來討論這個(gè) (1<<31): (1) 首先, IAR 中定義的常量, 都是有符號的 int 類型. 這個(gè)前提為大家公認(rèn), 但是我沒有找到出處``` 麻煩讀到此處的同行, 能給我一個(gè)出處鏈接, 或者是 IAR help documentation 中的說明. 蟹蟹. (2) 有符號數(shù) 1, 在左移 31 bit 后, 將導(dǎo)致符號位被置1, 也就是計(jì)算得到一個(gè)負(fù)整數(shù). 如果我們只看這里 NVIC_ICPR |= 1 << 31; 似乎沒有影響到最終邏輯結(jié)果. 但是, 其真實(shí)原因是, 該負(fù)整數(shù)被強(qiáng)制轉(zhuǎn)化為 unsigned int 的結(jié)果, 也即是最終正確的 0x80000000. 但這并不表示, coder 清楚這個(gè)結(jié)果是由強(qiáng)制轉(zhuǎn)換產(chǎn)生, 從這段代碼本身, 我們合理判斷該 coder 將分不清下面代碼的執(zhí)行結(jié)果, 也就是容易犯一些"初學(xué)者錯(cuò)誤". 比方說: 我懷疑該 coder 會毫無自覺寫出下面的代碼: if( (1<<31) > 1 ) { do what he wants; } 顯然我們知道, 這片代碼永遠(yuǎn)不能為真, 去執(zhí)行 what he want to do. (3) 根據(jù)圖例2, 我們對 (1<<31) 進(jìn)行詳論: [圖例2: Allen 隨手編碼給出3個(gè)例子討論 (1<<31) ]
我們把3個(gè)例子的結(jié)果, 都有注釋, 可以見到: (a) (1<<31) 的值, 不是正數(shù) 0x80000000, 而是負(fù)數(shù) -2147483648. (b) (1u<<31) 的值, 才是 0x80000000. (c) 條件比較語句, 首先是兩邊轉(zhuǎn)化為同類型才能比較. 由于無符號數(shù)優(yōu)先級高于 int, 故 (1<<31) 被強(qiáng)制轉(zhuǎn)化為 unsigned int, 也就是 0x80000000, 用于比較, 導(dǎo)致和 sample1 的結(jié)果截然不同. 上面3個(gè)例子, 清楚表明了 (1<<31) 的值為何(如果我有任何錯(cuò)誤請告訴我). [我們修改的代碼] 因此, Allen 嘗試修改這個(gè)例程如下, 見圖例3: [圖例3: 被修改后的例程]
[結(jié)論] 我們通過對一個(gè) enable interrupt 例程的修改, 討論了 firmware programmer 可能容易犯的問題, 主要有: (1) 不能熟讀 datasheet, 了解 register 的具體用法. (2) 代碼邏輯混亂. (3) 忽視邊界檢查. (4) 對有符號和無符號數(shù)區(qū)別不夠重視. (5) 不了解左移時(shí)牽涉符號位的特例. (6) 不清楚在條件比較時(shí)強(qiáng)制轉(zhuǎn)換現(xiàn)象. 上述問題, 一般多見于 uController 的初級選手. 作為公司新晉員工, 或者任何致力于 MCU code 實(shí)現(xiàn) application 的新進(jìn)同行們, 可以將上述錯(cuò)誤作為范例保存而自省. 另外, 我們說不定應(yīng)謹(jǐn)慎檢閱各種 Freescale 給出的 kinetis L series 的參考 samples, 反復(fù)測試, 可能避免出貨后造成不可預(yù)料之損失. |
