企业官网建设流程全解析

简介：面向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总线。下面是一个典型摄像组工程的外设分配方式：

这种分配方式的理由是：菜单的硬实时性要求极低，晚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. 从按键到OLED：TC264调试菜单的最小可跑实现

3.1 OLED显示驱动：缓冲区映射与局部刷新

调试菜单的载体基本是0.96寸OLED，SSD1306控制器居多。初始化后把要显示的内容写进显存数组，时机成熟再一次性刷到屏幕上。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，适合“进入编辑态”这种不希望误触发的操作。

状态机核心代码如下：

#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字节最小帧：

命令字只保留四个：0x01读取全部参数，0x02修改指定参数，0x03保存到Flash，0x04切换只读模式。接收解析放在串口中断里：

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中途掉电导致锁状态损坏。

本文还有配套的精品资源，点击获取