1 前言

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

2 遇到的問題

這個(gè)問題主要的體現(xiàn)就是在創(chuàng)建任務(wù)的接口調(diào)用上，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;

我們關(guān)注下第5個(gè)參數(shù)uxPriority，這個(gè)參數(shù)就是指定任務(wù)的優(yōu)先級(jí)。 我們都知道freeRTOS是基于任務(wù)優(yōu)先級(jí)來進(jìn)行調(diào)度的，創(chuàng)建任務(wù)時(shí)指定的任務(wù)優(yōu)先級(jí)直接影響任務(wù)響應(yīng)的實(shí)時(shí)性。 早前我們是使用AliOS，功能組件代碼也都是使用AliOS的創(chuàng)建任務(wù)的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層接口的轉(zhuǎn)換的時(shí)候，優(yōu)先級(jí)這個(gè)數(shù)值就出問題了。 比如AliOS的接口傳入prio=60；然后60傳入freeRTOS就會(huì)出問題了，導(dǎo)致的結(jié)果就是新創(chuàng)建的任務(wù)可以被調(diào)度起來，但是創(chuàng)建任務(wù)的接口沒法返回了。 這里的根本原因就是freeRTOS的優(yōu)先級(jí)定義，數(shù)值越小，優(yōu)先級(jí)越低；反之，優(yōu)先級(jí)越高。

3 如何解決

解決的方法，倒是比較簡(jiǎn)單，但是會(huì)比較繁瑣。 我們需要對(duì)所有創(chuàng)建的任務(wù)，傳入的優(yōu)先級(jí)數(shù)值重新進(jìn)行評(píng)估，明確每個(gè)任務(wù)是高優(yōu)先級(jí)還是低優(yōu)先級(jí)。 比如上面的prio=60(低優(yōu)先級(jí))改為prio=0或1就可以解決問題了。

4 經(jīng)驗(yàn)總結(jié)

針對(duì)freeRTOS這種反常的優(yōu)先級(jí)數(shù)值定義，我總結(jié)了其他常見RTOS的定義，做下對(duì)比，加深理解和記憶：

看到這里，大家一定感慨，就只有freeRTOS獨(dú)一檔的存在，只有它是數(shù)值越小，優(yōu)先級(jí)越低！ 這里提醒下大家，如果你從其他RTOS平臺(tái)遷移到freeRTOS平臺(tái)，尤其注意下優(yōu)先級(jí)數(shù)值的問題，否則可能會(huì)導(dǎo)致莫名其妙的問題。

5 更多分享

歡迎關(guān)注我的github倉(cāng)庫(kù)01workstation，日常分享一些開發(fā)筆記和項(xiàng)目實(shí)戰(zhàn)，歡迎指正問題。

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