简介面向TC264单片机智能车竞赛场景的调试菜单完整资料包适合嵌入式、自动化、电子信息等方向学生可用于课程设计、毕业设计或智能车竞赛项目起步。整包共548个文件以C/H源码为主体178个C文件、327个H文件另有工程配置、XML配置、引脚定义、说明文档和演示视频等压缩包约26.96MB。源码覆盖TC264常用外设驱动、通信接口与部分信号处理算法并附详细文档与录屏便于对照理解调试菜单的层级设计与交互流程从外设初始化到菜单项调度均有清晰实现可帮助读者快速定位关键代码。该项目为作者高分参赛源码已经过实际运行验证可直接作为竞赛方案参考也适合在此基础上扩展新功能或移植到同类单片机平台。已有116人学习浏览对正在准备智能车竞赛或单片机综合实训的读者具有较高参考价值配套目录与文件类型划分清楚既适合作为毕设、课设的完整项目参考也可作为智能车调试技巧的入门素材。1. 为什么说调试菜单是TC264智能车工程的隐形主线智能车竞赛里最贵的时间成本往往不是写控制算法而是烧录验证改一次PID的Kp或者编码器倍频系数编译下载一次算40秒跑一圈测两次一个晚上就耗掉几十次循环。TC264这类英飞凌单片机的开发流程绝大部分时间都消耗在“改代码、重编译、下载、上电、跑车”的重复动作上。调试菜单就是把这套动作里的“改代码、重编译”压缩成按键和OLED上的一次数值修改把参数调整周期从分钟级压到秒级。正因如此凡是能在国赛里跑进决赛的工程调试菜单几乎是标配——它不属于控制理论却决定控制理论的验证速度。这篇稿子面向备赛学生和有调参痛苦的嵌入式工程师按我实际使用的注册表方案把菜单从架构到落地讲透。2. TC264的资源分配与调试菜单架构先划分外设再做注册表2.1 双核分工与外设清单哪些资源给菜单不心疼TC264是双核TriCore架构单片机核0通常跑主控制环和传感器采集核1大部分时间空闲。菜单完全可以放在核1形成一个“慢任务”控制环按2ms周期跑菜单按20ms周期跑。需要注意OLED、按键、蓝牙这些外设如果挂在核0的SPI或UART上菜单刷新就会占用控制环的总线时间。常见的做法是把菜单相关外设统一划给核1至少不要让OLED与摄像头共用同一条SPI总线。下面是一个典型摄像组工程的外设分配方式外设总线/接口占用者工作方式OLED 0.96寸SPI1或I2C核1菜单任务轮询写入四个微动按键GPIO核1菜单任务5ms周期扫描蓝牙透传模块UART2核1无线菜单接收中断参数保存DataFlash核1菜单任务关中断后擦写编码器/摄像头专用接口核0控制环硬件处理这种分配方式的理由是菜单的硬实时性要求极低晚10ms响应用户按键不会影响控制效果但控制环的时序不能被打断。把“慢任务放核1、快任务放核0”比两个任务挤在同一核里抢优先级要可靠得多。如果你的工程已经把两个核都用满那就在主循环末尾调用菜单任务并确保菜单函数内部没有超过1ms的阻塞操作。2.2 菜单框架的骨架注册表而不是switch-case很多入门方案用一个大switch-case实现菜单伪代码如下switch (key) { case KEY_UP: switch (page) { case 0: pid_kp 0.1f; break; case 1: speed_ref 10; break; } break; }这种写法在前面几个菜单项时还算清晰参数增加到二十个以后按键处理、数值上下限、绘制逻辑散落在不同文件里改一个参数要动三处代码最后连自己都记不住case序号对应哪一项。我一般会把菜单重构成注册表把每个参数抽象成一个结构体菜单框架只遍历这张表按键事件只操作当前选中项。最小结构体定义如下typedef enum { MENU_ITEM_INT32, // 显示和编辑 int32_t 变量 MENU_ITEM_FLOAT, // 显示和编辑 float 变量 MENU_ITEM_ACTION, // 确认键触发回调比如“保存参数” MENU_ITEM_SUBMENU // 子菜单入口 } menu_type_t; typedef struct menu_item { const char *name; // 菜单项名称如 Speed.Kp menu_type_t type; // 菜单项类型 void *value_ptr; // 指向实际变量如 pid_speed.kp float min_v; // 数值编辑下限 float max_v; // 数值编辑上限 float step; // 每按一次键的步进量 void (*on_confirm)(void); // 确认回调可为NULL struct menu_item *child; // SUBMENU项的子菜单指针 } menu_item_t;这里有几个设计要点。第一value_ptr用void*指向目标变量的地址菜单直接操作控制环正在使用的变量不需要额外同步。第二min_v和max_v不只是用来限制显示还兼作保存前的强校验防止把PID系数改成负数导致上电飞车。第三on_confirm回调让确认键的行为完全由业务层定义菜单框架不需要知道参数最终存进哪块Flash也不需要知道编码器清零怎么执行。这样菜单和业务完全解耦将来换TC23x系列或者其他品牌单片机这套结构可以原样搬走。2.3 菜单的三种状态浏览、编辑、确认菜单运行时本质是一个状态机我通常只保留三个状态不引入更多状态机分支typedef enum { MENU_STATE_BROWSE, // 浏览态上/下键移动选中行 MENU_STATE_EDIT, // 编辑态左/右键调整数值 MENU_STATE_CONFIRM // 确认态短暂显示保存提示 } menu_state_t;浏览态下短按上/下键改变选中索引长按确认键进入编辑态编辑态下左右键按step增减数值越界就钳制到min_v和max_v确认键退出编辑回到浏览态。如果当前项是ACTION类型确认键直接触发on_confirm回调然后进入CONFIRM态显示一行提示几百毫秒后自动回到浏览态。状态迁移越简单越好不要在菜单里引入时间片轮转调度否则现场很容易出现“按一下跳两行”的失控感。3. 从按键到OLEDTC264调试菜单的最小可跑实现3.1 OLED显示驱动缓冲区映射与局部刷新调试菜单的载体基本是0.96寸OLEDSSD1306控制器居多。初始化后把要显示的内容写进显存数组时机成熟再一次性刷到屏幕上。SSD1306显存布局是8页每页128字节每字节代表纵向8个像素所以最小刷新单元是一个页区间。整屏刷新需要传输1KB数据SPI在10MHz下接近1ms如果只重绘一行传输量只有128字节耗时降到百微秒级。局部刷新在有图像回传需求的工程里尤其重要。下面是一个简单的显存操作封装#define OLED_W 128 #define OLED_H 64 #define OLED_PAGES (OLED_H / 8) static uint8_t g_fb[OLED_PAGES][OLED_W]; void oled_fill(uint8_t page_start, uint8_t page_end, uint8_t value) { uint8_t page, col; for (page page_start; page page_end; page) { for (col 0; col OLED_W; col) { g_fb[page][col] value; } } oled_flush(page_start, page_end); // 只回写脏区域 } void oled_flush(uint8_t page_start, uint8_t page_end) { // 发送SSD1306命令设置页地址范围和列地址范围 // 然后沿SPI连续写入 (page_end - page_start 1) * 128 字节。 }代码里的g_fb是完整的页面缓冲区绘制任意字符和矩形都先写缓冲区最后统一刷屏。这样菜单绘制函数不需要关心SPI时序细节也方便以后加“反色高亮”——把某个区域的数据按位取反再回写即可。局部刷新还要配合脏标记只有选中行或数值区域变化时才调用oled_flush否则菜单任务基本不碰SPI总线。3.2 按键状态机的参数设计去抖、短按、长按按键是菜单与人交互的唯一输入核心问题是不要让机械抖动干扰状态判断。我一般写一个5ms周期执行的按键扫描状态机采样连续三次相同电平才确认状态变化15ms以内的抖动被完全滤掉。长按阈值设为500ms适合“进入编辑态”这种不希望误触发的操作。参数推荐值作用扫描周期5ms与去抖时间匹配兼顾响应速度KEY_DEBOUNCE_MS15ms滤除机械抖动等于3个扫描周期KEY_LONG_MS500ms触法长按事件进入编辑或确认状态机核心代码如下#define KEY_DEBOUNCE_MS 15 #define KEY_LONG_MS 500 typedef struct { uint8_t stable; // 当前已确认的电平 uint8_t pending; // 上一次采样电平去抖中的候选值 uint16_t pending_t; // 候选值起始时间 uint16_t stable_t; // 当前电平维持时间 } key_sm_t; uint8_t key_update(key_sm_t *k, uint8_t raw, uint16_t now_ms) { if (raw ! k-pending) { k-pending raw; k-pending_t now_ms; return KEY_NONE; } if (raw ! k-stable (now_ms - k-pending_t) KEY_DEBOUNCE_MS) { k-stable raw; k-stable_t now_ms; return raw ? KEY_PRESS : KEY_RELEASE; } if ((now_ms - k-stable_t) KEY_LONG_MS) { k-stable_t now_ms; // 防止同一次按压重复触发长按 return KEY_LONG; } return KEY_NONE; }这段代码里pending记录的是上一次扫描的原始电平只有连续多次采样都相同才会被提升为stable。长按事件触发后把stable_t更新为当前时刻这样手指一直按住时不会每隔500ms就报一次长按只会在按下后报一次。实际调车时可以临时把KEY_LONG_MS改成300试试手感如果频繁误进编辑态就改回500。3.3 菜单渲染主流程事件驱动和脏标记配合有了OLED局部刷新和按键事件菜单主循环可以写得很短void menu_task(void) { uint8_t key key_scan(); switch (g_state) { case MENU_STATE_BROWSE: if (key KEY_UP) { g_selected (g_selected MENU_ROWS - 1) % MENU_ROWS; } if (key KEY_DOWN) { g_selected (g_selected 1) % MENU_ROWS; } if (key KEY_LONG) { start_edit(); } break; case MENU_STATE_EDIT: if (key KEY_UP) { step_selected(g_item.step); // 数值加一个步进 } if (key KEY_DOWN) { step_selected(-g_item.step); // 数值减一个步进 } if (key KEY_LONG) { stop_edit(); } break; } menu_draw_if_dirty(); }这里key_scan()返回的是事件而不是电平所以菜单状态机不需要关心按键按了多久只需要响应KEY_PRESS和KEY_LONG两种事件。每个菜单项在屏幕上的行位置由g_selected和当前滚动偏移计算绘制函数内部再做一层脏标记判断如果选中索引没变、数值没变、状态没变就直接跳过SSD1306写操作。这样整个菜单任务对CPU的占用可以控制在极低水平几乎不影响控制环。4. 把控制变量变成菜单项注册表、Flash持久化与无线调试4.1 宏注册表把定义菜单写成一行结构体定义好之后手写每个菜单项的初始化仍然麻烦。我一般用宏来生成菜单项让新增参数变成一行代码#define FLOAT_ITEM(name, var, min, max, step) \ { name, MENU_ITEM_FLOAT, (var), (min), (max), (step), NULL, NULL } #define ACTION_ITEM(name, fn) \ { name, MENU_ITEM_ACTION, NULL, 0, 0, 0, (fn), NULL } menu_item_t g_menu[] { FLOAT_ITEM(Speed.Kp, pid_speed.kp, 0.0f, 20.0f, 0.5f), FLOAT_ITEM(Speed.Ki, pid_speed.ki, 0.0f, 5.0f, 0.1f), FLOAT_ITEM(Speed.Kd, pid_speed.kd, 0.0f, 2.0f, 0.05f), FLOAT_ITEM(Turn.Base, turn_base, 20.0f, 100.0f, 1.0f), ACTION_ITEM(Save, params_save), };这种写法的好处从源码组织结构上就能看出来新增可调参数只需在g_menu[]里加一行减少参数就删一行。FLOAT_ITEM宏里的(var)括号不能省否则遇到pid_speed.kp这种带点运算符的表达式宏展开后可能产生优先级问题。调参步进step要按参数量级单独设置速度环Kp用0.5或0.1角度环基础值用1.0避免现场按几十下才能从20调30。4.2 参数保存到DataFlash扇区擦除与写后校验菜单调好的值必须掉电保存否则每次上电都要重调一遍。TC264的DataFlash是扇区擦除、按32位字写入写之前必须保证扇区处于已擦除状态。擦除一次大约几十毫秒这期间不能从该扇区取指也不能让中断服务程序访问它所以擦除时必须关中断。#define PARAM_FLASH_ADDR 0xAF000000u /* 示例地址实际以链接脚本为准 */ #define PARAM_SECTOR_SIZE 0x4000u uint32_t flash_buf[PARAM_SECTOR_SIZE / 4]; void params_save(void) { uint32_t i; memcpy(flash_buf, g_param, sizeof(g_param)); __disable(); // 关闭全局中断防止擦写被打断 flash_erase_sector(PARAM_FLASH_ADDR); flash_write_buf(PARAM_FLASH_ADDR, flash_buf, sizeof(flash_buf)); __enable(); for (i 0; i sizeof(g_param) / 4; i) { if (((uint32_t *)PARAM_FLASH_ADDR)[i] ! flash_buf[i]) { show_message(SAVE FAIL); return; } } show_message(SAVED); }注意PARAM_FLASH_ADDR只是演示用示例地址实际地址必须查你工程里的链接脚本写错地址会直接触发总线错误。__disable()是概称TC264的编译器里对应_disable()或__disable_interrupt()以实际工具链手册为准。代码里关中断的时间要尽量短只包住擦除和写入两个操作。DataFlash偶尔会出现个别位写不进去的情况所以写后回读校验不能省校验失败时菜单当场提示“SAVE FAIL”而不是等上电加载才发现参数不对。4.3 无线调试手机蓝牙透传与一个简短协议菜单如果在车上看跑赛道时仍然没法调。常见做法是给TC264接一个蓝牙透传模块UART2作为无线菜单通道波特率115200手机上用串口助手连接即可。无线协议尽量简单我常用一个7字节最小帧字节0字节1字节2-5字节60xAA 帧头命令字按大端序排列的float累加和命令字只保留四个0x01读取全部参数0x02修改指定参数0x03保存到Flash0x04切换只读模式。接收解析放在串口中断里void uart2_rx_handler(void) { static uint8_t idx 0; static uint8_t frame[7]; uint8_t b uart2_get_byte(); uint8_t i, sum; frame[idx] b; if (idx 7) { sum 0; for (i 0; i 6; i) { sum frame[i]; } if (sum frame[6] frame[0] 0xAA) { handle_wifi_cmd(frame); } idx 0; // 不管校验是否通过都重新对齐帧 } }这串代码里累加和计算直接依赖uint8_t的溢出回卷特性约定等于“前六个字节之和取低8位”。解析器接收满7字节就重置索引丢一个字节只丢当前帧不会导致后续帧错位。无线命令和按键操作共用同一个g_menu[]注册表通过菜单项编号定位变量修改时走同一套min_v/max_v校验不会出现“手机能改的值按键改不了”的行为差异。5. 现场救命的三个技巧菜单卡死排查与赛前冻结5.1 两个容易让菜单看起来很“坏”的编译期问题TC264的工程常用Tasking或HighTec编译器两者默认的堆栈配置并不相同。菜单框架把显存数组、菜单表、按键状态放在全局区本来不会占用多少栈但如果把g_fb这类按KB计的大数组误声明成局部变量默认几KB的栈会被瞬间击穿现象表现为屏幕乱码、菜单闪烁甚至函数都回不来。排查时先看编译器的栈使用报告或者直接把所有大数组移动到全局区。另一个问题是DataFlash擦写时的中断恢复。_disable()和_enable()必须严格配对一旦不对称关掉的中断恢复不出来现象是按键有电平变化但菜单完全不响应。排查时可以在_enable()后加一个GPIO翻转用示波器观察保存参数那一刻中断是否真正恢复。5.2 按键“按一下跳两行”的排查顺序菜单跑到赛道上后最常见的异常是按一下跳两行或者响应时快时慢。先确认按键扫描任务是不是被控制环任务抢占导致扫描周期不再是5ms再看去抖时间用的是“系统tick的绝对时间”还是“扫描次数计数”如果时间基准被暂停过去抖累积会出错。我一般把按键扫描放在固定定时器中断里菜单渲染放主循环两边通过事件队列通信这样控制环再忙也不会影响按键采样节奏。按键事件的响应边沿也要统一只在上跳沿产生KEY_PRESS不要同时在上跳和下跳沿都报事件否则一次按键会被当成两次。5.3 赛前冻结给调试菜单加一把只读锁比赛前几天参数已经收敛得差不多这时候最怕在赛场上手误按到关键项。我会在参数结构体里加一个menu_locked把菜单切换成只读模式uint8_t menu_locked 0; // 0 允许编辑1 只读 void menu_try_edit(void) { if (menu_locked) { show_message(LOCKED); return; } g_state MENU_STATE_EDIT; }锁定值可以做成菜单里的隐藏项正常查看参数时用一个组合键把menu_locked置1再触发params_save()存进Flash。上电加载参数时如果读出menu_locked 1就把菜单初始化到只读模式。这个锁不要做成“再长按一次就解锁”的简单逻辑赛场上紧张状态下很容易误开锁我见过更稳妥的工程把锁定值重复存三份上电时按多数一致恢复防止写Flash中途掉电导致锁状态损坏。本文还有配套的精品资源点击获取 TC264调试菜单实战：基于注册表架构与OLED交互的嵌入式调参方案
简介面向TC264单片机智能车竞赛场景的调试菜单完整资料包适合嵌入式、自动化、电子信息等方向学生可用于课程设计、毕业设计或智能车竞赛项目起步。整包共548个文件以C/H源码为主体178个C文件、327个H文件另有工程配置、XML配置、引脚定义、说明文档和演示视频等压缩包约26.96MB。源码覆盖TC264常用外设驱动、通信接口与部分信号处理算法并附详细文档与录屏便于对照理解调试菜单的层级设计与交互流程从外设初始化到菜单项调度均有清晰实现可帮助读者快速定位关键代码。该项目为作者高分参赛源码已经过实际运行验证可直接作为竞赛方案参考也适合在此基础上扩展新功能或移植到同类单片机平台。已有116人学习浏览对正在准备智能车竞赛或单片机综合实训的读者具有较高参考价值配套目录与文件类型划分清楚既适合作为毕设、课设的完整项目参考也可作为智能车调试技巧的入门素材。1. 为什么说调试菜单是TC264智能车工程的隐形主线智能车竞赛里最贵的时间成本往往不是写控制算法而是烧录验证改一次PID的Kp或者编码器倍频系数编译下载一次算40秒跑一圈测两次一个晚上就耗掉几十次循环。TC264这类英飞凌单片机的开发流程绝大部分时间都消耗在“改代码、重编译、下载、上电、跑车”的重复动作上。调试菜单就是把这套动作里的“改代码、重编译”压缩成按键和OLED上的一次数值修改把参数调整周期从分钟级压到秒级。正因如此凡是能在国赛里跑进决赛的工程调试菜单几乎是标配——它不属于控制理论却决定控制理论的验证速度。这篇稿子面向备赛学生和有调参痛苦的嵌入式工程师按我实际使用的注册表方案把菜单从架构到落地讲透。2. TC264的资源分配与调试菜单架构先划分外设再做注册表2.1 双核分工与外设清单哪些资源给菜单不心疼TC264是双核TriCore架构单片机核0通常跑主控制环和传感器采集核1大部分时间空闲。菜单完全可以放在核1形成一个“慢任务”控制环按2ms周期跑菜单按20ms周期跑。需要注意OLED、按键、蓝牙这些外设如果挂在核0的SPI或UART上菜单刷新就会占用控制环的总线时间。常见的做法是把菜单相关外设统一划给核1至少不要让OLED与摄像头共用同一条SPI总线。下面是一个典型摄像组工程的外设分配方式外设总线/接口占用者工作方式OLED 0.96寸SPI1或I2C核1菜单任务轮询写入四个微动按键GPIO核1菜单任务5ms周期扫描蓝牙透传模块UART2核1无线菜单接收中断参数保存DataFlash核1菜单任务关中断后擦写编码器/摄像头专用接口核0控制环硬件处理这种分配方式的理由是菜单的硬实时性要求极低晚10ms响应用户按键不会影响控制效果但控制环的时序不能被打断。把“慢任务放核1、快任务放核0”比两个任务挤在同一核里抢优先级要可靠得多。如果你的工程已经把两个核都用满那就在主循环末尾调用菜单任务并确保菜单函数内部没有超过1ms的阻塞操作。2.2 菜单框架的骨架注册表而不是switch-case很多入门方案用一个大switch-case实现菜单伪代码如下switch (key) { case KEY_UP: switch (page) { case 0: pid_kp 0.1f; break; case 1: speed_ref 10; break; } break; }这种写法在前面几个菜单项时还算清晰参数增加到二十个以后按键处理、数值上下限、绘制逻辑散落在不同文件里改一个参数要动三处代码最后连自己都记不住case序号对应哪一项。我一般会把菜单重构成注册表把每个参数抽象成一个结构体菜单框架只遍历这张表按键事件只操作当前选中项。最小结构体定义如下typedef enum { MENU_ITEM_INT32, // 显示和编辑 int32_t 变量 MENU_ITEM_FLOAT, // 显示和编辑 float 变量 MENU_ITEM_ACTION, // 确认键触发回调比如“保存参数” MENU_ITEM_SUBMENU // 子菜单入口 } menu_type_t; typedef struct menu_item { const char *name; // 菜单项名称如 Speed.Kp menu_type_t type; // 菜单项类型 void *value_ptr; // 指向实际变量如 pid_speed.kp float min_v; // 数值编辑下限 float max_v; // 数值编辑上限 float step; // 每按一次键的步进量 void (*on_confirm)(void); // 确认回调可为NULL struct menu_item *child; // SUBMENU项的子菜单指针 } menu_item_t;这里有几个设计要点。第一value_ptr用void*指向目标变量的地址菜单直接操作控制环正在使用的变量不需要额外同步。第二min_v和max_v不只是用来限制显示还兼作保存前的强校验防止把PID系数改成负数导致上电飞车。第三on_confirm回调让确认键的行为完全由业务层定义菜单框架不需要知道参数最终存进哪块Flash也不需要知道编码器清零怎么执行。这样菜单和业务完全解耦将来换TC23x系列或者其他品牌单片机这套结构可以原样搬走。2.3 菜单的三种状态浏览、编辑、确认菜单运行时本质是一个状态机我通常只保留三个状态不引入更多状态机分支typedef enum { MENU_STATE_BROWSE, // 浏览态上/下键移动选中行 MENU_STATE_EDIT, // 编辑态左/右键调整数值 MENU_STATE_CONFIRM // 确认态短暂显示保存提示 } menu_state_t;浏览态下短按上/下键改变选中索引长按确认键进入编辑态编辑态下左右键按step增减数值越界就钳制到min_v和max_v确认键退出编辑回到浏览态。如果当前项是ACTION类型确认键直接触发on_confirm回调然后进入CONFIRM态显示一行提示几百毫秒后自动回到浏览态。状态迁移越简单越好不要在菜单里引入时间片轮转调度否则现场很容易出现“按一下跳两行”的失控感。3. 从按键到OLEDTC264调试菜单的最小可跑实现3.1 OLED显示驱动缓冲区映射与局部刷新调试菜单的载体基本是0.96寸OLEDSSD1306控制器居多。初始化后把要显示的内容写进显存数组时机成熟再一次性刷到屏幕上。SSD1306显存布局是8页每页128字节每字节代表纵向8个像素所以最小刷新单元是一个页区间。整屏刷新需要传输1KB数据SPI在10MHz下接近1ms如果只重绘一行传输量只有128字节耗时降到百微秒级。局部刷新在有图像回传需求的工程里尤其重要。下面是一个简单的显存操作封装#define OLED_W 128 #define OLED_H 64 #define OLED_PAGES (OLED_H / 8) static uint8_t g_fb[OLED_PAGES][OLED_W]; void oled_fill(uint8_t page_start, uint8_t page_end, uint8_t value) { uint8_t page, col; for (page page_start; page page_end; page) { for (col 0; col OLED_W; col) { g_fb[page][col] value; } } oled_flush(page_start, page_end); // 只回写脏区域 } void oled_flush(uint8_t page_start, uint8_t page_end) { // 发送SSD1306命令设置页地址范围和列地址范围 // 然后沿SPI连续写入 (page_end - page_start 1) * 128 字节。 }代码里的g_fb是完整的页面缓冲区绘制任意字符和矩形都先写缓冲区最后统一刷屏。这样菜单绘制函数不需要关心SPI时序细节也方便以后加“反色高亮”——把某个区域的数据按位取反再回写即可。局部刷新还要配合脏标记只有选中行或数值区域变化时才调用oled_flush否则菜单任务基本不碰SPI总线。3.2 按键状态机的参数设计去抖、短按、长按按键是菜单与人交互的唯一输入核心问题是不要让机械抖动干扰状态判断。我一般写一个5ms周期执行的按键扫描状态机采样连续三次相同电平才确认状态变化15ms以内的抖动被完全滤掉。长按阈值设为500ms适合“进入编辑态”这种不希望误触发的操作。参数推荐值作用扫描周期5ms与去抖时间匹配兼顾响应速度KEY_DEBOUNCE_MS15ms滤除机械抖动等于3个扫描周期KEY_LONG_MS500ms触法长按事件进入编辑或确认状态机核心代码如下#define KEY_DEBOUNCE_MS 15 #define KEY_LONG_MS 500 typedef struct { uint8_t stable; // 当前已确认的电平 uint8_t pending; // 上一次采样电平去抖中的候选值 uint16_t pending_t; // 候选值起始时间 uint16_t stable_t; // 当前电平维持时间 } key_sm_t; uint8_t key_update(key_sm_t *k, uint8_t raw, uint16_t now_ms) { if (raw ! k-pending) { k-pending raw; k-pending_t now_ms; return KEY_NONE; } if (raw ! k-stable (now_ms - k-pending_t) KEY_DEBOUNCE_MS) { k-stable raw; k-stable_t now_ms; return raw ? KEY_PRESS : KEY_RELEASE; } if ((now_ms - k-stable_t) KEY_LONG_MS) { k-stable_t now_ms; // 防止同一次按压重复触发长按 return KEY_LONG; } return KEY_NONE; }这段代码里pending记录的是上一次扫描的原始电平只有连续多次采样都相同才会被提升为stable。长按事件触发后把stable_t更新为当前时刻这样手指一直按住时不会每隔500ms就报一次长按只会在按下后报一次。实际调车时可以临时把KEY_LONG_MS改成300试试手感如果频繁误进编辑态就改回500。3.3 菜单渲染主流程事件驱动和脏标记配合有了OLED局部刷新和按键事件菜单主循环可以写得很短void menu_task(void) { uint8_t key key_scan(); switch (g_state) { case MENU_STATE_BROWSE: if (key KEY_UP) { g_selected (g_selected MENU_ROWS - 1) % MENU_ROWS; } if (key KEY_DOWN) { g_selected (g_selected 1) % MENU_ROWS; } if (key KEY_LONG) { start_edit(); } break; case MENU_STATE_EDIT: if (key KEY_UP) { step_selected(g_item.step); // 数值加一个步进 } if (key KEY_DOWN) { step_selected(-g_item.step); // 数值减一个步进 } if (key KEY_LONG) { stop_edit(); } break; } menu_draw_if_dirty(); }这里key_scan()返回的是事件而不是电平所以菜单状态机不需要关心按键按了多久只需要响应KEY_PRESS和KEY_LONG两种事件。每个菜单项在屏幕上的行位置由g_selected和当前滚动偏移计算绘制函数内部再做一层脏标记判断如果选中索引没变、数值没变、状态没变就直接跳过SSD1306写操作。这样整个菜单任务对CPU的占用可以控制在极低水平几乎不影响控制环。4. 把控制变量变成菜单项注册表、Flash持久化与无线调试4.1 宏注册表把定义菜单写成一行结构体定义好之后手写每个菜单项的初始化仍然麻烦。我一般用宏来生成菜单项让新增参数变成一行代码#define FLOAT_ITEM(name, var, min, max, step) \ { name, MENU_ITEM_FLOAT, (var), (min), (max), (step), NULL, NULL } #define ACTION_ITEM(name, fn) \ { name, MENU_ITEM_ACTION, NULL, 0, 0, 0, (fn), NULL } menu_item_t g_menu[] { FLOAT_ITEM(Speed.Kp, pid_speed.kp, 0.0f, 20.0f, 0.5f), FLOAT_ITEM(Speed.Ki, pid_speed.ki, 0.0f, 5.0f, 0.1f), FLOAT_ITEM(Speed.Kd, pid_speed.kd, 0.0f, 2.0f, 0.05f), FLOAT_ITEM(Turn.Base, turn_base, 20.0f, 100.0f, 1.0f), ACTION_ITEM(Save, params_save), };这种写法的好处从源码组织结构上就能看出来新增可调参数只需在g_menu[]里加一行减少参数就删一行。FLOAT_ITEM宏里的(var)括号不能省否则遇到pid_speed.kp这种带点运算符的表达式宏展开后可能产生优先级问题。调参步进step要按参数量级单独设置速度环Kp用0.5或0.1角度环基础值用1.0避免现场按几十下才能从20调30。4.2 参数保存到DataFlash扇区擦除与写后校验菜单调好的值必须掉电保存否则每次上电都要重调一遍。TC264的DataFlash是扇区擦除、按32位字写入写之前必须保证扇区处于已擦除状态。擦除一次大约几十毫秒这期间不能从该扇区取指也不能让中断服务程序访问它所以擦除时必须关中断。#define PARAM_FLASH_ADDR 0xAF000000u /* 示例地址实际以链接脚本为准 */ #define PARAM_SECTOR_SIZE 0x4000u uint32_t flash_buf[PARAM_SECTOR_SIZE / 4]; void params_save(void) { uint32_t i; memcpy(flash_buf, g_param, sizeof(g_param)); __disable(); // 关闭全局中断防止擦写被打断 flash_erase_sector(PARAM_FLASH_ADDR); flash_write_buf(PARAM_FLASH_ADDR, flash_buf, sizeof(flash_buf)); __enable(); for (i 0; i sizeof(g_param) / 4; i) { if (((uint32_t *)PARAM_FLASH_ADDR)[i] ! flash_buf[i]) { show_message(SAVE FAIL); return; } } show_message(SAVED); }注意PARAM_FLASH_ADDR只是演示用示例地址实际地址必须查你工程里的链接脚本写错地址会直接触发总线错误。__disable()是概称TC264的编译器里对应_disable()或__disable_interrupt()以实际工具链手册为准。代码里关中断的时间要尽量短只包住擦除和写入两个操作。DataFlash偶尔会出现个别位写不进去的情况所以写后回读校验不能省校验失败时菜单当场提示“SAVE FAIL”而不是等上电加载才发现参数不对。4.3 无线调试手机蓝牙透传与一个简短协议菜单如果在车上看跑赛道时仍然没法调。常见做法是给TC264接一个蓝牙透传模块UART2作为无线菜单通道波特率115200手机上用串口助手连接即可。无线协议尽量简单我常用一个7字节最小帧字节0字节1字节2-5字节60xAA 帧头命令字按大端序排列的float累加和命令字只保留四个0x01读取全部参数0x02修改指定参数0x03保存到Flash0x04切换只读模式。接收解析放在串口中断里void uart2_rx_handler(void) { static uint8_t idx 0; static uint8_t frame[7]; uint8_t b uart2_get_byte(); uint8_t i, sum; frame[idx] b; if (idx 7) { sum 0; for (i 0; i 6; i) { sum frame[i]; } if (sum frame[6] frame[0] 0xAA) { handle_wifi_cmd(frame); } idx 0; // 不管校验是否通过都重新对齐帧 } }这串代码里累加和计算直接依赖uint8_t的溢出回卷特性约定等于“前六个字节之和取低8位”。解析器接收满7字节就重置索引丢一个字节只丢当前帧不会导致后续帧错位。无线命令和按键操作共用同一个g_menu[]注册表通过菜单项编号定位变量修改时走同一套min_v/max_v校验不会出现“手机能改的值按键改不了”的行为差异。5. 现场救命的三个技巧菜单卡死排查与赛前冻结5.1 两个容易让菜单看起来很“坏”的编译期问题TC264的工程常用Tasking或HighTec编译器两者默认的堆栈配置并不相同。菜单框架把显存数组、菜单表、按键状态放在全局区本来不会占用多少栈但如果把g_fb这类按KB计的大数组误声明成局部变量默认几KB的栈会被瞬间击穿现象表现为屏幕乱码、菜单闪烁甚至函数都回不来。排查时先看编译器的栈使用报告或者直接把所有大数组移动到全局区。另一个问题是DataFlash擦写时的中断恢复。_disable()和_enable()必须严格配对一旦不对称关掉的中断恢复不出来现象是按键有电平变化但菜单完全不响应。排查时可以在_enable()后加一个GPIO翻转用示波器观察保存参数那一刻中断是否真正恢复。5.2 按键“按一下跳两行”的排查顺序菜单跑到赛道上后最常见的异常是按一下跳两行或者响应时快时慢。先确认按键扫描任务是不是被控制环任务抢占导致扫描周期不再是5ms再看去抖时间用的是“系统tick的绝对时间”还是“扫描次数计数”如果时间基准被暂停过去抖累积会出错。我一般把按键扫描放在固定定时器中断里菜单渲染放主循环两边通过事件队列通信这样控制环再忙也不会影响按键采样节奏。按键事件的响应边沿也要统一只在上跳沿产生KEY_PRESS不要同时在上跳和下跳沿都报事件否则一次按键会被当成两次。5.3 赛前冻结给调试菜单加一把只读锁比赛前几天参数已经收敛得差不多这时候最怕在赛场上手误按到关键项。我会在参数结构体里加一个menu_locked把菜单切换成只读模式uint8_t menu_locked 0; // 0 允许编辑1 只读 void menu_try_edit(void) { if (menu_locked) { show_message(LOCKED); return; } g_state MENU_STATE_EDIT; }锁定值可以做成菜单里的隐藏项正常查看参数时用一个组合键把menu_locked置1再触发params_save()存进Flash。上电加载参数时如果读出menu_locked 1就把菜单初始化到只读模式。这个锁不要做成“再长按一次就解锁”的简单逻辑赛场上紧张状态下很容易误开锁我见过更稳妥的工程把锁定值重复存三份上电时按多数一致恢复防止写Flash中途掉电导致锁状态损坏。本文还有配套的精品资源点击获取