ATMEL mXT224電容觸控螢幕調試筆記

看了4天的datasheet，昨天終於開始寫代碼了。到目前為止，我做過的電容屏有 ite的，solomon的，focaltech的，eeti的，還有cypress的。說實話，寫這些東西的驅動已是輕車熟路了，但是我今天還是有感而發！ATMEL的電容屏做的是最好的。針對驅動人員的介面做的非常完美，甚至用了物件導向的思想！做atmel的驅動真的是一種享受啊。這時你能體驗到做一個驅動工程師的樂趣了！

接手這個工作源於我們公司被一個山寨手機公司給兼了。。。說是合并，其實說奸了也不為過。因為現在那個手機公司的老闆說了算。曾經公司給我們的 一些承諾以及福利待遇，自這個山寨公司接手後都一一化為泡影。。。從此我們原班的這些人馬就像一個個淪落青樓女子。。。。誰想上就上。。。。

光上上也就罷了。。。誰讓咱命苦呢。。。可是上你，也不讓你有高潮！，整個一個他上著你，還讓你痛苦著。。。

本來是個IC設計公司，，可是現在卻要接手一個手機方案的爛攤子。說是兩個月後就要上市，說是遇到一些難題解決不了讓我們給做。

上周給了我們資料讓我做電容屏。

拿到手機後一看，我靠！電容屏報點整個都是位移的，座標都和LCD對不準，兩指觸摸時竟然無法釋放其中一個點的觸摸座標。這麼明顯的bug都沒有解決！看看svn的log好像四五個月前就開始做這個驅動了。竟然才做到這種程度。。。。   他們還用svn。。用svn管理android的代碼！這足以說明這些人有多懶，為了不學習git竟然把這樣的工程用svn來管理。。。。

看了下代碼，四個字形容一下，不堪入目！ 怎一個爛字了得！可以想象，一群這樣的人組成的公司如果離開了FAE的支援就一個字 “死” ！！！！  很明顯現在把這個爛攤子交給我們就是因為marvel對他們的支援力度不夠。。。（他們做到是個marvel的方案）

我已經放棄了去修補這份垃圾一樣的驅動。。。

看來哥還是要從寫一下驅動啊。。

等哥下周寫好了，在把這個筆記完善一下吧！哥要在兩周內解決。。。壓力還是蠻大的。。。現在做這個驅動完全是哥對atmel的崇拜！如果哥所在的公司就這樣一步步被轉型為山寨手機公司的話，哥是要儘早考慮出路了。。。nnd

竟然說這個觸控螢幕每次開機都要校準。。。  真是扯淡！！！！  這是老闆說的。。。老闆被他的那幫“二刀子”工程師忽悠啊。。。。好殘忍啊。。

201202291312:

我打算用中斷+輪詢的方式來讀取報點資訊，因此對中斷引腳的狀態需要讀取。自然用了 gpio_get_value這個函數。卻發現自始至終讀出來的值都是0，鬱悶啊。迫不得已我用示波器量了下實際電平，發現一切都是對的，電平有高有低，怎麼讀取的就不對呢？折騰了一早上，最後發現，gpio_get_value的傳回值是整形int 而我卻把這個傳回值賦值給了一個u8，自然發生了截斷，所以總是得到0，這是我的疏忽大意啊。

不過，這個函數是平台相關，有的傳回值不是0就是1，這樣就算我用u8來存傳回值也不會出現問題，然而有的平台上這個函數的傳回值可能是gpio相關寄存器的值，這是個32位的值，它會用掩碼把其他無關位過濾掉，只留下一個表示value的位，所以就看到這32位中的某一個可能是1其他都是0，如果gpio_get_value返回這樣一個32位的int值，那麼我們只要根據這個值為0或者非0作出判斷即可，如果像我這樣把這個值賦值給一個小於32的類型的話，十有八九就要掛了。呵呵。大意了。。

atmel的firmware真好！給驅動提供的是物件導向的介面。這樣驅動編程會變得比較方便，而且極大的提高了驅動的可移植性！

另外atmel提供一個8位元組的user data 。這樣，驅動就能在裡面寫入一些標誌，如此便提高驅動的自適應能力。這關鍵要看驅動設計者能不能想到怎麼用，怎麼用的好了！

調觸控螢幕的時候最好能讓裝置一開機就自動運行相關的觸控螢幕測試應用，這樣會極大方便調試工作，因為你也不能保證你的驅動上來就能用。以下的這些資訊可以協助我們實現在android中開機不要鎖屏。

android 2.3中 如何禁止android開機鎖屏：

frameworks/base/policy/src/com/android/internal/policy/impl/KeyguardViewMediator.java

line:192  

external apps(like the phone app) can tell us to disable the keyguard.

private boolean mExternallyEnabled = true  //此處改為false即可

如何設定預設的自動鎖屏時間

base/packages/SettingsProvider/res/values/defaults.xml

ling21:

def_screen_off_timeout   的預設時間是60000毫秒，即一分鐘，改為你要的即可，注意不要越界了。

關於多點上報

kernel對多點上報的操作是按組來的。

見http://www.kernel.org/doc/Documentation/input/multi-touch-protocol.txt

Protocol Example A------------------Here is what a minimal event sequence for a two-contact touch would looklike for a type A device:   ABS_MT_POSITION_X x[0]   ABS_MT_POSITION_Y y[0]   SYN_MT_REPORT   ABS_MT_POSITION_X x[1]   ABS_MT_POSITION_Y y[1]   SYN_MT_REPORT   SYN_REPORTThe sequence after moving one of the contacts looks exactly the same; theraw data for all present contacts are sent between every synchronizationwith SYN_REPORT.Here is the sequence after lifting the first contact:   ABS_MT_POSITION_X x[1]   ABS_MT_POSITION_Y y[1]   SYN_MT_REPORT   SYN_REPORTAnd here is the sequence after lifting the second contact:   SYN_MT_REPORT   SYN_REPORTIf the driver reports one of BTN_TOUCH or ABS_PRESSURE in addition to theABS_MT events, the last SYN_MT_REPORT event may be omitted. Otherwise, thelast SYN_REPORT will be dropped by the input core, resulting in nozero-contact event reaching userland.

所以如果觸控螢幕硬體也是按照一組一組來產生資料，即每個package包含本次檢測到的所有點，這樣便可以輕易的使用上邊提到的sync方法。即上報了package中的每一個點後邊追加一個syn_mt_report，然後在將本package中的所有點report完了之後，由driver追加一個syn_report來表示本輪上報結束。

但是這個atmel的firmware沒有像我們期望的那樣將報點分組。而是一個個順序發送。所以要實現kernel的多點上報要求，便要驅動採用邏輯策略來實現。。。這個真有點兒不太方便。

不過，我已經想好了方法。。等驗證好了在寫吧。。

發現當通過上面提到的真對多點的上報方式上報兩個點後，如果其中一個點釋放了，這這時會發現這個點依然在螢幕上顯示。並且只在下一次report完成後才消失。解決的辦法就是把其中一個點釋放的事件report後再把所有的事件report一次即可。這樣就實現了，上次報n個點，這次報n-1個點。

201203120138

很悲劇，他們在量產在即的時候不知是什麼原因卻把這個電容屏的驅動給換了，換了後多點觸摸都失效了，就剩一個單點了。但是就是這樣的東西也被他們提交到了伺服器。我對這個山寨公司越發的懷疑了。一周前我重寫的驅動就已經完成了，考慮到他們馬上要生產，我便沒有提交My Code，因為更換一個驅動後需要進行詳細的長周期的測試才能確定一個驅動是否有潛在的問題。但是我怎麼也沒有想到在剩下十來天的時候，他們竟然更換了驅動，而且貌似都沒有做什麼測試就發布到中心伺服器了。這或許是個迷。。。。。不過，和哥沒關係。。

還好，我昨天已經把那個新驅動引發的多點失效問題解決了。說句實話，那個bug很低級。。。。。。

個人認為一個好的驅動工程師會花一周的時間研究datasheet，然後再花一周的時間去寫代碼。我做到了。但是很累。為這樣的公司做這樣的工作。真的不值得。