MTK驅(qū)動(dòng)架構(gòu)分析及驅(qū)動(dòng)調(diào)試指引_第1頁
MTK驅(qū)動(dòng)架構(gòu)分析及驅(qū)動(dòng)調(diào)試指引_第2頁
MTK驅(qū)動(dòng)架構(gòu)分析及驅(qū)動(dòng)調(diào)試指引_第3頁
MTK驅(qū)動(dòng)架構(gòu)分析及驅(qū)動(dòng)調(diào)試指引_第4頁
MTK驅(qū)動(dòng)架構(gòu)分析及驅(qū)動(dòng)調(diào)試指引_第5頁
已閱讀5頁,還剩79頁未讀 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請(qǐng)進(jìn)行舉報(bào)或認(rèn)領(lǐng)

文檔簡(jiǎn)介

MTK驅(qū)動(dòng)架構(gòu)分析及驅(qū)動(dòng)調(diào)試指引張雷2006.9版本歷史2005-9 張雷2005-11 張雷2006-9 張雷內(nèi)容介紹MTK驅(qū)動(dòng)程序架構(gòu)分析Mediatask與Camera程序分析UEMtask與中斷處理流程LCD及背光程序分析MTK驅(qū)動(dòng)程序調(diào)試Camera實(shí)現(xiàn)方案及驅(qū)動(dòng)調(diào)試介紹LCD及背光方案及調(diào)試介紹一、MTK驅(qū)動(dòng)程序架構(gòu)分析一、MTK驅(qū)動(dòng)程序架構(gòu)分析

1.1Mediatask與Camera程序分析1.2UEMtask與中斷處理流程1.3LCD及背光程序分析Camera程序架構(gòu)Camera程序相關(guān)模塊MMItaskCameraAPP:控制應(yīng)用程序邏輯MDI:應(yīng)用程序接口層,直接操作CamerafeatureGDI:處理Multi-layer,實(shí)現(xiàn)OSD

Mediatask調(diào)用Camera驅(qū)動(dòng)程序的接口層CameraDriver控制CameraBackendIC,Sensor以及LCD硬件LCDinterface控制LCMCameraMMI程序分析(1/3)CameraMMI層實(shí)現(xiàn)Camera的應(yīng)用程序的邏輯,控制Camera的各種狀態(tài)。應(yīng)用程序?qū)崿F(xiàn)了Camera的狀態(tài)機(jī),包括了preview,capture,save

confirm,save

down,cout

down,exit等各種狀態(tài)控制。繪制Camera的OSD層實(shí)現(xiàn)連拍、延遲拍攝等功能實(shí)現(xiàn)對(duì)音頻,LED,LCD的邏輯控制CameraMMI程序分析(2/3)CameraMMI程序分析(3/3)CameraMMI僅控制應(yīng)用邏輯,而避免去涉及照相機(jī)驅(qū)動(dòng)的細(xì)節(jié)。比如說進(jìn)入preview過程,CameraMMI僅僅是向MDI接口模塊發(fā)送一個(gè)Preview的請(qǐng)求,并將自己的數(shù)據(jù)結(jié)構(gòu)傳給MDI層,再由MDI層向Mediatask層發(fā)送請(qǐng)求,并最終調(diào)用到驅(qū)動(dòng)程序來控制芯片實(shí)現(xiàn)preview。MMI不關(guān)心不同的芯片如何去進(jìn)入preview。OSD是通過GDI層來繪制的,因?yàn)镚DI支持最大4層的圖像疊加(6228平臺(tái)可支持6層GDI)MDI簡(jiǎn)介MDI模塊是MediaDeviceInterface的縮寫。MDI模塊為多媒體MMI層提供一整套API,使得應(yīng)用程序編程更加簡(jiǎn)單。MDI層位于MMI層與Mediatask之間,MDI對(duì)MMI屏蔽了與Mediatask通信的細(xì)節(jié),以及多媒體狀態(tài)信息。MDICamera模塊是MDI中的一部分。CameraMDI分析(1/3)CameraMDI提供Camera相關(guān)的API,它有以下幾個(gè)主要的作用:提供簡(jiǎn)單易用的Camera接口負(fù)責(zé)從MMItask向MediaTask發(fā)送并處理消息,并通過一些事件處理MMI與Mediatask的同步關(guān)系。負(fù)責(zé)過濾和轉(zhuǎn)換從Cameraapp到MediaTask的數(shù)據(jù)CameraMDI分析(2/3)MDI在處理了APP的數(shù)據(jù)以后最終要和MediaTask進(jìn)行通信,它通過cam_send_XXX_req()函數(shù)向MediaTask線程發(fā)一條消息,并將MMItask線程阻塞,在收到MediaTask線程的相應(yīng)以后,再將MMItask恢復(fù)到就緒狀態(tài)。阻塞MMI的命令是CAM_WAIT_EVENT(XXX),當(dāng)Mediatask調(diào)用CAM_SET_EVENT(XXX)時(shí),恢復(fù)MMI線程。CameraMDI分析(3/3)MMI程序通過MDI層對(duì)底層的調(diào)用關(guān)系:

mmi_camera_preview_start(MMI邏輯控制)

mdi_camera_preview_start(數(shù)據(jù)轉(zhuǎn)換)

mdi_camera_preview_start_internal(數(shù)據(jù)打包,OSD層繪制,設(shè)置當(dāng)前LCD的ID)

media_cam_preview(發(fā)消息,阻塞MMI線程)

cam_send_preview_req(消息排隊(duì))

med_task_main(檢查消息)

med_maincam_main(識(shí)別消息)

cam_preview_req_hdlr(消息處理,控制驅(qū)動(dòng)程序)GDI簡(jiǎn)介(GraphicsDeviceInterface)MTK的畫圖功能有兩套體系,一套是pixtel的體系,另一套是GDI。Pixtel的體系比較老,它最開始是用來處理單層圖像的簡(jiǎn)單接口,pixtel體系也是基于GDI基礎(chǔ)上封裝出來的。而GDI體系由于有硬件的支持,它可以處理最多4個(gè)層數(shù)據(jù)的疊加,有很強(qiáng)的表現(xiàn)能力。硬件支持有:DMA的傳輸,圖片硬件解碼,以及2D加速器等。GDI應(yīng)用大部分的菜單使用Pixtel_UI來繪制,因?yàn)闆]有必要使用復(fù)雜的GDICamera程序需要使用GDI來實(shí)現(xiàn),因?yàn)樽畛醯腷ackendIC并不是很強(qiáng)大,很多都不能支持多層OSD,這時(shí)就不能在Preview區(qū)域以內(nèi)疊加ICON(象框除外)。這時(shí)需要GDI來實(shí)現(xiàn)多層疊加,事實(shí)上在19以后的平臺(tái),MTK的拍照部分是完全依賴GDI來實(shí)現(xiàn)多層疊加的除Camera以外,Idlescreen和MediaPlayer等也使用GDI,對(duì)基于05C軟件體系的新軟件,在MMI的體系尚做了大的變革,GDI的作用更大GDI和pixtel_UI的關(guān)系GDI使用簡(jiǎn)介使用GDI_HANDLE,gdi_handle來操作GDI對(duì)象,GDI的對(duì)象可以是layer,gif,jpeg等。GDI函數(shù)返回一個(gè)GDI_RESULTGDI函數(shù)使用互斥來保護(hù),進(jìn)入GDI函數(shù)時(shí)調(diào)用GDI_ENTER_CRITICAL_SECTION()退出函數(shù)時(shí)調(diào)用GDI_EXIT_CRITICAL_SECTION()MediaTask簡(jiǎn)介MediaTask模塊分成4個(gè)部分:CameraAudioImageVideoMediaTask分析(1/3)MediaTask模塊有以下的作用:管理硬件資源(camera,audio,ect.),為上層程序提供方便和統(tǒng)一的接口。使用一個(gè)單獨(dú)的線程,能更好的處理實(shí)時(shí)性很強(qiáng)的任務(wù),如Camera,Audio,jpegdecoder,并且各個(gè)模塊之間共享內(nèi)存資源,提高了內(nèi)存使用效率。MediaTask封裝了硬件驅(qū)動(dòng)程序的API,其他線程通過消息調(diào)用各種功能MediaTask功能很強(qiáng),管理方便,但它并不是完美的體系,比如在Mp3背景播放時(shí)不能同時(shí)使用照相機(jī)功能,這是由于將Mp3和Camera用同一個(gè)task管理所必然引起的。MediaTask分析(2/3)MediaTask線程從med_create開始創(chuàng)建,其實(shí)med_create函數(shù)只是將入口地址傳遞給庫里的函數(shù),由里面的函數(shù)來創(chuàng)建線程。Med_create中傳入了以下的函數(shù):

med_task_main, /*線程入口,消息泵*/

med_init, /*初始化,指定空間分配*/NULL, /*線程配置*/

med_reset, /*重設(shè)*/NULL, /*線程結(jié)束*/MediaTask分析(3/3)med_task_main函數(shù)是MediaTask的消息泵。這里是一個(gè)無限循環(huán),不停從消息隊(duì)列中獲取消息分發(fā)消息。從消息隊(duì)列中獲取消息,通過receive_msg_ext_q函數(shù)來實(shí)現(xiàn)設(shè)置當(dāng)前活動(dòng)模塊,通過stack_set_active_module_id分發(fā)消息,通過消息號(hào),找到對(duì)應(yīng)的消息處理函數(shù),使用med_main函數(shù)。程序里面有很大的一個(gè)消息索引釋放返回消息數(shù)據(jù)內(nèi)存區(qū)域,free_ilmMediaTask

Camera(1/4)MediataskCamera部分可以分為兩層:上層為Msghandler負(fù)責(zé)處理Mediatask消息,并和MDI層共同維護(hù)一個(gè)Camera的狀態(tài)機(jī)。下層為驅(qū)動(dòng)程序封裝層,這層按驅(qū)動(dòng)程序的接口一一對(duì)應(yīng)封裝程序。MediaTask

Camera(2/4)MediaTask

Camera(3/4)在Mediatask上層,實(shí)際上對(duì)Camera硬件邏輯進(jìn)行了判斷,并和上層是交互的。Msghandler對(duì)各種邏輯的判斷,并不涉及太多硬件操作細(xì)節(jié),更多的是對(duì)消息邏輯的控制,在一定時(shí)間沒有驅(qū)動(dòng)程序響應(yīng),或者Powercheck失敗等情況,就返回并通過SetEvent來釋放被阻塞的MMI線程。MediaTask

Camera(4/4)MediaTaskCamera主要有兩個(gè)部分,前面所講的是Cam_msg_handler.c部分。在下層是Ext_camera.c文件。雖然都屬于MediaTask模塊,但實(shí)現(xiàn)的職責(zé)并不相同:Cam_msg_handler.c主要負(fù)責(zé)處理和控制消息Ext_camera.c文件則主要是封裝驅(qū)動(dòng)程序,并負(fù)責(zé)控制LCD和Camera狀態(tài)的邏輯。此文件里的函數(shù)基本上和Cam_module.c驅(qū)動(dòng)文件里的函數(shù)一一對(duì)應(yīng),它抽取出了每個(gè)函數(shù)的一些共性的東西(主要是對(duì)芯片狀態(tài)的控制和對(duì)LCD的控制),使得在對(duì)Cam_module.c編程的時(shí)候僅需要考慮和backendIC硬件相關(guān)的東西。Camera驅(qū)動(dòng)封裝方法Ext_camera.c模塊下層是Cam_module.c模塊,Cam_module.c是按照一個(gè)模板規(guī)則編寫的驅(qū)動(dòng)程序?qū)崿F(xiàn)文件:這里使用全局函數(shù)結(jié)構(gòu)體ext_cam_module_func,來共享驅(qū)動(dòng)函數(shù)的指針。ext_camera.c可以從ext_cam_module_func類型的全局變量中得到驅(qū)動(dòng)函數(shù)指針,并調(diào)用相關(guān)函數(shù)這樣做是為了方便配置管理,驅(qū)動(dòng)程序可以使用不同的函數(shù)名稱,可以配置在不同的目錄,只要符合ext_cam_module_func模板的規(guī)則即可驅(qū)動(dòng)函數(shù)封裝解析(1/2)驅(qū)動(dòng)函數(shù)封裝解析(2/2)MediaTaskCamera總結(jié)總結(jié)MediaTaskCamera的主要作用:封裝了Camera驅(qū)動(dòng)程序控制了消息循環(huán)進(jìn)行出錯(cuò)判斷,控制一些超時(shí)等待以及硬件錯(cuò)誤的處理邏輯med_global.h中可以簡(jiǎn)單配置MediaTask的一些參數(shù)MediaTask總結(jié)總結(jié)充分了解MediaTask的作用和工作流程以后,就可以理順從Camera應(yīng)用程序到底層程序的整個(gè)流程和邏輯,無論是應(yīng)用程序還是驅(qū)動(dòng)程序編程都會(huì)變得非常的輕松。MediaTask是可擴(kuò)展可更改的,所有的代碼都是開放的,我們也可以訂制一些自己的東西。比如在200萬像素拍照時(shí)出現(xiàn)了內(nèi)存不足問題,我們就修改了對(duì)文件的操作方法。一、MTK驅(qū)動(dòng)程序架構(gòu)分析 1.1Mediatask與Camera程序分析1.2UEMtask與中斷處理流程1.3LCD及背光程序分析UEMtaskUEM(UserEquipmentManager)用戶設(shè)備管理模塊,管理Keypad、GPIO、RTC、USB及耳機(jī)等基本的用戶設(shè)備。UEM層是位于設(shè)備Driver層與L4C層之間的中間層。UEM的下行消息一般是MMI對(duì)設(shè)備的請(qǐng)求,UEM的上行消息,一般是由設(shè)備中斷發(fā)起。UEMOverviewUEMtask簡(jiǎn)介UEMtask和普通task的創(chuàng)建流程是一樣的,關(guān)于task的創(chuàng)建在《MTK軟件架構(gòu)分析》課程中已經(jīng)講過。uem_main.c文件中的uem_main函數(shù)是uem_task消息分發(fā)的地方,處理所有的消息。Uemtask中直接調(diào)用與中斷協(xié)議棧相關(guān)的函數(shù),并且直接操作芯片地址空間UEM與中斷處理流程分析(1/6)下面以CLAM中斷為例來講UEMtask與中斷(示例代碼為T05A_V31)中斷的注冊(cè)UEM與中斷處理流程分析(2/6)中斷服務(wù)例程UEM與中斷處理流程分析(3/6)消息處理UEM與中斷處理流程分析(4/6)L4c的相應(yīng)函數(shù)UEM與中斷處理流程分析(5/6)MMItask的處理函數(shù)UEM與中斷處理流程分析(6/6)GpioDetectInd函數(shù)一、MTK驅(qū)動(dòng)程序架構(gòu)分析 1.1Mediatask與Camera程序分析1.2UEMtask與中斷處理流程1.3LCD及背光程序分析LCD及背光程序分析LCD和背光程序是都是程序中最基本的模塊,它們是相互獨(dú)立的模塊:LCD相關(guān)的主要是LCDIF模塊(lcd_if.c),它直接控制LCD顯示,它可能被GDI及Meditatask調(diào)用背光相關(guān)模塊有GeneralDeviceInterface.c文件,是MMI中控制背光的程序。另外,custom_equipment.c文件,是在uemtask中直接操作背光芯片的模塊LCDIF介紹LCDIF模塊是LCD的重要模塊,它位于GDI與LCDdriver之間LCDdriver模塊控制LCD芯片,而LCDIF控制MTK芯片的LCDinterface硬件模塊LCDIF并不是使用單獨(dú)的task,LCDIF直接被GDI和Mediatask調(diào)用。這里存在的問題是Mediatask和MMI可以同時(shí)控制LCD顯示LCDIF圖解LCD接口程序模塊是一個(gè)中間層,它在整個(gè)軟件架構(gòu)中的位置是:MMIGDI/GUILCDIFLCDLCDDriverLCD驅(qū)動(dòng)的封裝方法同Camera程序,封裝的函數(shù)中,有以下幾個(gè)關(guān)鍵函數(shù):LCDinitial:開機(jī)時(shí)初始化LCDLCDentersleep:使LCD進(jìn)入休眠狀態(tài)LCDExitsleep:使LCD從休眠狀態(tài)進(jìn)入Standby狀態(tài)LCDBlockwrite:控制LCD顯示一幀畫面二、MTK驅(qū)動(dòng)程序調(diào)試二、MTK驅(qū)動(dòng)程序調(diào)試

2.1Camera實(shí)現(xiàn)方案及驅(qū)動(dòng)調(diào)試介紹2.2LCD及背光方案及調(diào)試介紹Camera硬件架構(gòu)Camera模塊硬件在手機(jī)上的基本架構(gòu)有三種:Baseband控制LCD+Sensor,Baseband對(duì)圖像進(jìn)行硬件或軟件的jpeg編解碼(如6219)。Baseband控制LCD+Backend

IC,BackendIC只控制Sensor。這時(shí)BackendIC的處理能力會(huì)相對(duì)較弱,硬件結(jié)構(gòu)也比較簡(jiǎn)單(如PAP1301)。Baseband控制BackendIC,并且在非Camera模式下Baseband控制LCD,在Camera模式下BackendIC控制LCD進(jìn)行各種操作。目前的大部分backendIC都是這樣的硬件架構(gòu)(如CL71x和VC05xx系列)。Camera硬件架構(gòu)架構(gòu)1(MT6219)MT6219LCMBasebandSensorCamera硬件架構(gòu)架構(gòu)2(PAP1301)MT6218BPAP1301LCMBasebandCameraBackendSensorCamera硬件架構(gòu)架構(gòu)3(CL712S8)MT6218BCL712S8

(CoreLogic)LCMBasebandCameraBackendSensorCamera硬件架構(gòu)我們這里主要討論的是架構(gòu)3,拍照性能指標(biāo)主要有:1、預(yù)覽幀率,這主要由Sensor采集到的原始數(shù)據(jù)傳輸?shù)紹ackendIC的速率決定2、拍照速率,主要由BackendIC中JPEGCodec模塊編碼的速度決定3、照片大小,主要內(nèi)部的RAM空間大小,及Codec編解碼能力預(yù)覽楨率分析(1/3)分析瓶頸1,先了解Sensor的工作原理:Sensor可提供若干Size的預(yù)覽模式,如OV9650是1.3MSensor,它提供兩種Preview的模式:VGA和SXGA。兩者在Preview時(shí)的數(shù)據(jù)量相差大約有4倍。如果不考慮BackendIC因素和LCD的刷新速度,Preview的幀率將相差4倍之多。BackendIC接收yuv信號(hào)后,轉(zhuǎn)換成RGBbitmap,并做Resize,截取其中的部分或全部數(shù)據(jù)后,再進(jìn)行圖像壓縮(壓縮成LCD大小preview),然后送LCD顯示。MClock將直接影響數(shù)據(jù)傳輸速度。預(yù)覽楨率分析(2/3)影響預(yù)覽楨率瓶頸的兩個(gè)Sensor因素:預(yù)覽的Size,size越小楨率越高M(jìn)Clock的頻率,頻率值越大,楨率越高除了Sensor端的因素,還有其他一些因素影響著預(yù)覽楨率:LCD的最大刷新速率BackendIC的處理速度硬件方案的架構(gòu)預(yù)覽楨率分析(3/3)預(yù)覽楨率與拍照速率之間的取舍,也是影響預(yù)覽楨率的主要因素:低像素預(yù)覽進(jìn)行拍照時(shí),需要切換到高像素模式,這需要消耗時(shí)間。高像素預(yù)覽,不需要切換Sensor尺寸,拍照速率快,但預(yù)覽速率很難提高。一般來說,Sensor工作模式的切換,需要較長(zhǎng)時(shí)間。如OV9650在從VGA模式到SXGA模式的切換,需0.5~1秒的等待Sensor重新穩(wěn)定(調(diào)節(jié)WB和EV等)。如果Sensor需要重新上電,則需要更長(zhǎng)時(shí)間。拍照速率分析(1/1)影響拍照速率主要有以下幾個(gè)因素:backendIC內(nèi)部Codec的壓縮速率,這是影響拍照速率的直接因素拍照時(shí)的圖像截取方案,如是否切換Sensor尺寸,這是影響拍照速率的重要因素此外,拍照照片使用何種方式提取,是DMA方式還是普通方式,將照片從RAM直接轉(zhuǎn)存到nandflash還是,使用內(nèi)存緩沖,等也會(huì)影響拍照速率照片大小分析(1/1)相機(jī)支持相片大小,也是相機(jī)性能的重要指標(biāo)。但它不是由驅(qū)動(dòng)程序或外圍電路方案決定,而是由芯片本身確定,主要是以下兩個(gè)因素:BackendIC的jpeg編碼能力芯片內(nèi)部的RAM大小相機(jī)案例分析1(1/1)預(yù)覽楨率與拍照速率的取舍問題,在M910的上,我們?nèi)∨恼账俾?,采用SXGA預(yù)覽模式。確定這樣的方案是由整體硬件性能決定的:LCD選用的是CSTN屏,屏的刷新幀率最大只能達(dá)到10幀/s。預(yù)覽高幀率是沒有意義的。使用26MHz的較高頻率時(shí)鐘來驅(qū)動(dòng)Sensor,SXGA模式下預(yù)覽的幀率為7.2幀/秒。這和10幀/秒預(yù)覽,在CSTN屏上沒有明顯差別。采用SXGA模式預(yù)覽,拍照時(shí)無需進(jìn)行模式切換,拍照時(shí)可以直接壓縮當(dāng)前預(yù)覽幀的圖像數(shù)據(jù),拍照速率高。相機(jī)案例分析2(1/2)一個(gè)普遍存在的問題,拍照時(shí)“所見非所得”,即拍照所得的圖片并非按下快門時(shí)看到的那張圖片。品質(zhì)部將其描述為,拍照過程中將手機(jī)從A處移動(dòng)到B處,拍到了B處的景物,并將B處的景物回顯出來以上的現(xiàn)象是由于拍照時(shí),相機(jī)模式切換引起的。如案例1的情況,我們使用VGA預(yù)覽,拍SXGA大小的圖片,模式切換需要0.5~1秒時(shí)間,其間丟掉了若干預(yù)覽楨,重新預(yù)覽后,還需要等待Sensor的EV,WB等穩(wěn)定,又必須要丟掉若干楨,所以導(dǎo)致了用戶移動(dòng)時(shí),無法捕捉到按下快門的當(dāng)前楨照片。相機(jī)案例分析2(2/2)關(guān)于拍照回顯的問題,這里簡(jiǎn)要分析一下MTK的拍照回顯過程:拍照時(shí)定格的圖片為預(yù)覽的最后一楨回顯的圖片為拍照最終存儲(chǔ)的圖片函數(shù)調(diào)用的過程:按下Capture鍵調(diào)用驅(qū)動(dòng)層,送Capture命令芯片對(duì)RGB數(shù)據(jù)進(jìn)行硬件編解碼,并將數(shù)據(jù)存放在內(nèi)部的RAM中MediaTask層申請(qǐng)一個(gè)buffer來從backend的RAM拷貝數(shù)據(jù)將拷貝到的數(shù)據(jù)送到GDI基帶芯片對(duì)JPEG照片解碼,并送到Layer2層GDI將提示信息(OSD)疊加,并送LCD_ifLCD刷屏,回顯拍到的照片相機(jī)驅(qū)動(dòng)方式Camera驅(qū)動(dòng)采用查詢方式實(shí)現(xiàn),通過查詢CL712S8的狀態(tài)寄存器來判斷相機(jī)狀態(tài)。查詢方式的好處是,程序的模塊化較好,編程簡(jiǎn)單,容易實(shí)現(xiàn),不容易出錯(cuò)。缺點(diǎn)是不夠靈活。采用中斷方式實(shí)現(xiàn)驅(qū)動(dòng),需要修改相應(yīng)中斷引腳的中斷服務(wù)程序。對(duì)非AP類型的芯片,并不是必須使用中斷方式。相機(jī)驅(qū)動(dòng)porting(1/3)Porting指配置各種的參數(shù)和IO口,使芯片能在相應(yīng)的基帶系統(tǒng)中運(yùn)行。Porting過程就是Bypass調(diào)試的過程。Porting過程以硬件調(diào)試手段為主,軟件為輔調(diào)試手段包括:測(cè)量總線數(shù)據(jù)信號(hào)及讀寫時(shí)序測(cè)量時(shí)鐘及電源信號(hào)的狀況及信號(hào)穩(wěn)定程度Reset線的信號(hào)質(zhì)量及Reset是否成功仔細(xì)研究芯片資料及硬件電路原理圖,各個(gè)功能引腳通過Trace確定程序執(zhí)行的路徑是必須的針對(duì)問題,編寫測(cè)試程序是很有效的手段相機(jī)驅(qū)動(dòng)porting(2/3)調(diào)Bypass主要是調(diào)試基帶芯片到backendIC芯片之間的硬件通路,需要檢查的模塊包括:MHold引腳控制總線地址的確認(rèn)及總線時(shí)序配置MClock時(shí)鐘確認(rèn)芯片內(nèi)部偏移地址計(jì)算LCD驅(qū)動(dòng)程序調(diào)試硬件電路確認(rèn),包括原理確認(rèn)、供電、接地等信號(hào)確認(rèn)相機(jī)驅(qū)動(dòng)porting(3/3)MClcok及電源狀況的確定,可以保證芯片正常的運(yùn)行MHold引腳控制引腳要拉高,切換芯片的bypass狀態(tài)總線地址、總線時(shí)序及芯片內(nèi)偏移地址必須配置,才能對(duì)芯片進(jìn)行指令讀寫LCD驅(qū)動(dòng)調(diào)試通過,就可以確認(rèn)bypass模式正常Bypass調(diào)試過程中,芯片的狀態(tài)無法查詢,所以調(diào)試過程基本以量測(cè)信號(hào)為主Preview調(diào)試分析(1/2)Preview的調(diào)試,主要是調(diào)試從backendIC到Sensor端及backendIC到LCD端的硬件通路及驅(qū)動(dòng)模塊:Sensor部分需要調(diào)試內(nèi)容包括IIC總線的讀寫,Sensor信號(hào)和backendIC的同步等問題LCD部分主要是對(duì)BackendIC的LCD控制模塊編程,使得BackendIC可以自由控制LCD刷屏Preview調(diào)試分析(2/2)調(diào)試經(jīng)驗(yàn):調(diào)試的順序應(yīng)該是先調(diào)試拍照功能,再調(diào)試預(yù)覽刷屏,因?yàn)榕恼展δ?,僅需要Sensor模塊正常即可。BackendIC芯片中寄存器的狀態(tài)應(yīng)該隨時(shí)獲取,可以通過trace語句得到。調(diào)刷屏?xí)r,沒有辦法獲得系統(tǒng)運(yùn)行狀態(tài),要給LCD讀寫時(shí)序設(shè)置時(shí)給最保險(xiǎn)的值。二、MTK驅(qū)動(dòng)程序調(diào)試

2.1Camera實(shí)現(xiàn)方案及驅(qū)動(dòng)調(diào)試介紹2.2LCD及背光方案及調(diào)試介紹LCDInterface(1/3)LCDInterface模塊是MTK

LCD驅(qū)動(dòng)方案的一個(gè)重要部分,它對(duì)LCD功能有一定的擴(kuò)展及一些限制,超過LCDInterface模塊處理能力的LCD器件是不能正常使用的LCD接口部分定義了一系列的寄存器,這些寄存器幫助實(shí)現(xiàn)LCD的中斷、Muti-Layer、DMA傳輸控制等。LCDInterface(2/3)6217的LCD接口模塊的一些基本參數(shù):支持最大320*240的分辨率支持8位、12位、16位、18位、24位色4層結(jié)構(gòu),并且每層都有自己的大小、偏移、旋轉(zhuǎn)度數(shù)等參量。LCDInterface(3/3)LCD驅(qū)動(dòng)程序分析(1/4)LCD驅(qū)動(dòng)程序包括lcd.c、lcd_sw.h、lcd_sw_rnd.h

、Lcd_sw_inc.h和lcd_hw.h五個(gè)文件:Lcd.c里面定義驅(qū)動(dòng)程序的函數(shù)接口,被Lcd_if.c文件直接調(diào)用。這里只定義了一個(gè)全局變量MainLCD,它是一個(gè)函數(shù)結(jié)構(gòu)體變量,結(jié)構(gòu)體里包含所有LCD驅(qū)動(dòng)函數(shù)的指針。Lcd_sw.h文件定義了總線地址、數(shù)據(jù)讀寫方式、DMA開關(guān)及讀寫語句、和Lcd.c和Lcd_if.c文件關(guān)聯(lián)。這個(gè)文件里相關(guān)參量的配置非常重要。Lcd_sw_inc.h定義LCD的長(zhǎng)和寬。Lcd_sw_rnd.h定義了顏色轉(zhuǎn)換接口,定義了一些宏,將MMI層的顏色轉(zhuǎn)換成LCD可以顯示的顏色值。被GDI/GUI的接口層關(guān)聯(lián)。LCD驅(qū)動(dòng)程序分析(2/4)LCD驅(qū)動(dòng)程序并不復(fù)雜,主要由以下幾個(gè)關(guān)鍵的函數(shù)組成:LCDinitial:開機(jī)時(shí)初始化LCDLCDentersleep:使LCD進(jìn)入休眠狀態(tài)LCDExitsleep:使

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請(qǐng)下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請(qǐng)聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會(huì)有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲(chǔ)空間,僅對(duì)用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對(duì)用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對(duì)任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請(qǐng)與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對(duì)自己和他人造成任何形式的傷害或損失。

評(píng)論

0/150

提交評(píng)論