裸機開發(fā)遇到的問題

第一、并發(fā)性。程序并發(fā)工作效率低在寫裸機軟件時，不可避免的在主程序中會有一個超級大的 while（1） 循環(huán)，這里面幾乎包含整個項目的所有業(yè)務(wù)邏輯。因為每個業(yè)務(wù)邏輯里面都會有 delay 這樣的循環(huán)等待函數(shù)，這樣導(dǎo)致了所有的業(yè)務(wù)邏輯幾乎都是串行起來工作的。這個時候CPU就會有很多時間都浪費在了延時函數(shù)里，一直在空轉(zhuǎn)，導(dǎo)致軟件的并發(fā)效率非常差。

第二、模塊化：高內(nèi)聚、低耦合的原則。從軟件工程的角度，我們在做軟件開發(fā)時，都會強調(diào)高內(nèi)聚、低耦合的原則。而裸機的模塊化開發(fā)難度非常大，模塊間的耦合較重，這也導(dǎo)致了無法在大型項目使用裸機來開發(fā)。還是剛才 main 函數(shù)中大 while（1） 的例子，可以想象到那么多功能都緊緊的擠在一個函數(shù)里，不可拆分，模塊化開發(fā)的困難重重。舉一個非常貼切的例子，在一些使用看門狗的項目中，如果使用 delay 延時函數(shù)，那得注意點，萬一延時過長，主函數(shù)來不及喂狗，看門狗就被觸發(fā)了。最后會產(chǎn)生這樣一種感覺，一個簡簡單單的delay還得考慮喂狗功能，裸機開發(fā)時操的心太多了，自然無法應(yīng)用在大型項目中。

第三、生態(tài)：很多高級軟件組件，必須依賴于操作系統(tǒng)來實現(xiàn)。比如說，我前些年開源過一個基于FreeModbus的Modbus主機協(xié)議棧，因為要考慮各個平臺適配問題，原本計劃支持各種各樣的操作系統(tǒng)，甚至是裸機平臺。在各個操作系統(tǒng)上的適配都非常容易，但再去嘗試著適配裸機時，發(fā)現(xiàn)難度重重，有一些函數(shù)在裸機上實現(xiàn)起來非常復(fù)雜，而且針對于不同的裸機環(huán)境，幾乎沒有通用性可言，太耗費精力了。所以我最終就放棄了裸機適配，一直到現(xiàn)在，在裸機上還是沒法用這個 Modbus 主機協(xié)議棧。還有一些軟件無法運行在裸機上，比如：樂鑫、Realtek、ti和聯(lián)發(fā)科提供的WIFi SOC SDK ，一些藍牙SO的SDK也都是只支持操作系統(tǒng)，所以，如果你不了解、不會使用操作系統(tǒng)，這些芯片也就玩不轉(zhuǎn)了。

第四、實時性：功能復(fù)雜的情況下，實時性無法保證。軟件的實時性在一些領(lǐng)域會有一定的要求，軟件的每個步驟必須在指定的時間被觸發(fā)。工控領(lǐng)域就是最常見到的場景，如果實時性無法保證，機械設(shè)備可能就無法按照指定時序要求去動作，以至于發(fā)生機械事故，甚至?xí){到人的生命?；剡^來接著看裸機軟件，如果軟件變得龐大以后，可以想象到，主程序中那么大的一個 while（1） 循環(huán)，代碼耦合嚴重，到處都是 delay 延時，要保證實時性幾乎是不可能的。

第五、可重用性：軟件可重用性差，總是重復(fù)造輪子?？芍赜眯耘c模塊化程度有直接的關(guān)系。相信大家每個人在工作中都不想做很多重復(fù)性的工作，同樣在寫代碼時，也想著盡可能少寫一些功能相似的代碼。但在這個嵌入式碎片化極其嚴重的時代，各式各樣的芯片，想要讓同樣的代碼，在裸機環(huán)境下同時適配不同的硬件，難度非常大。這樣也就導(dǎo)致了裸機的代碼會過多的依賴于底層硬件，重復(fù)造輪子的過程也就不可避免。

操作系統(tǒng)帶來的優(yōu)勢

操作系統(tǒng)的優(yōu)勢：線程方式的并發(fā)任務(wù)處理，解決模塊化問題，同時保證實時性。

1、模塊化。使用了操作系統(tǒng)以后，整個軟件的工作被拆分成了由多個任務(wù)來構(gòu)成（也會被稱為線程），每個線程有自己獨立的運行空間，即線程堆棧，這個時候每個線程你玩你的，我做我的，咱們大家互補干涉，模塊化程度得到很好的提高。

2、并發(fā)性。從并發(fā)的角度來看，各個線程在使用delay/事件等待 這類函數(shù)時，會自動的讓出CPU 給其他有需要的線程，不僅書寫delay延時函數(shù)操的心少了，整個CPU的利用率也得到了提高，最終提升并發(fā)性。

3、實時性。再來看實時性，像ucos/RT-Thread這些RTOS本身就被設(shè)計為實時的操作系統(tǒng)，各個線程都有不同的優(yōu)先級別，重要的線程可以設(shè)為高優(yōu)先級，不重要的線程可以降低優(yōu)先級，做好全局的統(tǒng)籌規(guī)劃后，這樣整個軟件的實時性也能得到保證。

4、開發(fā)效率。由于操作系統(tǒng)提供了統(tǒng)一的抽象接口層，方便了可重用組件的積累，提高開發(fā)效率。操作系統(tǒng)其實是一群軟件大牛們智慧的結(jié)晶，他們站在應(yīng)用軟件、底層驅(qū)動的開發(fā)角度，對很多常見的軟件功能進行了封裝、抽象，比如：信號量、事件通知、郵箱、環(huán)形緩沖區(qū)、單向鏈表/雙向鏈表等等，這些功能拿來即用，對于開發(fā)者方便極了。還有一些操作系統(tǒng)，比如：Linux和我們國產(chǎn)的RT-Thread ，這些系統(tǒng)對碎片化的硬件，統(tǒng)一封裝了一套標準的硬件操作接口，一般稱為設(shè)備驅(qū)動框架。這樣我們的應(yīng)用軟件工程師，就可以專攻應(yīng)用的工作，再也不用怕更換硬件，又需要重復(fù)造輪子了。

5、軟件生態(tài)

生態(tài)的豐富帶來了量變到質(zhì)變的過程（自己玩-》大家一起玩）。使用操作系統(tǒng)所帶來的軟件可模塊化、重用性的提升，也使得我們自己在做軟件開發(fā)時，可以封裝一套基于操作系統(tǒng)、適合嵌入式的可重用組件，這些組件不僅可以用在自己的項目中，還能開源出來分享給更多有需要的嵌入式開發(fā)者，把軟件的價值最大化。

個人感覺這是一件蠻有意義事情，我自己本身也是一名開源極客，也有在 GitHub 上開源一些嵌入式軟件。說實話在做開源軟件前，能夠深入交流嵌入式軟件的地方非常少，畢竟大家的代碼不是芯片不一樣，就是硬件不一樣，你的代碼給了他，也不一定能運行起來。但是自從用了操作系統(tǒng)后，軟件的可重用性提高了，能夠讓更多的人很迅速的用起來我的開源軟件，這個時候能夠有更多的人可以一起交流，還接觸到了很多的大牛們，甚至是國外的朋友。俗話說：水漲船高，我的能力也從此得到了快速的提升。所以總結(jié)下來，有一個能一起交流嵌入式軟件圈子還是蠻重要的，自己閉門造車，可能都是在重復(fù)造輪子。

常見RTOS優(yōu)勢對比

ucos/freertos/RT-Thread，選擇這三款OS的原因是，它們的年限都比較長了，在市面上都蠻有知名度，用過的人比較多，更有說服力。

1、基本功能、性能。各家RTOS差異很小，可比性并不是很大

2、易用性/可讀性。這塊FreeRTOS應(yīng)該說是最差，奇葩的匈牙利命名法，代碼實現(xiàn)用了很多宏，可讀性非常差。ucos可讀性還可以，注釋也很全。這塊做得比較好的是RT-Thread ，它是類Linux的代碼風(fēng)格，面向?qū)ο蟮脑O(shè)計模式，代碼簡潔易懂。在保證了體積（最小ROM：3K；RAM：1.5K）的同時，還借鑒了Linux的設(shè)備驅(qū)動框架、虛擬文件系統(tǒng)、Shell等功能，設(shè)計更加優(yōu)雅。

3、組件豐富性。RT-Thread比起傳統(tǒng)UCOS、FreeRTOS不僅僅在基礎(chǔ)功能上多而全，多達50個以上的可重用軟件組件，還有很多物聯(lián)網(wǎng)組件，對于物聯(lián)網(wǎng)產(chǎn)品幾乎做到開箱即用。RT-Thread還可以運行Python、Java、Lua這些高級語言的腳本，進一步降低開發(fā)難度。

4、開發(fā)資料。這塊ucos做的最好，還有配套相關(guān)的書籍，F(xiàn)reeRTOS屬于后起之秀，網(wǎng)上也有很多相關(guān)資料。RT-Thread這塊之前還是略顯薄弱的，不過現(xiàn)在RT-Thread對這塊非常重視，最直觀的可以看到官網(wǎng)上的應(yīng)用筆記越來越多了，還有一些配套教學(xué)視頻。

5、版權(quán)。ucos商業(yè)是要收費的，F(xiàn)reeRTOS和RT-Thread版權(quán)都很寬松，特別是RT-Thread剛剛使用了Apache許可協(xié)議。

6、社區(qū)生態(tài)。這三款RTOS的社區(qū)都比較活躍，現(xiàn)在可以感覺到ucos慢慢的用的人越來越少了，RT-Thread和FreeRTOS用的人都在增多。RT-Thread也是開發(fā)者最多的國產(chǎn) RTOS，并且還擁有國內(nèi)最大的嵌入式開源軟件社區(qū)。

審核編輯 ：李倩