2009/10/21

在 Freerunner 上開發 Android (cupcake) 應用程式 - 永遠的 Hello World

最近 Android 不知道在紅什麼, 一天到晚都看到新聞. 昨天突然想到自己這台電腦上 (ubuntu 8.04 LTS) 的裝的 Eclipse (3.2) 從來沒用過, 加上也沒用過最近 koolu release 的 Android 0.1.1 for Freerunner. 就想說來測一下, 來 study 一下有哪些變化. 發現目前好像 Android on Freerunner 的說明不是很完整, 就快速補一下.

首先, 參考了以下網站:
* http://developer.android.com/sdk 使用 Android SDK 相關需要的條件 (http://developer.android.com/sdk/1.6_r1/requirements.html ), 安裝 ADT (Android Development Tools) 相關的說明 (http://developer.android.com/sdk/1.6_r1/installing.html ). Download 1.6 的
SDK tar.gz 檔
* http://code.google.com/p/android-on-freerunner/ Download 最近一次的 0.1.1 release tar.gz 檔(or http://www.t0ny.net/openmoko/images/android/) 目前 android on freerunner 是用 weekly build 的方式 release fix.

Step1: 安裝 Eclipse, JDK, JRE

看了 google dev 說明依下, 就發覺一些問題. 因為我的桌機上裝的是 ubuntu 8.04 LTS, 預設 apt-get install 的 Eclipse 是 3.2 版. 完全不在 google 目前支援的範圍內 (3.4 and 3.5 版). 可是不死心, 想說 ADT 給他裝上去會不會動, 結果 install 一直失敗. 最後還是把 Eclipse 3.2 移了, 從http://www.eclipse.org/downloads/ 抓了 3.5.1 classic 版本下來 (不過 google 是建議 java 版 or RCP 版).

抓下來解壓縮放到我的 home 目錄下, 執行 Eclipse 檔, 然後按照 google 的指示 從 Eclipse 3.5 的選單 Help -> Install New Softare. 在 In the Available Software dialog, 按下 Add.... 把 Location 填上去
https://dl-ssl.google.com/android/eclipse.

接著想說按下一步就收工了, 結果一直發生 package 安裝驗證的 Error (connect to key store 或是類似的問題). 我想說我 jdk 都裝了 (雖然幾乎沒用過) 就 google 一下, 發覺是跟 gcj 相容性有關(後來在 google 的 specification 看到上面有寫 =_=?), 然後有善心人士把 command post 出來:

~$sudo apt-get install openjdk-6-jre sun-java6-jdk
~$sudo update-java-alternatives -s java-6-sun

安裝完後, 還有把 SDK 的 path export 到環境變數, 修改 ~/.bashrc 加上一行: export PATH=${PATH}:<sdk_dir>/tools ,修改 preference

Eclipse 部分大概是這樣.

Step 2: 寫一個 hello world...
寫個 helloworld, 以 Android 1.5 當 target 在 Android 模擬器上跑跑看, 編成 .apk 檔. 哈哈, 其實本篇不是教你寫 Hello world :P

Step 3: 請參考前面幾篇文章, 安裝 0.1.1 的 cupcake 到 Freerunner 上安裝完後, 到設定裏面把 screen and display 的 sleep 時間延長, 避免 suspend 時的 USB 斷線. 然後到 Application 設定裏面, 把 USB debugging/Stay awake/Allow mock locations 打勾, 然後把接受未簽名的 Unknown sources 選項打開.

Step 4: 建立 ADB 連線, 將 .apk 檔安裝到 freerunner 中.
tony@tony-945:~$ adb kill-server
tony@tony-945:~$ sudo ifconfig eth3 192.168.0.200 netmask 255.255.255.0
[sudo] password for tony:
tony@tony-945:~$ export ADBHOST=192.168.0.202
tony@tony-945:~$ adb install helloworld.apk
* daemon not running. starting it now *
* daemon started successfully *
112 KB/s (6796 bytes in 0.058s)
pkg: /data/local/tmp/helloworld.apk
Failure [INSTALL_PARSE_FAILED_NO_CERTIFICATES]

原來以為這樣就收工了, 但是不知為什麼, 即使 Unknown sources 選項打開, Android 一直不讓我裝未簽名 (NO_CERTIFICATES) 的 helloworld.apk, 迫不得已, 就順便簽一下了.

Step 5: 建立 keystore 目錄, 為 .apk 簽名. 這邊只提供過程 :)
tony@tony-945:~$ mkdir android_dev_deploy
tony@tony-945:~$ cd android_dev_deploy/
tony@tony-945:~/android_dev_deploy$ mkdir keystore
tony@tony-945:~/android_dev_deploy$ cd keystore/
tony@tony-945:~/android_dev_deploy/keystore$ mkdir keys
tony@tony-945:~/android_dev_deploy/keystore$ cd keys
tony@tony-945:~/android_dev_deploy/keystore/keys$ cd ..
tony@tony-945:~/android_dev_deploy/keystore$ keytool -genkey -alias GreenRoom
-keyalg RSA -validity 20000 -keystore keys/anddev.keystore
Enter keystore password:
Re-enter new password:
What is your first and last name?
[Unknown]: Neng-Yu 'Tony' Tu
What is the name of your organizational unit?
[Unknown]: GreenRoom
What is the name of your organization?
[Unknown]: GreenRoom
What is the name of your City or Locality?
[Unknown]: Taipei
What is the name of your State or Province?
[Unknown]: Taiwan
What is the two-letter country code for this unit?
[Unknown]: TW
Is CN=Neng-Yu 'Tony' Tu, OU=GreenRoom, O=GreenRoom, L=Taipei, ST=Taiwan,
C=TW correct?
[no]: yes

Enter key password for <anddev.keystore>
(RETURN if same as keystore password):
Re-enter new password:
tony@tony-945:~/android_dev_deploy/keystore$ ls
keys
tony@tony-945:~/android_dev_deploy/keystore$ cd keys
tony@tony-945:~/android_dev_deploy/keystore/keys$ ls
anddev.keystore
tony@tony-945:~/android_dev_deploy/keystore/keys$ cp
/home/tony/helloworld.apk /home/tony/android_dev_deploy/keystore/
tony@tony-945:~/android_dev_deploy/keystore/keys$ cd ..
tony@tony-945:~/android_dev_deploy/keystore$ ls
helloworld.apk keys

Step 6: apk 簽名 (Sign apk)

tony@tony-945:~/android_dev_deploy/keystore$ jarsigner -verbose -keystore
keys/anddev.keystore -signedjar helloworld_signed.apk helloworld.apk anddev.
keystore Enter Passphrase for keystore:
adding: META-INF/MANIFEST.MF
adding: META-INF/ANDDEV_K.SF
adding: META-INF/ANDDEV_K.RSA
signing: res/drawable/icon.png
signing: res/layout/main.xml
signing: AndroidManifest.xml
signing: resources.arsc
signing: classes.dex

tony@tony-945:~/android_dev_deploy/keystore$ ls
helloworld.apk helloworld_signed.apk keys

tony@tony-945:~/android_dev_deploy/keystore$ cp helloworld_signed.apk ~/
tony@tony-945:~/android_dev_deploy/keystore$

Step 7: 安裝簽名 apk (signed apk)
tony@tony-945:~$ ls hel*
helloworld.apk helloworld_signed.apk
tony@tony-945:~$ adb install helloworld_signed.apk
127 KB/s (8484 bytes in 0.064s)
pkg: /data/local/tmp/helloworld_signed.apk
Success

終於等到 Success, 然後在 Android 應用程式區上就可以看到 Helloworld
Application 了 :) 目前暫時結論是 unknown sources 選項在 0.1.1 版的 Android on Freerunner 有些問題, 所以 .apk 還是需要 sign 過才能用 adb 裝. Ya....收工.

後來發現 Eclipse 在這一版是可以自動找到 adb server, 直接從 Eclipse 將 code 丟到 0.1.1 版的 Android Freerunner 執行. 這樣直接 debug, 不需要使用 adb install 來做安裝的工作.

2009/10/29 update:

0.1.1 版的 Accelerometer 似乎有問題, 無法正確取得 accelerometer 的值, google groups/code track 也有提到. 不過 GPS/Wi-Fi/Audio/Vibrator 是可用的. SDK 的 samples 內附的 API demo 有很多範例除了看 code 怎麼寫. 還可順便測試硬體. 如果裝了 Eclispe, 可以編 API demo 試試看. GPS sample 我放了一個簡單的在 http://t0ny.net/openmoko/samples/android/gps/ , 需要注意的地方只有 AndroidManifest 要把加設 user right 有 Access fine location, 不然編完無錯誤但無法執行. google code 上有許多 android 相關的 project, 例如 http://code.google.com/p/bearing/ 也是一個 GPS data 的 viewer, 可以在 FR 上執行.

2009/10/12

意料內的意外 = or != 行銷

電視上新聞 "一直" 看到 Michael Jackson 的新單曲在正式 release 前, 很巧的 TMZ 又在網站上搶先 post 了 47 秒的 MV. 這類搶鮮試聽, 或是滿足人偷窺慾望的 release 方式, 實在覺得是很老的梗了, 不過我想應該還是很有效吧 :) 這類真真假假的娛樂新聞, 本來就很容易引起一般人的注意. 不過, 我是很佩服美國娛樂產業可以這麼快的用 "電影" 的方式, 來 release 最後未完成的 "演唱會". 除了行銷的 idea 外, 當初這些在排練 take 的畫面, 以及相關的合約 arrange, 若沒有充足的經驗, 是很難在短時間內組織出相關產品的.

很多 geek :P 可能會覺得這類娛樂新聞很無聊, 可是如果換一個方式呈現, 可能感覺就不一樣, 例如: 某個水果 3C 產品 release 一周被 hack 了, 或是某 online store 下載的軟體用很笨的 folder 方式保護. 到底是 user 破解了保護, 還是 marketing people 破解了 user 的心防.

世界真是有趣阿 :)

2009/10/8

雲端的迷思

這一陣子兩個颱風來, 大家為著氣象局的預報準不準在電視上鬧的沸沸揚揚. 媒體也乾脆把來自各國的預報路線用不同顏色疊在一起. 各電視台面對著向炸彈開花似的預報路線圖, 開始一種路線, 各自表述起來. 觀眾透過最簡單的 client 端: 電視, 收看著來自各個來自 "不同國家" 用 "不同演算法" 在所謂 "超級" 電腦中運算出來的結果. 突然覺得有點好笑, 想一想, 這也是種雲端運算吧, 只不過天邊不是只有一朵雲而已.

2009/9/23

有趣的互動設計概念 (interactive design concept)

感謝 youtube/vimeo and google, 最近看到幾個有趣的互動設計 concept.

* 這是真實物件位置跟背景光影互動

Bouncing Balls from Dofl Yun on Vimeo.



* 這是透過不同感知的方式來展現互動創作的可能性

ensemble project from Dofl Yun on Vimeo.



* 一個有趣的互動 Drum/sequencer (thanks, wilson :) )




* 可提供觸感的 3D 投影 (搭配 ultrasonic pad)




* Wii 的一個新 game, 非常令人深思的遊戲進行方式.

2009/9/15

感動的 T-SQUARE 表演

原來以為日本 Fusion 已經沒辦法再打動我了, 果然現場表演才是王道阿, 現場的氣氛讓我回想到以前天天聽他們 CD 的日子. 好聽的音樂還是好聽的音樂, 不會因為時間跟人的改變而改變.

想當年 (驚覺過了 20 年@_@ ) 開始聽 Fusion 這個領域, 最早是因為海國的老師, 拿了高中正義的虹傳說譜給我練, 當時狂練 Yngwie 掃弦的我根本不知道什麼是 fusion, 更不要說知道什麼是 jazz. 只是覺得很好聽, 但是聽不懂. 但是還是很努力的存錢, 買了一張又一張每張 700 到 1,000 起跳的原裝日本 CD. 開始慢慢喜歡上 CASIOPEA 跟 T-Square 這種華麗, 聽不懂, 也不是很吵的音樂.

後來隨著各種音樂越聽越多, 也到了美國這個 Jazz/Fusion 的發源地洗腦了兩年. 看到了許多有名或不有名但超厲害的表演. 也獨自到 NY 窩在巷子�狹小的 smalls, 呼吸充滿 jazz 的空氣, 體驗來自各個不同背景的樂手, 整晚交替表演各式不一樣風格的音樂. 每一個表演都充滿用靈魂敲擊音符的原始音樂能量. 後來有很長一段時間, 很少聽日本系的 fusion, 因為總覺得太拘謹, 過分修飾 (電味太濃) 跟華麗, 缺乏了那種生命推動音符的震撼.

好不容易過了 20 年, T-Square 終於來台灣. 可能很多人不知道 T-Square 這個團, 但其實聽過 T-Square 的音樂, 像傳統日本 F1 的轉播主題曲 Truth 就是 T-Square 的安藤(Andoh) 作品. 還有以前的 Arc the Lad (http://en.wikipedia.org/wiki/Arc_the_Lad_(series )遊戲, 跟 PS 上最有名的賽車 GT (Gran Turismo) 系列, 安藤也是音樂總監跟主題曲作者.

T-Square 官方站: http://www.tsquare.jp/free/index.html

期間 T-Square 團員也更換過好幾次了, 雖然 keyboard/bass/drums 都不是我那個年代的, 不過 "最" 主要的吉他安藤 (Masahiro Andoh) 跟負責 Sax 跟 EWI 的伊東 (Takeshi Ito) 都有來. 表演一開始, 我雞皮疙瘩就起來了, 因為我那時心情很平靜, 以為是冷氣太冷. 不過後來想想, 應該是潛意識的激動. 表演維持個一慣日系的精準, 華麗, 控制, 但是跟 CD 不一樣的是, 現場表演多了一股共鳴的張力. 果然日本 Fusion 也是可以很熱血.



現場表演很讚, 年輕鼓手的能量很夠而且完全的控制內. 加上很多來的人應該對 T-Square 都很熟, 也有很多音樂圈的樂手有來. 整體氣氛其實很 high, 最後 encore 表演 truth 更是熱血百分百. 如果沒提早開燈, 我想應該會 Encore 更多首. 雖然沒辦法像負責導聽的小呂老師有機會參加 T-Square 的慶功宴 ...>_<... 但這的確是難忘的 J-Fusion 之夜.

T-Square 最高....

2009/9/8

產品形象 (identity)

昨天到國家音樂廳, 看了我個人非常喜愛的一位吉他手 John Scofield (http://en.wikipedia.org/wiki/John_Scofield) 的 band 表演, 他很喜歡用一般 musician 不會用的 color note, 但是用非常流暢的藍調 a-like phase 跟 shuffle/funk rhythm 來表現他的音樂, 雖然曲目大部分是最近這一張專輯 gospel 類的音樂, 曲目本身結構不像他在純 jazz band 那麼複雜, 但是用音依舊是他自己的 taste, 而且非常 groovy 的一場好表演.

翻翻幾百張因為跟吉他手相關而買的 CD, 發現常聽的幾張, 音色跟旋律線的辨識度都非常高. 而且, 他們對現場即興 (improvising) 演奏的 taste 都有獨到品味難以被模仿.

美國娛樂產業發達, 有同樣技術的太多, 市場 (包含: "消費者" 以及挑選產品進市場的 "唱片公司") 非常注意原創性及獨創性, 所以能夠出現在一般人面前同時受歡迎的專輯, 其實都是打敗了數以萬計的競爭者才冒出頭的. 換句話說, 通常一般人看到的都是已經 build 好的 identity, 經紀/ marketing/promoter 對這些 identity 建立, 都下了許多一般人看不見的功夫 (選擇 artist/包裝/行銷) 在裡面.

人透過 identity (tag/icon) 來認識一樣東西是被從小訓練的. 例如: 受教育的過程本身就是一個 format 認知的過程, 如果大家都考一樣的試, 搶念一樣的學校, 看一樣的 MTV, 把一樣的人當偶像 (藝人 or 非藝人). 說實在的, 如果教育 build-in 這麼深, 要一般消費者有獨立思考跟自我品味這件事其實太強人所難 :)

正因為大家對於 identity 的認知多半來自於外部的描述, 而少有自己的感受, 所以廣告跟行銷手法才有發揮作用的地方. 很多人覺得 identity 是被包裝出來的, 我個人的看法有些不太一樣. 例如, 一般電子產品常見的 identity (簡化的):

* 最便宜
* 最炫, 最牛B
* 最物超所值
* 功能最多
* 服務最好
* 最方便
* 最有品味

其實建立好任何一樣 identity, 應該都可以在市場上存活, 持續重現這些 identity 的能力也都是每間公司的 know-how. 以製造業最擅長的 cost-down 為例, 都會知道一直做到 "最" 便宜其實也沒那麼容易, 因為從流程 - 設計 - 生產, 每個細節都會影響 "最" 這個字, 不小心就會讓 "最" 變得很 "一般".

從另一個角度來說, 當要作一個最有品味的產品, 出發點就是品味 :) 所有的包裝 (marketing/promote) 都會繞著品味打轉. 產品定義的人的 mindset 就跟 cost-down 的人 mindset 就完全不一樣. 人通常也不會是同一種人. 在現實生活, 經常 marketing 要把原先設計 " 功能最多" 的產品, 轉化成 "最有品味" 的產品 image, 其實不是那麼容易. 因為要改變產品的既有印象是很困難的, 除非 marketing 的人找到一個夠好的 story.

我常聽到: A 產品本身就沒有什麼特色可包裝, 所以廣告跟 marketing 效果不好. 但是, 經常問題來自於 A 產品當初建立時就沒有什麼明確的核心思想, 或本來的核心思想跟要進入的市場無關, 所以後來 marketing/promoter 在包裝時, 累得半死想破頭加減一些無關緊要的東西, 目的讓產品在要進入的市場看起來更 attractive, 經常是事倍而功半.

如果能在 identity 中, "建立" 一個市場沒有的字彙, "然後" 又獲得認同. 通常就是該新市場的 leading 角色了. But keep leading always another story :)

2009/9/7

硬體產品專案管理經驗分享 - 時程 (schedule)




不論專案或是產品, 通常都有俗話所謂的 deadline 或是market window 限制. 基本上 PM 被賦予的任務就是得到目標後 (明確 or 不明確 :P 的目標都有可能), 在指定的時間內, 協調公司內外部 resource (錢, 人員, 組織), 達成指定目標. 所有的 resource 投入, 都是為了在某個時間點取得某個成果 (working sample/demo/trade show/shipping/etc). 錯過了時間點, 後果通常都很嚴重. 通常影響 schedule 最大的是 scope 變更, 但這裡不討論 scope 變更的問題.

這幾天又在 HBO 看到 "大敵當前 (Enemy at the Gates )" 這部片子, 這個戰爭電影有一句還蠻經典的對白:

Vodka is a luxury we have. Caviare is a luxury we have. Time is not.
-Enemy at the Gates, Nikita Khrushchev

意思是說, 我們可以享用 (一般老百姓沒有的) 伏特加跟魚子醬, 但是唯一沒有時間可以浪費 (Time is not luxury we have). PM 可以協調找到資源, 但是永遠缺時間. 假你錯過時間, 可能產品失敗的機會或隱藏的成本, 一般來說會呈現 "幾何" 倍數增加. 要有一個重要概念: 最後一個月追加 30% 的預算跟 delay schedule 東西 marketing/sales 預估少賣 30% 的量, 到底是哪一個損失比較大. cost 觀念不是只有 PM 要有, 同時專案裡的人對 cost 要有相同共識.

Schedule 這個東西 "看" 起來很簡單, 不過就是做一件事需要多少時間, 把所有需要的時間按照發生的先後順序調整一下就好 (跟 programming 很像, 不是嗎 XD ). 問題來了:

* 如何知道做這個軟/硬體或做這個 project 一共有哪些事情 (scope 有多大)
* 這些事情對應的 function 組織及負責人是誰
* 如何知道這些事情需要多少時間
* 如何分辨這些事情出錯造成的風險跟衝擊有多大
* 遇到問題的應變跟通知對象

這一部分其實就是大部分 Developer 踏入 PM 領域的第一項 "技術" 門檻, 因為瞭解組織跟認識 API/function block 一樣, 都需要時間跟精神. 同時, 跟 "人" 溝通不是 下 command 給電腦, 不是馬上有結果 or 每次結果如你預期一樣. 當然某個程度來說, 做產品/專案有一點像 coding, 只不過 coding 的對象是組織而不是 library. 當然, 你對組織/流程/工具越熟, 就越能有效率跟機會達成原先設定的目標. 根據不同的成長經驗, 每一個 PM 都有每一個 PM 不同的風格, 下面是我覺得一開始比較重要的:

* 了解並釐清公司內部組織跟流程規範

每一間稍具規模的硬體公司, 都會有標準的流程或是 follow 公司訂的 ISO 流程. 認識這些流程是了解硬體相關專案管理的第一步. 台灣從純代工的 OEM 到現在佔世界 3C ODM 跟 OBM 的重要地位也有幾十年了. 從微利的代工開始, 所以設計到製造其實分工很細, 流程本身相對於很多其他產業來說也嚴謹許多, 每一個細節為什麼這樣做都有其歷史原因. 一般來說, 因為其實細節太多, PM 可以了解或不了解, 不懂可以問, 但最好不要用猜的.

* 總共有哪些重要項目, 哪些時間是固定的, 例如 (但不限於):

a. 每一個階段 (EVT/DVT/PVT or 不同 flow 階段) 的 check point 時間, 跟 check point 對應的 check item 是什麼.
b. BOM 裏面的關鍵零組件備料時間 (採購通常會提出一個安全反應時間, 有一些例如: 發 PCB gerber 到交貨時間, 常都是固定的天數)
c. 硬體產品認證時間 (Lab 會評估如果 sample "軟" + "硬" 體都沒問題, 多少時間可測完)
d. 每一個關鍵硬體功能的需要驗證時間 (從發出需求給 vendor, 到 sample 驗完)
e. 採購的作業時間
f. 整合測試的 cycle time, 例如發行軟體測一個 round 需要多少時間
g. 量產從 RD 到 PE 到工廠的技轉時間
h. 工廠的前置作業時間

* 產出重要文件需要的時間請放入 schedule 中

文件通常不是交付或驗收標的物, 所以很多人就忽略文件的重要性. 一般 Follow "標準" (ISO/CMMI) 流程的專案 (如果公司跑 ISO/CMMI/PDM 的話), 會產出一堆的文件, 用這些必然產出的文件當控制點是蠻方便作法. 但是因為跑流程, 有額外的文件負擔, 許多小規模的專案, 常只產出少量文件或完全沒有文件. 因為口說無憑, 進行到後段經常會很難收尾. 如果該產出的重要文件, 我個人覺得還是要放入 schedule 計畫中比較好. 有時前面為了省一些寫文件時間, 後面會浪費更多協調溝通時間.

* 將預先設定好的 milestone, 跟必然產出的文件項目放入 project 管理軟體

用最簡單的例子: product spec 展開後可以有-> hardware design spec + software design spec, 接下來又有各有對應的 verification citeria 跟 factory test item. 這有一定會產出的 item, 可以像樹狀圖一樣依照分類 (軟體/硬體/測試/etc) 先放到 project schedule 軟體, 這樣對整個 project scope 跟各個事件的相依性會清楚很多. 當然, 如果最後畫的出 critical path 更好, 不過在現實世界的互動裡, critical path 會隨專案進行變動的 ;)

* 保持溝通透明與順暢

專案越大, 協調溝通的人越多, 溝通透明跟順暢就越重要. 透明是盡量讓溝通過程中造成的誤解減少, 原則是對事不對人, 記得傳遞訊息的目的是解決問題. 順暢是讓專案成員願意主動傳遞訊息 (不論是好消息還是壞消息). 專案進行中有意識 or 無意識自我過濾訊息, 通常是災難的開始. Schedule 很多東西是看不到的, 通常事情都是發生問題, 才能從 schedule 看到 delay. 溝通的透明跟順暢讓這些看不出的問題, 影響 schedule 的程度減少, 同時縮短下對策的反應時間.

2009/9/2

硬體產品專案管理經驗分享 - 專利 (IPR)




記得很久以前, 小時候看天下雜誌還是商業週刊, 提到企業的資訊蒐集及 data mining 能力很重要. 那時只是很抽象的知道這件事很重要, 但是並沒有意識到到底有多重要 (or 多可怕). 工作一段時間之後, 透過許多不同的方式, 看到各家的產業報告, VC (venture capital) 的投資分析, 以及 real world 的專利分析報告. 才驚覺自己所學在整個產業中的渺小.

並不是每個人都喜歡 Intellectual Property Right (IPR) 的觀念, 跟所造成的壟斷跟限制, 但是現在除非是都是以專案 (非歐美地區) 或是封閉性小眾客戶為主, 我個人認為, 做產品很難不遇到 IPR 問題. 所以做某個跟 $$ 相關的決定, 要能先意識到 IPR 問題是很重要的, 因為這代表著隱藏的時間, 成本, 跟風險. 這類跟 IPR 相關的產品管理不是只出現在電子 or 製造業. 其它例如藥品業, 也是產品開發時就已經結合 IPR 跟生命週期管理. 透過有組織的分析各種公開資訊 (專利/法律/財報), 可以看見很多公司內部的訊息, 常見的包含:

* 公司未來可能產品方向跟佈局
* 公司有哪些專利訴訟正在進行 <- 有哪些 IPR 是經的起考驗, 或真的有 value 可以跟人家 trade
* 專利申請人有哪些 <- 通常是有 know-how 的 key man
* 用 IPR 被引用的次數, 做公司實際 value 的評估

另外, 很多人把 IPR 管理/分析, 跟商標/專利申請混為一談. 也很常常見到低品質, 或是其實無任何保護或攻擊效力的專利申請, 當成是 IPR 應用的全部. IPR 這個領域也已經有百多年歷史了, 其實有分工非常細的生態, 不是簡單可以說完的. 我個人是覺得科技業的企業整體戰力, 跟 IPR 法務戰力基本上是成正比的. 產品遇到的 IPR 問題, 也通常跟產品的熱門程度成正比 :)

很多人對 IPR 有很多迷思, 典型的例如: 這個產品是我們自己設計的, 沒有參考別人, 就沒有 IPR 問題. Or 我的 reference design 來自某某知名公司, 不會有相關 IPR 授權金問題. Or 用 Open source 沒有權利金的問題... 很多啦, 這幾個敘述都該打 X, 因為都是錯的 :) . 這邊有幾點常見注意的問題.

* 產品有哪些關鍵零組件 (key components), 這些關鍵零組件本身是否已經 cover 了 IPR (尤其是需要 essential IPR (基礎專利, 簡單來說就是你不可能做出功能一樣, 但是不侵犯專利的產品) 的元件, 如 GSM/3G/etc...)的費用? 一般來說, chipset solution 不 cover 終端產品的 IPR, 而 module solution 有些會, 有些不會. 在選料時要先確認.

* 很多專利 alliance/pool, 是找 manufacturer 簽約付授權金, 而不是根據 design house 或是 branding company 的實際生產/出貨數量. 這會造成 manufacturer 不見得願意付, 或是跟你一起跟 alliance/pool 談.

* 若使用的硬體 chipset 有內建 codec (MEPG2/MPEG3/others), 或 firmware (software) 包含 codec, 就有可能需要付授權費. 簡單的使用者 2 次加工 (例如: 出貨時功能不全, 但使用者把某一個東西放進 device, 或是按下某個鍵, 就可以讓 device 功能完整), 不見得能規避 IPR 的問題.

* (歐洲) 某些國家海關 (如: 德國), 海關可以直接扣押主觀認為有侵權疑慮的產品, 所以可能在沒收到任何 IP holder 的 letter 下, 毫無預警被扣押.

*產品交貨是 FOB, DDU 或是 DDP, IPR 授權金基本上跟出貨地點有間接關係 (who will pay), 在考慮整體 cost 跟 BOM 時, PM 應該把這一部份成本跟 schedule 考慮進去.

* 因為通常一個產品裡面會有多個 function block, 每個 function 都有可能有 patent 的問題. 所以被人發 letter claim IPR fee 時, 先確認人家 claim 什麼? 很多公司都是發警告信, 但是不會在第一時間跟你說要 claim 什麼. 此時不要 panic, 請先回信確認他代表哪些 IPR pool, 他要 claim 什麼?

* 如果產品中有包含 Open Source (GPL) 軟體/tools (如 busybox), 產品相關的 source code 也需要公佈, for example: http://thinkingopen.wordpress.com/2008/06/10/busybox-is-back-back-again/ 如果用到 codec, 還是要付 codec alliance 的 IPR.

當初 google android 不直接使用 Java ME VM 在產品中, 而自己重做 Dalvik VM, 其實也是有 patent 跟策略考慮在裡面, 因為能 open source code 跟能將 code 以硬體產品方式散佈是不同的授權 (不知道有沒有人冒冷汗 ^^!). 其中還點到 MS 跟 Sun 當初對 JVM 交換授權的問題. 有興趣可以搜尋一下 dalvik vm 相關的文章. 例如這一篇: http://www.betaversion.org/~stefano/linotype/news/110/ 裏面把 google 不使用 sun 的技術的原因, 從策略角度上做了不錯的說明. 除了規避之外, Microsoft 買了 Andy Rubin (Android leader) 的前一個 fund 的公司 Danger (同樣 base on JVM), 很多分析家都在看 Microsoft 何時會拿出這張牌.

即使是單純接收資料的 GPS, 可能在不同地區也會被 claim IPR (會發生很奇怪的現象, 收美國軍方衛星資料, 但要付歐洲公司錢??) 所以沒有什麼不會被 claim 的.

相關 IPR 的資訊現在開始越來越多, 下面幾個網站我覺得還蠻值得入門參考的:

* 國家實驗研究院科技政策研究與資訊中心 http://cdnet.stpi.org.tw/intro.htm
* 資策會科技法律中心 http://stlc.iii.org.tw/

參考書籍的話, 周延鵬 (周律師) 的書不錯, 很多 Business 上的細節都有點到, 很值得參考, 推一下 :)

2009/8/27

硬體產品專案管理經驗分享 - 規格 (specification)




前一陣子有朋友問到硬體產品專案設計/生產/測試該注意到的問題. 本來我想翻一下 google 找一些比較完整的說明 forward, 除本身這個話題範圍很廣外, 不知是我關鍵字用錯還是怎樣, 找不到比較適合的, 就順便就把我覺得 PM 該知道, 該注意的寫出來.

在有規模的系統廠, 組織的分工比較細, 硬體專案進行都有自己公司的標準 ISO 流程或 PDM/PLM 系統. 從前段規格確認, IP 專利分析規避, 合約檢查, 中段的設計檢查, 量產規劃, 到後段生產 flow, 生產 ramp up 該做的流程都蠻固定的, 但項目說起來頗多 (其實是非常多, 理論上所有 ISO 流程文件都會產出, 並且最後入到 DCC (document control center) 做統一管理). 像手持裝置 ("非" feature phone 類的) 變化又更多, 所以, 這邊介紹時會簡化很多.

在這邊除了寫規格該注意的事項外, 我覺得有幾個非技術的事情 PM 要隨時注意, 例如:

* 要保持對狀況的靈敏度 (例如: 要交付的目標是什麼, 目前共識有哪些, pending issue 有哪些, 問題的優先順序跟其他人是否一樣). 重點是, 不要讓自己或團隊狀況外. 你的產品會忠實呈現團隊狀況外的程度.

* 認識 team member 的行為模式, 不見得每個人都是華盛頓 (either 沒事會去砍櫻桃樹或面對問題認錯), 自我感覺良好不是高官們的專利. 從辦公室打掃的, 到公司管理階層, 沒出大事之前大家的感覺都會很好.

* 對自己不了解的問題, 不要輕易放水. 放水不代表不用負責, 只代表還不夠專業.

* 要記得追蹤有風險的決定, 不要以為一開始沒事就沒事. 莫非定律出現的機會通常比你的運氣好. 如果要用趕工 (crashing) 或是同步作業 (fast tracking), 請記得讓大家知道這叫 fast tracking 跟 crashing, 是有額外 cost 的. 要記得警告大家風險成本是多少.

* 問題能早解決就早解決, 拖到最後還是要解. 常見有人剛開始跟你說 ok, 但最後大家都得健忘症, 代價沒人願意承擔. 遇到這種情形, 請把深海魚油跟雞精準備好, 魚油給別人補腦力, 雞精留給自己熬夜吧 =_=

雖然大家都知道這些, 但是常因為現實環境 (成本, 時間, 部門利害關係) 而犧牲. 但是, 不管如何, 還是要隨時注意. 下面每個主題, 都只簡單介紹該領域我覺得最簡要的部份 (也就是包括, 但不限於的意思啦):

* 不要覺得規格確認是 one time work
規格確認不是一件做完就不用管的事, 而是一件到產品 phase out 之前都可能會跟著你的問題. 因為可能發生的狀況太多, 有可能零件停產, 某批零件 quality 有問題, 客戶發現新的設計問題, 有新的法規等... 不過以項目來說, 主要下面幾點:

** 硬體功能需求: 要有哪些硬體功能, 以及這些硬體功能的規格要求. 舉例來說: wi-fi 不是 chipset solution 決定就好, 輸出的 power 跟天線敏感度, 耗電量這些細節都要放到文件裡. 現在 wi-fi chipset 都會有 firmware 或是執行時要載入 firmware. Firmware 經常會有細小的差異跟 bugfix, 這些都會影響中段產品測試, 認證及產測規格. 如果客戶有指定或覺得重要的 test case (穩定在某個環境, 傳輸多少資料的效率或不中斷之類的測試), 請一定要做.
如果 wi-fi 傳輸時要亮燈, 或是可以用 packet 喚醒 suspend (IP phone 標準) 狀態的 wi-fi, 這些都跟電路的設計相關. 通常設計階段還會跟硬體及機構件的 placement (晶片放在電路板哪些位置) 相關, 這些都會影響 schedule 跟最終客戶驗收的 quality, 請注意.

** 與硬體相關使用者行為確認
使用者介面分為兩個, 一個是純軟體的 UI, 另一個是跟硬體的互動 (通常是 LED/按鍵/Dial/track ball 等等). 拿 iPod 當例子來說, 當 iPod 在播放音樂時, 把耳機線拔掉, 音樂就會停. 這就是硬體設計 interrupt 支援軟體行為可能性的範例. 盡可能把所有 user case 釐清楚. 請千萬記住, 硬體是沒辦法跟軟體一樣說改就改. 軟體按 make 重新 compile 的成本很低 (至少一般人感覺很低啦 =_= ), 以為改硬體也是重新焊個元件, 改個電路, 加個電阻或換個 filter. 但是改硬體馬上就有原有料變廢料,重新驗証新料/電路的時間, 新洗板子, 打件驗証的時間, DFM (design for manufacturing) 變更, 這時間跟成本其實是難以想像的高.
或許有人會提 rework 可節省一些驗證的時間, 但是問題是: rework 的 quality 通常不穩定, 很多驗證時會發生: 這是原有的問題, 還是 rework 的問題? 功能可能可以 rework 驗證, 但 DFM 可能還是要重新來一次才能確保 quality.

** 使用環境: 裝置是手持式, 車用, 家用, 工業用, 玩具都有不同的測試規範. 主銷非洲市場跟用在俄羅斯的產品要做的測試重點也不太一樣. 請針對環境可能的需求, 讓客戶盡量描述清楚, 並跟相關人員討論增加一些對應的 test case, 以及對應的入料檢驗規範. 在環測測試中, 你會發覺大部分東西遠比你想像的容易壞, 而零件的價格跟品質大部分都是有道理的. 請記得, 零件供應商的產品規格不檢驗的問題在 "你", 客戶通常是不會找零件供應商的. 東西該摔就要摔, 該震就要震, ESD 該打多少就多少. 產品的 quality 控制就靠這些細節執行. 我也相信 PMI 說的 quality 是 design in, 不是 inspect in, 但事實是: 通常大家都覺得已經 design in 了, 直到 fuse 爆掉那一天.

** 使用壽命: 使用壽命跟產品的成本 Life cycle 管理, 供應商管理, 售後服務都有關係. 跟產品的設計, 用料都有直接的關係. 機構料本身的 cycle 數使用限制, 到 SD 卡插槽的跟 SD 卡接點 pin 耐磨程度, connector 的鍍金厚度. 都是 base on 使用環境跟使用者行為來評估. 另外售後服務的時間, 跟備 customer support 的料的量, 都應該找相關部門以評估成本.

** 認證: 認證大致有幾種 1. 安規 Safty 類 2. 不同國家進口的額外需求 3. 客戶營運商需求 (PTRCB/FTA/etc) 4. 綠色環保類 (Green, RoHS, WEEE) 5. 還有要掛 Logo 類 (Bluetooth/Wi-Fi/etc). 不同國家的安規規定, 也會造成產品包裝/標示/說明書問題, 甚至送認證的名稱都可能會影響後續進口流程及系列產品認證, 這些都在認證時要考慮.

標準的安規例如 FCC/CE, 需要注意的地方是要跟安規實驗室 (lab) 討論 user test case. 產品的硬體版本, 及相關 accessory (尤其是變壓器/充電器), 連接 cable 等, 在進 lab 前請先確認. 同時, 進 lab 前記得要先做 pre-test, 如果 pre-test 沒過, 通常都是有 RD 沒說的隱藏問題, 一般來說送 lab 前還有這些問題, 這些問題都會影響最後 quality.

安規看起來大家都在做很平常, 但其實可以幫你從外部 lab 角度看產品 EMC/EMI 跟穩定問題. 不同國家, 可能有不同的認證需求, 像手機進台灣還要做 NCC. 如果是包含 GSM/3G 功能, 但是使用的是 chipset 而不是現成的 module (如 原為 Siemens 的 Cinterion), CE 還會需要 GSM protocol 相關測試, 這類 protocol 測試一個 run 要上百小時. 如果包含多個 RF 射頻的智慧型裝置, 不同國家還有不同的功率規定及通報規費 and 額外的時間, 請把它算到你出貨的 schedule.

Green 相關常見有 RoHS 跟 WEEE, RoHS 可依廠商宣告書管裡做自我宣告, 這部份每個公司對於廠商宣告書的 policy 跟管理工具都不太一樣. 當然 Lab 也有 X ray 掃描或化學方式可做分析, 但是大部分還是以供應商管理比較多. WEEE 除了要拆解說明書外,還要跟歐盟認可的廢棄物處理商簽約才算有效.

要把 Wi-Fi 跟 Bluetooth 的認證 Logo 合法掛在盒子上, 通常都有額外的認證/測試流程. 想掛 Logo 你必須先加入對應組織的會員 ( Alliance 或是 SIG (special interest group)). 加入價錢從免費 (Bluetooth), 到數千 USD 不等, 你必須選擇適合你的 package. 然後才是根據掛 Logo 需要的條件做認證. 請記得, 有 Wi-Fi 跟 Wi-Fi certified 是兩件事. RD 說功能 ok 不代表你可以掛 Logo. 掛 Logo 不是紙盒上印就有的, 要 1. 加入會員, 2. 做過認證 3. 符合相關掛 logo 規定才算. 最後記得把成本算進去. 有些 Logo 還有 IPR 的費用 (DVD/CD/MP3/etc), 付費方式也不一, 請先注意.

如果是你自己開公司作產品, 或公司本身先前沒有為 device 申請 MAC 專屬位置: 還需要先到 IEEE 申請一個 OUI (就是 MAC 位址前3 byte 啦), USB forum 申請一個 USB ID. 含通訊功能的手機或移動裝置的話, 還需要去申請一段空的 IMEI number 供使用.

IEEE OUI: http://standards.ieee.org/regauth/index.html
USB: https://www.usb.org/members_landing
IMEI: http://www.babt.com/gsm-imei-number-allocation.asp

2009/8/5

取得 Freerunner 原始碼及編譯完整 image 的方式 - 使用 mokomakefile




原本當初 Openmoko 新手手冊預計會寫 20 篇, 前 10 篇是基本操作, 後 10 篇預計是寫 tool/build 相關的. 最早會想寫的原因有幾個, 包含: 減少大家問重複問題的機會, 補充網路上一些中文資料不完整的地方, 還有順便當自己備忘錄 :)
後 10 篇最後沒寫是因為覺得網路上資料其實夠多, 像 OpenEmbedded (OE) 跟 git 都很多說明資料在 blog (英文很多) 或是有 PDF 格式可供下載, 一般 developer 如果這類閱讀問題沒辦法解決, 要真正加入 FOSS community development 的開發會很困難. 另外有公司組織上功能區分的原因 ;-)

原先 document team 有 "理想" 要把 wiki 內容整理到 Floss manuals 這個 project (http://en.flossmanuals.net/), 這樣只要再把整理的文件, 翻譯成中文, 這樣也比較會有一致性. 而 Flossmanuals 是另一個希望能讓 open source software 工具, 能有一個清楚説明公開文件的 project.

最早 Openmoko 在公開 wiki 時, 就提供了 SVN 的 u-boot/kernel 及 based on OpenEmbedded (OE) 的 package 在網路上供人下載. 同一時間, 少量的 Neo1973 的工程樣品, 也免費送到各個重要的 Open source community (phase 0 user) 的開發人員手上, Rod Whitby 是其中的一位, 他就幫 Openmoko 寫了一個非常強力的 makefile, 目的是讓 developer 能夠用簡單的方式, 透過 OE 能讓每個 developer 都能用 "一樣" 的 code base, 自己 build 完整的 distribution (kernel + rootfs). 早期的 mokomakefile 需要先自行安裝及設定 monotone (版本管理軟體, OE 在 2008 年前使用), 後來 OE 改用 git 當版本管理程式, mokomakefile 幾乎能全自動的完成所有 build image 的程序. 個人第一次使用時覺得: 這個 Makefile 真是超神奇跟強大的工具, 雖然當初在我的舊 PIII 1.2 G NB 編了快 3 天, 但自動化跟穩定程度真是神奇, 值得大家試試看.

* Mokomakefile 的主要說明網址: http://wiki.openmoko.org/wiki/MokoMakefile
Mokemakefile 全自動完成以下的幾件事:
* 下載 OpenEmbedded 的 Bitbake, 及相關設定檔原始檔
* 從網路上各個 bitbake recipt 指定的 git/svn 位置, 及下載套件指定訂版本原始碼
* 下載 recipt 裏的 patch 及相關設定
* 設定/建立 Host 端 OpenEmbedded 所需的設定, 包含工作目錄, 暫存目錄, image 存放目錄, 套件存放目錄...等等
* 依照編譯設定檔, 套用 recipt 指定的 patch 後, 編譯所有的套件, 包含 kernel 及建立 rootfs 所需的所有套件
* 根據設定檔的設定, 編譯套件的 ipk/opk 檔
* 將編譯好 rootfs, 根據設定, 做成 flash 可接受的 image 格式, 以及完整 rootfs.tar.gz 壓縮檔

OE 的系統龐大, 如果工具不熟, 對於開發人員是很大的負擔. 熟悉後, 它的優點及缺點大致如下:

* 優點: 能夠快速而且彈性的建立新的跨平台 embedded 專案套件, 不需要自己trace OE 套件都維持在最新的版本. 分散式開發架構, 國外開放/嵌入社群熟悉的工具及交流模式.

* 缺點: 學習曲線長, 速度慢, 開發工作易被外部的套件更新影響, 把原先簡單的工作複雜化 (如不是自己開發的套件發生 bug, 原本只需要在 local patch, 重 build, 重新 package. 使用 OE 協調多個 team 可能要繞一大圈, 效率低而且容易溝通出錯)

如果要使用 OE, 我建議還是讀一次 OE 的手冊, 尤其是第 7 跟第 8 章講授的系統概念部份.除了 OE 官方的英文外, 大陸 developer 有翻一份中文的, 如果習慣大陸編程語法的程式員們, 可以參考 http://blog.chinaunix.net/u1/52172/showart_1346396.html

Openmoko 版的 mokomakefile 現在由於無專職人員 maintain 加上 download path 有變更, 所以如果使用網站上的 mokomakefile (from freesmartphone) 會出現一些目錄找不到導致的 bitbake python 錯誤. 但是不用緊張, 還是有 community 的 team 負責維護相似的 mokomakefile. 目前主要有法國 Bearstech 的 SHR (http://shr.bearstech.com/ or http://shr-project.org/trac) 跟德國 Micky 帶領的 freesmartphone.org http://www.freesmartphone.org/index.php/Main_Page . 不過據最近 (2009.8) mailing list 討論, Freesmartphone (FSO) team 未來可能會 based on SHR 的 distribution 開發上層 dbus based application framework, 不會自己再發行 FSO distribution.

使用 mokomakefile (或是 SHR 的 Makefile) 很簡單, 但是時間可能很長 (一般來說, C2D 機器第一次 build 可能會到一整天), 大概步驟如下:

* 在 ~ 下建立一個屬於該 distro 的目錄
* 用 wget 把 http://shr.bearstech.com/ Makefile 檔案抓下來, 放到目錄下
* 根據自己 OS, 參考 http://wiki.openmoko.org/wiki/MokoMakefile 的說明, 安裝 host 端 (PC) 所需要的基本編譯套件. 每個 distribution 不太一樣, 例如 SHR 還需要額外的 curl. 基本上編譯時請先看 download site 對應的 readme, 以及編譯時的訊息, 缺什麼補什麼.
* 然後 make 或是 make "套件名稱" 像是 make shr-testing 之類的
* 然後第一次大概需要等一天, 依所使用的機器不同而不同. C2D E6420 大須需要 18-24 小時. 同時 download 套件可能需要數 G 的容量.

編譯完後, 可以在 deploy 目錄找到, 如圖.

如果你有多台電腦, OM 的 developer 會使用 icecc 來做編譯的工作, 靠著 5-7 台左右的 quad-core 電腦網路分散編譯, 把完整編譯時間縮短到一小時內. 這算一個很不錯的使用 linux 編東西 hint 跟 technique.
在 2008 資策會創新應用服務研究所的開放原始碼行動平台研討會上, 我有整理一份 Openmoko 相關環境的介紹 http://t0ny.net/openmoko/doc/Openmoko_enviorment_n.pdf 可以當參考.

2009/8/2

被忽略的M2M (Machine to Machine / 物聯網)




近來好像大家的注意焦點都擺在小筆電, 或是智慧型手機平台這類產品上. 不論各家廠商如何行銷自己的功能 (多點觸控, 待機時間長, 便宜, UI 炫, 開機使用服務快不快) 但檢驗法則很簡單, 就是使用者 (人) 對於產品的接受度.

小筆電 (x86 based netbook) 目前基本上廠商都只能在 Intel 跟 MS 定下的規則下面玩 (螢幕尺寸, 使用的周邊 chipset, 甚至 Windows 版本). 接下來半年應該是看看 ARM based 的 smartbook 面世後, 看的是一般使用者對於效能及功能上的滿意度. 還有 netbook 跟 smartbook 的 BOM/Retail 價格是不是能重新區隔出一個市場.

Smartphone 智慧型手機看起來雖然家數很多, 目前能提供整合軟硬體的使用者體驗的其實只有 Apple (iTunes/App store) 跟 Blackberry (push mail). 不把 Google/Nokia/HTC/Samsung 算進去是因為 Google 不是自己作硬體, 而 Nokia 的 Ovi store 使用者太少, HTC/Samsung 並沒有使用者忠誠度高的軟體服務.

最近一則新聞沒佔到什麼版面, 不小心閒閒沒事翻 news 翻到, 引起了我的注意. 就是 Verizon Wireless 跟 Qualcomm 要合資組一間專做 M2M 的公司. M2M 是 Machine to Machine 的縮寫, 字面上來說, 就是機器對機器. 寫到這邊, 覺得本篇的標題下錯了. 因為, 今年暑假最 hito 的就是 M2M 啦, 連小孩都愛的 M2M...變形金剛啦!!!

基本上 M2M 涵蓋的範圍很廣, 簡單的例子, 從搭捷運用 RFID 卡到高速公路 ETC 易通機, 或者計程車隊服務都算 M2M 的基本應用. M2M 通常需要整合軟體服務架構及硬體設備, 以提供一個穩定的服務, 所以大部分都是以專案的方式進行. 這裡有一篇介紹 m2m scope 的內容可參考.
因為 M2M 中間並不會有 "人", 所以系統穩定性要求很高, 軟體服務設計架構與測試也比一般的 utility 難度高很多. 因為不管是工業應用上的 SCADA 或是移動式車隊服務, 考慮通訊時的狀態/通訊 handshaking 時間窗口/連線穩定都是很大的挑戰. 但是由於資訊服務是內嵌在 M 的 (machine), 所以 M (machine) 只要工作, 就會 "固定" 使用到這些資訊服務跟頻寬, 提供這些服務跟頻寬的公司就可以收到 $$. 這個 ecosystem 裡, 一般通常包含以下的角色:

* 硬體提供者: 製作硬體的公司
* 通訊服務提供者: 通常是電信公司或是網路營運商
* 軟體服務提供者: 提供特定的軟體後台, 以及通訊 middleware
* System Integrator: 整合軟硬體服務

目前專案 M2M 大概包含這些角色. 但是 M2M 是不是只有這樣呢? 前幾年因為專案的關係, 做過一些 M2M applications, 後來因緣際會 Project 剛好有機會接觸到 Dash Navigation 的公司 (前一陣子被 Blackberry 的 RIM 併購), 除了 GPS 導航軟體/通訊服務 (T-mobile/Google wi-fi network)/軟體後台 (JMS/Oracle) 外, 他們基本上扮演了第 5 種角色:

* 整合資訊流提供者: 包含即時路況播送, 網路搜尋, 以及其他 LBS (location based service) 相關資訊提供給 device, 同時 device 也將最新的資料透過內建的統計資料庫及 trigger 將資料即時 feedback 回資訊提供者.
傳統的 M2M 的資料都在原先建好的系統架構中流動, 跟外界基本上是隔絕的. 但是資訊流提供者的角色, 是將整合不同的資訊流 (政府即時路況/搜尋/車隊特定服務/ Telcom 網路) 不斷的將新的外界資訊 Push/Sync 到 Machine 中, Machine 也把資料回饋給外部系統, 讓 Machine 跟 Machine, 以及 Machine 跟人有新的互動可能性. 這也是目前許多 GPS/LBS 廠商, 想要整合的 "功能". 但是, 其實這是一個整合資訊流的新角色.
現在除了 LBS (location based service) 外開始有另一個新名詞 real-time GPS. 也許以後支援這類動態 + 即時 + 雙向交換資訊的 GPS (PND) 會貼一個 real-time GPS, 然後 powered by T-Mobile (or other Telcom) 也說不定.
Dash Navigation 提供不同的資訊流整合 (即時路況/搜尋引擎/來自各地的訊息) 技術, 透過客戶端 request 或將客製化的資訊 push 到每一台 device. 這個軟體 framework 是獨立在硬體之上的, 所以可以預見 RIM 以後, 有計畫提供這類的 LBS based push 服務 (push LBS?).
舉例來說, 這類服務除了可以幫你找附近哪間加油站便宜, 超商在特價外. 對商用人士的服務甚至可能幫你安排兩個人見面的最適當地點, 提供最有效率的評估, 提供建議, 並完成安排行程所有程序 (booking tickets/make reservations/etc).
Verizon Wireless 跟 Qualcomm 的合資 M2M 是只是朝 MVPN 邁進, 還是會像新的整合資訊流提供者呢?

2009/7/27

PMP 唸書感想 - 2009




這一陣子離開 Openmoko 之後, 多了很多時間可以做這幾年計畫要做, 但是一直沒時間做的事. 生活也恢復到比較有趣的狀態. PMP 考試是我其中一個前幾年預計要做, 但一直沒做的事. PMP (Project Management Professional) 是一個專案管理的認證, 不是拍馬屁的縮寫 XD . 從 2000 年之後, 專案管理也一直是一個蠻 hot 的 topic, 我想大概是因為這十年來, 許多的公司原本的 operation 模式都遇到成長的瓶頸, 需要新型態的管理與加強原有組織資源的運用能力, 所以專案管理雖然不是什麼新的學問, 但是這幾年在一般公司才開始比較普及.

對很多人來說, PM (project manager, 有些公司把專案經理叫 jm, 產品經理叫 pm) 就只是幫忙管 schedule, 協調人員/資源的一個角色. 但是實際上, 專案管理的範疇並不是只有這樣. 當然, 有去上過 PMP 課程的都知道 PMBOK 9 大流程: integration, scope, time, cost, quality, HR, communication, risk, procurement 跟 42 個子流程 (PMBOK v4). 看起來 9 個流程好像很多, 也不見得組織內會在 Job description 中遇到, 但是我自己的經驗是一定都碰得到, 只不過不見得是 PM 的執掌, 有些可能是其他 function manager 的勢力範圍. PMI 只是把整個 PM scope outline 出來, 這一點我覺得還不錯, 讓所有準備 PMP 的人有心理準備, PM 不是只把落落長的 schedule gantt chart 填出來就好. 就算要填, 可能也要把 critical path 跟 float/slack 一起確認出來, 不然考試就不會過 XD

不過, 只要是流程, 就有 overhead 跟最小經濟規模. 這一點 PMI 隻字未提, 用一句 organization assets 就帶過去了, 也不管你的 assets 是 ISO 還是 CMMI. 還有如何整合 PMI 的 knowledge 到組織系統中, PM 知道這些東西 (像是 project charter) 的重要是一回事, 能讓想要引進專案系統的公司或組織, 提供一個友善的升級或是銜接方法也是很重要的. 我想一般 PM 管 project 內部的事情就管不完了, 應該沒辦法花太多時間對相關專案執行人員解釋每個流程的重要.

在上課期間, 聽到 effective PM 跟 successful PM 這兩個名詞, 感觸還蠻多的. 因為很多人覺得 effective (有效率) = execution (執行力) = successful (成功) 這幾件事畫上等號, 誤以為把 resource 跟時間投下去, manager 們開始緊迫釘人, 不需要特別的 planning 跟 risk management, 不斷的變更 scope, 只要投入的 resource 夠, project 還是可以得到預期的成果. Effective 可以是一種 PM/Manage style, 但是不見得是專案 successful 的保證 (經常只是把錢燒光). 這幾個名辭中都有潛藏的意思跟條件, 不然他們就該是同一個字. 專案經理的職責, 應該還是要確認專案能如 project charter 設定跟 sponsor 的最終期望 (公司或專案成功) 來設定行為標準.

PMP 考題跟模擬題很多問題很有趣, 剛開始讀會腦筋打結. 因為實務跟 PMI 的理想還有一段差距. 問的問題都很實務, 雖然不見得標準答案很實際. 哈哈... 不過, 撇開考試不談, 一個有經驗的 PM 應該是把盡量把答案準備好來等問題. 如果遇到問題再找答案通常都是災難. 當然無法預測的是風險的特色之一, 但是 PM 對大部分問題 (技術問題 or business 的問題) 應該心裏要有底.

網路上很多 PMP 考試的準備方法, 我基本上也是 base on 這些方法. 因為以前微軟 :P 的試考太多了, 對 CAT 類型的考試還有 Prometric 都很熟啦 :P 加上以前 SD 的 70-300 或更早的 Windows Architecture 也是這類模擬兩可 = 看起來沒標準答案的考試. 就上完課當天就向 PMI 提出考試申請, 一個星期通過申請後, book 時間, 強迫自己念書. 雖然還蠻多人警告 PMBOK v4 剛改版上線, 等幾個月在考, 考試資訊會比較多. 但我實在等不及了, 想說做 PM 那麼久, 被 PMI 當掉也不過只是個被 PMI 當掉的 PM >_< 只是考試費 4xx USD...很貴的失敗代價 >_< 第一次 booking 時間約 2 星期後, 發覺唸不完. 趕快延幾天. 考試 200 題, 寫到 3/4 就覺得超累, 因為大部分都要想一下. 還好最後撐完而且有過...PMP 入手. 以前每次想說考完這一次, 就不要再考試了. 不過好像每次都有意外... =_=

2009/6/30

社群開發與嵌入式產品開發流程的衝突與妥協


Neng-Yu 'Tony' Tu
前幾個禮拜, 參加了資策會 OSS (經濟部工業局自由軟體產業應用推動計畫) http://www.oss.org.tw/ 主辦的 FreedomHEC2009 (http://www.oss.org.tw/dokuwiki/doku.php?id=freedomhec2009) . 今年在 Android 與 Moblin 的市場光環加持下, 加上工作人員也很努力的拉國外 key developer 來演講, 現場人數大概比去年多了一倍 (完全感覺不出來產業不景氣...哈哈).

Greg Kroah-Hartman 跟其他主要幾位主講人, 其實講授的內容都很實在, 對 kernel developer 來說, 有很多有用的 tips, 例如這篇 kernel report:
http://www.oss.org.tw/dokuwiki/lib/exe/fetch.php?media=kreport.pdf

提到以最近的 release 30 來說, 每天 kernel 平均增加 6500 行 131 個 changes, 這個數字看起來對一班人來說只是數字而已, 但是對很多公司的開發人員來說, 一直 trace 最新的 kernel 其實是有負擔的. 就台灣開發硬體產品的 cycle 來說, 大約開發一個全新的產品平均需要 6-8 個月, 以新 linux kernel release 週期為 15 週來看, 這一段時間 kernel 起碼已經跳了 1 到 2 個版本.

換句話說, 即使產品一開始如果就使用最新 vanilla kernel, 到出貨時, 先為了符合 GPL 而開放原始碼, 然後更有心一點再作相關 driver/patch upstream 的工作, 但為了適應新的 kernel 變更, developer 也還是需要額外的工作時間去適應新版本. 如果有公司想要像 beagle board (http://elinux.org/BeagleBoard) 一樣, 能夠讓產品直接 make omap3_beagle_defconfig 就可以透過 toolchain 編出 kernel 其實是需要時間了解 upstream 的模式. 主要包含:

* porting 前先註冊硬體資訊 (mach id..etc)
* 加入討論區, 適應 Linux community 的 coding/討論習慣
* 你要送 code 到哪邊 upstream (這顆 AP (Samsung/TI/Freescale) 的 maintainer 是誰, review 流程大概是怎麼樣)

這些都要實際 "加入" community (社群), 才能了解更多的細節. 這邊又卡到兩點 1. 開發人員本身的意願及英文能力 2. 製作產品的 RD 資源投入的時間是否應該在產品出貨後結束.

我在網路上找到一篇還不錯介紹 arm linux porting white paper 的放在這裡, 有興趣的可以參考一下. http://www.t0ny.net/foss/doc/porting/PortingLinuxKernel.pdf

因為 OEM/ODM 特性做習慣的關係, 不需要面對終端客戶, 在台灣典型的都把產品出貨當成是產品投入 RD 資源週期的結束. 但這一點, 對 community 來說, 產品到手 (hacking) 才是軟體應用可能性階段的開始, 是不太一樣的. Community base 公司的產品 (buglabs/beagleboard or LEGO like!!!), 等於把第一個產品當成是產品線的頭, 再慢慢展開看 community 需要哪些產品, 再逐漸充實產品的內容, 軟體可能增加支援的 platform (Android/Linux/Windows CE...) or 硬體 (更多的模組). 雖然這類的應用模式, 早就存在於常需要客製化的工業電腦產業中, 但是包括 Openmoko 在內, 蠻多的 (or 一部分) 趨勢都是朝著將原先客製化的模式, 帶到標準消費性產品中. 當然, 以目前這幾年的景氣 (2009-), 跟這些公司目前的狀況來看, 整個 biz model 都還在試水溫的階段, 但是最起碼提供一個產品開發的有趣方向.

一般只是拿 linux 當成是免費的 OS + 一堆好用的 utility 的一般硬體廠商而言, 是完全 or 至少一部分誤解了開放硬體的精神. 大部分廠商都停留在擔心自己的產品有違反 了 GPL 規定. 而不是利用 community 來開拓可能的市場, 及需要開放硬體專案的合作機會.

另一個矛盾就是, linux kernel "community" 只會一直 maintain 最新 2-3 個 kernel 版本, 與個例子來說, kernel.org 是不會一直幫 2.6.18 上 patch, 而是只會 maintain 目前 (2009.06) 最新的 2.6.28-30, 然後以極快的速度 (跟 MS 系統比較) 繼續往新的 release 前進. 這也是與業界的一般方式, fork 一份 2.6.24/26 的 kernel 下來, 然後自己 maintain 自己的 tree 的一般開發 (非 community) 方式有很大不同. 一般完全 fork 然後 maintain 自己藏起來的 tree 方式最大的問題就是公司最後只有少數 RD 能 maintain/patch 整個 tree, 所以公司的產品能力跟擴充方向, 也會直接或間接會受到這些 keyman 的限制. Maintain 一個 distribution 其實就是一件 "事", 如果又有其他的工作 overlap, 自己 maintain distribution 只好挖東牆補西牆, result 跟 quality 都不會太好.

當然在兩天的研討會過程中, 也反映出許多業界使用 Linux 開發, 跟融入 Linux 社群中的矛盾點, 主要的就是 release 原始碼 (源代碼) 的問題. 又想要 community 幫忙解決, 或是快速接受自己的硬體, 另一方面又不想或非常被動的 release source code. 當然 release source 有許多的問題, OM 都遇過. 包括產品中有相關 chipset 廠商的 NDA 問題. 不過這並不是無解, 或者說, 在產品開發選料前就要跟廠商談好, 不是產品要出了才進行 community friendly 工作.

在 OM 專案中, 最好的例子就是 wi-fi driver source code, 因為 FOSS community 不喜歡 binary 的 driver, Atheros 當時又是以非常 community friendly 的方式 release wi-fi 的驅動程式原始碼 (align with mainline source), 所以就溝通協調專案內容後 (我們使用的 AR6k fw 版本是 2.x), 就請 Atheros 新 release 一份對應的 GPL driver 給 OM. 當然除了 GPL 版本外, Atheros 還有另一份只能 release binary 版的 driver, 這也是 chipset vendor 經營開放軟體 community 常見的手法.

總而言之, 如果希望 Open Source Community 支援你想要接近 community 的產品, 我個人的建議是:

* 提交硬體 community 開發時, 底線是開放 kernel 部分的 source code, 最簡單的 release 方式打成 tar ball, 或文明一點放在公開 git/svn 上.
* 想辦法幫 community 或是對你的硬體有興趣的人, 解決他們的問題 (提供 documentation/跟 vendor 談 release 文件)
* 了解跟 community 成員的溝通方式
* 讓 key community member 盡早拿到硬體 (每間公司的策酪及考量不一樣, 但這的確是目前國際大廠 (you name it!!!) 為了接近 FOSS community 都在做的事), 但是不能期望這些 community key member 能提供有用的 feedback.

當然, 以上純就有興趣建立品牌或是接觸社群開發的專案. 若只是 OEM/ODM, 只要 spec 跟 term 清楚, 問題很單純, 大部分的公司, 都不缺乏這類的經驗.

很高興能在這類大拜拜場合 :) 遇到像是 matt_hsu 及 jserv, 以及目前在 0xlab 的 前 OM 優秀 developer (FOSS or not FOSS...haha). Real FOSS will be a life long way ;)

2009/6/17

Open Platform Player


Neng-Yu 'Tony' Tu

最近所謂的開放平台解決方案真是越來越多了, base on linux 的, 數一數已經有下面幾家 player:

* Intel: Moblin
* Nokia: QT, oFono, maemo
* Google: Android
* Palm Pre (http://opensource.palm.com/)

很多人可能不知道, Palm 的核心也是 linux, Palm 也有把 kernel 相關的 patch release 出來. 當然還有 LiMo 跟其他的 foundation, 但是 LiMo 是採會員制的 (Samsung's 採用 LiMo 後做出的 OMNIA), 會員才能取得完整的 source tree).

就連學習曲線很高的 OpenEmbedded 都有蠻多 company 開始 adopt (包括 MontaVista 開始用 bitbake), 雖然 OE 有時不見得是開發嵌入產品最適合的工具.

下面這幾間都是這幾年(最近)比較受到注意的公司, 也有用到 package system (like OE).

* Beagleboard http://beagleboard.org/
* Gumstix
* Bug Labs http://www.buglabs.net/

這幾間公司都有一些蠻有趣玩 embedded 的 idea 跟 community 互動的方式. 大家對 open source 及 community development 有興趣可以參考.

另外, 最近有一家做 open hardware 的樂器公司還蠻 inspire 我的, 他不是做一般的 embedded, 他是做樂器類的應用 http://www.zoybar.net/ . 我一直覺得做音樂的很多工具/模擬器/社群經營都比一般的 embedded 進步 :-P 軟體類如 propellerhead 的 reason 跟 ableton live, 硬體類也有一堆, 例如 http://www.generalguitargadgets.com/ , 可能是音樂跟流行本身就是需要交流產生新的火花吧, 跟單向的生產 -> 銷售是不太一樣的行為.

2009/5/10

Developing a FOSS / Linux friendly embedded hardware - component selection


Neng-Yu 'Tony' Tu

Hardware component selection seems like a easy job after people have google and digikey. But in real world, lots reason that make googled/digikey search result dose not mean it could be used in the mass production product. Mostly is not technical reason, but sourcing/SCM reason. Component sourcing/SCM (supply chain management) is one of the critical issue that will affect your design could go into real mass production or not.

Following are some aspect was considered during component selection process.

* Business relation:
Module vendor/chipset vendor always put business (either real money or just marketing) as first priority. Usually vendor or distributor will spent FAE/RD/support resource at confirmed customer, so it's not only about your money while you using their products into yours but also their money as well. Most hardware vendor need forecast required material quantities to
drive their upstream supply chain as well. We take LCM (LCD module) as example, if you buy module from vendor, they need to prepare:

* Flex print circuit cable
* LCM frame parts
* LCD Controller IC
* Touch panel controller chips and glass
* Many small components
* Negotiates with their factory in order assemble/delivery in time

Sometimes hardware providers will concern about of losing trading secrets/expose bugs with "open source" device. You have to clearly define about delivery target, what could release and what couldn't release to end customer, including:

* What is hardware delivery item/firmware version?
* Who should finish driver to specific firmware version?
* Documentation/source under what type license
* How to co-work on missing delivery? (Like GPL'ed version driver and re-distributable documentation).

All above will be continuous process during project period.

* Specification: Sometimes online chipset/module manuals/specifications are not updated one (or in-correct/non-function), especially those not release through official web site. There are some components I called: paper components, means not put into mass production yet or only vendor want to test the market response. Also, you have to understand specification very
well, because you also have setup acceptance standard/rules during whole process. Most embedded hardware won't fulfill every specification at design stage (durability/sensitivity/environmental tolerance/may others), you have to negotiate/track along the way.

Some vendor don't have linux friendly policy, you might not get source code of driver/testing tool. You may need to develop your own version, and find a way verify the specification before your linux driver ready.

* Unique/hard to source parts: If you using component that very unique in specification (like special cap value or fancy function). And this component could help RD simplify design or make life easier. For most developer, make mass production is not their responsibility, design good product is. Tricky part is: in many cases, using hard to source part will cause lots sourcing/logistic over head later (lead-time), and you might need to postpone whole production because of single component that seems harmless at design stage. You have to be very careful using unique/hard to source part if really want make a mass production-able device.

Some companies like using unique part as a lock (like own design function chip) to protect product, or using it as tool (like their own variation of PMU) to simplify later product design/verification cycle.

* EOL (end of life): Just like your cellar phone, electronics device chip life cycle is not long as you think. Most manufacture using the same part that "popular" device used, if "popular" device phase out (usually less than 1.5 years), sometimes component lead time will dramatically increase, because vendor will manufacture the part for you instead of moving stock around market. You your product design -> mass production period is too long (over 1 year), you must be very careful track your original deign-in part EOL date or specification change. Sometimes, you never get updated until you place next order. EOL is killer for hardware verification, for software need to have another round of test plan/driver parameter adjustment.

Some experienced people might ask: why so many industrial devices could grantee over 5 years or longer availability/replacement, answer is easy: they buy more as stock and sale product in higher price. So when manufacture stop fabricate component, they could still have on stock.

* Price: Including payment term/delivery method/tax. You could not get good price with reasonable quantities. This issue has nothing to do with software ;) but for PM, might need to keep an eye on it.

* Technical support: Most chipset/module will assign technical (FAE) and sales contact window after business cooperation. You may ask support from technical contact, usually including:

* Hardware testing/verification support
* Driver required document (may not release to public, but release to you as reference)
* Source code that under GPL license (or co-work develop one)
* Co-work on product development schedule (firmware
release/test/verification/bugfix/function add...etc)

Most of time component vendor only have driver to specific linux version (usually not updated one), and may use some strange rootfs combination. You have to double check what is "We have linux driver" means with FAE.

Component must have at least one of following charactics that makes it community/developer friendly component :)

* Full documentation, release in creative commons or re-distributable license, accessible from public Internet web site

* GPL'ed driver source, and driver already in upstream linux kernel tree is best

What is not acceptable is: binary driver and all documenation (user manual/datasheet/etc) under NDA, that developer could not easily track source and debug it. Sometimes vendor will only provide compilied/kernel specific driver, this is not acceptable format to FOSS developer.

2009/5/7

Developing a FOSS / Linux friendly embedded hardware - documentation and source code


Neng-Yu 'Tony' Tu

During past few years, I have been through all kinds of challenge while develop an embedded hardware project. Most software people do not need to know (also don't want to know ;) ) the difficulty and potential problems/issues about design/verification/component sourcing/supply chain/factory/quality control in hardware (or embedded hardware). The reason using English in this series posts because I think it will help more community people have general ideas about how hardware industry works, and also how to make requirement if want to provide a linux/open source friendly device to community (another reason: I could type faster :P )

For FOSS/Linux projects, there will be more requirements (sometimes special support) that related to hardware vendor (component or chipset) in order to get project process smoother also avoid potential IPR issues.

Recently, open source, open platform and some make schematics publicly (like Openmoko or beagle board) already a trend nowadays, but open source itself and hardware product provide schematics is not new concept. 20 years before, most 3C electronics still provide schematics as part of product; my Apple II+ also came with several manuals that contained full product details.

Since more electronic circuit embedded into IC, also devices became more complex. Instead of fixing it, people throwing devices away once it became non-functional. And what most customers used to are: simple device, limited function, with limited way to used it. Not like camera today ;) even have wi-fi transmission/gps capability.

Also more and more IPR enforcement process inside/outside company; branding company may not own full product knowledge and rights because out source the design to ODM company, and re-distribution rights of related documents. So, there is more and more technical (trading secrets/legal/IPR) and non technical (business requirement for product) barrier make public hardware information required by software/community development become difficult.

For people developing software that related to hardware, need following information from hardware (at least one of following item will be required):

* Complete documentation about component (chipset/module), document may need
re-distribution rights, or release under creative commons

* Driver source code (boot code and kernel driver), under GPL is best. But usually you only could get reference code from vendor with other license and also under NDA

Effective documentation will contains all necessary information (initial setting/registers/gpio/usage conditions), and you have re-distribution rights. A lot of component documentations were under NDA (sometimes even you could easily acquired from Internet, but you still under NDA), and you have to communicate to right people get the approval for re-distribution rights.

Usually, component/chipset vendor will provide following solution for
FOSS/Linux hardware:

* Component/chipset vendor might provide you a striped version of document that with full required information and you could re-distribute (very common for Intel, but rare for most embedded application processor vendor)

OR
* Provide documentation and full reference code (usually Windows mobile), but you could NOT re-distribute either one, you must write your own version

OR
* Provide a stripped GPL version of driver (means, some function was hidden - you never know). This is not ideal, but acceptable, sometimes..

OR
* Provide driver porting service, provide you binary and dynamic load-able driver with limited parameter information, this is not preferred/friendly format for FOSS community.

For module like wi-fi/GSM/Bluetooth, usually you need to know interface protocol (SPI/UART/USB/I2C), initial method, commands. For component like application processor/graphics processor/power management unit, you will need full documentation to provide a community friendly hardware product.

2009/4/23

一篇有意思的 Matrix (駭客任務) 影片分析

這幾天跟朋友因為討論一些粗淺的神學, 哲學問題, 又討論到 Matrix 這一部我很喜歡的電影, 以前我對這一部電影非常著迷 (and still), 所以會去網路找一些有趣的 review 來讀, 這一篇是我覺得寫的很好的, 然後寫信給原作者讓我翻成中文, 以前這篇放在當代的版上 ( http://www.modernmusician.com/forum/showthread.php?t=21417&page=2 ). 原 post 如下:

-----------------------

以下翻譯自 http://corporatemofo.com/media_and_mediocrity/the_matrix_reloaded_the_corpor.html 此由 Ken Mondschein 授權我中文翻譯此文,並作為非商業用途使用.

網路上也流傳一份有關 Matrix 3 的劇情說明,疑似試片影工作人員外流的劇情,以下網站中,有簡體中文翻譯第 3 集劇情,如果不想知道劇情的,請勿進入!

==========================================
在去看 Matrix: Reload 之前,我對於第二集是不是跟第一集一樣,有出色的特效跟打鬥畫面,並不是那麼在意。在第一集中,故事其實充滿著 Gnostic 的二元論哲學思

想。我比較關心的是 Wachowski 導演兄弟怎麼樣延伸原先的有趣故事,而不是一堆有阿沒的電影效果。那些武打啦,慢動作閃子彈啦的炫程度,遠比不上把我們這個世界,直接說成是假的來的猛。那些特效跟功夫打鬥,其實都是紅色藥丸 的糖衣,讓高中生跟一般人比較能接受這部電影 (自從我開始學習武術之後,發覺有許多超現實的隱喻在功夫裡面。像 Thibault's 的神秘圓圈走位方式還真是有趣。

注: Thibault's http://www.dctkd.org/bibliography/re....cfm?pubID=260

雖然大部分的人看不懂 Wachowskis 導演兄弟在 Reloaded 這一部片要表達什麼,注意力也都集中在公路追逐的畫面。但 Reloaded 並沒有讓我失望,那些畫面對我來說還好,比較驚訝的是那兩兄弟將死海捲軸 (Dead Sea Scrolls) 跟俄利根 (Origen...註)

的神學理論巧妙地用在劇本中,實在是非常聰明的想法。我明白劇中東出現一個人物,西出現一句的劇本實在很難令人了解。而劇情,只在飛車追逐跟動作畫面的休息時間出現。下面是對 Reloaded 這部片的一點解釋,如果你還沒看 Reloaded,請先忍一下吧!

Martrix 基本上就是基努李維的地下世界之旅 (跟阿比阿弟暢遊鬼門關蠻像的),如果 Neo 除了變超人那招外,帶著阿弟回到 Matrix 應該會更有趣。在金枝 (Goloden Bough...註) 書中有女預言家,在 Matrix 中有 Oracle 引導 Neo 進行它的旅程 (Oracle 可能並不如表面上看起來那麼善良,即使她沒惡意,但是把 Neo 拖下水也有它的一份)。

Neo 的第一個任務就是從 Merovingin 手中解救 Key Maker (Randall Duk Kim 扮演),Merovingian 是 Matrix 上一個版本所留下來的背景服務程式 (Merovingians 是 Frankish 王朝的統治者,後來被查理曼 (Charlemagne ) 大帝家族所繼承 (包括有卡洛琳 (Carolingians) 王朝及之後的卡佩 (Capetians) 王朝,他們相信自己有耶穌的後裔血統)。在我常去買燕麥捲跟豆奶的健康食品店裡面,大家都認為 Merovingian 是 Neo 的前身。但是從 Merovingin 在電影中對於人類情慾如此有興趣,我想到聖經創世紀 6:4 節中的內容: "那時候有偉人在地上、後 來 神的兒子們 、 和人的女子們交合生子、那就是上古英武有名的人 ........"。而天使與人的交合後,產生了許多的怪物 (吸血鬼跟死靈)......對應到劇情,就是以前 Matrix 程式所留下來的那一堆無法刪除的程式。從線索中 ( 即使 Merovingian 是前個世界留下來的人,它角色仍然像是冥王 Hades 一樣 (由他老婆叫 Persephone (冥后) 可知,掌管著地下世界的鑰匙。像是特洛伊 (Troy) 戰爭中的勇士 Aeneas 的嚮導 Sybil 女巫,給 了Aeneas 的金色樹枝,讓它順利進入地下世界。Neo 也利用 Key Maker 順利的進入 Matrix 系統中心。

接著經過一連串的戰鬥和爆破畫面後,Neo 終於殺進 Matrix 的核心,然後遇到了 Matrix 的建造者 Architect。如果你以為在 Matrix 中 Architect 是扮演上帝的角色,那你就錯了。從 Gnostic 派的看法中,建立世界以奴役人性的當然是撒旦而不是上帝。Architect 放出那一堆八爪章魚來毀滅 Zion,也代表開啟世界末日的序幕。我猜第 3 集 (Revolutions) 中會揭露誰在 Architect 後面搞鬼,那個人就是把 The One 送進 Matrix ,我猜它長得一定很像 Neo (譯註)。

其實重點是 Architect 跟 Neo 說的是真的還是假的,他說 " 99% 的人都相信 Matrix 是真的,但是還有 1% 的人不相信這個虛擬的世界 (相對於少數 Gnostic 教派的信仰者)。所以 Matrix 系統會變得不穩定,隨時有當機的危險" (所以電影中,在 Zion 出現的人多半是有色人種。如果你是白人,住在郊區的住宅區,開著你在 Matrix 的休旅車到 Matrix 的高爾夫俱樂部.....那幹嘛沒事找事懷疑自己所處的世界是不是真的?)

所以 Matrix 容許這些不相信 Matrix 系統真實性的人轉移到 Zion,然後他們可以定期清除 Zion 這些不合群的人。同時 Matrix 也創造出 The One 傳說,而 The One 其實是為了增強 Matrix 人性化,讓 Matrix 的存在更穩定的設計。然後 The One 就可以啟動 Zion 的毀滅程序。在馬雅文化及佛教中,這種滅世後重生想法經常出現,在馬雅文化中,目前我們正處於第 5 次循環,而第 6 次循環從 2016 年開始。

利用 Zion 跟救世主的預言,建立另一層 Matrix 的概念,其實出自於 French 哲學。這電影使用了波德來爾 (Baudrillard) 摹物與摹像 (Simulacra and Simulation),並加入了傅科 (Foucault) 和達希達 (Derrida) 的結構與解構主義的觀點。在他們的理論中,系統對於語言及其他社會功能的限制,只是間接展示控制權的工具。而預言本身就何其他的預言一樣,是信仰的一部分。John Zerzan 曾寫過信仰的目的在於操作符號 (signs),而那些預言也包含了某些控制目的。Zion 在 Matrix 中是一個應許之地,脫離了善惡的戰爭,人們身處其中而不會疑問存在的世界是否還是真實的。

要了解 Matrix 中的世界,還必須了解 Asimov's (埃席克•艾西莫夫(俄裔美籍,1920-1992) 的三大機械人定律 (Laws of Robotics),機器人如 Smith 之流,並沒有自由意志,即使脫離了 Matrix,他還是要苦苦追殺 Neo (在許多神學理論中,天使和許多其他具有神格的東西並不像人一樣擁有自由意志)。Morpheus (作夢之神) 在第一集說那些機器將人囚禁起來,當作生物電池之類的說明根本是放屁。機器統治世界之後還將靈魂思考關在 Matrix 中,是因為他們本來就是創造來服務人類,而且機器本身還是需要人來做一些選擇。所以機器並無法摧毀人性 (靈魂),反而需要人來做一些選擇。

正如 Architect 所說的 Neo 不是第一個,而是第六個.....但為什麼是第六個呢? 答案就是 Neo 之前的化身代表 Five Books of Moses 代表聖經中的舊約。 Neo (代表救世的基督,也代表著新約時期),跟他前面幾代 Neo 不同的地方在於他具有 "愛" (希臘文中的 eros) 的能力。在 Origen of Alexandria 的神學理論以及早期的基督教徒筆下,耶穌基督因為愛而降世救贖人性 。而 Neo 單字本身代表著 "新" 或換言之的新約時期。 Matrix 在這一次又一次的循環中,也遇到一個會為了 Trinity 而毀滅人性的不合邏輯決定的 Neo。[Note to the theology geeks who've been e-mailing me:

I know the difference between eros and agape, but Origen used both terms for reasons I'd have to delve into pre-Socratic philosophy to explain.]

當 Architect 給 Neo 選擇的時候,是讓他選擇純機器世界,或純人類世界,而不僅把 Neo 變成能重新清除並啟動 Zion 的工具,。Architect's 說 The One 的目的在於清除所有的人性,但是由於 Neo 具有人性的部分,所以機器並無法控制,讓 Matrix 間接變得不是真的能準確預測。Neo 在 Origen 的神學理論中就是基督的化身,能打破生死間的循環,讓人性有一個新未來。在影片的最後 Neo 跟 Smith 先生,都在所謂的 "真實" 世界得到了一樣大的力量,也間接證明了 Matrix 模擬不只一層,所以 Neo 在這兩層都有力量。

一些有趣的花絮:
* Neo 跟 Trinity 在拱廊下愛愛的畫面,和馬澳其賽的三位一體圖有異曲同工之妙 (原圖請參閱原文,而說明請見 http://ceiba.cc.ntu.edu.tw/th9_207/w...messages/5.htm
* The One 來自機械世界的說法,巧妙地讓基努李維避免掉許多無法表演的內心....(程式) 運作戲碼。
*在來自 St. Augustine's 的神學理論中,像是 Oracle 跟 Neo 的預知能力都可以得到很好的解釋。
*j我看電影的時候,旁邊坐了一個非常可愛的女孩

在第三部片子應該會揭露一些迷團:

* 誰在 Architect 後面搞鬼
* Neo 必須要做出一些選擇,但重點是 "選擇是什麼"
* 正邪間的大戰必定爆發,但打完後呢?
* Agent Smith 到底是幹嘛的? 他有類似驅魔的能力 (....一人方陣兵團),但是我打賭他會和 Neo 結盟.....
* Neo 為什麼會有能力在現實世界中,把機械章魚幹掉?
* Tank 怎麼掛的?
* Link 會再次見到 Zee 嗎?
* Niobe 會離開 Jason Lock 回到 Morpheus 的懷抱嗎?
* Gloria Foster (Oracle) 怎麼辦? 也掛了嗎? (他在 Reloaded 中拍了有不少的鏡頭, 但 Revolutions 卻沒有多少鏡頭)
* 教士服會變成流行服飾嗎?
* 那位給 Neo 湯匙的小沙彌有什麼關鍵性的意義嗎?
* Neo 會殺了 Bane 嗎? Bane 所損毀的 Zion 防禦有多嚴重
* 誰帶 Morpheus 去找 Oracle 的?
* 在第 2 集的 "真實" 世界如果也是假的,是不是有一層疊一層的 "Matrix" 呢.....(譯註: 果然是名符其實的 Matrix...Hehehe....)?
* 如果第 3 集 Zion 確定是假的,那麼 Neo 會將那些人帶到真的的世界嗎 (當然再怎麼樣會扯,這都是一部電影,他們當然跑不出來)
* Neo 會突然醒過來說 "幹,你一定不相信我做了一個什麼夢....?"

註 Origen of Alexandria 的參考網址 http://www.christian-assembly.org/se...0030309-03.htm

註: 西元843年凡爾登協約(Treaty of Verdun)將卡洛林王朝(Carolingian)劃分為法蘭西(France)與日爾曼(Germania)

參考網址:
查理曼大帝 http://homework.wtuc.edu.tw/~wenlurg/forghis/0226-6.htm

Gnostic 跟金枝 (Golden Bough) 說明 http://deepskies.virtualave.net/orig...hers_3zoro.htm
http://www.lsmchinese.org/big5/07onl...s/3-1/3101.htm

創世紀 6:4 節,有關諾雅方舟的故事 http://www.chinachristianbooks.org/

Kabbalah http://god.hifate.com.tw/icp/icp46.asp

Architect 在資訊科技產業 (IT) 代表的是能整合許多不同知識的資深工程師,台灣常翻成架構工程師

譯註: 我反而猜它長得像 Trinity (Most the Guy think Trinity should be the Guy, Right? ^_^ )

北京記遊 2009 04

最近 project 告一段落, 有時間到處走一走. 剛好有朋友在北京工作, 以前出差都在大陸南方跟西邊的城市 (上海/深圳/武漢/西安...etc), 也沒到過北京 + 外公也算北京人, 所以就趁機到北京感覺一下大陸首都的氣氛.

2009 4 beijing


北京的空氣感覺蠻像 LA 的, 都是那種乾乾的空氣. 然後地鐵很方便, 聽說是奧運前把整個路網完成. 除了長城跟 13 陵外, 幾乎所有的重要景點都可以坐地鐵到達, 算是非常方便. 可能北京經過奧運洗禮的關係, 整體的環境跟人文素質的確比一般人所認知的大陸城市要好很多. 從地鐵上拿 iPhone 跟 Nokia/Blackberry 的人數, 就可以感覺的出來 :)

當然不免俗的, 我也紫禁城/長城/13 陵/前門大街/王府井/頤和園/798 等等地方走了一圈. 到大陸腳力真的要好, 不然長城學校教科書遠拍的照片看起來都是平的, 八達嶺的長城的階梯大概起碼有 30-50 層樓高, 沒一點腳力真的會累死. 平地的頤和園走一圈大概也要一整天, 大概半天腳就軟了.

頤和園果然不虛此名, 園內建築集江南庭園山水之長. 雖然歷史上將甲午戰爭戰敗歸咎於慈禧挪用軍費修園. 不知現在到頤和園熙來人往的人群, 看到頤和園欣賞美麗的風景同時, 會不會對歷史有另一番看法.

798 是另一個值得去的景點, 這裡原先是北京將廢置的廠房便宜出租給藝術工作人員, 供創作及展覽的地方. 目前算是經營很成功的藝術展出場地, 也有不錯的餐廳跟定期展覽 (UCCA). 整個園區也需要 6-8 小時才能逛完, 雖然展出風格有些一致, 但還是非常的不錯, 值得一遊.

2009/4/2

找一台適合跑 Linux 的電腦


Neng-Yu Tu (Tony Tu)

一定很多人很奇怪, Linux 不是幾乎每一台電腦都能跑嗎 (還有人覺得爛電腦跑 linux 剛剛好 ;-) ) 這有什麼好寫的?. 如果知道當初為了找 Harald 選定 OM developer 要用的電腦, 親自跑了 4 - 5 次光華商場還找不到適合的主機板, 就可以理解我為什麼會把這件事挑出來寫一寫.

其實當初 (2007 年) 指定的規格並不複雜 ;)

* 網路晶片組必須要 Intel 或 Marvell
* Intel 整合式繪圖晶片組 (945G), 板子上必須提供 RGB 輸出
* CPU 要有 4Mbytes 以上的 layer 2 cache
* 要有 DVI add2 卡

由於大部分的電腦使用者都會買分離式的 3D 顯卡, 其實本來整合式顯卡的板子在台灣消費市場就不多. 因為缺了 3D 顯卡, 這類板子可能都是假設使用者是辦公室或居家消遣用, 搭配的網路晶片組大都使用 realtek 或 attansic 的晶片.

當初會想找 Intel 和 Marvell 網路晶片板子的理由是: 相對來說產品比較 community friendly (晶片文件, 說明, 原廠的 linux 驅動程式原始碼及支援), 同時還支援一些遠端開機/安裝等功能 (Linux driver supported). 最重要的, 據說穩定性有差, 但是我沒實際測過, 只好姑且當參考.

使用整合式顯示晶片的原因: 是因為 Intel 有一個 community type project 提供整合式晶片組, 支援 Linux 的 2D/3D 顯示驅動程式 http://intellinuxgraphics.org/documentation.html . 所以基本上你不需要另外掛 ATI 或是 Nvidia 的 binary 非 GPL 驅動程式, 還需要作一些雜七雜八的設定, 就可以 "有" 3D 加速的功能.

而 DVI ADD2 卡, 就是可以讓整合晶片組, 由原本的主機板內建的 RGB 輸出, 透過一張簡單 PCI 卡直接提供雙 DVI 輸出. 這張卡不貴, 可是可能大部分用整合式晶片組的人, 都不知道 Intel 主機板加一張 PCI 轉卡就可以有雙 DVI 輸出, 不需要另外買 3D 加速卡 (Windows 系統插上去也會主動認得, 不需要另外裝驅動程式, 神奇吧!!!). 不過 DVI ADD2 當初真是天殺的難找, 台灣大家都裝 3D 顯卡, 哪來的那種東西阿. 後來好不容透過採購管道, 找到 DVI ADD2 卡. 後來居然還有另一段插曲, 某個相關研發部門, 因為需要 DVI ADD2 卡做試驗, 而台灣的庫存卡被我們買光了, 還跑來找我們借卡試 driver.

CPU 要有 4MB 的 layer 2 cache 則是為了編譯程式的需求, 跟一般 2M 的比起來, 4M 大概可以快 20-30 %, 在當時 C2D 只有 E6420 的 CPU 有 4M layer 2 cache. 而且, 後來 C2Q 的 Q6600 有一段時間可能是因為庫存或是推廣, 賣的比 E6420 還便宜 (非常奇怪), 而且還有 8M layer 2 cache. 所以後來 E6420 買不到, 就直接升 C2Q Q6600. 結果是編 FR 的 kernel under 100 秒.

後來好不容易挑到一張 ASUS 的 P5GZ-MX 符合規格, 但是要買時, 945G 的板子又已經停產 . 台灣又沒有符合需求的 (此時發現國內廠商放在國外賣的板子種類, 跟料好像都比台灣本地要好...火...), 轉成 Gigabyte 一張 965G-DS3, 試完可以, 又因為採購的人找不到廠商願意客製化大量加保固. 後來還是輾轉買到 ASUS 某個 965G solution.

結論是, 每一個選擇, 都有背後的原因 ;) 後來果然大家也沒花什麼時間 tune driver 這 tune driver 那, 省了一些時間, 但是很多當初想要做的 fancy 功能也還是沒用到 (如網路安裝所有機器, 遠端控制...等). So, 還沒 implement 就開始 optimization 不是只會發生在 coding 上 ;)

下次各位有興趣, 可以試試找一張內建整合顯卡的主機板, 然後還是用 Marvell 跟 Intel 網路晶片的 solution 是不是很難 ...

2009/4/1

開放軟體社群專案 - 開發模式簡介, 工具名詞解釋


Neng-Yu Tu (Tony Tu)

拜微軟良好的 MSDN 及產業的 ecosystem 建立完整之賜, 加上超級強力的 IDE Virtual Studio. 一般習慣 "微軟" 開發人員進入到 Open source 環境的時候, 由於工具跟說明都是散在各個地方, 最大的問題是被一堆新名詞/新指令搞的頭昏腦脹, 或是不太清楚工具的功能或使用方式. 下面是一些常用開發名詞, 開發流程, 跟工具功能

簡單的解釋.

名詞-
* Autotools: 如果想讓你的程式能夠在各個不同平台下編譯, autotools is the ABC have to follow.
* Toolchain: 編譯跨平台程式需要編譯器組合 (for example: x86 base to ARM base)
* OE: OpenEmbedded 的縮寫, 透過 OE 提供的套件庫, 你可以編譯不同硬體架構平台相關的整個 rootfs 所需要的檔案.
* Bitbake: OE 使用編譯套件庫的 make. 一般編譯器透過 config 編譯出所需程式, bitbake 透過 receipt 編譯特定平台上的所需的: 單一套件, 多個套件, 或整個 rootfs image, 同時可協助處理相依性的問題.
* Monotone/git: OE 使用的版本管理平台, 以前是 monotone, 現在開始改為 git (git 最早也是根據 monotone 改寫), 透過各種 manifest (檔案的清單, 套件的清單, 清單的清單) 做為所有套件版本追蹤的根據.

我把 monotone/autotools/OE 相關的 usermanual 放在 http://t0ny.net/openmoko/doc/ , 最新的, 可以到 http://www.openembedded.org/ , http://monotone.ca/ http://bitbake.berlios.de/manual/ 下載. git 相關的可以很容易從網路搜尋到.

開發流程-

其實軟體的開發流程並不應該是有區分開放軟體, 或是一般軟體的差別. 現實生活中, 開發方式也跟組織方式和人力調配方式有關. 但是大型 "開放" 軟體專案, 因為可能 90% 以上的軟體元件或函式庫並不是由自己開發, 如果不想要自己管理每一個組件的版本及設計細節, 只有藉助像是 OpenEmbedded 的平台來提供相關的組件原料.

一般的商用 embedded system 套件, 大部分都是已經 freeze 裡面所有套件的版本. 有問題或功能增加時, RD 只需要更新裡面的少數套件. Windows Embedded 是這種方式的典型代表. 其他像是 MontaVista 也是類似的方式.

但是 Linux 及較不純的 Android, 因為加入了社群開發, 所以套件的修正其實是很頻繁的. 套件間又有相依性的問題, 所以要能夠自己 download source/patch, 及 daily build 的能力其實很重要. 要能Daily build 所有變更中的專案 source, 其實很麻煩 (簡直是惡夢), 所以需要 OE 這類平台及 bitbake 這類工具幫助. 當然, release 產品並不一定需要所有的 package 都是最新的, 除非是因為有某個開發模組的相依專案, 也一直在更新. 相對於傳統開發, 就等於是有多個不同小組同時開發一個大型專案. 但這種開發方式, 對於本身就是分散式開發的 Linux 是非常常見的狀況.

所以, 透過 OE (組織) 的 monotone/git (版本管理工具) 及 bitbake (編譯選擇工具) 及 bitbake 的 receipt (編譯條件實際內容清單) 來做版本管理. 通常 Open source 專案的 binary download 網站會有幾個目錄 包含專案不同階段的 binary 及 package:

* stable: 穩定版, 或是經過測試的 release 版
* testing: 開發版, 或是正在測試中的版本
* unstable: 直接 daily build 出來, 或是未經測試的版本

如果要 sync 不同小組的工作, 每個小組都必須熟悉相同的工具, 在 linux 社群中, 因為所有的大型開發都是分散式, 所以需要不停的 sync (daily build/daily update), 使用相同 source, 才能整合不同團隊間的工作及合作.

開放軟體的開發, 通常最大的難關並不是技術或是工具的使用上. 而是讓開發人員習慣將程式碼, 每天或是每個問題有初步解決成果後, 就提交到 mailing list 中討論. 而不是悶著頭把程式寫到非常完整, 或是非常複雜才提交. 因為在開放環境下, 每一個人都可能在作同一份工作, 遇到相同的 bug. 唯一有效率的方式是當解決問題後, 盡快的提交 mailing list 或 maintainer 審核. 避免其他人也在解一樣的問題. 因為一旦 fork 太久, 任何人寫的程式都很難再與其他人程式整合.

大部分我目前遇到的 opensource developer, 例如 (harald/werner/andy...) 等, 他們解完問題到提交的時間不會多於 24 小時. 並不是在短短時間內, 他們提交的 code 一定不會有問題. 而是專案進行的模式, 就是 relaese early, release often.

2009/3/26

who I am

當具備多種不同專長能力後, 很多事情到後來是對生活態度跟生活方式的選擇. 每個選擇, 會有現實的理由, 當然也有抽象的原因. 很多時候, 人的一部分自我都活在別人的猜測跟想像中, 真實的那個, 本人可能都不見得認的清吧!

所有抽象具像化, 唯一的結果就是失真. 我很想解釋, 但是唯一的方式就是用失真的範例, 透過破碎的共同認知, 傳達一個注定模糊無意義的訊息.

我只知道, 我愛音樂, 也愛電腦及各式科技帶來的可能性. 每個人在某個時間點, 都會遇到 Neo pick pill 的問題. And, you never know what the choice means...

Life is still moving forward...

2009/3/25

專注力 - Ichiro

昨天很難得的, 有閑也有心情看棒球經典賽. 打開電視的時候, 日本還以 1 分領先, 後來一連串拉鋸的過程很精采, 但是我真正有興趣的一瞬, 是 ichiro 面對 10 局上, 面對命運之神帶著一點挑臖意味, 關鍵打席的表現.

我對於 Ichiro 的印象就是 baseball monk, 就是把棒球運動當成是一種修行, 包括練習的態度, 對球具的尊重...等. 而修行的成果, 可以從一路以來, 在比賽中的穩定表現看出來.

10 局上, Ichiro 站上運命的位置後, 一直很注意他的眼神跟動作, 我很好奇, 在這麼關鍵時間, 關鍵位置, 關鍵表現. 到底是: 苦修的專注力勝利? 還是球是圓的, 一切都是運氣?

就在 Ichiro 跟投手展開一連串的纏鬥, 連挖地瓜的球都擊成界外後, 我突然覺得, Ichiro 的穩定表現不是僅是個人專注力, 專注力更進一步的影響了整個氣氛. 運氣變成專注力有機會表現的舞台.

最後, 很 Ichiro 的安打, 結束了兩隊的糾纏. 運氣也許讓他站上了決定勝敗的關鍵位置. 但我想, 在那一瞬間, 我只能從 Ichiro 眼中看到專注力, 沒有運氣.

It's a great game - thanks to all players in this game!!!

2009/3/13

FreeRunner 一堆使用上的小 trick


Neng-Yu Tu (Tony Tu)

一些使用上的小 trick, 陸續增加中.

* 抓圖

在 FreeRunner 上抓圖可以很簡單, 或是很複雜 ;) 最簡單也最原始的方式就是直接:

#./cat /dev/fb0 > file.raw

當然, 你也可以把 raw 的圖, cat 回螢幕上.

#./cat file.raw > /dev/fb0

作假的程式或預覽效果還蠻方便的 :-) Android 的 fb0 的路徑不太一樣, 在 screen/display 下.

接著透過 fb2png 將 raw 的圖檔變成標準 png 檔

#./fb2png file.raw file_not_raw.png 9 480 640 16

fb2png Binary 可以從以下網址取得:
http://t0ny.net/openmoko/samples/bin/fb2png/

* 使用 VM 上的 Linux 連結 FR

拜台灣 Windows 盛行之賜, 很多 Developer 都是透過 VM (virtual box/vmware/virtual pc/others) 使用 Linux 系統. 但是透過這種方式連接 FR 時, 需要注意連接 FR 時, "記得" 視窗的 focus 要在 VM 上. 這樣 VM 才抓的到新加入的 device (FR).

透過 VM 做 ssh 跟 dfu 其實都是 ok 的, 但是 dfu 在 VM 下有時速度會很慢, 或是 dfu 到一半中斷. 同時, 請記得 ssh 連線時要把 suspend (休眠) 關掉, 不然 ssh 連線會一直斷.

* Windows 直接連 FR
Windows 是可以直接 ssh 進 FR 的, 不過你要安裝 Windows RNDIS 驅動程式:
http://t0ny.net/openmoko/driver/neo_rndis/ 然後透過 putty 或是 tunnelier (http://www.bitvise.com/tunnelier), 做 ssh 或 scp.

基本上, 你可以把 FR 是一台小的 linux 電腦, 可以透過 USB/Wi-Fi/BT 甚至 GPRS 做 ssh/scp 的工作.

2009/3/11

使用 Freerunner 的三軸動作感應器 (3 axis accelerometer) - motion sensor


Neng-Yu Tu (Tony Tu)

自從任天堂的 Wii 跟蘋果的 iPhone 出現以後, 動作感應器 (or 微機電 MEMS 系統) 感覺一下子變成顯學. 這幾年也看到越來越多的應用出現在 iPhone 或其他的 Device 上, 最常見的還是拿來當樂器或是其他控制器使用. 例如:




不過這個 air guitar 跟 Accelerometer 可能沒什麼直接關係 ;) 只是提神用!!!

Freerunner 有 2 個 ST LIS320DL 的三軸動作感應器, 一個位在機器的左上方靠近 Aux 鍵的位置, 一個在主板的右下方靠近麥克風的位置. 一般的手機只需用到 1 顆, 就可以偵測目前手機的機身狀態 (朝哪個方向傾斜/加速度). ST LIS320DL 規格是偵測區間可調 +- 2g 或 +-8g, 丟資料的頻率可設成 100 Hz 或 400 Hz. 它還有可以設定的 interrupt 腳位. 可以在特定狀況下(自由落體, 靜止突然移動), 才發出 interrupt. 這兩個 motion sensor 一個有接到可把 CPU 從 suspend 喚醒的腳位上. 詳細的 datasheet 可參考下面的網址: http://www.st.com/stonline/products/literature/ds/12726/lis302dl.htm

這兩個三軸動作感應器可以同時使用. 但是在大部分狀況下, 1 顆就已經足夠. 2 顆 motion sensor 組合起來是可以做比較複雜跟精準動作偵測 (偵測角加速度, 而不是只是單純 3 軸), 或是進一步作 gyro sensor, 生物動作特徵辨認等 or something you could dream of ;-)

簡單來說, 有一點像是原先的 Wii Remote + MotionPlus





* 設定 Accelerometer

設定 Accelerometer 可以透過 /sys 下面完成, 不過因為 kernel 版本關係, 2.6.28 版之後, 相關的 sysfs 設定會出現在

/sys/class/i2c-adapter/i2c-0/0-0073/lis302dl.{12}

root@om-gta02:/sys/devices/platform/lis302dl.1# ls
driver duration modalias sample_rate threshold wakeup
dump full_scale power subsystem uevent

可以設定包括 threshold (觸發臨界值), sample (取樣頻率) 以及其他的 Accelerometer 參數. 可以直接透過 cat threshold 或是 echo 72 > threshold 的方式改變設定數值. 同時, 設定數值有時並不是以 1 為基數, 以 threshold 來說, 就是 18 的倍數.

* 讀取 Accelerometer 數值

Openmoko wiki 一樣有詳細如何讀取 motion sensor 資料的方法, 請參考:
http://wiki.openmoko.org/wiki/Accelerometer_data_retrieval

最簡單的存取方式 motion sensor 方式, 就是直接 cat Accelerometer 的 event 輸出.

root@om-gta02:/# cat /dev/input/event2
root@om-gta02:/# cat /dev/input/event3

event2 及 event3 分別是第 1 顆及第 2 顆 Accelerometer 的資料輸出.

Accelerometer 輸出的資料格式如下:

root@om-gta02:/# cat /dev/input/event3 hexdump
0000000 3fec 3896 ebe5 0000 0002 0000 ffb8 ffff
0000010 3fec 3896 ebf2 0000 0002 0001 0036 0000
0000020 3fec 3896 ebf7 0000 0002 0002 0414 0000
0000030 3fec 3896 ebfd 0000 0000 0000 0000 0000
0000040 3fec 3896 ee80 0000 0002 0000 ffb8 ffff
0000050 3fec 3896 eea9 0000 0002 0001 0036 0000
0000060 3fec 3896 eeaf 0000 0002 0002 0132 0000
0000070 3fec 3896 eeb5 0000 0000 0000 0000 0000

以第一筆資料來說:

3fec 3896 ebe5 0000 是時間
0000 0002 是事件的種類
接下來的 0000 是 X 軸, 而 0001, 0002 分別是 Y 軸及 Z 軸
ffb8 ffff 是 Accelerometer 的數值.

你可以參考 http://wiki.openmoko.org/wiki/Accelerometer_data_retrieval 的內容, 用 perl/python, 或是 C 來讀取 accelerometer 數值. Community 的 rui 也 donate 了一個程式 rotate, 可以偵測手機機身的狀態. Source code 可以從這取得:

http://t0ny.net/openmoko/samples/src/rotate/ 執行結果如下.

root@om-gta02:~# ./test
Types: a(2), b(2), c(2)
Codes: a(0), b(1), c(2)
Value: a(-792), b(-252), c(522)
left
Types: a(2), b(2), c(2)
Codes: a(0), b(1), c(2)
Value: a(-810), b(-252), c(558)
left
Types: a(2), b(2), c(2)
Codes: a(0), b(1), c(2)
Value: a(-810), b(-270), c(540)
left
Types: a(2), b(2), c(2)
Codes: a(0), b(1), c(2)
Value: a(-774), b(-270), c(504)
left
Types: a(2), b(2), c(2)
Codes: a(0), b(1), c(2)
Value: a(-792), b(-270), c(522)
left

* 利用 Accelerometer 作動作捕捉

基本上像 Wii Sport 之類的遊戲, 都是透過比較複雜的動作捕捉方式來完成, 並不是單純的讀某一個時間的 Accelerometer 數值達成. 動作捕捉並不需要 2 顆 Accelerometer (模擬 gryo sensor 才需要), 但是需要比較/紀錄不同 Accelerometer 資料以及作加速度計算等. 在 GSoC (Google Summer of Code) 上, 有一個透過 FreeRunner 來做動作捕捉的範例.





Source code 及可安裝的 ipk 在此, 還意外的看到了 bb 檔 ;)
http://code.google.com/p/accelges/source/browse/#svn/trunk

論文位址如下:
http://dev.borza.ro/demo/Motion-based%20Gesture%20Recognition%20with%20an%20Accelerometer/Paper.pdf
另一個有關把 motion sensor 專案當成遙控器的專案是 ReMoko, 程式分為 target 端及 server 端:
Source 在:

Google Developer 也有官方的 sample

http://developer.android.com/resources/samples/AccelerometerPlay/index.html

呵, 突然發覺還是有 tube 有真相.

2009/3/10

FreeRunner 的 Koolu Android 及 Android cupcake source 位置及 image 安裝


Neng-Yu Tu (Tony Tu)

Cupcake 是 Android 在 release 1.0 之後, 開發人員根據 Android 的 roadmap 及問題, 提供的 update 版本 (接下來的 codename 根據 wiki 好像是甜甜圈). 這個版本基本上是以一個 development branch 的方式進行, 所提供的 update 及 bugfix 最終會 merge 到下一個 Android 的 release 版本.
cupcake branch 的詳細內容 http://source.android.com/roadmap/cupcake
目前 android on Freerunner 已經 host 在 google code 上 (http://code.google.com/p/android-on-freerunner/), 完整 freerunner android cupcake source 放在 http://gitorious.org/android-on-freerunner 的 git 上.

Koolu 是 Openmoko 在北美地區的經銷商, 專注在 Android 在 FreeRunner 上的應用. 從某個角度來說, Koolu 是 FreeRunner 的 Android distro maintainer. 所以 Koolu 的 Android image 會每個月更新. Koolu Android maintainer 是 brian code 及 maddog, 相關的討論可以到 koolu 的 forum 找到:

http://forum.koolu.org/

Koolu Android Beta 4 開始, 提供了更簡單的 FreeRuuner 安裝方式. 同時, Beta4 及 cupcake beta1 最大的改變是取消了原來 FR Android 需要 SD 卡的限制. 同時, 安裝程序簡單許多. 安裝步驟如下:

* 到 http://koolu.com/~marcelo/ , http://code.google.com/p/android-on-freerunner/downloads/listhttp://t0ny.net/openmoko/images/android/ 下載 Beta4 或 cupcake 的壓縮檔.
* 將檔案解壓縮後, 直接 copy 到 fat 格式的 SD 卡 (不需要分割)
* 將 Copy 完的 SD 卡放入 FR, 按下 Aux 鍵後按 Power 鍵開機, 用 Aux 鍵選 Boot From SD card
* 安裝程式會自動完成安裝動作, 重新開機後即可進入 Android. 同時 ... SD 卡可移除!!!
另外, debug 的連現在 beta4/rc1 有一些改變, 以前 USB connection 都是 hook 在 usb0, Koolu beta4/rc1 開始 hook 在 eth3 (or ethx) 上.
原先的 debug 連線命令:
#ifconfig usb0 192.168.0.200 netmask 255.255.255.0
#ADBHOST 192.168.0.202 ./adb shell
新的 debug 連線命令:
#ifconfig eth3 192.168.0.200 netmask 255.255.255.0
#ADBHOST 192.168.0.202 ./adb shell
ADB tools 是 SeanMcNeil 提供的 tool, 可以從 http://t0ny.net/openmoko/util/target/ 下載 adb binary
 
Creative Commons License
著作 係採用創用 CC 姓名標示-非商業性-相同方式分享 3.0 台灣 授權條款授權.