發表文章
我們一般車上的儀表版上有幾個重要的儀表，不管科技多進步，只要您是汽油引擎車的，
大部分都會有車速與引擎轉速，畢竟引擎是汽車的動力心臟，引擎轉速最能凸顯
引擎的工作狀態，就像人的心臟一樣，留意引擎轉速就像看心電圖一樣重要。
而在引擎控制上，引擎轉速是重要的控制參數（輸入）但也是控制的結果（輸出）。
有許多在控制計算中都會用到，譬如噴油量、點火角度乃至於怠速控制與傳動系統等。
所以，在引擎轉速的擷取與計算上，就顯得格外重要，但一般人總覺得引擎轉速的計算
很簡單嘛！就依據RPM 的數學定義用十根手指頭算就對了。果真是如此嗎？
那首先我們來看所謂RPM 的定義：
所以我們可以知道RPM 是一種旋轉的頻率單位。
一般在單晶片微控器裡，就是抓一個參考訊號到下一個同樣的參考訊號出現時，
兩者之間的時間間隔...至於，您說如果一個旋轉中有好幾個參考訊號時，
我是不是可以只抓兩個短時間的時間間隔？沒意見，只要您覺得您時間間隔抓取的
時間解析度夠就可以了～（其實，引擎轉速不快，一般常見的還是一轉抓一次的啦！）
單晶片微控器要抓外部參考訊號的時間間隔，當然就是用內部Timer來抓的啦。
這一點就沒什麼好爭議的，您說要用Clock Sampling 方式，那也是Timer 觀念的一種。
那要多少的Timer 的解析度來抓才比較合理呢？...
主要還是要看引擎轉速的操作範圍來決定。沒有說要一定用多少來抓會比較好。
您說要不要用一個比較特殊的數值來抓，來讓後面的數學運算比較簡單？
據我所知：沒有。因為從RPM 的定義來看：他本來就是一個0.0166667非整數的東西。
主要的考慮因素就是最低轉速限制。因為一般單晶片微控器的Timer 都是 16 bits 的。
所以；當您 Timer 發生Overflow 時，大概就是您能處理的最低轉速...
譬如：
您用 6 uSec 為一個單位，您Overflow 值就是 6x65536 = 393.216 mSec ~ 153 RPM。
當然您也會發現：當您用越粗的解析度（就是那個 6uSec） 所得到的誤差就越大。
所以，自己就稍微斟酌自己的應用條件吧。
---------------------------------------------------
好了，基本觀念講完了，但重點問題又來了，因為從上述的分析解說我們可以發現：
一般單晶片微控器的Timer 單位都是 uSec 級的，然後 RPM 的單位是以分鐘為單位。
這兩單位之間差著一個 60 X1000x1000 的單位...所以，在數學運算上就是得用到：
RPM = 60000X1000 / (Timer 之Counter x 基本解析度）,
譬如上述中那個例子 基本解析度為 6 uSec。 其中Timer Counter 為 1~ 65535 。
這下又好了，我們又碰到棘手的數學運算的問題...跟我們之前提到那個自然對數一樣。
該不會又要拿十根手指頭出來算吧？--- 就是直接呼叫一個超長變數外加浮點運算吧。
真是痛苦啊...又不能不算這個工程數值，但又擔心單晶片微控器的運算能力與
程式容量問題，所以，又往往在引擎運作中，幾乎每一個RPM 就得要完成所有的
工程參數的運算，否則會造成一些控制上的參數來不及更新...很氣人的是：
低轉速可以慢慢算，但遇到高轉速時，Timer/Counter就變得越小，然後運算時間又
更有限...這個就是造成引擎控制上的一大挑戰。
但我說過了：以前人家還是用 8 bits 單晶片微控器，跑的又是超慢的操作時頻。
人家可以作得到，那鐵定是有一些"不為人知"的方法可以把小狗養大成『人』的....
不是用我們這一種十根手指頭的思維模式作的，否則，早就一大堆人可以隨隨便便
交差了事了。
-----
好吧，廢話少說：我們就來看一些實驗結果吧：
我們就同時用兩種方法來看結果，一個就是人家那一種"不為人知" 的方法。
另一個就是我們老師教我們的十根手指頭的方法。我們也可以知道：
當一得到RPM 值之後就可以馬上帶入計算所謂的點火提前角(SA, Spark Angel)了。
兩個算RPM的式子都是只要一行就可以了，這當然就是以C 來寫的啦，差別的是：
一個是我們自己寫的"不為人知"之Library ，另一個也是Keil C "不為人知"的Library。
用了Keil C 直接呼叫上式的運算方法，所得到的程式容量為： 5817 Bytes 。
其中 LIB_CODE 為 615H = 1557 Bytes 。
理所當然的！
Keil C 幫我們呼叫了一大堆浮點運算的函數庫。程式會長大不是沒有道理的。
那如果只要用我們自己寫的函數庫呢？...答案是：
程式只剩下 4204 Bytes，外加Keil C 的Library 只有 108H = 264 Bytes 。
而我們要寫的RPM 浮點運算的Library 為 2FH = 47 Bytes....
這兩者之間運算效能應該就不用比了吧！（上方程式有我測試的簡單數據：22uSec)
那我們再來看最後的實驗結果，看這兩種運算方法的差異程度：
首先是一般低轉速，約 1150 轉速，
我們利用UART 把單晶片微控器的計算結果傳出來看結果：
第一行的數據為我們Timer/Counter 的值，第二行為我們自己的浮點運算結果，
第三行為呼叫 Keil C 函數庫的運算結果，在這一個條件下：只差 2 rpm 誤差 : 0.174 %
（您也不能說：誰的答案比較準，因為我們最後都是取成整數值，對於電腦運算來說，
多多少少都會有Truncation Error 的～尤其是用這一種8 Bits 的微處理器！）
接下來是： RPM 約 2810...兩者的誤差為 4 rpm : 0.1423 %
接下來是： RPM 約 3650...兩者的誤差為 6 rpm : 0.1643 %
接下來是： RPM 約 4220...兩者的誤差為 6 rpm : 0.1422 %
我們可以看到誤差都在 1 % 以內。但是我們的程式容量與效能都有很好的表現。
--
這個東西的最主要的觀念不在於是用KeilC 或什麼組譯器。
因為下回您知不知道還有沒有Keil C 這麼好用的組譯器讓您用，
上回就有人要我幫忙作個簡單的帶顯示器的轉速表...拿一棵很便宜的
單晶片微控器給我寫...他的程式容量才 1 KBytes 而已，還要寫LCD 介面程式，
還要有外接EEPROM，您說：如果要我們用那一種呼叫函數庫的作法，
那肯定一定把有限的程式容量寫爆的～沒有人說：程式不可以用大函數庫作，
但是：您能把函數庫寫得更小、更有效能...應該沒有人更反對的吧。
您看現在最夯的Apple iPad ...他的硬體規格很簡單，卻可以做到操作介面很流暢，
所以，人家告訴您說：要寫程式的觀念是不但要想辦法精簡對硬體規格的依賴，
而且還要達到一定的效能...
大家如果寫過程式，維護過程式的話，一定很清楚，不是把程式寫得很大，
就比較會有成就感...那是代表您的程式很難維護，而且也容易出問題...
就是人家所說的：多寫多錯...當您要Debug 您的程式時，根本無從下手。
所以，我才說：您能把函數庫寫得更小、更有效能...應該沒有人會反對的吧。
-----
RPM 轉速的計算不一定只用在引擎轉速的計算，在工程上也常常會用到...
以前我在作那個多核心微控器時，我也有寫過一個無刷馬達的展示程式，
他也有用這一個RPM 計算的演算法...那時還是用組合語言寫的。
所以我說：這些在工程上會常用也常碰到的數學計算的函數庫，
還是要花一點時間研究，然後您就可以隨時移植到任何一種單晶片微控器上了。
至於那一些什麼USB 或是標準界面的東西，只要按規格照本宣科的就隨時可以
上手了...會的人多，也不會差您一個人去學啊...是不是？
----
後記：其實，因為最近有人一直跟我說：國內有些公司所開發的數位點火控制器，
在操作上總覺得他的點火進角不是很穩的感覺，也不是很流暢...
我是不知道他們這些公司的數位點火控制器是哪一種單晶片微控器作的？
但我肯定應該不會是那一種 16 bits 甚至 32 bits 的微控器...
我想應該沒有人會反對您要用一般的8 bits 微控器，但如果您要用一般的 8 bits
微控器的話，那就不好意思，您寫程式尤其是數學方法的實現能力是鐵定被要求
一定要比人家好...否則，您想得到的十根手指頭的算法，別人也知道啊...
誠如上面所推演的數學方法與函數庫的...
當然您可以不必去用這些冗長的函數庫，但是您所得到的數學解析度與
我們常在數值分析上所說的Truncation Error ...所產生的偏差是您工程上所能忍受的嗎？
如果還要再加上我上回提到那個A/D 的一階濾波函數...那在引擎控制裡還有一大堆
內差公式...還有一堆數學運算，那一般的單晶片微控器哪受得了啊？
我們在學校那麼努力的上課與考試，而世界上或歷史上有那麼多數學家，
他們這麼努力的在學術研究與鑽研數學方法...難道只是要拿來考學生的成績而已嗎？
人類的科技發展都已經到達一定的境界了，那我們為什麼還要用遠古時代那個
十根手指頭的代數方法來加減乘除來算艱深的工程問題呢？...那我們所追求的
科技進步的目的在哪？...那當然人家找您寫程式也都不覺得您有什麼特別的價值。
因為人家再找一個會加減乘除，然後只要訓練他會所謂的 C 語言語法的工程師
就好了。...您沒有成就感，當然也沒有信心與存在嚴重的職業危機感啊...
或許，這一個簡單的例子也可以讓您有所警覺吧。....
---------------------------
沒有留言:
張貼留言