朱天龍
RT-Thread技術總監
Github中國區C語言類排名第24
嵌入式設備網絡化、功能復雜化的趨勢,使越來越多的、過去可以用裸奔實現的嵌入式產品,產生了應用操作系統的需求。芯片成本的連續下降,以及cpu性能和內存資源的迅速提高,又為大面積應用操作系統提供了物質基礎。那么我們到底該不該從裸奔走向操作系統呢?
回顧裸機時代
我第一次接觸到嵌入式,大概是在 2008 年,那時候還是大二,剛開始學 51 單片機,自然還是要從裸機開始跑。因為自己是計算機系的,以前寫程序都是跑在 PC 機上的,現在竟然能在電路板上執行軟件,感覺完全不一樣,至今還記得我第一次跑通流水燈的喜悅。但是隨著寫的裸機軟件越來越多,裸機所暴露的問題也越來越多,這里我給大家總結下吧:
并發性:程序并發工作效率低
在寫裸機軟件時,不可避免的在主程序中會有一個超級大的 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 年了。也跟大家也聊一聊操作系統的優勢:
線程方式的并發任務處理,解決模塊化問題,同時保證實時性
模塊化:使用了操作系統以后,整個軟件的工作被拆分成了由多個任務來構成(也會被稱為線程),每個線程有自己獨立的運行空間,即線程堆棧,這個時候每個線程你玩你的,我做我的,咱們大家互補干涉,模塊化程度得到很好的提高。
并發性:從并發的角度來看,各個線程在使用 delay/事件等待 這類函數時,會自動的讓出 CPU 給其他有需要的線程,不僅書寫 delay 延時函數操的心少了,整個 CPU 的利用率也得到了提高,最終提升并發性。
實時性:再來看實時性,像 ucos/RT-Thread 這些 RTOS 本身就被設計為實時的操作系統,各個線程都有不同的優先級別,重要的線程可以設為高優先級,不重要的線程可以降低優先級,做好全局的統籌規劃后,這樣整個軟件的實時性也能得到保證。
開發效率:
由于操作系統提供了統一的抽象接口層,方便了可重用組件的積累,提高開發效率
操作系統其實是一群軟件大牛們智慧的結晶,他們站在應用軟件、底層驅動的開發角度,對很多常見的軟件功能進行了封裝、抽象,比如:信號量、事件通知、郵箱、環形緩沖區、單向鏈表/雙向鏈表等等,這些功能拿來即用,對于開發者方便極了
還有一些操作系統,比如:Linux 和我們國產的 RT-Thread ,他們這些系統對碎片化的硬件,統一封裝了一套標準的硬件操作接口,一般稱為設備驅動框架。這樣我們的應用軟件工程師,就可以專攻應用的工作,再也不用怕更換硬件,又需要重復造輪子了。
軟件生態:
生態的豐富帶來了量變到質變的過程(自己玩->大家一起玩)
使用操作系統所帶來的軟件可模塊化、重用性的提升,也使得我們自己在做軟件開發時,可以封裝一套基于操作系統、適合嵌入式的可重用組件,這些組件不僅可以用在自己的項目中,還能開源出來分享給更多有需要的嵌入式開發者,把軟件的價值最大化。
個人感覺這是一件蠻有意義事情,我自己本身也是一名開源極客,也有在 GitHub 上開源一些嵌入式軟件。說實話在做開源軟件前,能夠深入交流嵌入式軟件的地方非常少,畢竟大家的代碼不是芯片不一樣,就是硬件不一樣,你的代碼給了他,也不一定能運行起來。但是自從用了操作系統后,軟件的可重用性提高了,能夠讓更多的人很迅速的用起來我的開源軟件,這個時候能夠有更多的人可以一起交流,還接觸到了很多的大牛們,甚至是國外的朋友。俗話說:水漲船高,我的能力也從此得到了快速的提升。所以總結下來,有一個能一起交流嵌入式軟件圈子還是蠻重要的,自己閉門造車,可能都是在重復造輪子。
常見RTOS優勢對比
ucos/freertos/RT-Thread,選擇這三款 OS 的原因是,它們的年限都比較長了,在市面上都蠻有知名度,用過的人比較多,更有說服力。
基本功能、性能:各家 RTOS 差異很小,可比性并不是很大
易用性/可讀性:這塊 FreeRTOS 應該說是最差,奇葩的匈牙利命名法,代碼實現用了很多宏,可讀性非常差。ucos 可讀性還可以,注釋也很全。這塊做的比較好的是 RT-Thread ,它是類 Linux 的代碼風格,面向對象的設計模式,代碼簡潔易懂。在保證了體積(最小 ROM:3K RAM:1.5K)的同時,還借鑒了 Linux 的設備驅動框架、虛擬文件系統、Shell 等功能,設計更加優雅。
組件豐富性:RT-Thread 比起傳統 UCOS、FreeRTOS 不僅僅在基礎功能上多而全,多達 50 個以上的可重用軟件組件,還有很多物聯網組件,對于物聯網產品幾乎做到開箱即用。RT-Thread 還可以運行 Python、JavaScript、Lua 這些高級語言的腳本,進一步降低開發難度。
RT-Thread架構圖
開發資料:這塊 ucos 做的最好,還有配套相關的書籍,FreeRTOS 屬于后起之秀,網上也有很多相關資料。RT-Thread 這塊之前還是略顯薄弱的,不過現在 RT-Thread 對這塊非常重視,最直觀的可以看到官網上的應用筆記越來越多了,還有一些配套教學視頻。
版權:ucos 商業是要收費的,FreeRTOS 和 RT-Thread 版權都很寬松,特別是RT-Thread剛剛使用了Apache許可協議。
社區生態:這三款 RTOS 的社區都比較活躍,現在可以感覺到 ucos 慢慢的用的人越來越少了,RT-Thread 和 FreeRTOS 用的人都在增多。RT-Thread 也是開發者最多的國產 RTOS,并且還擁有國內最大的嵌入式開源軟件社區。
-
操作系統
+關注
關注
37文章
6808瀏覽量
123291 -
C語言
+關注
關注
180文章
7604瀏覽量
136711 -
模塊化
+關注
關注
0文章
331瀏覽量
21344
原文標題:朱天龍:該不該用RTOS?我們只做對的選擇(上)
文章出處:【微信號:elecfans,微信公眾號:電子發燒友網】歡迎添加關注!文章轉載請注明出處。
發布評論請先 登錄
相關推薦
評論