工业控制

前言 如果你在工业自动化领域做过嵌入式开发，应该听过这样的抱怨：「Linux 什么都好，就是不够实时」。这句话背后藏着一个非常现实的困境——Linux 生态太强大了，驱动、网络、文件系统、调试工具应有尽有，但它天生就不是为了微秒级确定性设计的。当你的运动控制器需要在 100 µs 内响应编码器中断、当你的机器人关节需要每 1ms 完成一次 PID 闭环计算时，主线 Linux 的调度抖动可能让整个系统失控。 于是就有了三条路：第一条路是彻底放弃 Linux，改用纯 RTOS——VxWorks、QNX、或者 FreeRTOS，但代价是你得放弃整个 Linux 生态；第二条路是 PREEMPT_RT——给 Linux 内核打上实时补丁，这是我们之前详细讨论过的方案；第三条路就是今天的主角：Xenomai——它不走「改造 Linux」的路线，而是走「与 Linux 共存」的双内核架构路线。 我第一次接触 Xenomai 是在一个六轴机械臂项目上。当时客户要求关节控制周期 1ms，最大抖动不能超过 50 µs。我们先用了 PREEMPT_RT，在隔离 CPU、关中断、线程优先级拉满的情况下，最坏情况抖动还是冲到了 120 µs，偶尔还会有 200 µs 的尖刺。后来换成 Xenomai 3 Cobalt 内核，同样的硬件，最坏情况抖动稳定在 15 µs 以内，而且应用层的代码改动量不到 20%。 写这篇文章的目的，不是要争论 Xenomai 和 PREEMPT_RT 谁更好——它们有各自的适用场景。我想做的是把 Xenomai 的技术本质讲清楚，从双内核架构的设计哲学讲起，到实际的环境搭建、应用开发、延迟测量与调优，最后给出我在多个工业项目中验证过的最佳实践。 一、为什么需要 Xenomai？PREEMPT_RT 的极限在哪里？ 在深入 Xenomai 之前，我们得先搞清楚一个问题：既然 PREEMPT_RT 能让 Linux 变成实时系统，为什么还需要 Xenomai？ 1.1 PREEMPT_RT 的本质：把 Linux 尽量改得「更实时」 PREEMPT_RT 的核心思路是最大化 Linux 内核的可抢占性：...

前言 如果你做过几年嵌入式开发，迟早会撞到 CAN 总线这堵墙。它在汽车电子里几乎是默认标配，在工业控制、轨道交通、电梯、医疗设备、甚至是无人机机臂内部通信里，到处都有它的身影。我第一次和 CAN 打交道是在一个新能源 BMS 项目上——电池包要把每串单体电压、温度、SOC 上报给整车控制器（VCU），现场没有以太网，没有 RS485，PCB 上焊得整整齐齐就两根线：CAN_H 和 CAN_L。当时我天真地以为，无非就是另一个 UART，能收能发就完事。结果第一周就被仲裁机制、位时序、错误帧、Bus-Off 教育得明明白白。 写这篇文章的初衷，是想把这些年踩过的坑、读过的手册、调过的示波器波形，整理成一份能让后来人少走弯路的实战指南。我不会停留在「CAN 是一种串行通信总线」这种百度百科式的介绍，而是从协议本质讲起，一路下沉到 STM32 的 bxCAN 外设寄存器层，再上升到工程代码里那些「为什么我的滤波器配了却收不到包」的具体问题。 CAN 总线（Controller Area Network）由德国博世公司在 1986 年推出，最初的目标是给汽车上日益增多的电子控制单元（ECU）之间提供一条可靠、低成本的通信骨干。在 CAN 出现之前，每两个 ECU 之间都要拉一根专线，一辆中高端车里光线束就能有上百公斤重。CAN 把所有节点挂在同一条双绞线上，靠协议本身去解决冲突和优先级问题，线束重量瞬间砍掉一大半。这个设计哲学在今天看来依然非常先进——它把网络的复杂性下沉到了协议层，让物理层简单到极致。 放到 2026 年的视角，CAN 当然不算「新技术」。CAN FD（Flexible Data-rate）已经成为汽车主流，传输速率突破 5 Mbps，数据载荷扩展到 64 字节；CAN XL 已经在路上，可以飙到 10 Mbps、2048 字节负载；车载以太网（Automotive Ethernet）也在逐步蚕食骨干网的份额。但即便如此，传统 CAN 2.0B 在嵌入式工程里依然不可替代。原因很简单：它便宜、皮实、抗干扰能力恐怖、协议成熟到几乎不会出 bug，而且几乎每一颗工业级 MCU 都自带 CAN 控制器。 一、为什么是 CAN？四个无法替代的设计优势 要理解 CAN 为什么能屹立不倒近四十年，必须先看清它的核心设计。我把它总结成四点： 第一，多主架构（Multi-master）。 总线上没有「主机」和「从机」的区分，任何节点在总线空闲时都可以主动发起传输。这跟 SPI 那种「主机点名才能说话」的模式完全不同。在汽车里，发动机 ECU 和刹车 ECU 是平等的两个节点，谁需要谁就说。这种架构的好处是没有单点故障——主机挂了整条线就废这种事不会发生。 第二，非破坏性逐位仲裁（Non-destructive bitwise arbitration）。 这是 CAN 协议的精髓所在，也是最容易被新手忽略的点。当多个节点同时抢占总线时，CAN 通过比较报文 ID 的每一位来决定谁优先发送，而且——胜出的那一帧不会被损坏。技术上，CAN 总线物理层定义了「显性位」（Dominant，逻辑 0）和「隐性位」（Recessive，逻辑 1）。在线与（wired-AND）逻辑下，只要有一个节点输出 0，整条总线就是 0。每个节点在发送时会同时监听总线状态，一旦发现自己发送的是 1 但总线上是 0，立刻退出仲裁、转为接收方。ID 数值越小（高位 0 越多）的报文，优先级越高。...