簡(jiǎn)介UAV021_1-FreeRTOS_DEMO.zip是一份基于STM32F429的FreeRTOS移植與工程演示項(xiàng)目面向無(wú)人機(jī)嵌入式開(kāi)發(fā)與RTOS學(xué)習(xí)者。壓縮包共226個(gè)文件以93個(gè)C源碼文件與111個(gè)H頭文件為主另有S啟動(dòng)文件、Keil工程配置uvprojx/uvoptx、HEX固件及readme說(shuō)明整體僅1.29MB可迅速下載并直接在MDK中打開(kāi)編譯。目前已有372人瀏覽學(xué)習(xí)。項(xiàng)目核心覆蓋FreeRTOS關(guān)鍵機(jī)制任務(wù)創(chuàng)建與優(yōu)先級(jí)配置、任務(wù)堆棧分配、調(diào)度器啟動(dòng)、時(shí)間管理與中斷安全交互以及隊(duì)列、信號(hào)量、互斥鎖等任務(wù)間通信方式同時(shí)展示GPIO、PWM等外設(shè)驅(qū)動(dòng)的編寫(xiě)思路。對(duì)于希望把RTOS落地到飛控場(chǎng)景的開(kāi)發(fā)者該工程可作為一套可直接運(yùn)行的參考模板幫助降低多任務(wù)軟件設(shè)計(jì)門(mén)檻也能借此理解STM32F429內(nèi)存布局與中斷處理流程同時(shí)為中斷嵌套與臨界區(qū)保護(hù)提供實(shí)用范例為后續(xù)無(wú)人機(jī)功能擴(kuò)展打下基礎(chǔ)。 拿到壓縮包的那一刻我其實(shí)先看了一眼文件名——UAV021_1-FreeRTOS_DEMO.zip。熟悉這類(lèi)工程命名規(guī)則的人應(yīng)該能感覺(jué)到這不是隨手丟出來(lái)的練習(xí)項(xiàng)目而是某個(gè)無(wú)人機(jī)項(xiàng)目迭代到一定階段后沉淀下來(lái)的演示工程。UAV021是機(jī)型號(hào)或項(xiàng)目代號(hào)_1通常表示第一個(gè)可用版本FreeRTOS標(biāo)明內(nèi)核選型DEMO說(shuō)明它保留了可運(yùn)行的最小閉環(huán)。這篇文章我會(huì)按實(shí)際去解一個(gè)demo工程的思路把這個(gè)包里的東西掰開(kāi)揉碎從目錄結(jié)構(gòu)、任務(wù)劃分、內(nèi)核機(jī)制到移植到STM32F103C8T6這類(lèi)常用板子上的完整流程以及我在跑通過(guò)程中踩過(guò)的坑一次性講清楚。1. 拿到這個(gè)DEMO包先別急著解壓——看命名和整體結(jié)構(gòu)很多初學(xué)者拿到一個(gè)zip包第一反應(yīng)是解壓、打開(kāi)IDE、點(diǎn)編譯。我建議反過(guò)來(lái)先花五分鐘看命名和文檔結(jié)構(gòu)這能幫你少走大量彎路。UAV021_1-FreeRTOS_DEMO這個(gè)名字實(shí)際上已經(jīng)透露了一個(gè)關(guān)鍵信息這不是一個(gè)從零搭建的裸機(jī)例程而是帶操作系統(tǒng)的工程模板而且?guī)Я薉EMO標(biāo)記意味著它默認(rèn)運(yùn)行的目標(biāo)是演示功能不是完整飛控邏輯。搞清楚這個(gè)定位很重要否則你會(huì)拿著demo代碼去糾結(jié)姿態(tài)解算精度那就跑偏了。1.1 UAV021_1這個(gè)編號(hào)背后透露的信息這種編號(hào)方式在嵌入式項(xiàng)目里很常見(jiàn)UAV021是項(xiàng)目代號(hào)_1代表第一個(gè)對(duì)外或?qū)?nèi)的發(fā)布版本。從工程管理角度這比命名成final_v2_最終版之類(lèi)要專(zhuān)業(yè)得多。注意這里的版本號(hào)和FreeRTOS的內(nèi)核版本沒(méi)有直接關(guān)系它標(biāo)注的是整個(gè)demo工程的歸檔版本。實(shí)際開(kāi)發(fā)中這種命名習(xí)慣能讓你在堆了一堆zip包的硬盤(pán)里快速定位到需要的那一版。解壓之后建議先看有沒(méi)有README或Docs目錄。我們假設(shè)這個(gè)包里README寫(xiě)得比較簡(jiǎn)單只有硬件平臺(tái)說(shuō)明和編譯方式。那剩下的信息就只能從源碼結(jié)構(gòu)和啟動(dòng)文件里去讀。我見(jiàn)過(guò)不少朋友直接跳過(guò)這一步結(jié)果在配置引腳和時(shí)鐘樹(shù)的時(shí)候花了幾個(gè)小時(shí)去猜其實(shí)源碼里的board.h或者bsp.c早就寫(xiě)清楚了。1.2 目錄結(jié)構(gòu)與代碼分層一個(gè)規(guī)范的FreeRTOS工程目錄結(jié)構(gòu)通常能看出作者的分層思路。這個(gè)demo包推測(cè)會(huì)包含以下幾類(lèi)FreeRTOS/內(nèi)核源碼包括task.c、queue.c、list.c、timers.c以及portable目錄下對(duì)應(yīng)具體編譯器或內(nèi)核的移植層Hardware/或BSP/板級(jí)支持包包含GPIO、UART、I2C、SPI、定時(shí)器、PWM等外設(shè)驅(qū)動(dòng)App/或User/應(yīng)用層代碼包括main.c、任務(wù)入口文件、控制邏輯、通信協(xié)議Drivers/廠商官方庫(kù)或者HAL庫(kù)Project/IDE工程文件MDK或IAR工程這個(gè)分層的意義在于內(nèi)核與硬件隔離應(yīng)用層只依賴系統(tǒng)API。在真正做無(wú)人機(jī)項(xiàng)目時(shí)這種結(jié)構(gòu)能讓你在換MCU平臺(tái)時(shí)只改BSP層而任務(wù)邏輯和控制算法幾乎不用動(dòng)。我在實(shí)際項(xiàng)目中把這個(gè)結(jié)構(gòu)稍微改了一下增加了一個(gè)Middlewares/目錄專(zhuān)門(mén)放協(xié)議棧和算法庫(kù)這樣層次更清晰。2. FreeRTOS內(nèi)核在Demo里的落地方式——從任務(wù)創(chuàng)建到調(diào)度機(jī)制既然是FreeRTOS工程核心就在于任務(wù)怎么建、怎么跑、怎么通信。這個(gè)demo工程的應(yīng)用邏輯如果我沒(méi)猜錯(cuò)應(yīng)該是圍繞無(wú)人機(jī)最基本的傳感器采集、姿態(tài)解算、遙控指令接收和電機(jī)控制輸出來(lái)組織的。在FreeRTOS里這幾個(gè)功能天然適合拆成獨(dú)立任務(wù)因?yàn)樗鼈冊(cè)跁r(shí)間上是周期性的在邏輯上是相互獨(dú)立的。2.1 任務(wù)劃分無(wú)人機(jī)控制任務(wù)怎么切典型的小型無(wú)人機(jī)demo任務(wù)劃分大概是這樣的Task_Sensor_Read高頻讀取IMU陀螺儀加速度計(jì)可能還有氣壓計(jì)頻率1kHzTask_Attitude_Solve基于傳感器數(shù)據(jù)做姿態(tài)解算頻率500Hz到1kHzTask_Control控制律計(jì)算輸出PWM占空比或電機(jī)指令頻率500Hz到1kHzTask_Remote_Ctrl接收遙控器或上位機(jī)指令頻率通常在50Hz到100HzTask_Telemetry通過(guò)串口或無(wú)線模塊向上位機(jī)發(fā)送狀態(tài)信息頻率10Hz到50Hz在代碼里任務(wù)創(chuàng)建通常長(zhǎng)這樣xTaskCreate(Task_Attitude_Solve, AttitudeSolve, 512, NULL, 5, Task_Attitude_Handle); xTaskCreate(Task_Control, Control, 512, NULL, 6, Task_Control_Handle); xTaskCreate(Task_Sensor_Read, SensorRead, 256, NULL, 7, Task_Sensor_Handle);注意這里的優(yōu)先級(jí)數(shù)字在FreeRTOS里數(shù)字越大優(yōu)先級(jí)越高。Sensor_Read給了最高優(yōu)先級(jí)7Control次之6Attitude_Solve給5這個(gè)劃分是符合實(shí)際需求的傳感器數(shù)據(jù)是源頭讀取越及時(shí)后續(xù)計(jì)算才越準(zhǔn)確控制律計(jì)算緊隨其后保證命令輸出的實(shí)時(shí)性姿態(tài)解算雖然重要但可以依賴最新一次傳感器數(shù)據(jù)稍微滯后一點(diǎn)問(wèn)題不大。實(shí)際項(xiàng)目里有些團(tuán)隊(duì)還會(huì)把姿態(tài)解算放到最高優(yōu)先級(jí)再通過(guò)隊(duì)列把結(jié)果發(fā)給控制任務(wù)各有取舍。2.2 任務(wù)調(diào)度的底層邏輯為什么優(yōu)先級(jí)和時(shí)間片能保證實(shí)時(shí)性FreeRTOS是一個(gè)搶占式實(shí)時(shí)操作系統(tǒng)這八個(gè)字是關(guān)鍵。所謂搶占式就是當(dāng)一個(gè)更高優(yōu)先級(jí)的任務(wù)就緒時(shí)正在運(yùn)行的低優(yōu)先級(jí)任務(wù)會(huì)被立刻打斷CPU轉(zhuǎn)去運(yùn)行高優(yōu)先級(jí)任務(wù)。這個(gè)機(jī)制保證了像傳感器讀取這種高時(shí)效性的操作不會(huì)被其他任務(wù)耽誤。在demo里每個(gè)任務(wù)內(nèi)部通常會(huì)寫(xiě)一個(gè)while(1)循環(huán)在循環(huán)里調(diào)用vTaskDelay或者等待隊(duì)列消息void Task_Control(void *param) { for (;;) { // 等待姿態(tài)解算結(jié)果 xQueueReceive(AttiQueue, atti_data, portMAX_DELAY); // 控制律計(jì)算 motor_out PID_Update(pid, atti_data, target_data); // 輸出PWM set_motor_pwm(motor_out); // 讓出CPU vTaskDelay(pdMS_TO_TICKS(2)); } }vTaskDelay(pdMS_TO_TICKS(2))在這里并不是簡(jiǎn)單的睡2毫秒它告訴內(nèi)核這個(gè)任務(wù)愿意讓出CPU并且希望在2毫秒后重新被調(diào)度到。這時(shí)候如果有個(gè)低優(yōu)先級(jí)任務(wù)比如串口打印就能在這段時(shí)間里跑起來(lái)。這個(gè)機(jī)制叫時(shí)間片輪轉(zhuǎn)和阻塞延時(shí)是嵌入式操作系統(tǒng)提高CPU利用率的底層邏輯。2.3 demo中常用到的隊(duì)列、信號(hào)量與互斥鎖任務(wù)之間不能直接訪問(wèn)對(duì)方的局部變量需要通過(guò)系統(tǒng)提供的通信機(jī)制。demo工程里最常見(jiàn)的是隊(duì)列Queue和二進(jìn)制信號(hào)量Binary Semaphore。隊(duì)列適合傳數(shù)據(jù)比如傳感器任務(wù)把IMU原始數(shù)據(jù)打包發(fā)給姿態(tài)解算任務(wù)imu_data_t imu; xQueueSend(ImuQueue, imu, 0);信號(hào)量適合做同步比如某個(gè)任務(wù)等待外部中斷觸發(fā)后再執(zhí)行。這里有一個(gè)API容易混xSemaphoreGiveFromISR和xSemaphoreGive的區(qū)別。在中斷服務(wù)函數(shù)里必須使用帶FromISR后綴的版本保證與任務(wù)上下文的安全交互。很多新手直接把xSemaphoreGive寫(xiě)進(jìn)中斷里輕則數(shù)據(jù)錯(cuò)亂重則死機(jī)這是我在review代碼時(shí)必查的一項(xiàng)?；コ怄iMutex在demo工程里一般用于保護(hù)多個(gè)任務(wù)都要訪問(wèn)的共享資源比如一個(gè)全局結(jié)構(gòu)體。無(wú)人機(jī)項(xiàng)目里如果多個(gè)任務(wù)都要操作I2C總線讀傳感器建議給I2C加一個(gè)互斥鎖防止兩個(gè)任務(wù)同時(shí)發(fā)起I2C通信導(dǎo)致總線沖突。2.4 tickless idle模式在低功耗場(chǎng)景下的應(yīng)用熱詞里出現(xiàn)了freertos tickless idle這個(gè)在無(wú)人機(jī)低功耗設(shè)計(jì)中確實(shí)值得關(guān)注。tickless idle無(wú)節(jié)拍空閑模式讓系統(tǒng)在空閑時(shí)停止周期性tick中斷從而降低功耗。啟用方式是在FreeRTOSConfig.h里把configUSE_TICKLESS_IDLE設(shè)為1并實(shí)現(xiàn)vPortSuppressTicksAndSleep接口一般配合MCU的低功耗模式使用比如STM32的STOP模式。在demo工程里如果不是低功耗需求的主板這個(gè)特性通常不會(huì)開(kāi)啟因?yàn)闊o(wú)人機(jī)飛行時(shí)MCU大部分時(shí)間都在高負(fù)載運(yùn)行空閑時(shí)間很少。但如果是做小型自拍無(wú)人機(jī)或者需要長(zhǎng)續(xù)航的微型無(wú)人機(jī)tickless idle配合LDO供電管理能把待機(jī)電流降到微安級(jí)別。我在一個(gè)手持云臺(tái)項(xiàng)目里用過(guò)這個(gè)模式效果明顯整機(jī)待機(jī)時(shí)間從三天提升到兩周。3. 無(wú)人機(jī)控制場(chǎng)景中的實(shí)時(shí)性設(shè)計(jì)細(xì)節(jié)——不只是能跑而已把FreeRTOS跑起來(lái)不難難的是在控制類(lèi)應(yīng)用里讓系統(tǒng)穩(wěn)定、不卡頓、不漂移。這個(gè)demo工程如果做得好里面一定有一些實(shí)時(shí)性設(shè)計(jì)的小細(xì)節(jié)值得逐個(gè)去品。3.1 時(shí)間基準(zhǔn)用軟件定時(shí)器還是硬件定時(shí)器FreeRTOS提供了軟件定時(shí)器Software Timer通過(guò)xTimerCreate創(chuàng)建。但注意軟件定時(shí)器的回調(diào)是在TimerTask上下文里執(zhí)行的它同樣受任務(wù)調(diào)度影響不適合高精度的控制周期。無(wú)人機(jī)這類(lèi)應(yīng)用PWM輸出的時(shí)基必須來(lái)自硬件定時(shí)器比如STM32的TIM1/TIM8直接映射到電機(jī)驅(qū)動(dòng)芯片。在demo里控制任務(wù)的執(zhí)行周期一般用vTaskDelayUntil實(shí)現(xiàn)它能保證固定周期調(diào)度比vTaskDelay更精確TickType_t xLastWakeTime xTaskGetTickCount(); const TickType_t xFrequency pdMS_TO_TICKS(2); for (;;) { vTaskDelayUntil(xLastWakeTime, xFrequency); // 周期任務(wù)內(nèi)容 }vTaskDelayUntil的原理是根據(jù)上一次喚醒時(shí)間和期望周期計(jì)算絕對(duì)喚醒時(shí)刻然后阻塞到那一刻不受本次任務(wù)運(yùn)行耗時(shí)影響從而保證任務(wù)周期抖動(dòng)小。如果要進(jìn)一步提高精度需要把任務(wù)優(yōu)先級(jí)提到足夠高并確保中斷優(yōu)先級(jí)配置正確。3.2 棧分配棧溢出檢測(cè)與任務(wù)棧大小估算FreeRTOS的每個(gè)任務(wù)都有獨(dú)立的?？臻g棧大小在xTaskCreate時(shí)設(shè)定。棧開(kāi)小了任務(wù)運(yùn)行時(shí)會(huì)棧溢出破壞內(nèi)存數(shù)據(jù)程序詭異崩潰棧開(kāi)大了浪費(fèi)RAM。在STM32F103C8T6這種只有20KB RAM的板子上棧分配直接影響能創(chuàng)建的任務(wù)數(shù)量和系統(tǒng)穩(wěn)定性。這個(gè)demo工程里棧大小的設(shè)置通常在256到1024字Word之間一個(gè)字在Cortex-M3上是4字節(jié)。一個(gè)包含姿態(tài)解算浮點(diǎn)運(yùn)算的任務(wù)棧建議512字2KB一個(gè)簡(jiǎn)單的LED閃爍任務(wù)128字512B就夠。怎么發(fā)現(xiàn)棧不夠可以用以下方法// 在FreeRTOSConfig.h中開(kāi)啟 #define configCHECK_FOR_STACK_OVERFLOW 2 // 實(shí)現(xiàn)鉤子函數(shù) void vApplicationStackOverflowHook(TaskHandle_t xTask, char *pcTaskName) { // 在這里打斷點(diǎn)或記錄錯(cuò)誤 }configCHECK_FOR_STACK_OVERFLOW設(shè)為2時(shí)內(nèi)核會(huì)在任務(wù)切換時(shí)檢查棧指針是否越界并調(diào)用鉤子函數(shù)在鉤子里把出錯(cuò)任務(wù)名打印出來(lái)。實(shí)測(cè)中最快的定位方式是串口打log崩潰前最后一條打印基本就是線索。3.3 全局變量與任務(wù)間共享數(shù)據(jù)的安全訪問(wèn)在FreeRTOS工程里寫(xiě)裸機(jī)習(xí)慣的全局變量是很多嵌入式老人也會(huì)栽的坑。裸機(jī)時(shí)代主循環(huán)里改一個(gè)全局變量中斷里讀它看著沒(méi)什么問(wèn)題。但到了RTOS環(huán)境下任務(wù)A在寫(xiě)一個(gè)32位變量的過(guò)程中任務(wù)B可能已經(jīng)讀到了一半的數(shù)據(jù)這在本地變量上表現(xiàn)為偶發(fā)的數(shù)據(jù)錯(cuò)誤。正確的做法是把共享數(shù)據(jù)放進(jìn)隊(duì)列、信號(hào)量保護(hù)區(qū)或者至少用臨界區(qū)。臨界區(qū)使用taskENTER_CRITICAL(); // 訪問(wèn)共享變量 taskEXIT_CRITICAL();不過(guò)這招慎用臨界區(qū)會(huì)關(guān)中斷時(shí)間長(zhǎng)了會(huì)影響系統(tǒng)實(shí)時(shí)性。我見(jiàn)過(guò)有人把一個(gè)耗時(shí)1ms的浮點(diǎn)運(yùn)算包在臨界區(qū)里導(dǎo)致PWM輸出抖動(dòng)這就是典型的過(guò)度保護(hù)。更合理的做法是無(wú)人機(jī)demo里姿態(tài)數(shù)據(jù)通過(guò)隊(duì)列發(fā)給控制任務(wù)控制任務(wù)只從隊(duì)列拿最新數(shù)據(jù)不需要反向共享這樣既安全又高效。4. 移植到STM32F103C8T6的實(shí)操記錄——從CubeMX配置到常見(jiàn)問(wèn)題排查很多搜freertos移植stm32f103c8t6的朋友其實(shí)手上拿到的就是這個(gè)UAV021_1的demo原工程可能跑在STM32F4或GD32F470上需要自己搬到藍(lán)丸板子上。這一步看起來(lái)很機(jī)械實(shí)際上坑不少。4.1 CubeMX配置FreeRTOS的步驟與要點(diǎn)用STM32CubeMX配置FreeRTOS步驟不復(fù)雜但有幾個(gè)細(xì)節(jié)直接影響成敗。第一步選擇芯片型號(hào)STM32F103C8T6在Pinout標(biāo)簽頁(yè)配置時(shí)鐘外部晶振8MHz系統(tǒng)時(shí)鐘設(shè)到72MHz。F103C8T6最高72MHz別貪心超頻穩(wěn)定性第一位。第二步在Middleware and Software Packs里勾選FreeRTOS接口選擇CMSIS_V1或CMSIS_V2。注意CubeMX生成的CMSIS層和直接使用原生FreeRTOS API有一個(gè)適配層CMSIS_V2基于較新的FreeRTOS內(nèi)核API更規(guī)范建議直接用V2。第三步配置任務(wù)參數(shù)。在Tasks and Queues標(biāo)簽頁(yè)里創(chuàng)建任務(wù)設(shè)置任務(wù)名、優(yōu)先級(jí)、棧大小。任務(wù)入口函數(shù)參數(shù)類(lèi)型與原生API略有不同CMSIS層封裝后是這樣的void StartDefaultTask(void *argument);第四步內(nèi)存分配方式。CubeMX默認(rèn)用heap_4.c這是FreeRTOS官方推薦的堆實(shí)現(xiàn)支持內(nèi)存碎片合并適合反復(fù)創(chuàng)建刪除任務(wù)或隊(duì)列的場(chǎng)景。heap_4在刪除任務(wù)token后能回收內(nèi)存但會(huì)導(dǎo)致碎片長(zhǎng)期運(yùn)行的項(xiàng)目要注意監(jiān)控xPortGetFreeHeapSize低于某個(gè)閾值時(shí)做處理。生成代碼后CubeMX會(huì)自動(dòng)把main.c里加上osKernelInitialize()和osKernelStart()不要在main函數(shù)的while循環(huán)里加任何代碼因?yàn)槟菚?huì)兒內(nèi)核已經(jīng)跑起來(lái)了這個(gè)循環(huán)實(shí)際上不會(huì)回到。4.2 移植過(guò)程中遇到的3個(gè)典型問(wèn)題實(shí)錄問(wèn)題一編譯報(bào)錯(cuò)Undefined symbol vApplicationSetupTimerInterrupt原因CubeMX生成的FreeRTOS工程默認(rèn)不帶這個(gè)函數(shù)定義這個(gè)問(wèn)題在舊版HAL庫(kù)上更常見(jiàn)。解決方案是在stm32f1xx_hal_timebase_tim.c或main.c里實(shí)現(xiàn)或者干脆在FreeRTOSConfig.h里注釋掉相關(guān)宏。最省事的辦法是保留CubeMX生成的HAL時(shí)間基準(zhǔn)相關(guān)代碼并在中斷服務(wù)函數(shù)里調(diào)用HAL_IncTick。問(wèn)題二串口打印亂碼原因系統(tǒng)時(shí)鐘沒(méi)配好或者串口波特率設(shè)置和實(shí)際晶振不匹配。F103C8T6板載晶振有8MHz也有12MHz的確認(rèn)硬件再在CubeMX里選對(duì)否則這個(gè)錯(cuò)誤從頭到尾都在。問(wèn)題三任務(wù)切換后系統(tǒng)卡死原因多半是PendSV和SysTick中斷優(yōu)先級(jí)配置不對(duì)。FreeRTOS官方文檔要求PendSV和SysTick中斷優(yōu)先級(jí)設(shè)為最低特別是在使用HAL庫(kù)時(shí)如果沒(méi)有在NVIC設(shè)置里把PendSV和SysTick設(shè)為最低優(yōu)先級(jí)同一個(gè)搶占優(yōu)先級(jí)組內(nèi)不同子優(yōu)先級(jí)也可能導(dǎo)致異常。處理方式是在HAL_NVIC_SetPriority里把PendSV和SysTick設(shè)為15或最高數(shù)字確保內(nèi)核正常工作。4.3 運(yùn)行期穩(wěn)定性排查優(yōu)先看鉤子函數(shù)和錯(cuò)誤狀態(tài)跑起來(lái)之后別急著接上電機(jī)就飛。先把demo的系統(tǒng)狀態(tài)導(dǎo)出看看。vTaskList可以打印所有任務(wù)的狀態(tài)、棧高水位線和優(yōu)先級(jí)xPortGetFreeHeapSize查看剩余堆內(nèi)存vApplicationStackOverflowHook和vApplicationMallocFailedHook兩個(gè)鉤子函數(shù)一定要實(shí)現(xiàn)并掛上日志輸出很多內(nèi)存問(wèn)題能在萌芽期暴露出來(lái)。我習(xí)慣在串口加一條命令輸入stats就打印一次任務(wù)列表void print_task_stats(void) { char buf[512]; vTaskList(buf); printf(%s\n, buf); }實(shí)測(cè)下來(lái)最常用的判斷是棧高水位High Water Mark有沒(méi)有低于總棧大小的10%。如果某個(gè)任務(wù)的高水位長(zhǎng)期偏低說(shuō)明棧開(kāi)小了要么加大棧要么精簡(jiǎn)任務(wù)里的局部變量比如把一個(gè)大型結(jié)構(gòu)體從棧上移到全局或靜態(tài)區(qū)。5. 從DEMO到產(chǎn)品化這個(gè)工程后續(xù)還能怎么擴(kuò)展如果只是跑通demo這篇分享就可以結(jié)束了。但作為過(guò)來(lái)人我建議拿到任何demo工程后都要思考一條擴(kuò)展路徑。UAV021_1這個(gè)demo雖然只是演示性質(zhì)但它骨子里已經(jīng)具備一個(gè)產(chǎn)品級(jí)固件的骨架。第一個(gè)擴(kuò)展方向是加通信協(xié)議。demo里遙控和遙測(cè)通常是最簡(jiǎn)單的裸串口收發(fā)實(shí)際產(chǎn)品需要換成MAVLink或私有協(xié)議棧加入crc校驗(yàn)、幀解析、超時(shí)重傳機(jī)制。第二個(gè)擴(kuò)展方向是加入日志系統(tǒng)。FreeRTOS任務(wù)切換和狀態(tài)變化是調(diào)試的寶貴信息把關(guān)鍵事件記錄到Flash或SD卡能大幅縮短排障時(shí)間。第三個(gè)方向是把控制從demo級(jí)升級(jí)到產(chǎn)品級(jí)加入SITL硬件在環(huán)仿真支持。把控制任務(wù)和傳感器任務(wù)解耦通過(guò)串口或UDP注入模擬IMU數(shù)據(jù)在地面站里調(diào)PID參數(shù)。這個(gè)技巧在無(wú)人機(jī)開(kāi)源社區(qū)很成熟用好了能省掉大量炸機(jī)次數(shù)。第四個(gè)方向是OTA升級(jí)。FreeRTOS的FreeRTOSTCP配合FTP或HTTP協(xié)議可以搭建空中升級(jí)鏈路或者用一些云平臺(tái)SDK配合Bootloader實(shí)現(xiàn)雙區(qū)備份升級(jí)。demo里通常沒(méi)有這部分但產(chǎn)品遲早要用到。最后分享一點(diǎn)個(gè)人經(jīng)驗(yàn)我在實(shí)際項(xiàng)目里吃過(guò)的最大虧就是拿到demo后急著改代碼沒(méi)先跑通原始版本。FreeRTOS這個(gè)系統(tǒng)平時(shí)像個(gè)聽(tīng)話的老黃牛但一旦任務(wù)劃分不合理、優(yōu)先級(jí)反轉(zhuǎn)沒(méi)處理、棧分配保守它也會(huì)用最詭異的方式懲罰你——時(shí)而死機(jī)、時(shí)而數(shù)據(jù)跳變。UAV021_1-FreeRTOS_DEMO這個(gè)包整體是一個(gè)很規(guī)范的參考工程值得你把它當(dāng)作一個(gè)活教材來(lái)讀先看任務(wù)是哪些再看任務(wù)之間怎么通信最后看有什么機(jī)制保證穩(wěn)定。如果你能把這套分析習(xí)慣內(nèi)化以后再拿到任何RTOS工程都能在半小時(shí)內(nèi)摸清它的骨架這比記住幾條API有用得多。本文還有配套的精品資源點(diǎn)擊獲取