尧图网站建设 
1. 移植LiteOS-M之前先想清楚这三件事上周同事拿了一块GD32F427的板子找我说想把LiteOS-M跑起来做一个小型网关项目。结果折腾了两天卡在官方Demo到底怎么用这一步——工程拷下来编译报错一大堆改了半天连LED都没闪起来。这个场景太常见了资料不是没有但一上来就闷头改代码方向不对越改越乱。先说清楚这篇东西解决什么问题。GD32F427这颗MCU我之前用了很久最早是跑裸机后来上了FreeRTOS再后来因为项目用了华为云的IoT方案才被迫认真研究LiteOS-M。折腾一圈下来最大的体会是LiteOS-M的官方Demo其实已经把99%的脏活累活干完了你要做的不是重复移植而是学会站在Demo的肩膀上改。这篇我打算从Demo仓库结构讲起把移植步骤、任务模型、常见的坑和排查思路都过一遍。适合三类人看第一类是从STM32转过来想快速上手GD32的第二类是裸机开发想第一次上RTOS的第三类是已经会FreeRTOS但被LiteOS-M的工程结构绕晕的。1.1 为什么选GD32F427这颗料配LiteOS-M先聊硬件。GD32F427是兆易创新基于ARM Cortex-M4内核的国产MCU主频最高可以跑到200MHzFlash最大能做到3MBRAM也有256KB级别。这个资源放在几年前就是中高端水准现在价格已经打到和普通M4一个水平性价比确实高。你要跑一个带网络协议栈、传感器采集、屏幕显示的小型物联网设备这个配置很舒服。我实际用下来F427这个系列在同等主频下性能比GD32F3系列强不少带了FPU和DSP指令跑浮点运算、FFT这类活不用CPU干等着。而且它和STM32F4系列引脚兼容性做得不错很多老项目可以直接平移这在国内项目里是个巨大的优势——老板让国产化替代的时候你几乎不需要重新画板子。至于LiteOS-M它是华为开源的轻量级物联网操作系统主打一个小而全。内核只有几万行代码RAM占用可以压到KB级别在Cortex-M0/M3/M4/M7这些核上都能跑而且支持CMSIS-RTOS2接口。对做物联网设备的人来说最实际的三个好处组件丰富华为专门适配了物联网场景常用的组件AT指令框架、MQTT、CoAP这些拿来就能用不用自己拼。有生态背书虽然网上讨论热度不如FreeRTOS但华为系的模组方案里大量在用LiteOS踩坑的人多沉淀下来的解决方案也多。支持标准接口你在FreeRTOS里写的应用程序逻辑只要用CMSIS-RTOS2 API封装过搬到LiteOS-M上几乎不需要改应用层代码。当然LiteOS-M在国内资料方向性比较散官方Demo版本之间差异也大这也是很多人卡住的原因。1.2 所谓移植真正要动的是哪些代码很多新手听到移植操作系统就慌以为要从零写调度器、写内存管理。实际上操作系统内核本身就是通用的谁都能跑。移植要做的全部事情就是让内核知道怎么在这颗芯片上完成三件事开关中断、触发调度、切换上下文。具体到GD32F427上需要关注的就这几块功能涉及文件说明启动与向量表startup_gd32f4xx.s、system_gd32f4xx.c芯片上电初始化中断向量表时钟节拍SysTick或其他硬件定时器给内核提供时间基准中断底层los_dispatch、port相关汇编上下文切换、PendSV/SVC处理内存布局链接脚本.sct/.ld定义栈顶地址、堆区、RO/RW段好消息是官方Demo里这些全部已经给你配好了。你要做的不是重新写一遍而是确认这些文件和你自己板子的硬件参数是否匹配然后改掉对应配置。1.3 为什么快速复用官方Demo是最高效的路线有人喜欢从零构建工程把内核源码一股脑加进keil然后自己写startup、自己配时钟、自己接SysTick、自己调上下文切换。说实话如果目标是学习这条路非常有价值能让你对操作系统原理有一个质的理解。但如果目标是项目尽快跑起来从零移植纯属浪费时间——官方已经给你探好路了你只需要裁裁剪剪。我自己实际经验是**从零移植一个RTOS顺利的话要一到两周从官方Demo改到自己项目跑起来一个下午就能搞定。**差距就在芯片相关代码和应用代码之间的那一层官方已经处理好了。所以这篇文章的核心思路就是教你读懂官方Demo的结构知道哪些能直接搬、哪些必须改、哪些值得借鉴然后带着这个理解去改自己的硬件项目。2. 官方Demo仓库的底层结构哪些能直接搬哪些必须改拿到LiteOS-M的SDK包时不要急着双击Keil工程去编译。我现在养成了一个习惯先花半小时把目录结构看一遍搞清楚谁是谁再动手。因为LiteOS的目录组织方式和FreeRTOS差别还挺大的你拿FreeRTOS的思路去找文件夹大概率会糊涂。2.1 LiteOS-M内核的目录划分逻辑一个典型的LiteOS-M工程基于GD32F427的target包目录如下LiteOS-M ├── arch # 架构相关代码移植重点 │ ├── arm │ │ ├── cortex-m4 │ │ │ ├── gcc # GCC编译链下的启动和上下文切换 │ │ │ └── iar # IAR下的实现 │ │ │ └── keil # MDK下的实现 │ │ └── include ├── components # 组件层 │ ├── cmsis # CMSIS-RTOS2适配 │ ├── llib # 轻量libc实现 │ ├── net # lwIP等网络组件 │ └── shell # 调试shell ├── kernel │ ├── include # 内核头文件 │ ├── src # 内核源码任务、队列、信号量、事件等 └── targets └── gd32f427i_start # 具体开发板适配层 ├── GCC ├── IAR ├── Keil ├── Src │ ├── main.c │ └── los_init.c ├── Inc └── gd32f4xx # GD32官方固件库注意arch目录里cortex-m4下面还有gcc/iar/keil三个子目录。这三个子目录里的文件看起来很像但汇编语法不一样千万别混用。你用什么编译器就只保留对应目录的文件其他的哪怕编译能过也尽量删掉不然工程文件混乱后面排查问题会疯掉。2.2 GD32F427的Demo里哪几个文件是最要紧的我把整个targets目录下的关键文件整理了一下优先级从高到低排文件作用移植时要做什么los_startup_gcc.s或对应keil版本内核启动入口第一个执行的汇编代码基本不用动target_config.h配置系统主频、内存起始地址、中断数量等硬件参数必须核对los_config.h内核裁剪配置比如任务栈大小、系统时钟节拍、内存池大小必须按需修改los_init.c内核初始化入口调用LOS_KernelInit等不用大改main.cDemo应用代码创建测试任务替换成你自己的逻辑.sct链接脚本定义Flash/RAM布局必须核对最有意思的是target_config.h这个文件就是芯片与内核之间的翻译官。里面会定义类似这样的宏#define OS_SYS_CLOCK 200000000 // 主频200MHz #define OS_SYS_TIMER_FREQ 1000 // 系统节拍1ms #define RAM_START_ADDRESS 0x20000000 // RAM起始地址 #define RAM_SIZE 0x30000 // 192KB RAM #define LOSCFG_BASE_CORE_TIMER 0 // 使用哪个定时器做系统节拍你改了主频但没改这里的OS_SYS_CLOCK系统节拍计算全乱任务延时和超时全都对不上——这是新手最容易踩的隐形坑之一。2.3 构建方式怎么选Keil老三样反而最省心官方Demo支持GCC、IAR、Keil三套构建方式。我个人的实践建议是跟着你最熟悉的工具链走但环境配置必须统一。我自己在Windows下开发用Keil MDK5最顺手就用keil目录下的工程文件。很多人一上来就想换成VSCodeGCC倒不是不行但LiteOS的GCC编译链要自己处理头文件路径、链接脚本、宏定义配置成本高而且出错后网上查到的资料大多是Keil工程下的经验你会在这行代码在我这边编译不过这种问题上卡很久。我的建议是先把官方Demo在Keil里跑通跑通了再考虑换工具链也不迟。提示不同版本的LiteOS-M源码arch目录下的文件路径可能略有差异。以你下载的SDK包里实际路径为准不要照抄网上的旧教程路径。3. 让官方Demo在你自己的板子上跑起来完整移植步骤搞清楚结构之后真正的移植其实就是一个改配置的过程。我把自己总结的步骤整理成了清单照着做大概率一个下午能跑通。3.1 环境准备软件、SDK、驱动一个都不能少基础环境三步走Keil MDK5建议5.30以上版本装好对应的芯片支持包GD32F4xx系列。去Keil官网或者兆易创新官方社区下载都可以注意芯片包版本要和你芯片料号对上。LiteOS-M的GD32F427 Demo包从Gitee的LiteOS-M仓库或者兆易创新官方的SDK页面下载。注意下载带targets/gd32f427i_start的版本不同芯片的Demo结构不一样。调试器驱动如果你的板载调试器是DAP-Link那插上USB就能用如果是J-Link需要装好J-Link驱动。硬件方面我建议准备一块带板载调试器的开发板别用那种只有最小系统、需要外接仿真器的核心板调试效率低很多。3.2 在Demo基础上复制工程改名字当自己项目进入targets/gd32f427i_start/Keil目录你会看到一个.uvprojx工程文件。我的习惯是不要在这个目录里直接改而是把整个gd32f427i_start文件夹复制一份重命名成你自己项目的名字比如my_gateway_board。原因很简单LiteOS-M的SDK会持续迭代更新你要是在原版目录里改了一堆东西后面官方发布新版本你想diff一下改动点都无从下手。复制一份出来保留了原始Demo作为参照改坏了随时可以对比恢复。复制完成后用Keil打开工程文件第一步就是看Target选项里的Device是否选到了你的芯片型号比如GD32F427VGT6。如果芯片型号不对编译器的宏定义如GD32F427和启动文件都匹配不上编译会报各种莫名其妙的问题。3.3 核对时钟、Flash和RAM这是移植的第一个分水岭不同的GD32F427型号Flash和RAM大小差异很大。比如GD32F427IG是1MB Flash而GD32F427VI是3MB Flash你用错链接脚本程序烧进去要么跑不起来要么直接烧录失败。打开工程里的链接脚本Keil下是.sct文件在工程的Target选项的Linker页面可以看到路径检查类似这样的内容LR_IROM1 0x08000000 0x00100000 { ; 1MB Flash ER_IROM1 0x08000000 0x00100000 { *.o (RESET, First) *(InRoot$$Sections) .ANY (RO) } RW_IRAM1 0x20000000 0x00040000 { ; 256KB RAM .ANY (RW ZI) } }这里0x00100000是FLASH容量1MB0x00040000是RAM容量256KB。如果你的芯片是512KB Flash就改成0x00080000。这个数字一定要和你的具体芯片型号对应宁小勿大改大了烧录时校验不通过。然后检查target_config.h和system_gd32f4xx.c里的系统时钟配置。GD32F427外部晶振常见的有8MHz和25MHz两种你板子上用的是哪种要查对应开发板的原理图确认。进入SystemInit函数可以看到PLL倍频相关的设置比如外部8MHz晶振倍频到200MHz代码里会有一个宏定义#define __SYSTEM_CLOCK_200M_PLL_8M_HXTAL (uint32_t)(200000000)如果你的板子用的是25MHz外部晶振这个宏就得换成__SYSTEM_CLOCK_200M_PLL_25M_HXTAL。晶振配置错了表现往往是串口输出的波特率不对或者干脆系统跑飞。3.4 改串口和LED初始化把调试通道打通我一直认为移植RTOS之后第一件事不是跑任务而是把printf调通。没有printf你后面排查任何问题都像盲人摸象。官方Demo里通常会有一段串口初始化代码位置在板级初始化文件里或者是main.c里直接调用。GD32F427的串口例程写法大致如下使用官方固件库void board_uart_init(void) { /* 使能时钟 */ rcu_periph_clock_enable(RCU_GPIOA); rcu_periph_clock_enable(RCU_USART0); /* 配置PA9为USART0_TXPA10为USART0_RX */ gpio_af_set(GPIOA, GPIO_AF_7, GPIO_PIN_9 | GPIO_PIN_10); gpio_mode_set(GPIOA, GPIO_MODE_AF, GPIO_PUPD_PULLUP, GPIO_PIN_9 | GPIO_PIN_10); gpio_output_options_set(GPIOA, GPIO_OTYPE_PP, GPIO_OSPEED_50MHZ, GPIO_PIN_9); /* 配置USART0参数115200-8-N-1 */ usart_deinit(USART0); usart_baudrate_set(USART0, 115200U); usart_word_length_set(USART0, USART_WL_8BIT); usart_stop_bit_set(USART0, USART_STB_1BIT); usart_parity_config(USART0, USART_PM_NONE); usart_hardware_flow_rts_config(USART0, USART_RTS_DISABLE); usart_hardware_flow_cts_config(USART0, USART_CTS_DISABLE); usart_receive_config(USART0, USART_RECEIVE_ENABLE); usart_transmit_config(USART0, USART_TRANSMIT_ENABLE); usart_enable(USART0); }这里的引脚号和复用功能编号要看你板子的实际连接不同开发板可能走不同的串口引脚。比如GD官方开发板用的是USART0PA9/PA10有些第三方核心板默认把调试串口接到了USART1PA2/PA3这个必须自己确认。然后是printf重定向int fputc(int ch, FILE *f) { usart_data_transmit(USART0, (uint8_t)ch); while(RESET usart_flag_get(USART0, USART_FLAG_TBE)); return ch; }注意Keil里要在Target选项的MicroLIB前面打勾用微库才能让printf走fputc重定向。忘记勾选MicroLIBprintf会进hardfault这也是一个经典坑。3.5 创建第一个任务并验证串口和时钟都通了之后下一步就是替换掉Demo的main.c写一个简单的闪灯任务验证系统跑起来了。一个最小可用的main陷入大致长这样#include los_task.h #include los_printf.h UINT32 g_ledTaskID; UINT32 g_ledTaskStack[512]; static VOID Led_Task(VOID *param) { while(1) { gpio_bit_toggle(GPIOF, GPIO_PIN_6); /* 翻转LED */ LOS_TaskDelay(500); /* 延时500ms */ } } int main(void) { /* 板级初始化时钟、LED、串口 */ board_init(); /* LiteOS内核初始化注意返回值判断 */ UINT32 ret LOS_KernelInit(); if (ret ! LOS_OK) { return -1; } /* 创建任务 */ TSK_INIT_PARAM_S taskParam {0}; taskParam.pfnTaskEntry (TSK_ENTRY_FUNC)Led_Task; taskParam.uwStackSize 512; /* 单位是字即512*42KB */ taskParam.pcName LedTask; taskParam.usTaskPrio 5; taskParam.uwResved LOS_TASK_STATUS_DETACHED; ret LOS_TaskCreate(g_ledTaskID, taskParam); if (ret ! LOS_OK) { return -1; } /* 启动调度从此进入多任务世界不会返回 */ LOS_Start(); return 0; }编译烧录后如果LED以1秒周期闪烁亮500ms灭500ms说明LiteOS-M已经在这颗GD32F427上跑起来了。提示LiteOS的任务栈大小uwStackSize单位是字Word不是字节。你写512实际分配的内存是512×42048字节。这个和FreeRTOS的堆栈大小单位一样但很多人习惯性以为是字节然后发现栈总是不够用。3.6 验证调度两个任务交替跑确认系统真的活了LED闪烁只能说明任务在跑但还看不出调度器的真实状态。为了确认多任务调度正常我习惯加一个调试打印任务VOID Print_Task(VOID *param) { UINT32 count 0; while(1) { printf([PrintTask] count%u, uptime%u ms\r\n, count, LOS_TickCountGet()); LOS_TaskDelay(1000); } }如果串口工具里能看到这个打印每秒出现一次而且LED也按预期闪烁那说明两个独立任务在各自的时间片里正常切换调度器工作正常。此时我们才真正完成了让LiteOS-M在GD32F427上跑起来这个目标接下来才是二次开发的真正战场。4. 任务编程模型切换从裸机思维到LiteOS-M跑通Demo只是起点真正的二次开发是把你的业务逻辑用多任务的方式重新组织起来。这一步对于习惯裸机编程的工程师来说是最容易走弯路的地方。4.1 裸机while(1)与RTOS多任务的核心区别裸机开发里最常见的结构是这样的while(1) { /* 处理按键 */ scan_key(); /* 处理传感器 */ read_sensor(); /* 刷新屏幕 */ update_display(); /* 处理网络 */ poll_network(); }结构简单但有个致命问题所有功能的实时性互相拖累。如果网络驱动调用的阻塞时间很长按键扫描就会被卡住屏幕刷新也会变慢。你只能用中断标志位状态机去拆解整个流程代码越写越绕。RTOS的思路完全不同。你把每个功能拆成独立任务调度器负责哪个时刻轮到谁跑。按键任务可以在自己被唤醒时立刻执行传感器任务用阻塞延时等待数据网络任务长时间阻塞等收包也完全不影响其他任务。互不干扰实时性可预期。程序员从管理所有事情的上帝模式变成了只关心自己这个任务逻辑的模块化模式。4.2 LiteOS-M常用API以及和FreeRTOS的对比我用一张表列下最常用到的API给从FreeRTOS转过来的读者快速对照功能FreeRTOSLiteOS-M备注创建任务xTaskCreateLOS_TaskCreateLiteOS的参数结构体类型为TSK_INIT_PARAM_S删除任务vTaskDeleteLOS_TaskDelete延时vTaskDelayLOS_TaskDelay单位都是tick不传入ticks毫秒需换算下同获取tickxTaskGetTickCountLOS_TickCountGet信号量创建xSemaphoreCreateBinaryLOS_SemCreate用法类似互斥锁xSemaphoreCreateMutexLOS_MuxCreate注意LiteOS有独立的Mux模块消息队列xQueueCreateLOS_QueueCreate队列ID类型不同软件定时器xTimerCreateLOS_SwtmrCreate定时器回调上下文有差异说两个容易踩坑的点LiteOS的LOS_TaskDelay参数单位是tick不是毫秒。1个tick等于多久取决于los_config.h里的LOSCFG_BASE_CORE_TICK_PER_SECOND配置。一般默认是1000即1ms一个tick。如果你把系统节拍改成了100Hz那LOS_TaskDelay(500)就是延时5秒不是0.5秒。FreeRTOS的pdMS_TO_TICKS宏挺好用LiteOS里也有类似定义但位置比较隐蔽在los_common.h里或者直接用公式转换。4.3 优先级分配LiteOS的数字越小越优先别搞反优先级配置是RTOS项目里最需要理性规划的一环。LiteOS的优先级规则是数字越小优先级越高和FreeRTOS一样LiteOS一般支持0~31级即最高优先级为0。实际项目里我一般这么分配优先级任务说明0-1中断相关处理任务如果有尽量少用会抢占所有其他任务2-3高实时性任务比如电机控制4-6通讯任务比如串口收发、网络7-9业务逻辑、用户交互10低优先级后台处理比如LOG输出关键是两个任务的优先级差距不要拉太大。比如一个任务优先级是2另一个是10那优先级10的任务很可能长时间得不到调度——只要优先级2的任务里有一个LOS_TaskDelay(1)在循环跑低优先级的任务就饿死了。虽然LiteOS的时间片调度同优先级任务轮流执行也能缓解但极端情况下问题依然存在。4.4 一个实际的例子传感器采集网关上报LED指示三个任务拿我之前做的一个小项目举例任务是做一个环境监测网关采集温湿度传感器通过UART上报数据给主机同时用LED指示运行状态。任务划分如下VOID Sensor_Task(VOID *param) { while(1) { read_temp_humi(temp, humi); /* 读取传感器 */ /* 把数据放进消息队列 */ LOS_QueueWrite(g_reportQueue, sensorData, sizeof(sensorData), 0); LOS_TaskDelay(2000); /* 每2秒采集一次 */ } } VOID Report_Task(VOID *param) { while(1) { /* 从队列取出数据此时会阻塞直到有数据 */ LOS_QueueRead(g_reportQueue, sensorData, sizeof(sensorData), LOS_WAIT_FOREVER); printf(temp%.2f humi%.2f\r\n, sensorData.temp, sensorData.humi); } } VOID Led_Task(VOID *param) { while(1) { /* 呼吸灯效果 */ led_toggle(); LOS_TaskDelay(500); } }三个任务里Sensor_Task用LOS_TaskDelay(2000)实现了定时采集Report_Task用LOS_QueueRead(..., LOS_WAIT_FOREVER)做到有数据就上报没数据就睡觉Led_Task是独立的状态指示。三个任务互不阻塞逻辑非常清晰。这在裸机里实现起来各种标志位、缓冲区、状态机代码量至少翻一倍。5. 移植过程中最容易踩的五个坑完整排查思路讲项目经验不聊坑等于白讲。下面这几个坑我每一个都亲自踩过而且都花了不少时间才定位到根因。我把完整的排查链路写出来不是让你避过所有的坑而是让你在踩进去后有能力自己爬出来。5.1 坑1编译报错却找不到文件头文件路径缺失现象打开官方Demo工程编译报错cannot open source file: los.h或者类似的找不到头文件。排查链路先别慌这种报错90%是头文件包含路径Include Paths不全导致的。Keil工程靠C/C选项里的Include Paths来指定去哪里搜索头文件官方Demo工程在发布时可能因为路径调整、绝对路径失效导致这个问题。打开工程选项 - C/C - Include Paths对照SDK目录检查这几类路径是否存在内核头文件目录kernel/include架构相关目录arch/arm/cortex-m4/keil/include以及arch/arm/common之类的目录芯片固件库目录比如targets/gd32f427i_start/gd32f4xx下的CMSIS、GD32F4xx_standard_peripheral/Include组件目录如果用到shell或cmsis需要components下的对应include路径根因路径写错或者文件夹被移动位置。解决方法是把路径改成相对路径如..\..\..\kernel\include或者直接把SDK放在固定位置。经验我新建项目时会把SDK放在一个固定深度的路径下比如D:\workspace\projects\...这样相对路径不会因为层级太深出问题。5.2 坑2任务没创建就启动了调度器或者初始化顺序颠倒现象程序编译烧录后LOS_Start()之后没有任何任务执行板子看起来是死的。或者卡在某个LOS_ASSERT上。排查链路LiteOS的启动流程是有严格顺序的乱了就会出这种问题。标准的初始化顺序是LOS_KernelInit(); // 1. 内核初始化 /* 2. 创建任务可以创建多个 */ LOS_TaskCreate(...); /* 3. 启动调度器 */ LOS_Start();很多人从FreeRTOS转过来会习惯性把创建任务的代码放在LOS_Start()之后FreeRTOS里vTaskStartScheduler之后就不能再创建任务了但LiteOS也可以在启动前创建或者在LOS_KernelInit()之前就创建任务。LiteOS的内核数据结构在LOS_KernelInit之后才初始化完成提前创建任务会访问未初始化的内存行为不可预知。验证方法在LOS_KernelInit()之后加一行printf(kernel init ok\r\n)在创建任务后加printf(task create ok\r\n)在LOS_Start()前加printf(start scheduler\r\n)。看日志停在哪一步就知道问题在哪。5.3 坑3SysTick被占用任务延时完全失效现象任务里写了LOS_TaskDelay(1000)结果任务像死循环一样疯狂执行串口打印刷屏根本停不下来。排查链路这个问题把我折磨了整整两天。现象非常诡异单个任务跑得好好的一加多个任务就全乱了。后来一步步排查才发现问题不在LiteOS而是GD32固件库的某个外设初始化函数里重开了SysTick。GD32固件库的SystemInit或者某些标准外设库函数可能会重新配置SysTick作为延时用比如官方例程用的delay_init和delay_1ms函数而LiteOS的系统节拍时钟也用的是SysTick两边一冲突tick计数就全乱了。排查步骤全局搜索SysTick关键字看有没有其他地方在使用SysTick。搜索delay_init、delay_1ms这类函数看板级初始化里是否调用了。如果有要么把硬件延时函数改用一个普通定时器如TIM3实现要么永远不要在LiteOS跑起来后调用这些函数。验证方法把板级初始化里所有可疑的SysTick相关配置注释掉重新编译烧录看任务延时是否恢复正常。这基本就能确认根因。5.4 坑4printf重定向没做好串口输出的都是乱码或者卡死现象程序能跑任务也在切换但串口助手显示的是乱七八糟的乱码或者输出几个字符后程序挂死。排查链路两个原因按优先级排查波特率不匹配最常见。如果你在board_uart_init里配置的波特率和串口助手选的不一样必然乱码。查一下你的配置是不是115200串口助手是不是也选的115200。printf重定向的问题如果你用的是官方Demo的代码但编译时忘了勾选MicroLIB或者你的编译器优化等级偏高导致fputc没有被正确调用printf就可能是空的。验证方法不用printf直接用usart_data_transmit发送一个固定字符串例如H看串口是否正常。如果正常说明串口配置没问题问题在printf重定向如果不正常先查波特率和串口配置。5.5 坑5hardfault_handler——中断里调用阻塞API导致的崩溃现象程序运行一段时间后突然进入HardFault_Handler死循环或者每次触发某个外部中断后立刻崩溃。在Keil里debug时可以看到PC指针停在HardFault_Handler。排查链路这类问题90%的原因是在中断上下文里调用了会阻塞的API比如在UART的接收中断回调函数里调用LOS_TaskDelay或者LOS_QueueWrite。LiteOS的很多API都做了中断上下文检查但有些没那么严格或者某些API虽然在文档里写可在中断中使用使用方式不对照样崩。排查步骤先在HardFault_Handler里打断点看PC指针和LR寄存器LR的值能告诉你是从哪段代码跳到HardFault的。查看调用栈Call Stack窗口找出崩之前最后执行的用户代码。重点检查所有中断处理函数UART中断、定时器中断、外部中断里有没有调用LOS_TaskDelay、LOS_QueueWrite带超时时间、LOS_SemPend这类阻塞操作。正确的做法中断里只做最少的处理——清标志位、把数据抄进缓冲区然后通过LOS_QueueWrite注意用0超时或信号量去通知任务。真正的数据处理放在任务里做。例如UART接收中断的标准处理方式void USART0_IRQHandler(void) { uint8_t data; if(RESET ! usart_flag_get(USART0, USART_FLAG_RBNE)) { data usart_data_receive(USART0); /* 直接把数据发到队列不在中断里做业务处理 */ LOS_QueueWrite(g_uartQueue, data, 1, 0); // 0超时不阻塞中断 } }经验如果你发现LOS_QueueWrite在中断里偶尔返回错误不要慌。检查队列长度是否够大以及是不是用0超时非阻塞模式。中断里的API必须是非阻塞的这条铁律适用任何RTOS。6. 从能跑到好用项目化改造的几个进阶思考Demo能跑、任务能建、串口能打印这时候很多人觉得大功告成了。但以我的经验这最多算玩具能跑距离产品能交付还有一大截。这个阶段的核心工作不是继续堆功能而是做减法、做规划、做健壮性设计。6.1 先做任务规划再写代码我见过太多失败的移植项目失败原因不是RTOS没移植好而是任务划分太随意。有人把整个业务塞进一个超级任务说是用了RTOS结果里面还是一个大while(1)一堆switch。有人又走另一个极端把每个小动作都拆成一个任务光优先级调度表就写了二十多行最后系统在调度上花费的资源比业务还多。分享一个我总结的任务划分判断标准一个任务里如果有一个阻塞等待队列读取、信号量等待、延时并且这个阻塞对整个系统来说是必须的、合理的那这个任务就是合格的。反例是一个任务里全是轮询查询没有阻塞点那这个任务大概率应该拆成几个由事件驱动的子任务或者合并到其他任务里去。以一个网关设备为例合理的任务规划大概是协议解析任务阻塞等待串口/网络数据收到一帧解析一帧解析结果通过队列发给上报任务。上报任务阻塞等待数据队列拿到数据后打包上报。外设管理任务周期性通过延时读取传感器把变化量发到数据队列。异常处理任务阻塞等待错误事件看门狗复位、电源异常做统一处理。6.2 用好LiteOS的IPC机制任务之间解耦二次开发很关键的一步是用消息队列/信号量/事件标志组来解耦任务之间的依赖。直接共享全局变量虽然简单但会产生各种竞态问题。举个实际例子。我有段时间在传感器数据采集任务里直接修改了一个全局变量g_sensor_data上报任务直接读这个变量。运行起来偶尔会读到半新半旧的数据——采集任务写到一半上报任务来读了。后来改成消息队列彻底解决采集任务把完整的数据结构放进队列上报任务读取时永远拿到的是一个完整的数据快照。LiteOS的队列读写API很简单/* 定义队列句柄 */ UINT32 g_reportQueue; /* 创建队列一次传一份SENSOR_DATA_S */ LOS_QueueCreate(reportQueue, g_reportQueue, 8, sizeof(SENSOR_DATA_S), 0); /* 写队列注意最后一个参数0不阻塞可用LOS_WAIT_FOREVER阻塞 */ LOS_QueueWrite(g_reportQueue, data, sizeof(SENSOR_DATA_S), 0); /* 读队列第二个参数是接收缓冲第三个参数要写成sizeof(SENSOR_DATA_S)不是单个字节 */ LOS_QueueRead(g_reportQueue, recvData, sizeof(SENSOR_DATA_S), LOS_WAIT_FOREVER);用队列/信号量替代全局变量之后任务之间的耦合度显著下降排查问题也容易了——数据流变成了清晰的一条线而不是剪不清的一张网。6.3 功能验证别只看着像要用数据说话移植完成后要做系统性的验证别只看了LED在闪就说搞定。我一般会做一个长时间稳定性测试跑72小时以上监控任务执行次数、队列占用率、内存余量。如果队列总是满的说明数据处理速度跟不上采集速度如果任务执行周期抖动大说明优先级分配不合理。LiteOS提供了一些调试接口比如LOS_TaskInfoGet可以获取任务信息LOS_MemIntegrityCheck可以检查内存完整性。写一个小工具任务定期把这些信息打印出来长期跑着看曲线对发现潜在问题非常有效。6.4 和LVGL、网络协议栈的联动下一条进阶路线很多用GD32F427的兄弟项目会涉及屏幕显示或网络通信。如果后面要把LVGL跑起来或者接一套MQTT协议我的建议是先保持LiteOS的内核配置最小化不要急着把官方Demo里所有组件都开起来。组件越多配置项越多出问题的概率越大。实测下来把LVGL跑在LiteOS上内核的tick配置建议保持1000Hz1ms否则动画帧率会有明显波动。而跑MQTT的时候注意网络任务和业务任务的优先级区分网络收发的任务优先级要比耗时的UI刷新任务高——不然你按下屏幕按钮时MQTT消息可能延迟很久才被处理。最后聊两句软件这行RTOS移植这个事情会者不难难者不会。第一次移植LiteOS-M确实容易一头雾水但只要你跑通一次把官方Demo的结构吃透了之后换任何芯片、换任何RTOS都只是换个目录、改几行配置的事。我的个人经验是别嫌官方Demo代码啰嗦里面每一行背后都有原因。你有空的时候把Demo里的启动流程用自己的话写一遍注释比刷十个教程都管用。真正到项目紧张的时候你会感激自己当初花的那一个小时。 GD32F427移植LiteOS-M实战：从官方Demo到项目落地
1. 移植LiteOS-M之前先想清楚这三件事上周同事拿了一块GD32F427的板子找我说想把LiteOS-M跑起来做一个小型网关项目。结果折腾了两天卡在官方Demo到底怎么用这一步——工程拷下来编译报错一大堆改了半天连LED都没闪起来。这个场景太常见了资料不是没有但一上来就闷头改代码方向不对越改越乱。先说清楚这篇东西解决什么问题。GD32F427这颗MCU我之前用了很久最早是跑裸机后来上了FreeRTOS再后来因为项目用了华为云的IoT方案才被迫认真研究LiteOS-M。折腾一圈下来最大的体会是LiteOS-M的官方Demo其实已经把99%的脏活累活干完了你要做的不是重复移植而是学会站在Demo的肩膀上改。这篇我打算从Demo仓库结构讲起把移植步骤、任务模型、常见的坑和排查思路都过一遍。适合三类人看第一类是从STM32转过来想快速上手GD32的第二类是裸机开发想第一次上RTOS的第三类是已经会FreeRTOS但被LiteOS-M的工程结构绕晕的。1.1 为什么选GD32F427这颗料配LiteOS-M先聊硬件。GD32F427是兆易创新基于ARM Cortex-M4内核的国产MCU主频最高可以跑到200MHzFlash最大能做到3MBRAM也有256KB级别。这个资源放在几年前就是中高端水准现在价格已经打到和普通M4一个水平性价比确实高。你要跑一个带网络协议栈、传感器采集、屏幕显示的小型物联网设备这个配置很舒服。我实际用下来F427这个系列在同等主频下性能比GD32F3系列强不少带了FPU和DSP指令跑浮点运算、FFT这类活不用CPU干等着。而且它和STM32F4系列引脚兼容性做得不错很多老项目可以直接平移这在国内项目里是个巨大的优势——老板让国产化替代的时候你几乎不需要重新画板子。至于LiteOS-M它是华为开源的轻量级物联网操作系统主打一个小而全。内核只有几万行代码RAM占用可以压到KB级别在Cortex-M0/M3/M4/M7这些核上都能跑而且支持CMSIS-RTOS2接口。对做物联网设备的人来说最实际的三个好处组件丰富华为专门适配了物联网场景常用的组件AT指令框架、MQTT、CoAP这些拿来就能用不用自己拼。有生态背书虽然网上讨论热度不如FreeRTOS但华为系的模组方案里大量在用LiteOS踩坑的人多沉淀下来的解决方案也多。支持标准接口你在FreeRTOS里写的应用程序逻辑只要用CMSIS-RTOS2 API封装过搬到LiteOS-M上几乎不需要改应用层代码。当然LiteOS-M在国内资料方向性比较散官方Demo版本之间差异也大这也是很多人卡住的原因。1.2 所谓移植真正要动的是哪些代码很多新手听到移植操作系统就慌以为要从零写调度器、写内存管理。实际上操作系统内核本身就是通用的谁都能跑。移植要做的全部事情就是让内核知道怎么在这颗芯片上完成三件事开关中断、触发调度、切换上下文。具体到GD32F427上需要关注的就这几块功能涉及文件说明启动与向量表startup_gd32f4xx.s、system_gd32f4xx.c芯片上电初始化中断向量表时钟节拍SysTick或其他硬件定时器给内核提供时间基准中断底层los_dispatch、port相关汇编上下文切换、PendSV/SVC处理内存布局链接脚本.sct/.ld定义栈顶地址、堆区、RO/RW段好消息是官方Demo里这些全部已经给你配好了。你要做的不是重新写一遍而是确认这些文件和你自己板子的硬件参数是否匹配然后改掉对应配置。1.3 为什么快速复用官方Demo是最高效的路线有人喜欢从零构建工程把内核源码一股脑加进keil然后自己写startup、自己配时钟、自己接SysTick、自己调上下文切换。说实话如果目标是学习这条路非常有价值能让你对操作系统原理有一个质的理解。但如果目标是项目尽快跑起来从零移植纯属浪费时间——官方已经给你探好路了你只需要裁裁剪剪。我自己实际经验是**从零移植一个RTOS顺利的话要一到两周从官方Demo改到自己项目跑起来一个下午就能搞定。**差距就在芯片相关代码和应用代码之间的那一层官方已经处理好了。所以这篇文章的核心思路就是教你读懂官方Demo的结构知道哪些能直接搬、哪些必须改、哪些值得借鉴然后带着这个理解去改自己的硬件项目。2. 官方Demo仓库的底层结构哪些能直接搬哪些必须改拿到LiteOS-M的SDK包时不要急着双击Keil工程去编译。我现在养成了一个习惯先花半小时把目录结构看一遍搞清楚谁是谁再动手。因为LiteOS的目录组织方式和FreeRTOS差别还挺大的你拿FreeRTOS的思路去找文件夹大概率会糊涂。2.1 LiteOS-M内核的目录划分逻辑一个典型的LiteOS-M工程基于GD32F427的target包目录如下LiteOS-M ├── arch # 架构相关代码移植重点 │ ├── arm │ │ ├── cortex-m4 │ │ │ ├── gcc # GCC编译链下的启动和上下文切换 │ │ │ └── iar # IAR下的实现 │ │ │ └── keil # MDK下的实现 │ │ └── include ├── components # 组件层 │ ├── cmsis # CMSIS-RTOS2适配 │ ├── llib # 轻量libc实现 │ ├── net # lwIP等网络组件 │ └── shell # 调试shell ├── kernel │ ├── include # 内核头文件 │ ├── src # 内核源码任务、队列、信号量、事件等 └── targets └── gd32f427i_start # 具体开发板适配层 ├── GCC ├── IAR ├── Keil ├── Src │ ├── main.c │ └── los_init.c ├── Inc └── gd32f4xx # GD32官方固件库注意arch目录里cortex-m4下面还有gcc/iar/keil三个子目录。这三个子目录里的文件看起来很像但汇编语法不一样千万别混用。你用什么编译器就只保留对应目录的文件其他的哪怕编译能过也尽量删掉不然工程文件混乱后面排查问题会疯掉。2.2 GD32F427的Demo里哪几个文件是最要紧的我把整个targets目录下的关键文件整理了一下优先级从高到低排文件作用移植时要做什么los_startup_gcc.s或对应keil版本内核启动入口第一个执行的汇编代码基本不用动target_config.h配置系统主频、内存起始地址、中断数量等硬件参数必须核对los_config.h内核裁剪配置比如任务栈大小、系统时钟节拍、内存池大小必须按需修改los_init.c内核初始化入口调用LOS_KernelInit等不用大改main.cDemo应用代码创建测试任务替换成你自己的逻辑.sct链接脚本定义Flash/RAM布局必须核对最有意思的是target_config.h这个文件就是芯片与内核之间的翻译官。里面会定义类似这样的宏#define OS_SYS_CLOCK 200000000 // 主频200MHz #define OS_SYS_TIMER_FREQ 1000 // 系统节拍1ms #define RAM_START_ADDRESS 0x20000000 // RAM起始地址 #define RAM_SIZE 0x30000 // 192KB RAM #define LOSCFG_BASE_CORE_TIMER 0 // 使用哪个定时器做系统节拍你改了主频但没改这里的OS_SYS_CLOCK系统节拍计算全乱任务延时和超时全都对不上——这是新手最容易踩的隐形坑之一。2.3 构建方式怎么选Keil老三样反而最省心官方Demo支持GCC、IAR、Keil三套构建方式。我个人的实践建议是跟着你最熟悉的工具链走但环境配置必须统一。我自己在Windows下开发用Keil MDK5最顺手就用keil目录下的工程文件。很多人一上来就想换成VSCodeGCC倒不是不行但LiteOS的GCC编译链要自己处理头文件路径、链接脚本、宏定义配置成本高而且出错后网上查到的资料大多是Keil工程下的经验你会在这行代码在我这边编译不过这种问题上卡很久。我的建议是先把官方Demo在Keil里跑通跑通了再考虑换工具链也不迟。提示不同版本的LiteOS-M源码arch目录下的文件路径可能略有差异。以你下载的SDK包里实际路径为准不要照抄网上的旧教程路径。3. 让官方Demo在你自己的板子上跑起来完整移植步骤搞清楚结构之后真正的移植其实就是一个改配置的过程。我把自己总结的步骤整理成了清单照着做大概率一个下午能跑通。3.1 环境准备软件、SDK、驱动一个都不能少基础环境三步走Keil MDK5建议5.30以上版本装好对应的芯片支持包GD32F4xx系列。去Keil官网或者兆易创新官方社区下载都可以注意芯片包版本要和你芯片料号对上。LiteOS-M的GD32F427 Demo包从Gitee的LiteOS-M仓库或者兆易创新官方的SDK页面下载。注意下载带targets/gd32f427i_start的版本不同芯片的Demo结构不一样。调试器驱动如果你的板载调试器是DAP-Link那插上USB就能用如果是J-Link需要装好J-Link驱动。硬件方面我建议准备一块带板载调试器的开发板别用那种只有最小系统、需要外接仿真器的核心板调试效率低很多。3.2 在Demo基础上复制工程改名字当自己项目进入targets/gd32f427i_start/Keil目录你会看到一个.uvprojx工程文件。我的习惯是不要在这个目录里直接改而是把整个gd32f427i_start文件夹复制一份重命名成你自己项目的名字比如my_gateway_board。原因很简单LiteOS-M的SDK会持续迭代更新你要是在原版目录里改了一堆东西后面官方发布新版本你想diff一下改动点都无从下手。复制一份出来保留了原始Demo作为参照改坏了随时可以对比恢复。复制完成后用Keil打开工程文件第一步就是看Target选项里的Device是否选到了你的芯片型号比如GD32F427VGT6。如果芯片型号不对编译器的宏定义如GD32F427和启动文件都匹配不上编译会报各种莫名其妙的问题。3.3 核对时钟、Flash和RAM这是移植的第一个分水岭不同的GD32F427型号Flash和RAM大小差异很大。比如GD32F427IG是1MB Flash而GD32F427VI是3MB Flash你用错链接脚本程序烧进去要么跑不起来要么直接烧录失败。打开工程里的链接脚本Keil下是.sct文件在工程的Target选项的Linker页面可以看到路径检查类似这样的内容LR_IROM1 0x08000000 0x00100000 { ; 1MB Flash ER_IROM1 0x08000000 0x00100000 { *.o (RESET, First) *(InRoot$$Sections) .ANY (RO) } RW_IRAM1 0x20000000 0x00040000 { ; 256KB RAM .ANY (RW ZI) } }这里0x00100000是FLASH容量1MB0x00040000是RAM容量256KB。如果你的芯片是512KB Flash就改成0x00080000。这个数字一定要和你的具体芯片型号对应宁小勿大改大了烧录时校验不通过。然后检查target_config.h和system_gd32f4xx.c里的系统时钟配置。GD32F427外部晶振常见的有8MHz和25MHz两种你板子上用的是哪种要查对应开发板的原理图确认。进入SystemInit函数可以看到PLL倍频相关的设置比如外部8MHz晶振倍频到200MHz代码里会有一个宏定义#define __SYSTEM_CLOCK_200M_PLL_8M_HXTAL (uint32_t)(200000000)如果你的板子用的是25MHz外部晶振这个宏就得换成__SYSTEM_CLOCK_200M_PLL_25M_HXTAL。晶振配置错了表现往往是串口输出的波特率不对或者干脆系统跑飞。3.4 改串口和LED初始化把调试通道打通我一直认为移植RTOS之后第一件事不是跑任务而是把printf调通。没有printf你后面排查任何问题都像盲人摸象。官方Demo里通常会有一段串口初始化代码位置在板级初始化文件里或者是main.c里直接调用。GD32F427的串口例程写法大致如下使用官方固件库void board_uart_init(void) { /* 使能时钟 */ rcu_periph_clock_enable(RCU_GPIOA); rcu_periph_clock_enable(RCU_USART0); /* 配置PA9为USART0_TXPA10为USART0_RX */ gpio_af_set(GPIOA, GPIO_AF_7, GPIO_PIN_9 | GPIO_PIN_10); gpio_mode_set(GPIOA, GPIO_MODE_AF, GPIO_PUPD_PULLUP, GPIO_PIN_9 | GPIO_PIN_10); gpio_output_options_set(GPIOA, GPIO_OTYPE_PP, GPIO_OSPEED_50MHZ, GPIO_PIN_9); /* 配置USART0参数115200-8-N-1 */ usart_deinit(USART0); usart_baudrate_set(USART0, 115200U); usart_word_length_set(USART0, USART_WL_8BIT); usart_stop_bit_set(USART0, USART_STB_1BIT); usart_parity_config(USART0, USART_PM_NONE); usart_hardware_flow_rts_config(USART0, USART_RTS_DISABLE); usart_hardware_flow_cts_config(USART0, USART_CTS_DISABLE); usart_receive_config(USART0, USART_RECEIVE_ENABLE); usart_transmit_config(USART0, USART_TRANSMIT_ENABLE); usart_enable(USART0); }这里的引脚号和复用功能编号要看你板子的实际连接不同开发板可能走不同的串口引脚。比如GD官方开发板用的是USART0PA9/PA10有些第三方核心板默认把调试串口接到了USART1PA2/PA3这个必须自己确认。然后是printf重定向int fputc(int ch, FILE *f) { usart_data_transmit(USART0, (uint8_t)ch); while(RESET usart_flag_get(USART0, USART_FLAG_TBE)); return ch; }注意Keil里要在Target选项的MicroLIB前面打勾用微库才能让printf走fputc重定向。忘记勾选MicroLIBprintf会进hardfault这也是一个经典坑。3.5 创建第一个任务并验证串口和时钟都通了之后下一步就是替换掉Demo的main.c写一个简单的闪灯任务验证系统跑起来了。一个最小可用的main陷入大致长这样#include los_task.h #include los_printf.h UINT32 g_ledTaskID; UINT32 g_ledTaskStack[512]; static VOID Led_Task(VOID *param) { while(1) { gpio_bit_toggle(GPIOF, GPIO_PIN_6); /* 翻转LED */ LOS_TaskDelay(500); /* 延时500ms */ } } int main(void) { /* 板级初始化时钟、LED、串口 */ board_init(); /* LiteOS内核初始化注意返回值判断 */ UINT32 ret LOS_KernelInit(); if (ret ! LOS_OK) { return -1; } /* 创建任务 */ TSK_INIT_PARAM_S taskParam {0}; taskParam.pfnTaskEntry (TSK_ENTRY_FUNC)Led_Task; taskParam.uwStackSize 512; /* 单位是字即512*42KB */ taskParam.pcName LedTask; taskParam.usTaskPrio 5; taskParam.uwResved LOS_TASK_STATUS_DETACHED; ret LOS_TaskCreate(g_ledTaskID, taskParam); if (ret ! LOS_OK) { return -1; } /* 启动调度从此进入多任务世界不会返回 */ LOS_Start(); return 0; }编译烧录后如果LED以1秒周期闪烁亮500ms灭500ms说明LiteOS-M已经在这颗GD32F427上跑起来了。提示LiteOS的任务栈大小uwStackSize单位是字Word不是字节。你写512实际分配的内存是512×42048字节。这个和FreeRTOS的堆栈大小单位一样但很多人习惯性以为是字节然后发现栈总是不够用。3.6 验证调度两个任务交替跑确认系统真的活了LED闪烁只能说明任务在跑但还看不出调度器的真实状态。为了确认多任务调度正常我习惯加一个调试打印任务VOID Print_Task(VOID *param) { UINT32 count 0; while(1) { printf([PrintTask] count%u, uptime%u ms\r\n, count, LOS_TickCountGet()); LOS_TaskDelay(1000); } }如果串口工具里能看到这个打印每秒出现一次而且LED也按预期闪烁那说明两个独立任务在各自的时间片里正常切换调度器工作正常。此时我们才真正完成了让LiteOS-M在GD32F427上跑起来这个目标接下来才是二次开发的真正战场。4. 任务编程模型切换从裸机思维到LiteOS-M跑通Demo只是起点真正的二次开发是把你的业务逻辑用多任务的方式重新组织起来。这一步对于习惯裸机编程的工程师来说是最容易走弯路的地方。4.1 裸机while(1)与RTOS多任务的核心区别裸机开发里最常见的结构是这样的while(1) { /* 处理按键 */ scan_key(); /* 处理传感器 */ read_sensor(); /* 刷新屏幕 */ update_display(); /* 处理网络 */ poll_network(); }结构简单但有个致命问题所有功能的实时性互相拖累。如果网络驱动调用的阻塞时间很长按键扫描就会被卡住屏幕刷新也会变慢。你只能用中断标志位状态机去拆解整个流程代码越写越绕。RTOS的思路完全不同。你把每个功能拆成独立任务调度器负责哪个时刻轮到谁跑。按键任务可以在自己被唤醒时立刻执行传感器任务用阻塞延时等待数据网络任务长时间阻塞等收包也完全不影响其他任务。互不干扰实时性可预期。程序员从管理所有事情的上帝模式变成了只关心自己这个任务逻辑的模块化模式。4.2 LiteOS-M常用API以及和FreeRTOS的对比我用一张表列下最常用到的API给从FreeRTOS转过来的读者快速对照功能FreeRTOSLiteOS-M备注创建任务xTaskCreateLOS_TaskCreateLiteOS的参数结构体类型为TSK_INIT_PARAM_S删除任务vTaskDeleteLOS_TaskDelete延时vTaskDelayLOS_TaskDelay单位都是tick不传入ticks毫秒需换算下同获取tickxTaskGetTickCountLOS_TickCountGet信号量创建xSemaphoreCreateBinaryLOS_SemCreate用法类似互斥锁xSemaphoreCreateMutexLOS_MuxCreate注意LiteOS有独立的Mux模块消息队列xQueueCreateLOS_QueueCreate队列ID类型不同软件定时器xTimerCreateLOS_SwtmrCreate定时器回调上下文有差异说两个容易踩坑的点LiteOS的LOS_TaskDelay参数单位是tick不是毫秒。1个tick等于多久取决于los_config.h里的LOSCFG_BASE_CORE_TICK_PER_SECOND配置。一般默认是1000即1ms一个tick。如果你把系统节拍改成了100Hz那LOS_TaskDelay(500)就是延时5秒不是0.5秒。FreeRTOS的pdMS_TO_TICKS宏挺好用LiteOS里也有类似定义但位置比较隐蔽在los_common.h里或者直接用公式转换。4.3 优先级分配LiteOS的数字越小越优先别搞反优先级配置是RTOS项目里最需要理性规划的一环。LiteOS的优先级规则是数字越小优先级越高和FreeRTOS一样LiteOS一般支持0~31级即最高优先级为0。实际项目里我一般这么分配优先级任务说明0-1中断相关处理任务如果有尽量少用会抢占所有其他任务2-3高实时性任务比如电机控制4-6通讯任务比如串口收发、网络7-9业务逻辑、用户交互10低优先级后台处理比如LOG输出关键是两个任务的优先级差距不要拉太大。比如一个任务优先级是2另一个是10那优先级10的任务很可能长时间得不到调度——只要优先级2的任务里有一个LOS_TaskDelay(1)在循环跑低优先级的任务就饿死了。虽然LiteOS的时间片调度同优先级任务轮流执行也能缓解但极端情况下问题依然存在。4.4 一个实际的例子传感器采集网关上报LED指示三个任务拿我之前做的一个小项目举例任务是做一个环境监测网关采集温湿度传感器通过UART上报数据给主机同时用LED指示运行状态。任务划分如下VOID Sensor_Task(VOID *param) { while(1) { read_temp_humi(temp, humi); /* 读取传感器 */ /* 把数据放进消息队列 */ LOS_QueueWrite(g_reportQueue, sensorData, sizeof(sensorData), 0); LOS_TaskDelay(2000); /* 每2秒采集一次 */ } } VOID Report_Task(VOID *param) { while(1) { /* 从队列取出数据此时会阻塞直到有数据 */ LOS_QueueRead(g_reportQueue, sensorData, sizeof(sensorData), LOS_WAIT_FOREVER); printf(temp%.2f humi%.2f\r\n, sensorData.temp, sensorData.humi); } } VOID Led_Task(VOID *param) { while(1) { /* 呼吸灯效果 */ led_toggle(); LOS_TaskDelay(500); } }三个任务里Sensor_Task用LOS_TaskDelay(2000)实现了定时采集Report_Task用LOS_QueueRead(..., LOS_WAIT_FOREVER)做到有数据就上报没数据就睡觉Led_Task是独立的状态指示。三个任务互不阻塞逻辑非常清晰。这在裸机里实现起来各种标志位、缓冲区、状态机代码量至少翻一倍。5. 移植过程中最容易踩的五个坑完整排查思路讲项目经验不聊坑等于白讲。下面这几个坑我每一个都亲自踩过而且都花了不少时间才定位到根因。我把完整的排查链路写出来不是让你避过所有的坑而是让你在踩进去后有能力自己爬出来。5.1 坑1编译报错却找不到文件头文件路径缺失现象打开官方Demo工程编译报错cannot open source file: los.h或者类似的找不到头文件。排查链路先别慌这种报错90%是头文件包含路径Include Paths不全导致的。Keil工程靠C/C选项里的Include Paths来指定去哪里搜索头文件官方Demo工程在发布时可能因为路径调整、绝对路径失效导致这个问题。打开工程选项 - C/C - Include Paths对照SDK目录检查这几类路径是否存在内核头文件目录kernel/include架构相关目录arch/arm/cortex-m4/keil/include以及arch/arm/common之类的目录芯片固件库目录比如targets/gd32f427i_start/gd32f4xx下的CMSIS、GD32F4xx_standard_peripheral/Include组件目录如果用到shell或cmsis需要components下的对应include路径根因路径写错或者文件夹被移动位置。解决方法是把路径改成相对路径如..\..\..\kernel\include或者直接把SDK放在固定位置。经验我新建项目时会把SDK放在一个固定深度的路径下比如D:\workspace\projects\...这样相对路径不会因为层级太深出问题。5.2 坑2任务没创建就启动了调度器或者初始化顺序颠倒现象程序编译烧录后LOS_Start()之后没有任何任务执行板子看起来是死的。或者卡在某个LOS_ASSERT上。排查链路LiteOS的启动流程是有严格顺序的乱了就会出这种问题。标准的初始化顺序是LOS_KernelInit(); // 1. 内核初始化 /* 2. 创建任务可以创建多个 */ LOS_TaskCreate(...); /* 3. 启动调度器 */ LOS_Start();很多人从FreeRTOS转过来会习惯性把创建任务的代码放在LOS_Start()之后FreeRTOS里vTaskStartScheduler之后就不能再创建任务了但LiteOS也可以在启动前创建或者在LOS_KernelInit()之前就创建任务。LiteOS的内核数据结构在LOS_KernelInit之后才初始化完成提前创建任务会访问未初始化的内存行为不可预知。验证方法在LOS_KernelInit()之后加一行printf(kernel init ok\r\n)在创建任务后加printf(task create ok\r\n)在LOS_Start()前加printf(start scheduler\r\n)。看日志停在哪一步就知道问题在哪。5.3 坑3SysTick被占用任务延时完全失效现象任务里写了LOS_TaskDelay(1000)结果任务像死循环一样疯狂执行串口打印刷屏根本停不下来。排查链路这个问题把我折磨了整整两天。现象非常诡异单个任务跑得好好的一加多个任务就全乱了。后来一步步排查才发现问题不在LiteOS而是GD32固件库的某个外设初始化函数里重开了SysTick。GD32固件库的SystemInit或者某些标准外设库函数可能会重新配置SysTick作为延时用比如官方例程用的delay_init和delay_1ms函数而LiteOS的系统节拍时钟也用的是SysTick两边一冲突tick计数就全乱了。排查步骤全局搜索SysTick关键字看有没有其他地方在使用SysTick。搜索delay_init、delay_1ms这类函数看板级初始化里是否调用了。如果有要么把硬件延时函数改用一个普通定时器如TIM3实现要么永远不要在LiteOS跑起来后调用这些函数。验证方法把板级初始化里所有可疑的SysTick相关配置注释掉重新编译烧录看任务延时是否恢复正常。这基本就能确认根因。5.4 坑4printf重定向没做好串口输出的都是乱码或者卡死现象程序能跑任务也在切换但串口助手显示的是乱七八糟的乱码或者输出几个字符后程序挂死。排查链路两个原因按优先级排查波特率不匹配最常见。如果你在board_uart_init里配置的波特率和串口助手选的不一样必然乱码。查一下你的配置是不是115200串口助手是不是也选的115200。printf重定向的问题如果你用的是官方Demo的代码但编译时忘了勾选MicroLIB或者你的编译器优化等级偏高导致fputc没有被正确调用printf就可能是空的。验证方法不用printf直接用usart_data_transmit发送一个固定字符串例如H看串口是否正常。如果正常说明串口配置没问题问题在printf重定向如果不正常先查波特率和串口配置。5.5 坑5hardfault_handler——中断里调用阻塞API导致的崩溃现象程序运行一段时间后突然进入HardFault_Handler死循环或者每次触发某个外部中断后立刻崩溃。在Keil里debug时可以看到PC指针停在HardFault_Handler。排查链路这类问题90%的原因是在中断上下文里调用了会阻塞的API比如在UART的接收中断回调函数里调用LOS_TaskDelay或者LOS_QueueWrite。LiteOS的很多API都做了中断上下文检查但有些没那么严格或者某些API虽然在文档里写可在中断中使用使用方式不对照样崩。排查步骤先在HardFault_Handler里打断点看PC指针和LR寄存器LR的值能告诉你是从哪段代码跳到HardFault的。查看调用栈Call Stack窗口找出崩之前最后执行的用户代码。重点检查所有中断处理函数UART中断、定时器中断、外部中断里有没有调用LOS_TaskDelay、LOS_QueueWrite带超时时间、LOS_SemPend这类阻塞操作。正确的做法中断里只做最少的处理——清标志位、把数据抄进缓冲区然后通过LOS_QueueWrite注意用0超时或信号量去通知任务。真正的数据处理放在任务里做。例如UART接收中断的标准处理方式void USART0_IRQHandler(void) { uint8_t data; if(RESET ! usart_flag_get(USART0, USART_FLAG_RBNE)) { data usart_data_receive(USART0); /* 直接把数据发到队列不在中断里做业务处理 */ LOS_QueueWrite(g_uartQueue, data, 1, 0); // 0超时不阻塞中断 } }经验如果你发现LOS_QueueWrite在中断里偶尔返回错误不要慌。检查队列长度是否够大以及是不是用0超时非阻塞模式。中断里的API必须是非阻塞的这条铁律适用任何RTOS。6. 从能跑到好用项目化改造的几个进阶思考Demo能跑、任务能建、串口能打印这时候很多人觉得大功告成了。但以我的经验这最多算玩具能跑距离产品能交付还有一大截。这个阶段的核心工作不是继续堆功能而是做减法、做规划、做健壮性设计。6.1 先做任务规划再写代码我见过太多失败的移植项目失败原因不是RTOS没移植好而是任务划分太随意。有人把整个业务塞进一个超级任务说是用了RTOS结果里面还是一个大while(1)一堆switch。有人又走另一个极端把每个小动作都拆成一个任务光优先级调度表就写了二十多行最后系统在调度上花费的资源比业务还多。分享一个我总结的任务划分判断标准一个任务里如果有一个阻塞等待队列读取、信号量等待、延时并且这个阻塞对整个系统来说是必须的、合理的那这个任务就是合格的。反例是一个任务里全是轮询查询没有阻塞点那这个任务大概率应该拆成几个由事件驱动的子任务或者合并到其他任务里去。以一个网关设备为例合理的任务规划大概是协议解析任务阻塞等待串口/网络数据收到一帧解析一帧解析结果通过队列发给上报任务。上报任务阻塞等待数据队列拿到数据后打包上报。外设管理任务周期性通过延时读取传感器把变化量发到数据队列。异常处理任务阻塞等待错误事件看门狗复位、电源异常做统一处理。6.2 用好LiteOS的IPC机制任务之间解耦二次开发很关键的一步是用消息队列/信号量/事件标志组来解耦任务之间的依赖。直接共享全局变量虽然简单但会产生各种竞态问题。举个实际例子。我有段时间在传感器数据采集任务里直接修改了一个全局变量g_sensor_data上报任务直接读这个变量。运行起来偶尔会读到半新半旧的数据——采集任务写到一半上报任务来读了。后来改成消息队列彻底解决采集任务把完整的数据结构放进队列上报任务读取时永远拿到的是一个完整的数据快照。LiteOS的队列读写API很简单/* 定义队列句柄 */ UINT32 g_reportQueue; /* 创建队列一次传一份SENSOR_DATA_S */ LOS_QueueCreate(reportQueue, g_reportQueue, 8, sizeof(SENSOR_DATA_S), 0); /* 写队列注意最后一个参数0不阻塞可用LOS_WAIT_FOREVER阻塞 */ LOS_QueueWrite(g_reportQueue, data, sizeof(SENSOR_DATA_S), 0); /* 读队列第二个参数是接收缓冲第三个参数要写成sizeof(SENSOR_DATA_S)不是单个字节 */ LOS_QueueRead(g_reportQueue, recvData, sizeof(SENSOR_DATA_S), LOS_WAIT_FOREVER);用队列/信号量替代全局变量之后任务之间的耦合度显著下降排查问题也容易了——数据流变成了清晰的一条线而不是剪不清的一张网。6.3 功能验证别只看着像要用数据说话移植完成后要做系统性的验证别只看了LED在闪就说搞定。我一般会做一个长时间稳定性测试跑72小时以上监控任务执行次数、队列占用率、内存余量。如果队列总是满的说明数据处理速度跟不上采集速度如果任务执行周期抖动大说明优先级分配不合理。LiteOS提供了一些调试接口比如LOS_TaskInfoGet可以获取任务信息LOS_MemIntegrityCheck可以检查内存完整性。写一个小工具任务定期把这些信息打印出来长期跑着看曲线对发现潜在问题非常有效。6.4 和LVGL、网络协议栈的联动下一条进阶路线很多用GD32F427的兄弟项目会涉及屏幕显示或网络通信。如果后面要把LVGL跑起来或者接一套MQTT协议我的建议是先保持LiteOS的内核配置最小化不要急着把官方Demo里所有组件都开起来。组件越多配置项越多出问题的概率越大。实测下来把LVGL跑在LiteOS上内核的tick配置建议保持1000Hz1ms否则动画帧率会有明显波动。而跑MQTT的时候注意网络任务和业务任务的优先级区分网络收发的任务优先级要比耗时的UI刷新任务高——不然你按下屏幕按钮时MQTT消息可能延迟很久才被处理。最后聊两句软件这行RTOS移植这个事情会者不难难者不会。第一次移植LiteOS-M确实容易一头雾水但只要你跑通一次把官方Demo的结构吃透了之后换任何芯片、换任何RTOS都只是换个目录、改几行配置的事。我的个人经验是别嫌官方Demo代码啰嗦里面每一行背后都有原因。你有空的时候把Demo里的启动流程用自己的话写一遍注释比刷十个教程都管用。真正到项目紧张的时候你会感激自己当初花的那一个小时。