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去
過了有理想的年紀 架構翻新不如穩定
架構沒有那麼容易 才會特別讓人著迷
剛出社會的年紀
曾經最用心 所以最開心 曾經