主讲：CAN、UART、RS485/232、USB、I2C、SPI
一、先构建企业级项目的总框架思维
在企业里，通信接口很少孤立存在。更常见的是这样的系统结构：
硬件设备层：传感器、执行器、仪表、摄像头、网关、控制器、外部模块
↓↓↓
驱动与内核抽象层：tty、i2c-dev、spidev、SocketCAN、USB 类驱动、网卡、视频设备
↓↓↓
应用通信层：串口协议解析、CAN 报文处理、I2C 寄存器访问、SPI 事务、USB 设备管理
↓↓↓
业务服务层：数据采集、状态监控、设备控制、告警、参数管理、日志、升级
↓↓↓
系统集成层：本地 UI、远程平台、云端、上位机、PLC、MES、SCADA
“从 Linux 抽象层往上，把通信接口封装成可维护、可测试、可重试、可监控的应用模块。”
二、企业级项目里，通信模块的统一设计方法
不管是 CAN、UART、RS485、USB、I2C 还是 SPI，都建议按下面方式设计。
1. 分层设计
至少拆成四层：
第一层：设备访问层
职责是“对接 Linux 节点或 socket”。
例如：
- UART：
open + termios + read/write - I2C：
open + ioctl(I2C_SLAVE) + read/write - SPI：
open + SPI_IOC_MESSAGE - CAN：
socket + bind + read/write
这一层不要混业务逻辑。
第二层：协议层
职责是“把字节流或报文流变成结构化协议”。
例如：
第三层：业务层
职责是“设备能力建模”。
例如：
第四层：系统层
职责是“把业务能力接入整体系统”。
例如：
2. 通信模块统一要具备的能力
企业项目里，一个通信模块通常至少要有这几个能力：
初始化
发送
接收
异常处理
监控
可测试性
3. 面试时最加分的工程词汇
这些词不只是“高级”，而是说明你真的做过工程。
三、CAN 企业级知识点
1. CAN 在企业项目里的典型角色
说实在的，CAN 很少单独出现，它常出现在这些场景：
它的项目定位通常是：
2. CAN 的企业级理解
CAN 的核心优势不是“能发报文”
而是：
所以不要只说：
“CAN 是差分通信。”
要说：
“CAN 的工程价值在于它把总线访问控制、错误处理和优先级调度都做进了协议层，非常适合分布式控制系统。”
3. Linux 下 CAN 的企业级开发重点
第一重点：SocketCAN
用户态通常走：
socket(PF_CAN, SOCK_RAW, CAN_RAW)
第二重点：过滤器
实际项目不会无脑接收所有报文，而是设置过滤器，只接自己关心的 ID报文。
第三重点：收发解耦
高流量场景下：
第四重点：状态管理
要能感知：
4. 企业级 CAN 模块应该怎么封装
建议至少有这些对象：
can_device
负责设备打开、关闭、socket 初始化、过滤器设置。
can_frame_parser
负责把不同 ID 的报文映射成结构体。
can_dispatcher
负责把报文分发给不同业务模块。
can_tx_manager
负责发送队列、优先级、重发控制。
can_monitor
负责统计：
5. CAN 项目里常见难点
报文频率不稳定
可能原因：
偶发丢帧
可能原因：
设备状态异常
可能是：
6. CAN 面试时的项目表达模板
你可以这样答：
“在项目中我通常把 CAN 通信拆成设备层、报文层和业务层。设备层基于 SocketCAN 完成接口初始化、过滤器配置和状态检测；报文层按 ID 定义结构体并做统一解析；业务层处理具体控制逻辑。为保证稳定性，我会增加收发统计、超时告警、错误状态监控以及必要的重发或降级策略。”
7. CAN 高频笔试 / 面试题
问：CAN 为什么适合分布式控制？
答：因为它支持多主共享、基于 ID 的优先级仲裁、差分抗干扰和完善的错误处理机制。
问：Linux 下为什么用 SocketCAN？
答：因为 Linux 把 CAN 统一纳入网络接口框架，便于用 socket 模型管理、过滤和监控。
问：CAN 项目里为什么要做过滤器？
答：因为总线上可能有大量与本模块无关的报文，过滤器可以降低用户态负担，提高处理效率和稳定性。
问：bus-off 怎么理解？
答：当节点错误过多，控制器会进入一种自我隔离状态，避免继续污染总线。
四、UART 企业级知识点
1. UART 在企业项目里的典型角色
UART 在企业项目里非常常见，因为很多外部模块天然就通过串口接入：
所以 UART 的项目定位通常是：
2. 企业里真正做 UART，不是“会配置波特率”就够了
UART 最难的地方通常不是初始化，而是：
记住一句
串口最麻烦的通常不是硬件，而是协议边界。
3. UART 项目里最常见的协议模型
固定长度帧
优点：简单 缺点：扩展性差
帧头 + 长度 + 数据 + 校验
最常见，也最推荐。
帧头 + 帧尾
适合 ASCII 协议，二进制协议慎用。
行协议
比如以 \r\n 结尾，常见于 AT 指令。
4. UART 模块企业级封装建议
uart_port
负责打开设备、termios 配置、读写接口。
uart_rx_buffer
负责接收缓冲管理，通常用环形缓冲区。
uart_protocol_parser
负责按协议找帧头、长度、校验。
uart_session
负责一次请求-响应式事务，如发送命令并等待应答。
uart_monitor
负责统计：
5. UART 项目里为什么常用线程或事件驱动
因为真实项目里串口通信通常不是“一次发，一次收”这么简单，而是：
所以常见两种模式：
模式一：独立接收线程
优点：简单直接 缺点：多线程同步要处理好
模式二：select / poll / epoll 事件驱动
优点：适合多 fd 统一管理 缺点：代码复杂度略高
6. UART 项目里最常见的坑
只按字符串读写
实际很多协议是二进制，不应该用字符串思维。
误以为 write() 返回就等于对方收到
其实通常只代表数据进了内核缓冲区。
不做协议状态机
容易被半包、噪声、错位数据打乱。
不做超时
系统容易一直挂死等数据。
不做校验
线上环境一旦有干扰很难定位。
7. UART 面试项目表达模板
“在串口项目中，我通常会把串口设备访问和协议解析分层。底层通过 termios 配置波特率、校验位和阻塞行为；中间层使用环形缓冲区和状态机完成字节流到完整帧的转换；上层业务按命令字处理请求与应答。为提升稳定性，我会加入超时、重试、校验、日志和异常统计。”
8. UART 高频面试题
问：串口为什么容易出粘包问题？
答：严格说 UART 更常见的是字节流边界丢失，而不是 TCP 意义上的粘包。根本原因是应用层没有做明确帧边界设计。
问：为什么要用状态机解析串口协议？
答：因为串口数据是连续到来的，可能有半包、错位、噪声，状态机更适合持续解析和恢复同步。
问：termios 最重要的配置点有哪些？
答：波特率、数据位、校验位、停止位、流控、原始模式、VMIN 和 VTIME。
五、RS485 / RS232 企业级知识点
1. 在企业里，RS232 和 RS485 很少单独被提起
它们几乎总是和下面这些组合在一起：
所以：
RS232 / RS485 是串口的电气层延伸，不是应用协议本身。
2. 企业为什么更重视 RS485
因为工业现场的关键词是：
RS485 刚好解决：
所以它在工业场景非常普遍。
3. RS485 项目中的关键不是“发”，而是“总线管理”
企业级 RS485 通信要重点理解：
谁是主站
谁是从站
谁主动轮询
总线空闲时谁可以说话
半双工方向怎么切
一次事务何时算结束
这就是为什么很多 RS485 项目天然是主从轮询式，而不是大家乱发。
4. RS485 + Modbus RTU 是面试重点
为什么？
因为它是工业项目中的高频真实组合。
主站做什么
从站做什么
5. 企业级 RS485 模块设计建议
serial_phy
负责底层串口和方向控制。
rtu_framer
负责 Modbus RTU 帧组包和 CRC16。
master_scheduler
负责轮询多个从站、调度请求顺序。
slave_state_cache
缓存从站最新数据，便于业务层快速取值。
fault_manager
记录：
6. RS485 项目里最重要的工程思维
不要让一个坏从站拖垮整个总线
所以必须有：
主站轮询要有节奏
不能无脑满速轮询，否则：
方向切换一定要严谨
否则会出现“偶发帧尾丢失”这类非常难查的问题。
7. RS232 项目典型场景
RS232 在现代项目里多见于：
你的面试表达要偏“兼容性”和“设备集成”：
“项目中使用 RS232 主要是对接已有设备生态，其本质仍然是串口应用，只是在电气层和 TTL/RS485 不同，因此在软件层重点仍是串口参数配置、协议解析和错误处理。”
8. 高频面试题
问：RS232 和 RS485 的核心区别是什么？
答：RS232 是单端、点对点；RS485 是差分、适合长距离和多节点总线。
问：为什么 RS485 常与 Modbus RTU 绑定出现？
答：因为 RS485 只定义电气层，而 Modbus RTU 提供统一工业协议格式。
问：主站轮询为什么要有限速和隔离策略？
答：为了避免慢设备或故障设备拖垮整条总线，提高系统整体可用性。
六、USB 企业级知识点
1. USB 在企业项目中的真实角色
USB 在 Linux 项目中常见角色包括：
所以企业里看 USB，不只是“协议”，更是：
2. USB 项目的关键理解：枚举和绑定
插上设备后，系统做的事大致是：
所以真正做 Linux USB 项目时，经常关注的是：
3. 企业项目里的 USB 应用开发，常见不是直接写 libusb
常见方式是：
摄像头
走 V4L2
USB 串口
走 tty
Wi-Fi
走 netdev
U 盘
走文件系统
所以真正写 libusb 的场景通常是：
4. USB 项目里的高频工程问题
热插拔
设备随时可能被拔掉，所以应用不能假设它永远在线。
重新枚举
重新插入后路径可能变化，如 /dev/ttyUSB0 变 /dev/ttyUSB1。
权限与规则
需要考虑 udev 规则、权限、持久命名。
带宽与供电
特别是摄像头、多设备 Hub 下容易遇到。
5. 企业级 USB 模块设计建议
usb_detector
负责发现设备插拔和识别设备类型。
usb_binder
负责根据设备特征决定绑定策略。
device_abstraction_adapter
把不同 USB 设备统一封装成业务侧可调用的抽象。
hotplug_manager
负责掉线恢复、资源释放和重新打开。
6. USB 面试项目表达模板
“在 Linux 项目中处理 USB 设备时，我更关注设备枚举、驱动绑定和热插拔管理。对于标准类设备，我优先使用内核已暴露的高层抽象，例如视频设备、串口或网卡；对于定制设备，则基于 libusb 做用户态访问。同时会考虑热插拔、路径变化、权限和异常恢复。”
7. 高频面试题
问：为什么很多 USB 项目不直接写 libusb？
答：因为大量 USB 设备已有成熟类驱动，应用直接使用高层抽象更稳定、更简洁。
问：USB 项目为什么要特别重视热插拔？
答：因为设备可能随时掉线或重连，系统必须处理资源释放、重新识别和恢复流程。
问：VID/PID 和 class driver 各自起什么作用？
答：VID/PID 帮助识别设备具体型号，class driver 用于匹配一类标准设备的通用驱动。
七、I2C 企业级知识点
1. I2C 在企业项目里的典型角色
I2C 在项目中通常不是高速数据通道，而是：
常见设备：
2. 企业级理解 I2C：重点是寄存器模型
I2C 项目绝大多数时候都在做这件事：
读某个寄存器 / 写某个寄存器
所以项目里应该把设备抽象成：
这比单纯 i2cget 更接近真实项目。
3. I2C 模块的企业级设计建议
i2c_bus
负责打开总线和设备选择。
i2c_regmap
负责通用寄存器读写封装。
device_driver_in_userspace
负责把某个具体 I2C 器件抽象成设备对象，如 rtc_device、temp_sensor。
sensor_manager
负责周期采集、滤波、异常值处理和缓存。
4. I2C 项目常见痛点
地址混淆
7 位地址和 8 位地址文档写法不同，特别容易错。
总线共享冲突
多个设备在同一总线上，应用层要避免乱序访问和并发混乱。
ACK 丢失
原因可能非常多：
启动时序问题
某些设备上电后要延时才能访问。
5. 企业里 I2C 应用开发必须考虑的东西
统一寄存器访问接口
不要业务代码里到处散落寄存器地址常量。
重试机制
I2C 偶发失败并不少见，适当重试很常见。
错误码与日志
日志至少应包含：
线程安全
如果多线程访问同一 I2C 总线，必须有同步机制。
6. I2C 面试项目表达模板
“在 I2C 项目中，我一般先把总线访问和具体器件驱动拆开。底层提供统一的寄存器读写接口，上层按器件手册封装寄存器表和初始化流程。考虑到 I2C 设备经常是低速寄存器型设备，我会重点做地址管理、重试、日志、启动时序和并发访问控制。”
7. 高频面试题
问：为什么 I2C 很适合传感器？
答：因为它线少、成本低、适合低速寄存器访问，非常适合配置型和小数据量器件。
问：I2C 项目为什么要做 regmap 思维？
答：因为很多 I2C 设备本质上都是寄存器模型，抽象成寄存器访问层有利于可维护性和复用。
问：为什么 I2C 容易在项目里出现偶发故障？
答：因为共享总线、上电时序、上拉、电气质量和器件稳定性都会影响 ACK 与波形。
八、SPI 企业级知识点
1. SPI 在企业项目里的典型角色
SPI 在企业项目中常用于：
它的定位通常是：
2. 企业级理解 SPI：重点不只是“快”，而是“确定性强”
SPI 的工程优势：
所以 SPI 很适合：
3. SPI 项目的关键设计点
片选管理
多从设备时，片选是关键资源。
时序参数
不同器件可能需要不同：
事务封装
SPI 项目里通常不是“发几个字节”，而是“执行一次完整事务”。
比如：
4. SPI 模块企业级设计建议
spi_bus
负责设备打开和基础参数配置。
spi_transaction
封装一次 SPI 事务。
spi_device_ops
针对具体器件定义命令集和访问方法。
flash_manager / adc_manager / display_manager
具体业务设备管理器。
5. SPI 项目常见问题
模式不匹配
读出来全错或偏一位。
时钟过高
实验室能跑，现场不稳。
CS 时序不对
有些设备对 CS 前后延时很敏感。
事务边界不清晰
命令、地址、数据阶段拼接错误。
6. 为什么企业里经常不用 spidev 直接做最终方案
因为很多 SPI 设备最终会有专用内核驱动，例如：
用户态直接走 spidev 更适合：
7. SPI 面试项目表达模板
“SPI 项目中我会把关注点放在事务边界和设备时序要求上。底层负责模式、字宽、频率和片选控制，上层围绕具体器件命令集封装事务，例如读 ID、读写寄存器、批量传输等。对稳定性要求较高时，还会重点验证模式匹配、时钟裕量和 CS 时序。”
8. 高频面试题
问：为什么 SPI 常比 I2C 更适合高速场景？
答：因为 SPI 协议更轻量，没有地址仲裁和 ACK 开销，且通常是同步全双工设计。
问：SPI 项目里最容易出错的地方是什么？
答：模式、时钟、片选时序和事务边界。
问：什么时候不建议直接用 spidev？
答：当设备复杂、性能要求高或已有成熟内核驱动时，更适合走内核驱动方案。
九、把六个通信外设，真正串成“企业项目能力”
例如一个企业级设备网关项目，可能是这样：
然后 Linux 应用层做：
这时你在面试里就可以说：
“我不是单点地看某个接口，而是把不同接口统一纳入设备访问层、协议层和业务层，通过统一的错误码、日志和监控机制实现可维护系统。”
十、面试官最喜欢追问的“项目级问题”
1. 如何做超时和重试？
答题要点：
2. 如何保证通信模块可维护？
答题要点：
3. 如何做并发访问控制？
答题要点：
4. 如何排查现场偶发问题？
答题要点：
5. 如何做异常隔离？
答题要点：
