|
|
FreeRTOS中文使用教程（附件里面還有英文版）：
xQueueCreate() API 函數
隊列在使用前必須先被創建。
隊列由聲明為 xQueueHandle 的變量進行引用。xQueueCreate()用于創建一個隊列，并返回一個xQueueHandle 句柄以便于對其創建的隊列進行引用。
當創建隊列時，FreeRTOS從堆空間中分配內存空間。分配的空間用于存儲隊列數據結構本身以及隊列中包含的數據單元。如果內存堆中沒有足夠的空間來創建隊列，xQueueCreate()將返回NULL。第五章會有關于內存堆管理的更多信息。
6.3 其它常見錯誤
問題現象：在一個 Demo應用程序中增加了一個簡單的任務，導致應用程序崩潰 任務創建時需要在內存堆中分配空間。許多 Demo 應用程序定義的堆空間大小只夠用于創建 Demo 任務——所以當任務創建完成后，就沒有足夠的剩余空間來增加其它的任務，隊列或信號量。
空閑任務是在 vTaskStartScheduler()調用中自動創建的。如果由于內存不足而無法創建空閑任務，vTaskStartScheduler()會直接返回。在調用 vTaskStartScheduler()后加上一條空循環[for(;;)]可以使這種錯誤更加容易調試。
如果要添加更多的任務，可以增加內存堆空間大小，或是刪掉一些已存在的 Demo任務。
問題現象：在中斷中調用一個 API 函數，導致應用程序崩潰
除了具有后綴為”FromISR”函數名的 API 函數，千萬不要在中斷服務例程中調用其它 API 函數。
問題現象：有時候應用程序會在中斷服務例程中崩潰
需要做的第一件事是檢查中斷是否導致了棧溢出。 在不同的移植平臺和不同的編譯器上，中斷的定義和使用方法是不盡相同的——所以，需要做的第二件事是檢查在中斷服務例程中使用的語法，宏和調用約定是否符合Demo程序的文檔描述，以及是否和Demp程序中提供的中斷服務例程范例相同。 如果應用程序工作在 Cotex M3 上，需要確定給中斷指派優先級時，使用低優先級號數值表示邏輯上的高優先級中斷，因為這種方式不太直觀，所以很容易被忘記。一個比較常見的錯誤就是，在優先級高于configMAX_SYSCALL_INTERRUPT_PRIORITY的中斷中調用了 FreeRTOS API 函數。
問題現象：在啟動第一個任務時，調度器就崩潰了
如果使用的是 ARM7，那么請確定調用 vTaskStartScheduler()時處理器處于管理模式(Supervisor mode)。最簡單的方式就是在 main()之前的 C啟動態碼中將處理器設置為管理模式。ARM7 的 Demo應用程序就是這么做的。 如果處理器不在管理模式下，調度器是無法啟動的。
問題現象：臨界區無法正確嵌套
除了 taskENTER_CRITICA()和 taskEXIT_CRITICAL()，千萬不要在其它地方修改控制器的中斷使能位或優先級標志。這兩個宏維護了一個嵌套深度計數，所以只有當所有的嵌套調用都退出后計數值才會為0，也才會使能中斷。
問題現象：在調度器啟動前應用程序就崩潰了
如果一個中斷會產生上下文切換，則這個中斷不能在調度器啟動之前使能。這同樣適用于那些需要讀寫隊列或信號量的中斷。在調度器啟動之前，不能進行上下文切換。 還有一些 API 函數不能在調度器啟動之前調用。在調用 vTaskStartScheduler()之前，最好是限定只使用創建任務，隊列和信號量的API 函數。
問題現象：在調度器掛起時調用 API 函數，導致應用程序崩潰
調用 vTaskSuspendAll()使得調度器掛起，而喚醒調度器調用xTaskResumeAll()。 千萬不要在調度器掛起時調用其它 API 函數。
問題現象：函數原型 pxPortInitialiseStack()導致編譯失敗
每種移植都需要定義一個對應的宏，以把正確的內核頭文件加入到工程中。如果編譯函數原型 pxPortInitialiseStack()時出錯，這種現象基本上可以確定是因為沒有正確定義相應的宏。請參見附錄 4以獲得更多信息。
可以基本相應平臺的 Demo 工程建立新的應用程序。這種方式就不用擔心沒有包含正確的文件，也不必擔心沒有正確地配置編譯器選項。
|
評分
-
查看全部評分
|
[復制鏈接]
