1. 首頁
  2. 問答
  3. AVR上的多任務實時操作系統

AVR上的多任務實時操作系統

2011-10-25 32 views
1

我有一個AT90USB162 AVR芯片，我想運行一個多任務RTOS，因此我正在評估可能的RTOS以便與我的AVR芯片配合使用。 AVR支持哪些多任務實時操作系統？也許QNX？ （是否可以在AVR微芯片上運行QNX內核？）。AVR上的多任務實時操作系統

在此先感謝。

來源

2011-10-25 Rego

+0

您的意思是「實時...」中的「RTOS」？ - 或者你只是在尋找先發制人的時間安排？ – JimmyB

+0

我的意思是實時操作系統。 – Rego

+1

@Hanno：AVR有沒有一個先發制人的調度器，它不是實時的！？ – Clifford

回答

8

愛特梅爾AT90USB162是基於RISC-AVR 8位微控制器 - QNX將是一個延伸，和AVR是不符合他們的BSP directory

Micrium支持AVR的UC/OS-II

FreeRTOS還支持AVR

來源

2011-10-25 03:49:20

+0

Doug，你知道uC/OS-II是開源嗎？ （我認爲FreeRTOS是開源的，不是嗎？） – Rego

+0

我不是Doug，但uC/OS-II是開源許可的軟件：http://micrium.com/page/downloads/source_code（您必須註冊，創建一個帳戶，併購買許可證，如果你想在商業應用中使用它。） –

+2

下載源的能力與「開源」不同，請仔細閱讀產品的許可條款，而不是依賴任何陳述這裏。 Jean Labrosse的書中包含uC/OS-II的源代碼;這是以前獲得它的唯一方法。沒有購買許可證，您不能在商業產品中使用它。 FreeRTOS是開源的;它要求您確定在任何分佈式產品中使用FreeRTOS。如果你不想這樣做，OpenRTOS是相同的，但商業許可和支持。 – Clifford

3

當你說「RTOS」時，我認爲你是指先發制人的多任務？我猜測（因爲這是一個8位AVR），你不需要文件系統，網絡堆棧等。

如果你正在尋找一個微小的，先發制人的多任務內核，你可能要檢查出Quantum Platform - 我用它像AVR & MSP430非常資源有限的平臺。同事們也將其用於8位8051和HC11變種。 QP的搶佔內核（QK）是一個運行到完成的內核，它減少了對堆棧（RAM）的要求，並且使上下文切換更少資源密集型（沒有TCB，更少的上下文以節省還原）。

有一個「小」的QP/C變體和一個「微小」的QP-nano變體。由於這些條款是絕對沒有意義沒有數字，the QP-nano page有一個核心類型比較&其典型的大小。例如（提供的最小數字）：典型的RTOS，10K ROM，10K RAM; QP/C - 8K ROM，1K RAM; QP-nano-2K ROM，100字節的RAM。

好的是，所有的代碼是可用的，所以你可以下載&嘗試它&看你自己。

來源

2011-10-26 16:37:05 Dan

+0

謝謝你的建議。 – Rego

2

QNX - 不是一個機會！ QNX是一款相對較大且複雜的操作系統，適用於帶MMU的32位器件，不僅提供內核級調度，還提供文件系統，容錯網絡，POSIX API和GUI等。其最重要的特性是支持內存保護 - 每個線程運行在它自己的虛擬內存段中，所以只能在具有適當硬件支持的設備上運行。

你想從你的操作系統中獲得什麼功能？在8位設備上，期望基於優先級的基於優先級的調度和IPC是合理的。其他服務（如網絡，文件系統，USB等）通常是來自RTOS供應商的附件，或者必須與第三方代碼集成。

如果你想不花錢的話，這個明顯的選擇是FreeRTOS。這是合格，雖然在某些方面非常規的架構，即使在API級相當傳統。在我的ARM測試中，它的上下文切換時間較慢，我將其他內核與我測試過的其他內核進行了比較，但AVR上可能並不是這種情況，並且如果您需要實時響應時間，則這只是一個問題。幾微秒。 AVR有一個相當大的寄存器組，所以在任何情況下上下文切換通常都很昂貴。

愛特梅爾擁有包括RTOS在內的第三方支持列表，網址爲http://www.atmel.com/products/AVR/thirdparty.asp#。他們列出如下：

  • CMX Systems公司：CMX-RTX，的CMX-Tiny +（附加組件：CMX-的MicroNet，CMX-FFS）
  • FreeRTOS.org：FreeRTOS的
  • Micriμm，公司：μC/ OS-II
  • 螺母/操作系統：帶有類似Posix的API的RTOS和TCP/IP堆棧。
  • SEGGER：embOS

我的CMX-Tiny +（對於dsPIC）的個人經驗，embOS（基於ARM）和FreeRTOS操作系統（基於ARM）和uC/OS-II。它們全部勝任，uC-OS-II只有在每個優先級級別允許單個任務（沒有循環調度）的次要限制，但因此可能會更快地進行上下文切換。就embOS而言，我已經成功集成了第三方文件系統和USB代碼，儘管供應商也有自己的附加組件。

來源

2011-12-15 10:30:14 Clifford

0

雖然不是對您的問題的直接回答，但是由於資源有限的8位控制器，在提交到OS層之前考慮優勢，只有在項目必須處理主要子系統時，OS層的優勢纔會受益這是繁瑣的編碼和維護前。文件系統，圖形，音頻，網絡等。

由於大多數供應商提供集成開發環境和標準庫以及更多，你可以編寫代碼與高級語言如C，C++，簡單的控制任務堅持你的自己的框架工作將更易於管理

來源

2017-01-30 14:57:28 Raj

相關問題

 相關問題