TC264开源链接
项目架构
本工程基于逐飞科技 TC264 开源库，主控为英飞凌 AURIX TC264D（双核 TriCore），使用 MT9V03X 灰度摄像头（188×120）识别赛道，双编码器闭环控制左右电机，舵机负责方向。
为什么是双核？
可以把 TC264 的双核想象成一辆车上的「司机」和「领航员」：CPU0 是司机，双手不能离开方向盘——所有实时控制（方向环、速度环、编码器采样）都跑在它的定时中断里；CPU1 是领航员，负责看路（图像处理）、记笔记（屏幕显示）、和后方基地通话（WiFi 上位机）。两人通过共享变量交换信息，谁也不阻塞谁。
硬件资源
- 左电机 PWM：P33.6，方向 P33.7；右电机 PWM：P02.4，方向 P02.5
- 舵机 PWM：P33.9，频率 333Hz
- 编码器：GPT12 的 TIM6（左）/ TIM5（右），标定 11485 count/m
- 摄像头：MT9V03X，VSYNC + DMA 采集
- 显示：IPS200 SPI；无线：逐飞 WiFi SPI 模块（TCP 客户端）
双核分工及其中断分配
CPU0（司机）：实时控制，所有中断都归它执行。
- 2ms（CCU61 CH0）→ 方向环 + 舵机滤波/限幅
- 5ms（CCU60 CH0）→ 系统计时、IMU
- 10ms（CCU61 CH1）→ 编码器采样、里程、速度环、出赛道保护
- 1s（CCU60 CH1）→ 帧率统计
CPU1（领航员）：视觉与通信，跑主循环调度（非中断）。
- 10ms 按键扫描；33ms WiFi 图像上传；100ms 刷屏/数据上传
关键：PIT、摄像头 DMA、串口中断全部用
IFX_INTERRUPT(..., 0, ...)绑在 CPU0，方向环和速度环都在中断上下文里跑；CPU1 只负责图像处理和 WiFi，不碰实时控制。
常用算法
基础循迹及其图像处理
大津法二值化
摄像头输出的是 188×120 的灰度图，要提取赛道边线，第一步就是把灰度图变成黑白二值图——赛道为白、背景为黑。本工程用的是全局大津法（Otsu）。
大津法是什么？
可以把它想象成一个「自动找最佳切割点」的分割师：遍历所有可能的阈值（0~255），计算每个阈值下「赛道像素」和「背景像素」两组之间的类间方差，方差最大的那个阈值就是最佳分割点——它让两组分得最开。
优点：无需手动设阈值，能自动适应光照变化。
局限：当画面出现局部强光/阴影（比如赛道上有光斑、远处有反光）时，全局单一阈值会让局部区域过曝或丢失信息。本工程后续通过逆透视+点云处理来弥补。
左：MT9V03X 灰度原图；右：大津法二值化结果
元素处理
调试工具链
- IPS200 屏幕：边线/中线逐行对齐绘制、点云调试行（pts/ang/cL cR）、开机动画、按键调参 UI
- WiFi 上位机：约 30fps 上传二值图 + 边线/角点；支持
$GO发车（等效按键双击：清里程/起步速度/开始测距）和$TMODE状态标签（0 普通 / 1 预十字 / 2 十字中） - 保护机制：出赛道保护、丢线停车、蜂鸣器提示、里程与平均速度统计
踩坑记录
ltc E112 链接错误（RAM 不足）：十字爬线曾新增 2820 字节全帧位图 crawl_visited，导致 CPU1 的 120KB DSPR1 放不下（堆、栈、CSA 都要从这块分）。解决方法是删掉静态数组，复用本帧已用完的点云缓冲和 WiFi scratch 尾部空间。教训：TC264 的 RAM 是分区管理的，”总需求小于总容量”不代表能链接通过，连续区约束会直接卡死。
