常用的實時嵌入式操作系統有哪些?最近閑來無事對比了幾款嵌入式操作系統的基本特性,發現現在操作系統逐步發展為了行業應用的技術框架主要對比了linux基金會的zephyr;Adam dunkels團隊(LWIP作者)的contiki-ng;arm公司的mbedOS;移動的OneOS,國内老牌的RT-THread,開源鴻蒙OpenHarmonyL0,以及使用最廣的Freertos,今天小編就來說說關于常用的實時嵌入式操作系統有哪些?下面更多詳細答案一起來看看吧!
最近閑來無事對比了幾款嵌入式操作系統的基本特性,發現現在操作系統逐步發展為了行業應用的技術框架。主要對比了linux基金會的zephyr;Adam dunkels團隊(LWIP作者)的contiki-ng;arm公司的mbedOS;移動的OneOS,國内老牌的RT-THread,開源鴻蒙OpenHarmonyL0,以及使用最廣的Freertos。
Zephyrzephyr由linux基金支持,從其官網描述zephyr出現的目的是為了解決産品廠家,芯片 廠家,傳感器廠家在最終産品組合的組合解耦,并提供便捷的網絡服務。zephyr在系統的設計中考慮了再某些應用場合,某些功能擁有覺得的絕對的優先級,提供了協程(隻能由任務自身放棄資源)。但也帶來了系統的控制陷阱。在一定程度上内核對系統不在 擁有絕對的控制權,取決于應用開發者的能力。
zephyr在IPC通訊機制中提供了工作隊列,以及提供了系統工作隊列,用處是解決中斷,以及高優先級中的部分處理事件較長但又非緊急需求的部分。可以将此部分扔到任務工作隊列中處理。
zephyr提供了大量的中間件,針對物聯網的常用MQTT,COAP等,以及6powpan ble mesh組網。
zephyr在驅動層提供了驅動框架,針對GPIO I2C SPI 以及sensor等各自做了驅動接口出來,需要适配 其驅動,對芯片廠家提供的HAL庫不太友好。
zephyr針對低功耗也提供了電源管理。也提供了物聯網通訊安全的機制。
ContikiContiki是一個相當輕量的操作系統,其基于PT模式,采用了事件驅動的方式。其最小的RAM可以小到幾百個Byte,最大的特點就是适配芯片不需要考慮彙編。從8位到32位都可以适配。Contiki主要給極低RAM配置的單片在物聯網應用方向提供了一個操作系統。
Contiki針對物聯網也提供了MQTT COAP HTTP 等協議。
在驅動框架上,受限于其操作系統的定位,采用的宏定義來統一驅動層。
MbedOS
MbedOS是ARM公司針對物聯網行業在原來RTX的基礎上退出的操作系統。其風格是采用了C 。正物聯網所需的MQTT,COAP 以及ble5.0 ,Thread等MbedOS都有實現。
其驅動層隻是定義了統一的接口,并沒有對驅動進行管理。
安全方面,MbedOS 結合自身的芯片架構可以提供較好的安全性能。在通信安全上,很多操作系統都是用MbedOS提供的Mbedtls庫
OneOSOneOS是移動出針對物聯網的操作系統。在内核層OneOS 也提供了類似Zephyr的工作隊列以及基于工作隊列實現的系統工作隊列。其作用與Zephyr提供的目的一樣。其有特色的是在内核層也提供了一個硬件定定時。
在中間件這一層,針對物聯網提供了MQTT COAP HTTP LWM2M等組件。也提供了對常用的雲的對接SDK,比如華為雲,阿裡雲,天翼雲,移動自己的OneNet雲,亞馬遜雲,騰訊雲等。
在工業物聯網方面提供了CanFestival協議組件。
當然也提供了電源管理組件與安全管理組件。
在驅動這一層,OneOS通過os_device_t這個父類對所有的驅動做統一的管理。在對底層接口提供了adpater層方便與芯片廠家的HAL庫對接。在對應用層提供了Core層統一對應用層的接口。
RT-ThreadRT-Thread 現在有Nano和Smart倆個版本,Smart需要MMU的支持。我們直說Nano版本。
RT-thread在國内是相當成功的操作系統。其在驅動上的設計也是采用rt_device_t作為父類來對所有的驅動做同統一管理。RT-Thread提供了adapter層,提供了 open close read write ioctrl,prv_data等接口。芯片可以通過HAL庫對接這幾個接口。在core這一層。RT-Thread提供了統一對應用的接口。
RT-THread提供了GUI操作庫,基于C ,名稱叫做柿餅。
RT-THread針對屋裡網提供了MQTT COAP HTTP,并且也提供了JS引擎。
RT-Thread利用eclipse實現了自己的IDE,并建立了社區。
OpenharmonyL0Openharmony是華為捐獻給國家開源基金的操作系統。其發展與華為自身的harmonyOS有區别。屬于社區共建。Openharmony根據芯片的資源可以分為L0-L5。我們在此處隻讨論L0(後續有時間會讨論下L1)。
Openharmony在官網上宣傳的是最小RAM開銷在128K,但實際從代碼來看取決于應用需求哪些功能。是可以裁剪或增加的。Openharmony一個比較好的設計理念就是一切皆服務。
在驅動這一層提供一個HDF的統一框架,配合HCS可以實現對驅動的統一管理,也同樣提供了adpater層來滿足底層适配,在對應用也提供了Core層。
Openharmony有特色的設計是系統的基礎服務組件,以及分布式軟總線,分布式任務調度。個人理解這很符合物聯網的思維。在物聯網中信息的給予着和動作的執行者,往往都是服務者。那麼利用分布式任務調度。可以 實現将不同的設備,屏蔽底層通訊差異。組合起來當做一個整體。瘦設備可以成為一個服務者。富設備可以作為需求者統合所有瘦設備。形成一個整體。方便設計。個人理解有點像SOA的設計理念。其軟總線就像是SOA裡面的ESB總線。當然OpenHarmony目前的很多代碼還不是很成熟。但值得期待。
PS:下次我們再聊聊嵌入式操作系統内在的哪些邏輯設計。
,更多精彩资讯请关注tft每日頭條,我们将持续为您更新最新资讯!