MTK內(nèi)存、任務管理和定時器消息機制 轉(zhuǎn)

1、MTK內(nèi)存、任務管理和定時器消息機制 轉(zhuǎn)MTK內(nèi)存、任務管理和定時器消息機制(轉(zhuǎn))2010年11月16日15：401內(nèi)存管理。平臺不提供動態(tài)分配內(nèi)存的方式；應用程序需要使用動態(tài)分配內(nèi)存時，可以采用以下幾種方式：與系統(tǒng)其他模塊共享內(nèi)存，典型的是使用MED模塊的內(nèi)存；定義一個靜態(tài)數(shù)組，交給系統(tǒng)adm托管，然后調(diào)用kal_adm_alloc、kal_adm_free等內(nèi)存操作函數(shù)實現(xiàn)動態(tài)內(nèi)存分配；定義一個靜態(tài)數(shù)組，應用自己實現(xiàn)基于此數(shù)組的分配和管理，也就是實現(xiàn)自己的內(nèi)存管理模塊。在MTK的資料中，介紹了它的內(nèi)存管理機制，有3種：ADM、Control buffer、System Memory。后兩個

2、是系統(tǒng)使用的，與上層應用無關。但是我對kal_system_alloc也做了初步分析。sys_mem_ptr,其估計應該指向的是System_Mem_Pool，debug_mem_ptr,其估計應該指向的是debug_Mem_Pool。經(jīng)過初步分析，kal_system_alloc就是從System_Mem_Pool做簡單的加法操作，sys_mem_left_size就是System_Mem_Pool還剩下多少。kal_system_alloc從sys_mem_ptr開始來計算要取的內(nèi)存。ctrl_buf是通過kal_system_alloc的內(nèi)存，然后再通過NU_Create_Partiti

3、on_Pool創(chuàng)建POOL。系統(tǒng)的一些task stack.等也都是通過kal_system_alloc來分配的。也就是說，Control buffer、System Memory用的都是System_Mem_Pool的空間。而System_Mem_Pool可以查到，是在custom_configmem函數(shù)中配置。ADM就完全沒有使用操作系統(tǒng)提供的內(nèi)存管理算法，是平臺自創(chuàng)了一套。開發(fā)者，可以自己開辟一個POOL,自己在這個池用ADM提供的內(nèi)存管理API完成內(nèi)存的動態(tài)管理。具體的分配算法，就沒有再細看，跟一些通用的內(nèi)存分配算法應該一致。但是在以前調(diào)試一個問題的時候，應該是可以斷定，ADM在每一個

4、alloc node前后都加了GAP調(diào)試區(qū)，來判斷是否被overwrite。至于系統(tǒng)中，到底是用了多少塊內(nèi)存用于ADM，各塊內(nèi)存又是讓哪些應用在共享，開發(fā)者可能更清楚。在系統(tǒng)中是否建立了對內(nèi)存動態(tài)分配的監(jiān)控機制，比如查詢內(nèi)存泄漏、動態(tài)內(nèi)存使用效率等等。3少于2K使用get_ctrl_buffer。大于2K使用adm get_ctrl_buffer是在系統(tǒng)定義的一塊區(qū)域申請空間。這段空間被分為好多塊均等大小。好像有以下幾種方式：2個1K*2 4個0.5K*4 6個0.25K*8申請的話，按首適應算法。這就是你所說的小塊內(nèi)存管理。adm主要是你自己定義的一塊全局數(shù)組比如400K.你可以使用它的ad

5、m相關函數(shù)去動態(tài)申請釋放這400K大小的區(qū)域，維護也靠你自己。2.任務管理任務管理。系統(tǒng)任務采用靜態(tài)創(chuàng)建方式，靜態(tài)配置任務優(yōu)先級、棧大小、任務全局唯一ID等；不提供動態(tài)創(chuàng)建Task的方式；任務內(nèi)部以及任務之間的通信通過內(nèi)部事件隊列和外部事件隊列完成Application_Initialize中的mainp函數(shù)，負責任務的創(chuàng)建。我們在代碼中見不到任務創(chuàng)建的函數(shù)，只需要維護任務初始化參數(shù)數(shù)據(jù)結(jié)構(gòu)。對于系統(tǒng)的那些task信息，都保存在sys_comp_config_tbl變量中，我們看不到。但是MTK提供給客戶的custom_comp_config_tbl，客戶是可以修改的，在這里用戶可以定義自己的

6、task。關于任務，需要關心數(shù)據(jù)結(jié)構(gòu)comptask_handler_structcomptask_handler_struct成員的執(zhí)行順序，應該是：comp_init_func在系統(tǒng)還未schedule即在Application_Initialize中完成，然后task schedule后執(zhí)行comp_entry_func。comp_cfg_func、comp_reset_func、comp_end_func我認為無太多意義。MTK6235Custom_config.h中對于添加一個Task如下注釋：Steps to add component task 1.add component t

7、ask's index(Please add before system service)添加Task索引(在系統(tǒng)服務之前)2.add component task's module id definition(Please add before system service)添加Task模塊ID(在系統(tǒng)服務之前)3.add module to task transformation in syscomp_config.c在syscomp_config.c中添加Task轉(zhuǎn)換模塊4.add and implement component task's create han

8、dler添加并實現(xiàn)Task創(chuàng)建句柄另外用戶定義Task不超過16個3.定時器消息機制MTK定時器消息機制分析1.數(shù)據(jù)結(jié)構(gòu)(1).stack_timer_struct定時器類型的信息結(jié)構(gòu)其主要作用似乎是用以裝載待發(fā)送的定時器消息數(shù)據(jù)(2).TIMERTABLE定時器隊列節(jié)點結(jié)構(gòu)其由主要元素mmi_frm_timer_type結(jié)構(gòu)及鏈表指針兩個元素組成(3).event_scheduler隊列信息結(jié)構(gòu)(4).mmi_frm_timer_type定時器信息結(jié)構(gòu)2.L4定時器初始化(1).步驟創(chuàng)建MMI Task-設置MMI Task初始化函數(shù)在該函數(shù)中調(diào)用L4InitTimer(2).作用初始化定時

9、器隊列并設置基本定時器1,2 3.發(fā)送定時器消息(1).步驟StartTimer-L4StartTimer(2).兩種類型的定時器MTK中有兩種類型的定時器a.NO_ALIGNMENT非隊列式的,即要求立即執(zhí)行的定時器,時間到了就自動被reset.b.ALIGNMENT隊列式的,即可以通過隊列操作,有一定的延時容忍的定時器.其基本執(zhí)行流程執(zhí)行定時器超時?-保存timer id,event id-timer stop|no event?-END；c.除了觸摸屏和手寫,其他情況下的定時器一般都是隊列式的.(3).L4StartTimer的作用判斷將要發(fā)送的定時器ID,根據(jù)是否是隊列類型傳遞給不同的

10、隊列結(jié)構(gòu)(event_sheduler1/event_sheduler2)；(4).TimerExpiry這是作為參數(shù)傳遞給L4StartTimer的回調(diào)函數(shù),由于MTK做了一定的封裝,因此其內(nèi)部具體回調(diào)觸發(fā)過程無法得知,但根據(jù)猜測,應該是在定時時間一到,以中斷的方式發(fā)出消息(MSG_ID_TIMER_EXPIRY),并將其寫到MMI的循環(huán)隊列.該函數(shù)可能是在L4CallBackTimer中調(diào)用的,L4CallBackTimer的作用如下a.重置當前定時器信息結(jié)構(gòu)(mmi_frm_timer_type)；b.執(zhí)行定時器到點后的執(zhí)行函數(shù)(TimerExpiry)；c.將Timer消息寫到MMI循環(huán)隊列中.4.與StartTimer對應的StopTimer(1).具體實現(xiàn)通過調(diào)用L4StopTimer操作.(2).作用找出指定要停止的定時器ID在隊列中的位置,然后使用evshed_cancel_even