分析一下CesiμmRTOS與FreeRTOS的差異

μC/OS的商業(yè)版Cesiμm RTOS，和FreeRTOS是嵌入式軟件領域流行的兩種實時內核。雖然這兩款RTOS功能相似，并且具有可比較的執(zhí)行指標，但它們都有各自的優(yōu)點和缺點，本文將分析一下其差異。

功能區(qū)別

Cesiμm RTOS和FreeRTOS的API之間存在比較大的差異。以信號量創(chuàng)建為例，F(xiàn)reeRTOS提供了下列對象創(chuàng)建函數(shù):

與信號量創(chuàng)建函數(shù)一樣，互斥信號量和隊列也使用類似的函數(shù)變體，而非一個統(tǒng)一的函數(shù)來創(chuàng)建這些內核對象，導致用戶必須熟悉更多的API。

雖然FreeRTOS這些函數(shù)使得在應用程序中查找相應的信號量創(chuàng)建函數(shù)更容易，但用戶需要付出更多努力理解每個函數(shù)的具體用途。相反，使用Cesiμm RTOS，信號量或互斥量創(chuàng)建更簡單。

傳遞給函數(shù)的參數(shù)將決定用戶創(chuàng)建的對象類型。這種方法非常簡單，用戶不需要象FreeRTOS一樣，在調試時執(zhí)行多個重定向創(chuàng)建函數(shù)。

通過OSSemCreate()函數(shù)，根據(jù)參數(shù)值可以創(chuàng)建二值、計數(shù)或靜態(tài)信號量，設置初始計數(shù)并將信號量數(shù)據(jù)對象定義為靜態(tài)變量或非靜態(tài)變量。

通過傳入創(chuàng)建函數(shù)的不同參數(shù)，創(chuàng)建與FreeRTOS相同類型的對象，而無需為每個對象單獨提供函數(shù)。

從使用上講，Cesiμm RTOS的功能沒有缺失，但調試時需要了解、管理和維護的API更少。

調試特性

FreeRTOS中，信號量創(chuàng)建函數(shù)將映射到等效隊列函數(shù)實例中。例如:

隨著函數(shù)嵌套深度的增加，在調試期間跟蹤錯誤將變得更加困難。而在Cesiμm RTOS中調試信號量、隊列或互斥信號量的創(chuàng)建更簡單，更容易找到故障點或錯誤配置。

例如xSemaphoreTake()函數(shù)將調用xQueueSemaphoreTake()函數(shù)，后者將根據(jù)調用來自信號量還是隊列，實現(xiàn)后續(xù)操作。

額外的條件處理使函數(shù)在調試時的跟蹤更加復雜。相比之下，Cesiμm RTOS中的創(chuàng)建函數(shù)更直接、簡短，并且能更快的調試并識別問題。

在性能方面，兩者幾乎相同，但從開發(fā)人員的角度來看，Cesiμm RTOS代碼將更容易跟蹤。

特性區(qū)別

盡管兩個內核提供的功能相似，但Cesiμm RTOS提供了更高的代碼質量和一些獨特的特性。

其中包括更具描述性的錯誤返回代碼、與現(xiàn)成的Cesiμm軟件棧的兼容性以及整體代碼的清潔度。

錯誤返回碼

FreeRTOS函數(shù)返回碼非常簡單。通常會給出兩個返回代碼值給其調用API。大多數(shù)函數(shù)的返回值為pdPASS, pdFAIL, pdTRUE和pdFALSE。

對于描述性稍強的返回代碼，一些函數(shù)可能返回值errCOULD_NOT_ALLOCATE_REQUIRED_

MEMORY、errQUEUE_BLOCKED、errQUEUE_YIELD、errQUEUE_BLOCKED或errQUEUE_YIELD。

當試圖檢測代碼以實現(xiàn)故障恢復或更復雜的錯誤處理時，這些返回值無法提供更多詳細的反饋。

如vSemaphoreDelete()，這個函數(shù)調用了vQueueDelete()，其返回代碼是void，這使得測試該函數(shù)的結果是成功還是失敗變得很棘手。

相比之下，Cesiμm RTOS提供了豐富的錯誤返回值和消息，供開發(fā)人員在API中使用。所有用戶調用的OS函數(shù)都提供了(OS_ERR *)類型參數(shù)。

該變量在執(zhí)行完成時被賦予一個值來反映成功或失敗的原因。這些細節(jié)可以提供更精確的調試體驗。

當調試一個大型應用程序時，這個特性將顯著影響開發(fā)時間。

vSemaphoreDelete()的等效函數(shù)，在Cesiμm RTOS 為OSSemDel()，此函數(shù)接受(OS_ERR *)類型參數(shù)，該參數(shù)可以返回以下值之一。

支持的軟件棧

Cesiμm RTOS的另一個優(yōu)勢是其豐富的中間件支持。中間件與RTOS基于相同的規(guī)范設計和標準。使開發(fā)人員的學習體驗更加順暢。

廣泛使的用FreeRTOS，也支持許多第三方軟件棧。然而，這些產品具有不同的代碼設計標準，使得產品集成更具挑戰(zhàn)性。開發(fā)人員不僅要學習新產品，還必須熟悉其代碼風格。移植和集成工作更具挑戰(zhàn)性。Cesiμm RTOS全系列軟件產品在設計時考慮到了互操作性。這有助于加快開發(fā)人員在集成新軟件堆棧時的學習曲線。Cesiμm RTOS提供以下產品棧:

· 文件系統(tǒng)Cs/FS

· 網(wǎng)絡協(xié)議棧Cs/NET，其中應用協(xié)議如HTTP、DHCP等

· USB設備棧Cs/USBD

· USB主機棧Cs/USBH

· Modbus棧Cs/Modbus

此時，Cesiμm還支持SSL解決方案、圖形用戶接口和其他第三方產品。

潔凈的代碼

在查看代碼時，將代碼和注釋混合在一起時中，將很難將兩者分開并只關注其中一個。因此，Cesiμm RTOS代碼被劃分為左邊的代碼和右邊的注釋。當然，這并沒有真正的改進性能，完全是為了用戶體驗。結構越清晰，就越容易學習、使用和支持。這使得理解Cesiμm RTOS代碼更容易，從而節(jié)省了進入開發(fā)階段的時間。

雖然FreeRTOS和Cesiμm RTOS解決方案在性能和功能上相似，但Cesium RTOS提供了的更佳的用戶體驗。為應用程序選擇最佳的RTOS涉及許多因素，例如性能、功能和可靠性。對開發(fā)人員來說，同樣重要的是精通RTOS特性所需的努力程度及其易用性(其中包括應用程序調試，這是開發(fā)周期中經常被忽視的階段)。

隨著應用的增長，會添加新的特性集，整個項目的復雜性也會增加。Cesiμm RTOS內置的用戶體驗增強功能使用戶在復雜應用程序中更高效，并幫助提高工作效率。







審核編輯：劉清