爲什麼要使用操作系統
從51單片機開始使用簡單的邏輯系統，慢慢的開始接觸ucos、FreeRTOS這類小型的操作系統，到現在開始接觸Linux這種大型的開源操作系統，是否有想過爲什麼要使用操作系統呢？以前簡單的邏輯關係不是挺好的，爲什麼要搞定越來越複雜了。
引入例子
在博客上看到一個例子覺得很好，一步一步引導我們進行思考爲什麼藥使用操作系統。
一般的簡單的嵌入式設備的編程思路是下面這樣的：
main
{
{處理事務1}；
{處理事務2}；
{處理事務3}；
.......
{處理事務N}；
}
isr_server
{
{處理中斷}；
}
這是最一般的思路，對於簡單的系統當然是夠用了，但這樣的系統實時性是很差的，比如“事務1”如果是一個用戶輸入的檢測，當用戶輸入時，如果程序正在處理事務1下面的那些事務，那麼這次用戶輸入將失效，用戶的體驗是“這個按鍵不靈敏，這個機器很慢”；
而我們如果把事務放到中斷裏去處理，雖然改善了實時性但會導致另外一個問題，有可能會引發中斷丟失，這個後果有時候比“慢一點”更加嚴重和惡劣！又比如事務2是一個只需要1s鍾處理一次的任務，那麼顯然事務2會白白浪費CPU的時間。
這時，我們可能需要改進我們的編程思路，一般我們會嘗試採用“時間片”的方式。這時候編程會
變成下面的方式：
main
{
{事務1的時間片到了則處理事務1}；
{事務2的時間片到了則處理事務2}；
.......
{事務N的時間片到了則處理事務N}；
}
time_isr_server
{
{判斷每個事務的時間片是否到來，並進行標記}；
}
isr_server
{
{處理中斷}；
}
我們可以看到，這種改進後的思路，使得事務的執行時間得到控制，事務只在自己的時間片到來後，纔會去執行，但我們發現，這種方式仍然不能徹底解決“實時性”的問題，因爲某個事務的時間片到來後，也不能立即就執行，她必須等到當前事務的時間片用完，並且後面的事務時間片沒到來，她纔有機會獲得“執行時間”。
這時候我們需要繼續改進思路,爲了使得某個事務的時間片到來後能立即執行，我們需要在時鐘中斷裏判斷完時間片後，改變程序的返回位置，讓程序不返回到剛剛被打斷的位置，而從最新獲得了時間片的事務處開始執行，這樣就徹底解決了事務的實時問題。
我們在這個思路上，進行改進，我們需要在每次進入時鐘中斷前，保存CPU的當前狀態和當前事務用到的一些數據，然後我們進入時鐘中斷進行時間片處理，若發現有新的更緊急的事務的時間片到來了，則我們改變中斷的返回的地址，並在CPU中恢復這個更緊急的事務的現場，然後返回中斷開始執行這個更緊急的事務。
上面的這段話有些不好讀，事實上，這是因爲要實現這個過程是有些複雜和麻煩的，這時候我們就需要找一個操作系統(OS)幫我們做這些事了，如果你能自己用代碼實現這個過程，事實上你就在自己寫操作系統了，其實從這裏也可也看出，操作系統的原理其實並不那麼神祕，只是一些細節你很難做好。
到這裏，我們終於知道了爲什麼我們需要操作系統了。事實上，操作系統的用處遠不止幫你完成這個“事務時間片的處理”，她還能幫你處理各種超時，進行內存管理，完成任務間的通信等，有了她，程序的層次也更加清晰，給系統添加功能也更方便，這一切在大型項目中越發的明顯！
1. 多任務，提高實時性
單片機系統就一個main函數，可以看做是隻有一個任務在while函數裏面一直跑；而多任務則可看做有多個任務同時在跑，每個任務有一個自己的while循環，感覺每個任務都擁有一個CPU，在各自的CPU中做着自己的事情。
這邊所說的同時運行，其實不是真的並行執行，而是併發執行。操作系統都有個基準切換時鐘，比如爲10ms，當有多個任務時，每個任務之間的運行以10ms的頻率進行切換運行，這就讓人感覺像是所有的任務一起執行的錯覺。
操作系統的最大優勢就在於任務的併發執行，當然根據不同的操作系統配合中斷/優先級等其任務調度的方式不相同。
2. 分模塊開發，減少耦合度
操作系統對模塊的劃分很明確，特別是像Linux這種系統，在開發過程分工更加明確。
如底層驅動中各類驅動都放在各自的文件夾下，i2c、spi、mmc、mtd、usb等等；應用層則一般以進程區分，每個進程之間相互獨立，各自完成各自的功能，進程間要通訊可以有多種方式，將各個功能的程序開發進行隔離，減少程序之間的耦合性。
3. 移植性強，在線安裝卸載
爲什麼要使用操作系統的分析就到這邊，有感悟時會持續會更新。
注：以上內容都是本人在學習過程積累的一些心得，難免會有參考到其他文章的一些知識，如有侵權，請及時通知我，我將及時刪除或標註內容出處，如有錯誤之處也請指出，進行探討學習。文章只是起一個引導作用，詳細的數據解析內容還請查看操作系統相關教程，感謝您的查閱。