1 前言

最近博主在做一些適配freeRTOS的項目，簡單來說就是從別的RTOS平臺遷移到freeRTOS平臺。 由于之前的代碼都是可用的，憑經驗我們認為只需要將OSAL的接口重新封裝一下，理論上上層的邏輯應該問題不大；但是我們沒想到的卻是在OSAL層適配的時候，遇到了一些之前沒有考慮到的問題。

2 遇到的問題

這個問題主要的體現就是在創建任務的接口調用上，freeRTOS的接口原型為：

BaseType_t xTaskCreate( TaskFunction_t pxTaskCode,
                            const char * const pcName,     /*lint !e971 Unqualified char types are allowed for strings and single characters only. */
                            const configSTACK_DEPTH_TYPE usStackDepth,
                            void * const pvParameters,
                            UBaseType_t uxPriority,
                            TaskHandle_t * const pxCreatedTask ) PRIVILEGED_FUNCTION;

我們關注下第5個參數uxPriority，這個參數就是指定任務的優先級。 我們都知道freeRTOS是基于任務優先級來進行調度的，創建任務時指定的任務優先級直接影響任務響應的實時性。 早前我們是使用AliOS，功能組件代碼也都是使用AliOS的創建任務的API：

/**
 * Create a task.
 *
 * @param[in]  task        handle.
 * @param[in]  name        task name.
 * @param[in]  fn          task function.
 * @param[in]  arg         argument of the function..
 * @param[in]  stack_buf   stack-buf: if stack_buf==NULL, provided by kernel.
 * @param[in]  stack_size  stack-size in bytes.
 * @param[in]  prio        priority value, the max is RHINO_CONFIG_USER_PRI_MAX(default 60).
 *
 * @return  0: success, otherwise: fail.
 */
int aos_task_new_ext(aos_task_t *task, const char *name, void (*fn)(void *),
                     void *arg, int stack_size, int prio);

這樣在做OS層接口的轉換的時候，優先級這個數值就出問題了。 比如AliOS的接口傳入prio=60；然后60傳入freeRTOS就會出問題了，導致的結果就是新創建的任務可以被調度起來，但是創建任務的接口沒法返回了。 這里的根本原因就是freeRTOS的優先級定義，數值越小，優先級越低；反之，優先級越高。

3 如何解決

解決的方法，倒是比較簡單，但是會比較繁瑣。 我們需要對所有創建的任務，傳入的優先級數值重新進行評估，明確每個任務是高優先級還是低優先級。 比如上面的prio=60(低優先級)改為prio=0或1就可以解決問題了。

4 經驗總結

針對freeRTOS這種反常的優先級數值定義，我總結了其他常見RTOS的定義，做下對比，加深理解和記憶：

看到這里，大家一定感慨，就只有freeRTOS獨一檔的存在，只有它是數值越小，優先級越低！ 這里提醒下大家，如果你從其他RTOS平臺遷移到freeRTOS平臺，尤其注意下優先級數值的問題，否則可能會導致莫名其妙的問題。

5 更多分享

歡迎關注我的github倉庫01workstation，日常分享一些開發筆記和項目實戰，歡迎指正問題。

同時也非常歡迎關注我的專欄：有問題的話，可以跟我討論，知無不答，謝謝大家。