Firmware 沒有那麼容易 不只 Function Call 來 Call 去...

個人於上個月底離職了
主要因素是需要一段時間休息運動和調養身體
這段空檔時間, 按照慣例一樣作了一些目標設定
算是去年一月空檔時弄Prex的延續, 然而平台已經不是S3C2440
在告一段落後, 希望能藉此能有更進一步的突破

回想這幾年, 由於工作因素不斷地在 linux 與 embedded os 間交錯
對於 firmware 相關工作日漸有些許不平之鳴
而這些林林總總, 多半在所謂良善管理與時程下而掩蓋

改寫"沒那麼簡單"歌詞: "Firmware 沒有那麼容易, 不只 Function Call 來 Call 去"
道出了 firmware 的甘苦辛酸

若以公司為出發點的角度去思考
Firmware 最大的困難之處或許不在於 coding 實作本身
而是在於相關工作難免接手的人來來去去.
這樣的情形下, 一旦 Firmware 在介面與架構缺乏良好規劃的前提
在接手/參與的人無法完全熟悉的情況下, 為了盡快地完成任務, 也只能依樣畫葫蘆
只是如此時間一拉長, 經手的人一多, 就會轉變為一個悲劇.
換來的是, 日漸膨脹混亂, 開發與除錯時間逐漸地延長.
即便在此看來簡短而淺顯易懂, 但諷刺的地方在於, 這部分很容易被管理階層所忽略

這裡舉個常見現象作為例子
一個以 MP3 player作為起始產品時可能僅支援 MP3
而在 IC 中需要 Hw 需要的功能是 Audio playback, SD Card, LED display, Buttons.
軟體上需要的就是 FAT FileSystem 與 MP3 decoder
硬體的 Audio Hw 通常透過 Interrupt 去擷取需要輸出的 audio buffer
這個 case 就是 mp3 decoder output buffer.
接著藉由某種 message 傳遞通知 decoder 繼續 decode
這樣的情況下, 很有可能的方式就是直接在 ISR 中取用 MP3 decoder buffer

然而隨著 audio 格式一多 aac, ogg ... etc
依樣畫葫蘆的結果就是針對不同codec的一堆Audio ISR
最後就是演變成 policy 與 mechanism 混亂的情形
隨著規格要求不同有不同與交錯混亂的 path
這樣的問題並不侷限在這方面, 而是廣泛見於各種軟硬體程式介面上
像是 File System, 多半好一點都會將 FS 與 flash device 做個 layer
慘一點的 flash device 與 filesystem 混著寫也是有的
鮮少見再將 SD/NAND/NOR 的 protocol 與 device 分離的實作

更不用再多說由於多數Firmware 的 monolithic 特性
很容易在缺乏訓練之下或是為了急就章, 任意呼叫不適當的 function
因而造成日後專案維護性與移植性的低落

的確很多時候是用不到 Linux 這樣龐大架構的系統
然而相對而言的lightweight OS更需要心力去維護良架構.

最後是之前隨手改的詞, 博君一笑..

=================================================

沒那麼簡單 就能寫出想要的方案
尤其是在 firmware 年久失修又雜亂
總是不安 只好硬幹
誰謀殺了我的責任感

沒那麼簡單 就能去改 別的全不看
變得實際 也許好也許壞各一半
不愛加班 一久也習慣
被老婆唸勝過被老闆狗幹

靈感來了就快Coding去
感覺累了就聊天打屁
主管的意見 隨便聽一聽 自己作決定
開會不想投入情緒
一杯咖啡配coding
在周五晚上 關上了手機 免得六日被Call去

Firmware沒有那麼容易 不只 function call來 call去
過了有理想的年紀 架構翻新不如穩定
架構沒有那麼容易 才會特別讓人著迷
剛出社會的年紀
曾經最用心 所以最開心 曾經

OpenGL 4.0 specification released.

上週引起廣大討論的新聞莫過於 OpenGL 4.0 規格的釋出
眼尖的人可以發現 GLSL 的版本編號與 OpenGL 一致了
(不再像以往有著不同的編號: ex: GLSL 1.4 - OpenGL 3.1, GLSL 1.5 - OpenGL 3.2)
同一時間 OpenGL 3.3 規格也釋出了
OpenGL 3.3主要目的在於盡可能導入4.0的功能, 提供OpenGL 3.x世代硬體所能利用的 4.0 特性
詳細關於 4.0 的介紹可以參考這篇

特別的新功能在於
1. 兩個新的 shader 來處理 geometry tesselation
2. 能夠使用 OpenGL/OpenCL 計算出的資料來繪圖 ( 如此將可大幅降低CPU運算, 也降低CPU 對於CG, Gaming 的重要性, 可以預期的是與其花大錢買高速CPU, 其效應可能不如省下來買張中階顯卡還有找 )
3. shader 支援 倍精準(double) 浮點數運算, 以增進繪圖的正確性與品質.

Linux kernel 2.6.33

Linux kernel 2.6.33 在 Feb 24th, 2010 釋出了
主要的更動可以參考 kernelnewbies 與 H-Online 的What's new in linux 2.6.33這篇

這個版本受到注目在於
1. 整合Nouveau - open source nvidia 3D driver (Nvidia 並無提供協助, 主要是以逆向工程實作)
2. 整合DRBD - Distributed Replicated Block Device, 能視為基於網路的 RAID-1 實作
3. 整合Compcahe - 提供 Ram-Based Compressed Swap Device, 主要是切割出一塊記憶體空間, 將需要swap-out page資料, 壓縮後存放. 如此達到在記憶體中放置更多page 的目的, 減少 Harddisk IO(現今 CPU 壓縮/解壓縮 速度勝過對 HardDisk 讀寫), 提高效能.
4. Android removed from the linux kernel - 相關細節請參考 Android and the Linux kernel community (關於文章作者Kroah), 在今年二月初時此事在各大資訊相關網站廣受討論.

from linux thread to protothread

去年在使用 buildroot/uClibc 環境移植 linux 過程中
由於編譯時對於 thread 選項選取預設的 linuxthreads 而非較為完整的 NTPL
因 thread 行為模式的緣故, 造成 IP 廠商提供的 OpenGL ES 環境無法正常運作
當時觀察到主要的錯誤在於每個 thread 取得的 pid 是不相同的
明顯地, 這不符合 thread 一般的認知, 然而這也與 linux thread 實作演進有相當的關係
(而linuxthreads 演進到 NTPL 的過程, 請參考 wikipedia 上的關於linux thread的歷史, 這裡就不詳加說明.)

在碰到這樣結果的當下, 稍微感到有些訝異
現今 thread 的概念在 OS 教科書中是一大重點
而 thread programming tutorial/guide 更是垂手可得
利用 thread 來改善系統效能, 更是常見於日常的程式中
這些資訊多到讓人產生一種 thread 的存在是理所當然似地
看著 wikipedia 中對於 thread 的說明, 跟教科書其實相去不遠

撇開 user-level/kernel-level 的優缺 和 1:1, N:1, N:M 的 Model 不同的理論不談
kernel-level threads 間的 context switch 可能可以較容易理解, 或是寄情於OS的能力
其中最引人入勝的莫過於 user-level threads 間又是如何達成的?

對於 user-level thread 的考量點有二
1. 如何於 user space 維護 thread context
2. thread switch 的時機點
preemptive or non-preemptive

其中 1.又取決於針對 2.的考量決定複雜的程度
可以想見, 可能必須在 process 中建構屬於 thread 的context
從 PC register, stack, 甚至可能細到 signal, 取決於實作的規劃

複雜者可能如 FSU Thread 在user-level 中實作了 POSIX thread

另外常見的 user-level thread 方式是提供特定的 I/O 與 switch API
讓 programmer 決定可以選擇切換的時機
這類者像GNU Portable Thread 即為一例
對於 GNU Pth 的細節技術可以參考這篇論文
主要在於使用泛 unix 的 ucontext/setjmp 支援

然而確也可能簡單到像 Contiki 中使用的 protothread
(與 coroutine 不同的地方在於 protothread 是 stack-less)
其概念可以拜讀 Simon Tatham 關於 coroutine 的大作
jserv 於 2006 年也對 coroutine 做了簡單的介紹
其精神在於僅存放 thread 所在的狀態, 以利於切換時跳至正確的位置

由於不停地在 thread 中切換, 若 thread 的 execution time 過小
搭配 sleep 的時機不佳, 簡單者是浪費 cpu 的 busywaiting
然而延伸而言, 卻也會影響 scheduling 與 cpu freqency 切換的判斷
而需要 computation 時, thread 間執行時間的比例, 與 sleep 可能造成降低效能
而這些都與使用 user-level thread API 實作 thread routine 的方式有很大的關係

儘管 thread 帶給 programmer 許多便利性
然而需要注意 thread 在各種環境下的特性, 才能夠正確地使用

HiRadioTray 20100109 & Hinet Radio Script 20100110

HiRadioTray 20100109
檔案連結: HiRadioTray_20100109_ubuntu910_i386.deb

1. 根據 Hinet 更動了 mms 取得方式
2. 修正 奇美古典音樂網 格式
3. 修正更新功能

由於個人疏忽, 20091010版無法使用更新功能

使用 20091010 版本的使用者:
安裝更新檔者:
請移除 ~/.HiRadioTray 目錄後再執行程式即可

不想安裝更新檔者
請到此下載 update.sh 並覆寫原本 ~/.HiRadioTray 下的檔案, 以修正更新功能
請到此下載 get_mms.sh 並覆寫原本 ~/.HiRadioTray 下的檔案, 以修正收聽功能

Hinet Radio Script 20100110
檔案連結: radio_20100110.tgz
或執行 update.sh 更新即可

打造簡易監控系統 - ffmpeg + lighttpd

(TODO: 附圖)

由於個人與老婆必須工作, 平日就將寶貝女兒託給爸媽照顧
在家中, 女兒目前待在三樓塌塌米房間
然而難免會有需要短時間離開處理一些事務
能清楚知道baby何時醒了和哭了的時間很重要
因此母親希望能夠架設視訊系統, 方便在一樓能知道三樓狀況

的確, 最快的方式就是購買現成IP Cam產品
想想這部份的技術並不是非常高
所以第一時間想到的就是擺放在家中當床頭機的 EeePC 701
(老實說, 現在有點慶幸當時買的是有Webcam的版本, 那時嚷嚷我只需要長效電池)

接著就是作 video streaming 了
其實依開始我想到的是使用 VideoLan 來作
然而設定/使用與過高的CPU loading都不讓人滿意
加上是給父母操作使用, 使用過程愈簡單愈好

朝 flash video 方向尋找方案, 發現 ffserver/ffmpeg 是個不錯的選擇
參考ffmpeg的這篇討論文章, 搭配需求將設定檔做了些許更動
像是加入了Audio部份, (ffmpeg 的啟動指令亦必須加入 -f oss -i /dev/dsp)
另外提高VideoFrameRate至15, 移除了 VideoIntraOnly, 加入VideoGopSize 以降低bitrate
原本只打算使用 swf 格式, 如此browser 可以直接開啟播放
然而個人設定 SWF 搭配 Audio一直無法順利啟動
(如有設置上限制, 歡迎告知指正)
只好轉而使用FLV, 測試後,VGA frame, 15FPS 加上 Audio
在 630Mhz 的 EeePC, CPU loading 約為 50~60% (打開900Mhz 模式, 降低到 33%~40%)
設定好後, 假設存檔為 webcam.conf, 如此執行指令 "ffserver -f webcam.conf"
就可以在 http://MACHINE_IP:8090/webcam.flv 收到 streaming video/audio

使用 FLV 相較於 SWF 比較麻煩的是需要 flv player
browser 上需要 swf 元件來處理 flv video
網路上免費solution不少, 像是37-flvplayer.swf與GPL的flowplayer
最簡單的方式, 就是寫個 HTML, 連到提供該元件的主機, 搭配 flv 來源URL
為了降低對外部網路系統的依賴, 搭配輕巧快速的 lighttpd 來使用是不錯的選擇
(Apache?! 殺雞焉用牛刀.)
下載好 swf 元件, 依照各個swf flvplayer 規格撰寫個簡單的 HTML
放置於 /var/www 後就完成了

如此, 一樓電腦打開browser, 設好首頁, 就完成了

想想, 在 embedded 產品上, 將 hw codec 整合至 ffmpeg 是個不錯的作法
如此很快就可以建立具有網路傳輸功能的分散式 IPCam

關於 Chrome OS 的另一觀點

今日很榮幸受到先前在NCHC主管Steven的邀請
分享一些關於Chrome OS 與 GO 程式語言的心得

Chrome OS Observation

View more documents from Champ Yen.

在Chrome OS推出時, 難免將此與Google 要正面挑戰 Microsoft 做連結
並且以個人裝置的用途來思考, 因此Chrome OS也就相形見絀
在此回歸以Chrome OS的三大特性 - 快速, 簡單, 安全的方向思考
也許 Google 所規劃的是不同方向的佈局