在IC設計公司，有一部分的軟體工程師需要與IC設計師緊密合作，負責驗證相關硬體模組功能與驅動程式撰寫。在硬體設計初步完工階段，通常會先在FPGA上進行邏輯方面的軟體驗證，通常軟體在此時會以最簡單的方式，準備好C語言運行環境後，進行bare metal上的控制，確認無誤後，才送交後端進行timing的調整。如果是功能較為豐富的SoC，還會在FPGA上運行完整的作業系統（如Linux），確認在實際應用情況下，所有功能仍然如預期般執行。
bare metal控制的好處是環境單純。容易確認問題是在某個步驟所發生，而且執行效率極高。另一方面，運行作業系統的好處不言而喻，但缺點就是摻雜了太多額外不相干的環節，並且由於FPGA效能問題，一段時間能進行的測試次數相較於bare metal的環境往往少一個數量級以上。所以，我們有時會需要以bare metal為基礎，往上逐漸添加部份系統功能以協助驗證工作。
其中一項常見的需求就是：bare metal環境通常沒有多工能力，但我們需要確認某幾個硬體功能"同時"運作時，是否會有系統執行問題？（bus hanged, interrupt lost, hardware state錯亂...）
為了這項功能，許多人的選擇是想辦法運行完整的作業系統來確認，但在初期的環境準備與後續的除錯，都常常耗費大量不必要的精力與時間。所以有些人則是在bare metel的環境下，以各種怪招來實現不同硬體動作"同時"運行的效果，比如說在某個硬體的ISR中，去驅動另一個硬體的read/write。這種作法往往誨澀難懂，並且掛一漏萬。
其實如果只是要達成上述需求，我們可以有更乾淨的作法：一個簡單的scheduler。只需要準備：
- context switch
- task structure與其獨立的stack
- timer interrupt
- ramdom timeslot for task
而task間的同步機制通常直接開/關中斷，也就足夠了。不太需要實作完整的task state machine。也就是說，基本上只要將"一步步寫嵌入式操作系統"一書的最後一章的範例程式稍作修改，即可備妥以上基礎設施（大概不到200行C與assembly）。有圖有真相，以下是我在實際工作中應用的快照：
有了這個scheduler，我們就能將個別硬體的操作分別運行於不同task，然後運行一段時間，如果都沒太大問題，我們就可以具備足夠信心，絕大部分的切換設定組合與硬體"同時"運行情況都有打到過了。頂多再輔以幾個用怪招建出的special cases，去確認某些特別擔心的組合即可。等到這些測試都過了，對於運行於複雜的作業系統的信心便會大增，也減少了debug時間。
所以啦～學習作業系統是很實用的。不只可以加速對於功能複雜的系統程式的學習時間，個別技術也具有自身實際應用的時機。或許，哪天還真的有自己開幹kernel的機運亦未可知啊... :-)
留言
張貼留言