FreeRTOS——隊列

• 隊列
• 使用者模型
• 隊列阻塞

隊列

隊列是任務間通信的主要形式。它們可用于在任務之間、中斷和任務之間發送消息。在大多數情況下，它們被用作線程安全的FIFO（先入先出）緩沖區，新資料被發送到隊列的後部，盡管資料也可以發送到前端。

向隊列寫入和從隊列讀取。在這個例子中，建立的隊列包含5個條目，并且隊列永遠不會滿。

使用者模型

使用者模型：最大的簡單性，最大的靈活性。。。

FreeRTOS隊列使用模型設法将簡單性與靈活性結合起來——這些屬性通常是互斥的。消息發送是通過複制隊列來實作的，這意味着資料（可以是指向大緩沖區的指針）本身被複制到隊列中，而不是隊列總是存儲對資料的引用。這是最好的方法，因為：

• 已經包含在C變量（整數、小型結構等）中的小消息可以直接發送到隊列中。不需要為消息配置設定緩沖區，然後将變量複制到已配置設定的緩沖區中。同樣，消息可以直接從隊列讀取到C變量中。

  此外，以這種方式發送到隊列允許發送任務立即覆寫發送到隊列的變量或緩沖區，即使已發送的消息仍在隊列中。因為變量中包含的資料被複制到隊列中，是以變量本身可以重用。發送消息的任務和接收消息的任務不需要就哪個任務擁有消息以及哪個任務負責在不再需要消息時釋放消息達成一緻。

• 使用按複制傳遞資料的隊列并不會妨礙使用隊列來按引用傳遞資料。當消息的大小達到一定程度，不能将整個消息以位元組為機關複制到隊列中時，可以定義隊列來儲存指針，并将指向該消息的指針複制到隊列中。
• 核心完全負責配置設定用作隊列存儲區域的記憶體。
• 可變大小的消息可以通過定義隊列來儲存結構，該結構包含一個指向隊列消息的成員，以及另一個儲存隊列消息大小的成員。
• 單個隊列可以用來接收不同的消息類型和來自多個位置的消息，方法是将隊列定義為持有結構，該結構擁有一個持有消息類型的成員，以及另一個持有消息資料（或指向消息資料的指針）的成員。如何解釋資料取決于消息類型。
• 該實作自然地适合于在記憶體保護環境中使用。一個被限制在受保護記憶體區域的任務可以将資料傳遞給一個被限制在不同受保護記憶體區域的任務，因為通過調用隊列發送函數來調用RTOS将提高微控制器的特權級别。隊列存儲區域隻被RTOS（具有完全權限）通路。
• 提供了一個單獨的API供中斷内部使用。将RTOS任務使用的API與中斷服務例程使用的API分離意味着RTOS API函數的實作不需要在每次執行時檢查它們的調用上下文。使用單獨的中斷API也意味着，在大多數情況下，建立RTOS感覺的中斷服務例程對終端使用者來說比其他RTOS産品更簡單。
• 無論如何，API都更簡單。

隊列阻塞

隊列API函數允許指定阻塞時間。

當一個任務嘗試從一個空隊列中讀取時，該任務将被放置到阻塞狀态（是以它不消耗任何CPU時間，其他任務可以運作），直到隊列上的資料可用，或者阻塞時間過期。

當一個任務嘗試寫滿一個隊列時，該任務将被置于阻塞狀态（是以它不消耗任何CPU時間，其他任務可以運作），直到隊列中有可用空間或阻塞時間到期。

如果同一個隊列上有多個任務阻塞，那麼優先級最高的任務将首先被解除阻塞。

注意，中斷不能使用不以“

FromISR

”結尾的API函數。