嵌入式設備網絡化、u盤化、功能復雜化的趨勢，使越來越多的、過去可以用裸奔實現的嵌入式產品，產生了應用操作系統的需求。

而人力成本的持續上升、芯片成本的連續下降，以及cpu性能的迅速提高，又為大面積應用操作系統提供了物質基礎。

本文和大家一起討論一下，從裸奔到操作系統，我們將面對什么挑戰。

1、速度

我們首先面對的，將是cpu運行速度的問題，毋庸置疑，操作系統調度需要cpu開銷，需要cpu有更高的速度來彌補；再者，嵌入式系統經常用于實時控制，需要較高的定時精度，縮短tick時間間隔有利于提高控制精度，嵌入式系統中經常使用1mS甚至更短的tick間隔。然而，tick間隔越短，調度開銷就越高，同樣需要更高的cpu速度來彌補。當前日益提高的嵌入式cpu的性能，甚至單片機都32位了，很好地回答了這個問題。

2、內存容量

先討論一個問題，一個原先需要50K內存的裸奔程序，如果移植到自身開銷1K內存的RTOS下面，需要增加多少內存？是51K嗎？

有許多嵌入式操作系統，都把運行操作系統的內存開銷作為主要性能指標，有些甚至聲稱不到1K內存就可以運行。但我們千萬不要被誤導，以為用操作系統需要的內存與裸機差不多，只要比裸奔程序多那么1K、2K就行了。操作系統會使應用程序所需要的內存暴增，使用操作系統所增加的內存需求，主要來自以下方面：

1) 運行操作系統本身需要的內存。2) 創建線程控制塊、消息控制塊等操作系統組件需要的內存。3) 每個線程配置獨立的棧所增加的內存需求。

其中第一項很好理解，幾乎所有操作系統都會給出這個指標。第二項也容易理解，不用操作系統的情況下，我們常常定義標志位或全局變量來在不同模塊之間傳遞信息，需要的內存就很少。而操作系統模式下，需要用到同步、互斥、線程間交換數據等，這就需要使用信號量、郵箱等操作系統組件，信號量需要分配信號量控制塊，郵箱需要分配郵箱控制塊……，這些，都需要消耗可觀的內存。許多操作系統標明的，僅僅是OS本身運行需要的內存，并不包括信號量控制塊拉、郵箱控制塊拉等等這些操作系統組件需要的內存。

我們知道，一個僅運行OS的系統，是毫無意義的，真正實現產品功能的，是應用程序。而djyos的si版本，大約需要的10K內存，則包含了一定數量的事件控制塊、信號量控制塊等操作系統組件所需內存的條件下的，完全滿足一個小型系統所需。

說了半天，其實也只講了操作系統對內存需求的冰山一角，OS下編程，對內存需求的影響最大的，當屬OS的多線程并發特性，這使得我們要為每一個線程分配獨立的棧。下面我們定性分析一下棧獨立化帶來的內存需求變化。棧是用來保存函數參數和局部變量的，可以說，有函數調用，就有局部變量。在單線程環境下，應用程序需要的棧，幾乎就是main函數需要的棧，而在多線程環境下，每個線程的棧是獨立的，分別等于該線程的線程執行函數所需要的棧，而系統總的棧需求，就是所有線程的棧需求之和。

在超級循環中，分別調用了func1~func5這5個函數，他們的棧需求分別是10K、5K、9K、8K、9K。調用func1時，系統分配10K的ram作為棧，func1函數返回，這10K空間將被釋放，并且再次分配給func2使用，所以，整個程序的棧需求，就是這5個函數中需要棧最多的那個函數需要的棧空間：10K。

如果要把這個程序移植到OS下，最簡單的方法就是創建5個線程來調用func1~5這5個函數，這5個線程需要的棧分別是10K、5K、9K、8K、9K，而這5個棧是獨立的，不能共用，程序總共需要的棧空間是（10+5+9+8+9）=41K，線程棧一般是從堆中動態分配的，考慮到動態分配本身的開銷，硬件須準備50K以上的內存用于程序的運行棧。一下子增長到5倍，沒想到吧。

可見，上操作系統，雖然操作系統本身不需要很大內存，但會極度增加應用程序的內存需求。做項目時，一是不要盲目上OS，要根據需求綜合考慮，二是設計硬件系統時，應該充分考慮到內存方面的需求，配置充足的內存。

3、人

任何產品都是由人開發的，所以，討論嵌入式產品開發的任何話題，都不能離開人的因素，科技以人為本嘛！從裸奔到操作系統，那么程序員，也將由編寫裸奔程序轉為在操作系統下編程。這些迅速、大量增加的程序員，他們可能習慣了在裸奔環境下編程，他們可能是化工、建筑、地質等不同行業的專家，他們也許已經上了年紀，沒有太多的精力學習多線程編程等知識。然而，涉及到專業的程序，仍然離不開他們，如何從技術上降低他們的入門門檻，是一個亟需考慮的問題。但是，普通的操作系統下，你不掌握線程控制技術，就無法編寫正確的程序。djyos允許你按事件編程，沒有任何跟線程相關的api函數，無需程序員掌握線程技術，客觀上降低了裸奔到OS編程的轉換技術門檻。