1. 课程导入

无人机飞控系统并不是一块孤立的电路板，而是由飞控主控、电调、云台、GPS/RTK、光流、激光测距、电池管理、遥控接收机等多个子系统通过总线与串行链路协同工作的嵌入式网络。CAN 与 UART 是其中最常见的两类物理层通信方式：CAN 具备差分抗扰、多主仲裁、错误检测与非破坏性重发能力，适合电机转速指令、电池状态、舵机控制等实时性要求高的场景；UART 结构简单、成本低、生态成熟，广泛用于 GPS 定位数据、数传电台、光流模块、调试串口等点对点通信。本课程的目标，是让学习者从“会调用串口读写函数”进阶到“能独立设计并调试一套稳定可靠的无人机设备驱动”。

一、学习目标：从接口认知到驱动落地

完成本课程后，学习者应达到以下四个层次的能力：

• 接口层：理解 CAN 的帧格式、位定时、终端电阻、ID 过滤与 UART 的波特率、数据位、校验位、流控等基础参数，能根据器件手册正确配置外设。
• 驱动层：掌握 Linux 下 SocketCAN、TTY 子系统的设备模型，能编写字符设备或网络设备驱动，完成中断/DMA 收发、环形缓冲区管理、阻塞与非阻塞读写。
• 协议层：能设计面向无人机的轻量应用层协议，包括帧头、长度、命令字、负载、CRC 校验、序号与超时重传机制。
• 系统层：具备多设备并发、错误恢复、日志追踪与性能评估能力，能定位丢帧、乱序、总线关闭、串口粘包等典型问题。

二、核心概念：CAN 与 UART 的本质差异

CAN 是总线型、多主、基于报文 ID 的广播网络，节点通过“线与”机制进行位仲裁，ID 越小优先级越高；它自带 CRC、应答位、错误计数器与总线关闭状态机，可靠性由控制器硬件保障。UART 是异步、点对点、无地址的字节流通道，本身不提供帧边界、校验与重传，所有可靠性机制必须由驱动或应用层补齐。理解这一差异，是后续所有设计决策的起点：CAN 驱动更关注过滤器、邮箱、总线负载与错误状态；UART 驱动更关注缓冲区、帧解析、超时与流控。

三、整体知识框架与实战路线图

本课程按“硬件—内核—协议—应用—调优”的主线展开，下图给出整体知识框架与学习路径，帮助你在进入各章节前建立全局地图。

四、典型场景：从需求到驱动选型

假设你要为一架四旋翼无人机接入电池管理模块与 RTK 定位模块。电池模块需要以 100 Hz 上报电压、电流、温度与剩余电量，并要求飞控在异常时快速下发断电指令；RTK 模块以 5 Hz 输出 NMEA 语句与原始观测数据，数据量大但实时性要求相对宽松。此时合理的选型是：电池模块走 CAN，利用其优先级仲裁保证断电指令优先发送；RTK 模块走 UART，利用其高吞吐与成熟解析生态。驱动设计上，CAN 侧重点在过滤器配置与 Bus-Off 恢复，UART 侧重点在 DMA 接收与 NMEA 帧解析。

五、常见误区与复盘建议

建议在学习过程中建立“问题—现象—根因—验证”的复盘习惯。例如遇到 UART 粘包，先确认帧头与长度字段设计是否唯一，再用示波器或逻辑分析仪抓取原始波形，最后在驱动日志中打印接收缓冲区快照。遇到 CAN 丢帧，先读取 /proc/net/can/stats 与错误计数器，再检查总线负载与终端电阻。只有把现象与底层机制对应起来，驱动开发能力才会真正沉淀。

# 常用排查命令示例
ip -details link show can0          # 查看 CAN 位定时与状态
candump can0                        # 抓取 CAN 报文
cat /proc/net/can/stats             # 查看 CAN 统计与错误
stty -F /dev/ttyS3 -a               # 查看 UART 当前参数
cat /sys/class/tty/ttyS3/uartclk    # 查看 UART 时钟