第一、併發性
程序併發工作效率低在寫裸機軟件時，不可避免的在主程序中會有一個超級大的 while(1) 循環，這裡面幾乎包含整個項目的所有業務邏輯。因為每個業務邏輯裡面都會有 delay 這樣的循環等待函數，這樣導致了所有的業務邏輯幾乎都是串行起來工作的。這個時候 CPU 就會有很多時間都浪費在了延時函數里，一直在空轉，導致軟件的併發效率非常差。
第二、模塊化：高內聚、低耦合的原則
從軟件工程的角度，我們在做軟件開發時，都會強調高內聚、低耦合的原則。而裸機的模塊化開發難度非常大，模塊間的耦合較重，這也導致了無法在大型項目使用裸機來開發。
還是剛才 main 函數中大 while(1) 的例子，可以想象到那麼多功能都緊緊的擠在一個函數里，不可拆分，模塊化開發的困難重重。
舉一個非常貼切的例子，在一些使用看門狗的項目中，如果使用 delay 延時函數，那得注意點，萬一延時過長，主函數來不及餵狗，看門狗就被觸發了。最後會產生這樣一種感覺，一個簡簡單單的 delay 還得考慮餵狗功能，裸機開發時操的心太多了，自然無法應用在大型項目中。
第三、生態：很多高級軟件組件，必須依賴於操作系統來實現
比如說，我前些年開源過一個基於 FreeModbus 的 Modbus 主機協議棧，因為要考慮各個平臺適配問題，原本計劃支持各種各樣的操作系統，甚至是裸機平臺。在各個操作系統上的適配都非常容易，但再去嘗試著適配裸機時，發現難度重重，有一些函數在裸機上實現起來非常複雜，而且針對於不同的裸機環境，幾乎沒有通用性可言，太耗費精力了。所以我最終就放棄了裸機適配，一直到現在，在裸機上還是沒法用這個 Modbus 主機協議棧。
還有一些軟件無法運行在裸機上，比如：樂鑫、Realtek、 ti 和 聯發科 提供的 WIFi SOC SDK ，一些藍牙 SOC 的 SDK 也都是隻支持操作系統，所以，如果你不瞭解、不會使用操作系統，這些芯片也就玩不轉了。
第四、實時性：功能複雜的情況下，實時性無法保證
軟件的實時性在一些領域會有一定的要求，軟件的每個步驟必須在指定的時間被觸發。工控領域就是最常見到的場景，如果實時性無法保證，機械設備可能就無法按照指定時序要求去動作，以至於發生機械事故，甚至會威脅到人的生命。回過來接著看裸機軟件，如果軟件變得龐大以後，可以想象到，主程序中那麼大的一個 while(1) 循環，代碼耦合嚴重，到處都是 delay 延時，要保證實時性幾乎是不可能的。
第五、可重用性：軟件可重用性差，總是重複造輪子
可重用性與模塊化程度有直接的關係。相信大家每個人在工作中都不想做很多重複性的工作，同樣在寫代碼時，也想著儘可能少寫一些功能相似的代碼。但在這個嵌入式碎片化極其嚴重的時代，各式各樣的芯片，想要讓同樣的代碼，在裸機環境下同時適配不同的硬件，難度非常大。這樣也就導致了裸機的代碼會過多的依賴於底層硬件，重複造輪子的過程也就不可避免。
操作系統帶來的優勢
第一次接觸操作系統，是在 2010 年左右，那時 STM32 已經開始流行起來，這麼強大的單片機，有很多人都在上面跑操作系統，我也跟著移植了 ucos ，在上面還跑了 ucgui ，這個時候寫應用完全是一種全新的體驗，爽了很多，玩了一年了 ucos ，後來接觸到咱們國產的 RT-Thread ，在它上面有很多現成的、拿來即用組件，試用以後發現更爽，就一直用到了今天，大概有 8 年了。也跟大家也聊一聊操作系統的優勢：
線程方式的併發任務處理，解決模塊化問題，同時保證實時性
1、 模塊化
使用了操作系統以後，整個軟件的工作被拆分成了由多個任務來構成（也會被稱為線程），每個線程有自己獨立的運行空間，即線程堆棧，這個時候每個線程你玩你的，我做我的，咱們大家互補干涉，模塊化程度得到很好的提高。
2、 併發性
從併發的角度來看，各個線程在使用 delay/事件等待 這類函數時，會自動的讓出 CPU 給其他有需要的線程，不僅書寫 delay 延時函數操的心少了，整個 CPU 的利用率也得到了提高，最終提升併發性。
3、 實時性
再來看實時性，像 ucos/RT-Thread 這些 RTOS 本身就被設計為實時的操作系統，各個線程都有不同的優先級別，重要的線程可以設為高優先級，不重要的線程可以降低優先級，做好全局的統籌規劃後，這樣整個軟件的實時性也能得到保證。
4、開發效率
由於操作系統提供了統一的抽象接口層，方便了可重用組件的積累，提高開發效率
操作系統其實是一群軟件大牛們智慧的結晶，他們站在應用軟件、底層驅動的開發角度，對很多常見的軟件功能進行了封裝、抽象，比如：信號量、事件通知、郵箱、環形緩衝區、單向鏈表/雙向鏈表等等，這些功能拿來即用，對於開發者方便極了
還有一些操作系統，比如：Linux 和我們國產的 RT-Thread ，他們這些系統對碎片化的硬件，統一封裝了一套標準的硬件操作接口，一般稱為設備驅動框架。這樣我們的應用軟件工程師，就可以專攻應用的工作，再也不用怕更換硬件，又需要重複造輪子了。
5、軟件生態
生態的豐富帶來了量變到質變的過程（自己玩->大家一起玩）使用操作系統所帶來的軟件可模塊化、重用性的提升，也使得我們自己在做軟件開發時，可以封裝一套基於操作系統、適合嵌入式的可重用組件，這些組件不僅可以用在自己的項目中，還能開源出來分享給更多有需要的嵌入式開發者，把軟件的價值最大化。
個人感覺這是一件蠻有意義事情，我自己本身也是一名開源極客，也有在 GitHub 上開源一些嵌入式軟件。說實話在做開源軟件前，能夠深入交流嵌入式軟件的地方非常少，畢竟大家的代碼不是芯片不一樣，就是硬件不一樣，你的代碼給了他，也不一定能運行起來。但是自從用了操作系統後，軟件的可重用性提高了，能夠讓更多的人很迅速的用起來我的開源軟件，這個時候能夠有更多的人可以一起交流，還接觸到了很多的大牛們，甚至是國外的朋友。俗話說：水漲船高，我的能力也從此得到了快速的提升。所以總結下來，有一個能一起交流嵌入式軟件圈子還是蠻重要的，自己閉門造車，可能都是在重複造輪子。
常見RTOS優勢對比
ucos/freertos/RT-Thread，選擇這三款 OS 的原因是，它們的年限都比較長了，在市面上都蠻有知名度，用過的人比較多，更有說服力。
1、 基本功能、性能
各家 RTOS 差異很小，可比性並不是很大
2、 易用性/可讀性
這塊 FreeRTOS 應該說是最差，奇葩的匈牙利命名法，代碼實現用了很多宏，可讀性非常差。ucos 可讀性還可以，註釋也很全。這塊做的比較好的是 RT-Thread ，它是類 Linux 的代碼風格，面向對象的設計模式，代碼簡潔易懂。在保證了體積（最小 ROM：3K RAM：1.5K）的同時，還借鑑了 Linux 的設備驅動框架、虛擬文件系統、Shell 等功能，設計更加優雅。
3、 組件豐富性
RT-Thread 比起傳統 UCOS、FreeRTOS 不僅僅在基礎功能上多而全，多達 50 個以上的可重用軟件組件，還有很多物聯網組件，對於物聯網產品幾乎做到開箱即用。RT-Thread 還可以運行 Python、Java、Lua 這些高級語言的腳本，進一步降低開發難度。
4、 開發資料
這塊 ucos 做的最好，還有配套相關的書籍，FreeRTOS 屬於後起之秀，網上也有很多相關資料。RT-Thread 這塊之前還是略顯薄弱的，不過現在 RT-Thread 對這塊非常重視，最直觀的可以看到官網上的應用筆記越來越多了，還有一些配套教學視頻。
ucos 商業是要收費的，FreeRTOS 和 RT-Thread 版權都很寬鬆，特別是RT-Thread剛剛使用了Apache許可協議。
6、 社區生態
這三款 RTOS 的社區都比較活躍，現在可以感覺到 ucos 慢慢的用的人越來越少了，RT-Thread 和 FreeRTOS 用的人都在增多。RT-Thread 也是開發者最多的國產 RTOS，並且還擁有國內最大的嵌入式開源軟件社區。
免責聲明：本文由作者原創，文章內容系作者個人觀點，電子發燒友網轉載僅作為傳達一種不同的觀點，不代表電子發燒友網對該觀點的贊同或支持，如有異議，歡迎聯繫電子發燒友網。
全球135萬確診！停工停產、無薪休假、降薪，扛過寒冬！
戴口罩人臉照片2毛一張暗中交易！人臉識別安全應用如何保障？
華為斥資6600萬入股中電儀器，國內測試儀器局面將鉅變?
拆解華為P40：“去A化”加強，國產化更進一步
主動降噪與音質加強，TWS耳機的未來走向
閱讀更多 電子發燒友網 的文章
