想了很久，要不要寫這篇文章？最后覺得對操作系統感興趣的人還是很多，寫吧。我不一定能造出玉，但我可以拋出磚。 包括我在內的很多人都對51使用操作系統呈悲觀態度，因為51的片上資源太少。但對于很多要求不高的系統來說，使用操作系統可以使代碼變得更直觀，易于維護，所以在51上仍有操作系統的生存機會。 流行的uCos，Tiny51等，其實都不適合在2051這樣的片子上用，占資源較多，唯有自已動手，以不變應萬變，才能讓51也有操作系統可用。這篇貼子的目的，是教會大家如何現場寫一個OS，而不是給大家提供一個OS版本。提供的所有代碼，也都是示例代碼，所以不要因為它沒什么功能就說LAJI之類的話。如果把功能寫全了，一來估計你也不想看了，二來也失去靈活性沒有價值了。 下面的貼一個示例出來，可以清楚的看到，OS本身只有不到10行源代碼，編譯后的目標代碼60字節，任務切換消耗為20個機器周期。相比之下，KEIL內嵌的TINY51目標代碼為800字節，切換消耗100~700周期。唯一不足之處是，每個任務要占用掉十幾字節的堆棧，所以任務數不能太多，用在128B內存的51里有點難度，但對于52來說問題不大。這套代碼在36M主頻的STC12C4052上實測，切換任務僅需2uS.

　　一。什么是操作系統？

　　人腦比較容易接受“類比”這種表達方式，我就用“公交系統”來類比“操作系統”吧。 當我們要解決一個問題的時候，是用某種處理手段去完成它，這就是我們常說的“方法”，計算機里叫“程序”（有時候也可以叫它“算法”）。 以出行為例，當我們要從A地走到B地的時候，可以走著去，也可以飛著去，可以走直線，也可以繞彎路，只要能從A地到B地，都叫作方法。這種從A地到B的需求，相當于計算機里的“任務”，而實現從A地到B地的方法，叫作“任務處理流程” 很顯然，這些走法中，并不是每種都合理，有些傻子都會采用的，有些是傻子都不采會用的。用計算機的話來說就是，有的任務處理流程好，有的任務處理流程好，有的處理流程差。 可以歸納出這么幾種真正算得上方法的方法： 有些走法比較快速，適合于趕時間的人;有些走法比較省事，適合于懶人;有些走法比較便宜，適合于窮人。 用計算機的話說就是，有些省CPU，有些流程簡單，有些對系統資源要求低。

　　現在我們可以看到一個問題： 如果全世界所有的資源給你一個人用（單任務獨占全部資源），那最適合你需求的方法就是好方法。但事實上要外出的人很多，例如 10個人（10個任務），卻只有1輛車（1套資源），這叫作“資源爭用”。 如果每個人都要使用最適合他需求的方法，那司機就只好給他們一人跑一趟了，而在任一時刻里，車上只有一個乘客。這叫作“順序執行”，我們可以看到這種方法對系統資源的浪費是嚴重的。 如果我們沒有法力將1臺車變成10臺車來送這10個人，就只好制定一些機制和約定，讓1臺車看起來像10臺車，來解決這個問題的辦法想必大家都知道，那就是制定公交線路。 最簡單的辦法是將所有旅客需要走的起點與終點串成一條線，車在這條線上開，乘客則自已決定上下車。這就是最簡單的公交線路。 它很差勁，但起碼解決客人們對車爭用。對應到計算機里，就是把所有任務的代碼混在一起執行。 這樣做既不優異雅，也沒效率，于是司機想了個辦法，把這些客戶叫到一起商量，將所有客人出行的起點與終點羅列出來，統計這些線路的使用頻度，然后制定出公交線路：有些路線可以合并起來成為一條線路，而那些不能合并的路線，則另行開辟行車車次，這叫作“任務定義”。另外，對于人多路線，車次排多點，時間上也優先安排，這叫作“任務優先級”。 經過這樣的安排后，雖然仍只有一輛車，但運載能力卻大多了。這套車次/路線的按排，就是一套“公交系統”。哈，知道什么叫操作系統了吧？它也就是這么樣的一種約定.