1、SW FG 算法分析目錄1， Battery架構(gòu)簡析2， MTK 電量算法簡析3， 72/82平臺SW FG算法分析4， 誤差和消除誤差Battery架構(gòu)簡析MTK平臺Battery軟件架構(gòu)基本如上圖所示。具體過程：硬件ADC讀取Battery的各路信息：包括溫度，電壓等。MTK開發(fā)的電量算法分析得到的數(shù)據(jù)。Kernel層將電量信息通過寫文件節(jié)點(diǎn)的方式更新,并通過UEVENT通知上層。上層Service開啟UEVENT LISTENER，監(jiān)聽到UEVENT后，讀取battery相關(guān)文件節(jié)點(diǎn)，獲取電量信息。Service更新數(shù)據(jù)后，通過Broadcast通知所有開啟了相關(guān)listener的act

2、ivities。根據(jù)不同的電量讀取和計算的策略，第一步的讀取和第二步的算法部分會有比較大的差異，而后面的數(shù)據(jù)更新和事件通知部分一致性較高。本篇重點(diǎn)分析72/82平臺SW FG算法實(shí)現(xiàn)，對比SW_FG 和HW_FG在硬件及軟件上的部分差異，分析電量誤差形成的一些原因和MTK已經(jīng)采取的消除誤差的措施。對于Battery數(shù)據(jù)更新和充電流程則粗略分析。 充電狀態(tài)機(jī)，battery充電的邏輯，就依賴于這張圖，如果是用的external charger ic，則應(yīng)當(dāng)參考該IC的充電邏輯。linear charging下 cc轉(zhuǎn) cv，是通過ADC讀取電壓后，軟件切換。而使用charger ic 則很可能是

3、硬件直接切換。這部分的相關(guān)代碼路徑在：alps/mediatek/kernel/drivers/power/linear_charging.calps/mediatek/kernel/drivers/power/switching_charging.ckernel層battery驅(qū)動工作的流程，Bat_thread是工作的重點(diǎn)，通過單獨(dú)的線程依賴10s定時器，更新battery相關(guān)信息。電量算法分析后得到的數(shù)據(jù)也不會直接update，Information Processing還會針對一些特殊情況對顯示電量做調(diào)整，比如0%tracking&100%tracking。除了10s一次的定時

4、器更新，插拔充電器會觸發(fā)中斷，中斷處理時同樣會更新battery數(shù)據(jù)。所有和 電池 充電相關(guān)的數(shù)據(jù)都存儲在power_supply類型的結(jié)構(gòu)體中，這是linux標(biāo)準(zhǔn)的電源子系統(tǒng)體系。MTK電量算法簡析為了得到較為精確的電量數(shù)據(jù)，需要改善測量方式和計算方法，并針對已知誤差采取優(yōu)化手段。一下介紹MTK平臺下采用的一些電量算法。AUX ADC算法：事實(shí)上，所有算法都要依賴ADC讀取電量信息，這邊的AUX ADC算法指只依賴ADC讀值 然后查表讀取電量的算法。這種算法只重構(gòu)了ZCV table，誤差會很大。庫侖積分法：通過開路電壓查表得到初始電量D0，后續(xù)電量通過電流積分累積，通用性強(qiáng),依賴初始電量的

5、精確度。混合型算法:SW FG算法 HW FG算法。事實(shí)上MTK平臺項(xiàng)目通常采用的是混合型算法。 SW FG的參考電路:HW FG的參考電路相同點(diǎn): NTC電阻用于測量溫度 ADC測量各路信號不同點(diǎn): HW FG有單獨(dú)的ADC和20毫歐的電阻 作電流的偵測。HW FG 和SW FG最大差異就是電流的獲取方式。混合算法的流程，HW FG通過FGADC 讀取FG電阻兩端電壓獲得電流， 而SW FG則結(jié)合庫倫算法通過SW方式算得。這部分會詳細(xì)介紹。72/82平臺SW FG算法分析主要分析上圖黃色部分大部分項(xiàng)目都采用混合算法，下面從算法初始化開始介紹下SW FG的算法實(shí)現(xiàn)。battery_meter.

6、c這個C文件 主要負(fù)責(zé)電池電量算法的實(shí)現(xiàn) 向上主要承接battery_common.c 向下調(diào)用battery_meter_hal.c中的接口，以讀取電池的各路信號。=>battery_meter_initial首先看下調(diào)用這個func的timing。顯然 在開機(jī)初始化階段，就會進(jìn)入該函數(shù)，且只會運(yùn)行一次。針對AUXADC SW_FG HW_FG三種不同的電池算法方案 分別初始化，因?yàn)?2平臺采用的SW_FG, 所以接下去先主要分析SW_FG的流程。SW_FG的準(zhǔn)備工作 分為兩步: table_init oam_init先看table_init首先要獲取當(dāng)前的溫度信息=> forc

7、e_get_tbatADC讀值這邊就是MTK為了結(jié)合實(shí)際溫度 獲取較為精確的電池信息 而采取的線性平均值法。原理是利用預(yù)先測得的分布在-10 0 25 50 攝氏度下的ZCV表，結(jié)合真實(shí)溫度，動態(tài)重構(gòu)一張當(dāng)前溫度下的ZCV表格。TEMPERATURE對應(yīng)預(yù)留的空ZCV表格，如下構(gòu)造新表的函數(shù)如下采用線性平均法 填補(bǔ)了有效溫度內(nèi)所有的ZCV對應(yīng)值 但與真實(shí)曲線必然存在一定的誤差。=>oam_init常見的指針函數(shù) 傳參比較有趣 vol_bat這個參數(shù)下傳給底下pmic做count，然后被重新賦值成讀取的v_bat值 之所以能這樣做 是因?yàn)檫@兩塊代碼 同處在kernel層 并地址傳參 bat

8、tery_meter_hal.c 雖然頂著hal的名頭，其實(shí)是驅(qū)動程序，工作在內(nèi)核層，主要實(shí)現(xiàn)上表各結(jié)構(gòu)體 針對MTK不同種的充電方案 讀取各項(xiàng)參數(shù)，包括v_bat temperature v_i_sense 等這邊走pmic這個函數(shù)也是起分流作用的 通過dwchannel，分到不同的處理函數(shù)去。硬件上，ADC通過一個mux 數(shù)據(jù)選擇器 對各路模擬信號進(jìn)行切換 有點(diǎn)類似cpu的時間片和移動通信的時隙切換。 vbat是channel 5， 要等到adc數(shù)據(jù)ready 才能去讀寄存器，看一下pmic的手冊精度15bit的ADC 其中14bit用來存儲數(shù)據(jù) 1個bit做ready信號 ，似乎ADC3

9、 和我們之前的dwchannel number有點(diǎn)對不上？ 可以看到 dwchannel 5 最終訪問的仍是ADC3，另外可以直接比較下寄存器地址。和datasheet左上角的寄存器地址一致最后還要做次數(shù)值轉(zhuǎn)換，公式如下：分辨率計算：測量電壓范圍/(2AD位數(shù)-1)另外，對于同為電壓值的v_bat 和 v_i_sense，可能會出現(xiàn)adc量程不夠的問題 這時候需要通過電阻分壓。 所以case 6 和 7 的r_val_temp為分壓比和前面一樣 ADC讀值 但是6320的spec上對于PCHR沒有說明 從函數(shù)定義的名稱上看 是開路電壓 但是如何在一個閉路的環(huán)境中通過ADC讀取ocv，有些不解。

10、 查了下讀這個值的timing，只有在init suspend 和resume的時候才去獲取.猜想 一是可能 利用linear charging這種充9停1的方式，在第10s讀取電壓 作為OCV 也可能是因?yàn)閯傞_機(jī)時 電流還不大 讀到的電壓值 可用作OCV 總之 這個值應(yīng)該是真實(shí)的開路電壓的一個近似值。=> oam_init根據(jù)電壓讀表獲取電量可以看到 用的是table_init時重構(gòu)的新表Ok 這邊再一次 利用線性平均法 這一次是針對ADC讀到測到的電壓 線性平均后 得到一個較精準(zhǔn)的電量=> oam_init首先判斷是否插著充電器，讀PMU寄存器實(shí)現(xiàn)為什么 需要判斷有沒有插著充電

11、器呢？我是這么理解的，之前通過ADC讀取了兩個電壓值 其中一個是V_BAT 另一個是hw_ocv 是在閉路環(huán)境下讀取的開路電壓近似值， 如果此時插著充電器，會有充電電流通過 這個hw_ocv的值和開路電壓的誤差會增大，因此需要做進(jìn)一步的處理。插入充電器時,電量誤差不大于30 滿電誤差不大于10 否則hw_ocv無效=>oam_init Dod是指用電深度，100-dod = 電池剩余容量看一下 dod_init的實(shí)現(xiàn)ð dod init首先看g_rtc_fg_soc這個變量 MTK的策略是 每隔一段時間將當(dāng)前電量存儲到RTC寄存器中，在開機(jī)時讀取該電量。主要目的是改善用戶體驗(yàn)。

12、看下這個值是何時被寫入的：電池信息 10s update 1次 同樣UI 電量 10s 存入RTC寄存器一次。用7個bit 存儲 電量信息。開機(jī)時直接顯示關(guān)機(jī)時保存的電量，會增強(qiáng)用戶體驗(yàn)性，但是如果是更換電池或其他情況 造成關(guān)機(jī)電量和開機(jī)電量相差過大，顯然應(yīng)該采用開機(jī)電量，否則后續(xù)電池電量跳變反而會影響用戶體驗(yàn)。Normal boot下忽略|后面的條件 主要就是要求沒有插入充電器 不處于低電量 誤差不超過40%經(jīng)過前面所有的判斷 最終得到了gFG_capacity 這個電量，也就是開機(jī)電量 因?yàn)殚_機(jī)電量在整個電量計算中相當(dāng)重要并且又要結(jié)合用戶體驗(yàn) 所以之前會有很多的條件分支。Q_MAX_POS

13、_25 是常溫下電池容量 因?yàn)镕G算法計算電池容量 會用到庫倫積分 所以需要關(guān)注電池容量的問題。這個值需要根據(jù)實(shí)際電池容量客制化。即 25度用標(biāo)準(zhǔn)容量 其他溫度下需要乘上一個比例值。oam_v_ocv_1 和oam_v_ocv_2 現(xiàn)在是根據(jù) dod_init的結(jié)果取得的 大部分情況下就是關(guān)機(jī)電量查表得到的ocv電壓值 而注釋掉的原方案 直接采用hw_ocv的值這邊是算 ocv1 和 ocv2 對應(yīng)的電池內(nèi)阻 r，通過查表的方式獲取 因?yàn)閞和v的對應(yīng)表 也是開路條件下測得 所以用hw_ocv查表獲取的值 比 原先通過vbat 取平均要精準(zhǔn)些。其他一些oam 電量算法 需要的參數(shù)初始化oam_i

14、nit 后, oam_run這個func負(fù)責(zé) 電量的計算，看一下調(diào)用的時機(jī)。=>mt_battery_GetBatteryData顯然也是10s 輪詢一次，get_percentage這個func 多個分支對應(yīng)不同的電量算法=>oam_run先看下MTK SW FG算法的原理圖SW FG的核心 在于 通過兩種方式更新電壓，去逼近真實(shí)開路電壓 最終查表獲取近似真實(shí)的電量值。ocv1 被假定為開路電壓 ocv2則是閉路電壓，以下結(jié)合實(shí)際代碼和上述流程圖分析下SW_FG 算法流程D0 D1 D2 D3 D4 D5 代表不同的放電深度這個算法的思路是這樣的： 最終通過開路電壓oam_v_o

15、cv_1查ZCV表得到當(dāng)前的電量值 -> 開路電壓需要通過閉路電壓v_bat 和 閉路電流oam_i_2 去回溯電池內(nèi)阻 逐次逼近 > oam_i_2 通過 另一種方式 電量積分更新的電壓oam_v_ocv_2總的來說：電壓通過兩種方式更新 電流積分求電量后查表 / 電池內(nèi)阻回溯IR drop求得 電池內(nèi)阻 更新方式只有一種 根據(jù)電壓查表具體分析部分代碼：閉路電壓的更新 不需要算法支持 直接通過讀寄存器實(shí)現(xiàn)，注意vol_bat這個參數(shù)被復(fù)用，下傳表平均次數(shù) 返回時為最終的v_bat電壓值ocv_1 和 ocv_2 分別是兩種方式更新的電壓 這邊通過內(nèi)阻的IR drop求電流.上圖R

16、 可以是電池內(nèi)阻關(guān)鍵是oam_i_2 這邊的I2 有幾個作用：<1>因?yàn)殡娏魇峭ㄟ^上圖的內(nèi)阻IR drop得到的，而方式一內(nèi)阻回溯逼近開路電壓本質(zhì)也是IR drop，如果使用oam_i_1 則沒有意義，只能使用不同體系的I2.<2>方式二 電流積分求電量查表 同樣依賴 oam_i_2 這個體系是累積積分 不需要引用其他體系的參數(shù)<3>I2的方向作為充電還是放電的依據(jù)而oam_i_1只有作用3oam_car_1/oam_car_2 是累積電量 顯然oam_car_2是算法的有效參數(shù)gFG_BATT_CAPACITY_aging 是電池總?cè)萘?之前分析過了 根據(jù)

17、開機(jī)時讀取的電池溫度 會有所不同d2 為積分法算出的電池當(dāng)前容量 d0為開機(jī)電量 不會更新 d1不重要內(nèi)阻回溯 IR drop 逼近開路電壓，具體分析下：主要是這個for循環(huán)，首先通過v_bat去查表得到電池內(nèi)阻r 然后用另一種算法求得的電流I和內(nèi)阻r 算出內(nèi)阻分去的電壓v,推算ocv_1.幾次循環(huán) 反復(fù)這個過程 逼近真實(shí)的開路電壓。有幾個注意點(diǎn)：1,這邊的電壓單位到底是v 還是mv？ 實(shí)際上是0.1mv2，gFG_resistance_bat和R_FG_VALUE 分別是指代 電池內(nèi)阻和硬件FG 使用的FG電阻（一般是20毫歐） 這邊是SW_FG 所以后一項(xiàng)為03,因?yàn)閞et_compens

18、ate是int型變量 做除法時取整處理 會引入較大誤差， 加上這個值使結(jié)果四舍五入實(shí)際做6次內(nèi)阻回溯，這時的電壓值已經(jīng)和開路電壓比較接近，查表得到D3，D3基本就能反映當(dāng)前電量了。MTK在D3的問題上針對電量跳變的情況 又做了步優(yōu)化得到D5,看下代碼這部分代碼比較簡單，1分鐘內(nèi)電量值不會改變，且每分鐘電量的變化不會大于1%，這樣用戶體驗(yàn)會比較好。防止因?yàn)榈碗妷簳r陡峭的電量曲線，以及比較耗電的應(yīng)用，或突然的大電流引起的電量跳變。當(dāng)然特殊應(yīng)用下應(yīng)該取消這個功能，否則會帶來電量變化延時等問題。這邊的返回值將填充BMT_status.SOC ，這個參數(shù)再經(jīng)過優(yōu)化得到BMT_status.UI_SOC就

19、是菜單欄看到的電池電量了。誤差和消除誤差因?yàn)殡娏恐当旧聿蝗菀淄ㄟ^儀器直接測量，只能依賴開路電壓與電量的關(guān)系即電量曲線或者電流積分公式演算，這樣一個過程會有很多產(chǎn)生誤差的點(diǎn)，MTK針對其中一些給出了優(yōu)化方式。另外 由于電池特性 有些時候真實(shí)的電量數(shù)據(jù)反而使得用戶體驗(yàn)下降，這時候還要針對電量數(shù)據(jù)做一些特殊處理，以滿足用戶的預(yù)期。以下是82平臺 SW FG中部分電量誤差產(chǎn)生的原因 以及 MTK用于消除/減小誤差的方法。庫倫積分時的電流:即使是cc狀態(tài)，電流也是有波動的，而進(jìn)入cv狀態(tài)后，電流的變化會更大。因?yàn)檫@樣一個電流變化并無規(guī)律，所以不可能導(dǎo)出電流公式用于電量積分。目前代碼會把每10s 算一次電

20、流作為這10s的平均電流。這樣會形成一個電量累積誤差。MTK的觀點(diǎn): MTK認(rèn)為電流誤差既有正誤差，也有負(fù)誤差，在較長的一段時間內(nèi)認(rèn)為誤差相互抵消。但實(shí)際進(jìn)入恒壓后 誤差應(yīng)該會稍大。電池內(nèi)阻不穩(wěn)定造成的誤差:電池的內(nèi)阻會隨溫度變化，且幅度很大，而在SW FG的算法中依賴電池內(nèi)阻計算電流大小，如果使用固定值的電池內(nèi)阻會嚴(yán)重影響電流的計算。MTK應(yīng)對方案：1，建立zcv tableMTK的zcv table，建立了幾個特定溫度（-10，0，25，50）下的內(nèi)阻r和開路電壓ocv的關(guān)系，這樣可以根據(jù)可量測的電壓信號查表推算內(nèi)阻2，線性平均值MTK在算法初始化時，讀取溫度信息，通過線性平均重構(gòu)zcv table，這樣可以覆蓋從-10到50的所有溫度點(diǎn)。82平臺 MTK電量算法只會在初始化的時候去通過讀取的溫度重構(gòu)zcv table，但假設(shè)使用者周圍的溫度在手機(jī)使用過程中變化比較大，或者電池本身發(fā)熱很厲害，電池內(nèi)阻值有了較大改變，則測出的電量偏差也會比較大。假設(shè)從高溫環(huán)境到低溫環(huán)境，根據(jù)電池特性，電池內(nèi)阻會大幅增大，而電池可使用容量將會下降。實(shí)際耗流假設(shè)變化不大，由于還是用之前的zcv表格，用于計算的內(nèi)阻比實(shí)際內(nèi)阻小很多，則算出來的電流會偏大。這樣顯示電量會快速下降。開機(jī)電壓的誤差:由