2012年2月20日 星期一

TI OMAP3 DM3730 USB host controller high full low speed?

因為 TI OMAP3 DM3730 在 USB host controller 上偵測不到 full/low speed USB device,經查之後發現目前的硬體接線 ULPI 因為 DM3730 跟選用的 USB transceiver 的ULPI phy 的 serial 排線順序不一樣,在設定為外接 USB transceiver phy,而非 TLL 的接線方式時,無法使用 full/low speed mode,選用 device 時必須注意只能接 high speed device,如果要保持原有 

USB host controller ---phy--- USB transceiver --D+D-

接法, ulpi phy 線路不改而想要使用 full/low speed USB device,可以再外接一顆 high speed USB hub 解決。

2012/02/24

今天又花了些時間跟 Ken,還有 EE 確定 USB 問題,有些地方一開始誤解,因為是從軟體驅動程式行為,發現硬體有問題,一開始以為是目前元件接法

USB host controller ---phy--- USB transceiver --D+D-

無法實作, EE 在我提出有問題後就進行調查,發現是 ulpi serial 無法對應,其實並非這樣子的元件接法問題,而是 DM3730 的輸出分 ulpi parallel, ulpi serial, TLL 三種,因為我們有接 transceiver,就只能選擇 transceiver 有支援的 ulpi parallel 或 ulpi serial二擇一,high speed 的接法是 ulpi parallel,而 full/low speed 的 ulpi serial 接法,因需要接腳比 parallel 少,原本可以使用同一組硬體排線,但是因為 DM3730 跟所用 transceiver 的 ulpi serial 接腳順序與 transceiver 不同,造成無法使用現有的線路,待跳線驗證後可確定。

結論:

跳線加上 ohci driver 實測驗證後發現以 3 wire 的 ulpi serial 對 usb transceiver 就已經會發生誤判為有 USB low device (MiniPCI-E 上沒插卡),但我們 usb host port 的 transceiver 又沒有介面控制調整為 3-wire serial, 6-wire serial 或 12(8+4) parallel(預設),再加上 DM3730 SoC 原有的 ehci 轉換到 ohci 就會鎖死的 bug,最後確定無法使用原來的 

DM3730 USB host controller -- phy -- USB transceiver -- D+D- 

的接法,必須要再外接一個 USB hub 在 MiniPCI-E 上才能使用 USB full/low speed device.

相關文章:

2012年2月18日 星期六

Cadence Allegro 可讀電路圖 brd layout 檔案

The Cadence®  Allergo®  FREE Physical Viewer 填入個人資料後,會郵寄下載連結到電子郵件信箱供下載。

如果要測漏電,通常都是讀 EE 人員給的 pdf 電路圖,但要量測電壓電流時,pdf 檔怎麼對應到 PCB 板子上的元件就比較麻煩了。

Ken 因為有畫過電路圖 layout,提出向 EE 要 brd 檔案的需求,並且教我們如何使用 Allegro 讀 brd 檔,當然我還在學習中(*汗*)。

首先看 pdf 轉出來的電路圖,找到要量測的點,如 T82,但要找到PCB 板子上的元件實際量測點 ,需要使用 Allegro 開 brd 檔,選擇 Top 或 Bottom(因為只有這兩面我們量得到)配合搜尋跟 highlight 去找到 T82 的亮點,再配合右下角縮圖,跟滑鼠中鍵的移動視角(而非圖本身)就可以知道在整個 PCB 板的哪個實際位置了。

說到 Cadence...今天在 Google plus 有個叫 Cadence 的 porn bot 要找我視訊XD 看到 Cadence 我就先點了,但問了幾個問題後,發現都是固定回應,就刪了他,要刪掉加入 Google talk 的聯絡人還有點麻煩,Google plus 上看不到,必須要到 Gmail 選左上角的通訊錄 tab,搜詢新加的聯絡人 porn bot email address, 再刪除他即可。

2012年2月10日 星期五

BUILD_BUG_ON_XXXX macros in kernel.h

剛在 stackoverflow 看到有人在問 ":-!!" 在 C 語言的作用,點進去才知道是 linux kernel
header file ./include/linux/kernel.h 的兩個 Macro 定義:

683 /* Force a compilation error if condition is true, but also produce a
684    result (of value 0 and type size_t), so the expression can be used
685    e.g. in a structure initializer (or where-ever else comma expressions
686    aren't permitted). */
687 #define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
688 #define BUILD_BUG_ON_NULL(e) ((void *)sizeof(struct { int:-!!(e); }))
689
然後也有人解釋了:-!!,就是 : 取位元數, - 負的,!! 測試 e 是否為 0 ,回傳 0 或 1

就語意上是在測試另一個在 ./include/asm-generic/bug.h BUG_ON() macro 是否回傳
 0 或 null,如果是 0 或 null 就正確 (size 0),否就會 build fail (size (-1))

2012年2月8日 星期三

解 bug 的心理陷阱:我的可以動

昨天又遇到鬼打牆的解 bug 問題,一開始是自己寫的 AP + JNI shared library 可以用,但是給同事的 AP call 就有錯誤,於是卡在我的可以動的迷思中 XD。所以先請同事幫忙 debug,但是除了一個 static access warning 外,在應用程式端也沒別的線索了。自己才真正開始回去追 JNI shared library,結果確定是該用 jintArray 的型態用錯為 jint *。於是修改過後今天給同事確定可以解掉這個問題。但現在問題變成是,為何原本的寫法我的應用程式可以存取 JNI integer array ? XD

另外昨天看到一篇 Joshua Bloch 的 binary search, merge sort 的實作 bugJoshua Bloch 發現 Jon Bentley 的 Programming Pearls 書(1986, second edition 2000 )中的演算法,跟他在 JDK 實作 java.util.Array 的 binarySearch (存在九年的 bug) 同樣犯了 divide and conquer 取中間數的錯誤:

 6:             int mid =(low + high) / 2;

mid 可能遇到太大的 low 跟 high 造成 mid 發生 integer overflow,大於最大正整數 (2^31 - 1),這個 bug 可以藏這麼久的原因是之前沒有人測過這麼大量的 binary search 或 merge sort 解法是

 6:             int mid = low + ((high - low) / 2);

或用 Java 的 unsigned right shift, ">>>", (最高位補 0 確保為正整數)取代除以 2 較快些

 6:             int mid = (low + high) >>> 1;

C/C++ 參考解法如下:(參考 Nokia 的 Antonie Trux 指出 C89/90 跟 C++、C99 說明 signed integer 相加 overflow 的話是未定義行為,因此先轉型為 unsigned int)

 6:             mid = ((unsigned int)low + (unsigned int)high)) >> 1;

該文後面 Joshua Bloch 說明的是這個 bug 讓他學會謙虛,即使是我們認為理所當然的取平均都可能出錯,細心的設計、測試的重要性、正規方法、檢 視程式碼、靜態分析都是很棒的,任何單一方法絕對無法保證沒有 bug。即使我們竭盡全力解一個 bug,也可能要花上幾十年才解掉。因此寫程式必須小心、防衛並時時警覺。



2012年2月5日 星期日

被誇大的架構議題

摘譯:Architect - Overrated 一文自我警惕開發者該做的事

1. 總是在談願景、大方向
2. 認為自知該怎麼建造系統
3. 對於團隊不依照自己想法執行讓你不高興
4. 從沒擁有一個可用的 build
5. 花太多時間寫文件而非程式碼
6. 可以寫出產品原型,但從未寫出可賣的量產品
7. 花太多時間開會
8. 寫過最好的程式碼都是幾年前的事了
9. 被問到意見時,都只能回答一些不切實際的大概、方向
10. 懷疑團隊成員私底下取笑你
11. 花太多時間看科技、資訊產品部落格
12. 成為過去式

不要只寫維基文件跟 powerpoint。寫程式。