摘要：当一个系统同时具备高速 USB、多节点 CAN-FD 和专属的一对一 RS-485 链路时，最愚蠢的做法就是为每一个接口写一套独立的业务逻辑。物理介质是多变的，但数据的本质是统一的。本文将解构 C++ 在软硬协同中的“抽象”力量，通过提取共性构建 IChannel 接口，运用策略模式将协议解析与物理传输解耦，带你打造一套无论在 STM32 裸机还是 Qt 上位机都能完美复用的现代化通信架构。
一、 意大利面条代码的诞生：被物理接口绑架的业务
很多项目的陨落，是从底层代码对业务逻辑的“物理入侵”开始的。
假设我们需要向外部设备发送一条电机控制指令，初学者的代码通常长这样：
// 灾难性的多路分发逻辑
void SendMotorCommand(uint8_t target_type, uint8_t* data, size_t len) {
if (target_type == TYPE_USB) {
USB_CDC_Transmit(data, len);
} else if (target_type == TYPE_CAN_FD) {
CAN_FD_SendFrame(0x123, data, len); // 还要硬编码 ID
} else if (target_type == TYPE_RS485) {
RS485_SetTxMode();
UART_Transmit(data, len);
RS485_SetRxMode();
}
}
三大原罪：
开闭原则 (OCP) 彻底沦丧：明天硬件改版，加了一个以太网口，你必须打开这个庞大的 if-else 函数，小心翼翼地加上第四个分支。
协议与传输死锁：这段代码既管“发什么数据”，又管“怎么控制硬件管脚”。
无法进行单元测试：你在 PC 上想测这段逻辑，因为没有底层的 UART_Transmit 函数，代码连编译都编不过。
二、 拔高维度的上帝视角：提取 IChannel 接口
在 C++ 的世界里，解决耦合的终极武器是 多态 (Polymorphism)。 无论底层是 12Mbps 的 USB，还是拥有仲裁机制的 CAN-FD，抑或是简单粗暴的、绝对点对点的单一 RS-485 链路，它们在更高维度的逻辑看来，只有两个最基本的动作：读 (Read) 和 写 (Write)。
我们必须定义一个神圣的契约（纯虚基类）：
// 通信通道的终极抽象
class IChannel {
public:
virtual ~IChannel() = default;
// 硬件初始化
virtual bool open() = 0;
// 关闭硬件
virtual void close() = 0;
// 发送底层字节流
virtual int write(const uint8_t* buffer, size_t size) = 0;
// 注册异步接收的回调函数（观察者模式的核心）
using RxCallback = std::function<void(const uint8_t*, size_t)>;
virtual void setRxCallback(RxCallback cb) = 0;
};
哲学内涵： 有了这个 IChannel，你的业务解析类（比如 ProtocolParser）只需要持有一个 IChannel* 的指针。业务层永远不知道，也不需要知道数据是究竟是从 USB 飘进来的，还是从 RS-485 爬进来的。
三、 派生类的自我修养：封装物理的丑陋
现在，我们可以让不同的硬件驱动去实现这个契约。物理层的脏活累活，全被锁死在了这些具体的实现类里。
1. 点对点 RS-485 通道实现
RS-485 半双工通信最大的痛点是收发使能引脚（DE/RE）的切换。我们将这个逻辑死死封印在 Rs485Channel 中：
class Rs485Channel : public IChannel {
private:
RxCallback m_rxCallback;
// 这是一个单一的 485 链路，不需要处理复杂的总线寻址
public:
int write(const uint8_t* buffer, size_t size) override {
HAL_GPIO_WritePin(RS485_DIR_PORT, RS485_DIR_PIN, GPIO_PIN_SET); // 切换为发送
HAL_UART_Transmit(&huart2, buffer, size, 100);
HAL_GPIO_WritePin(RS485_DIR_PORT, RS485_DIR_PIN, GPIO_PIN_RESET); // 切回接收
return size;
}
// …
};
2. CAN-FD 通道实现
CAN-FD 不像串口那样是连续字节流，它是以“帧 (Frame)”为单位的。在 CanFdChannel 的 write 中，我们需要做碎片化处理：将长达几十字节的数据，自动切分为 64 字节的 CAN-FD 数据场。 对上层而言，依然只是调用了一次 write，它根本感知不到底层的分包动作。
四、 解耦的狂欢：依赖注入 (Dependency Injection)
现在，让我们重写第一节中那个灾难性的电机控制代码。 我们将使用现代软件架构中极为推崇的 依赖注入。
class MotorController {
private:
IChannel* m_channel; // 我只依赖抽象，不依赖具体硬件！
public:
// 构造函数注入：你要我用什么通道，我就用什么通道
MotorController(IChannel* channel) : m_channel(channel) {
// 绑定接收中断的回调
m_channel->setRxCallback([this](const uint8_t* data, size_t len) {
this->onDataReceived(data, len);
});
}
void sendCommand(const MotorCmd& cmd) {
uint8_t buffer[16];
size_t len = SerializeCommand(cmd, buffer); // 序列化
m_channel->write(buffer, len); // 盲发！不管底层是谁
}
void onDataReceived(const uint8_t* data, size_t len) {
// 处理电机反馈…
}
};
见证奇迹的时刻（工厂模式实例化）：
在系统 main.cpp 的初始化阶段：
// 如果客户买的是 USB 版本的设备
UsbCdcChannel usbChannel;
MotorController motor1(&usbChannel);
// 如果内部需要控制一个专属的 RS-485 传感器
Rs485Channel rs485Channel;
MotorController motor2(&rs485Channel);
一行核心业务代码都不用改！ 我们只是在启动时，把不同的硬件“管道”插到了同一个逻辑“引擎”上。
五、 跨域复用：Qt 上位机与 STM32 的双向奔赴
这套 DAL (设备抽象层) 架构最恐怖的威力在于它的 跨平台复用性。
这个 IChannel 接口不仅可以跑在 STM32 上。如果你在开发配套的 Qt 上位机软件，你可以原封不动地把 IChannel.h 和 MotorController.cpp 拷贝到 Qt 工程里。 在 Qt 里，你只需要派生一个 QtSerialChannel（封装 QSerialPort）或者 QtCanChannel，然后传给 MotorController。
结果： 上位机和下位机共享了完全一致的 C++ 面向对象业务逻辑体系。这不仅杜绝了“两套代码逻辑不一致”的 Bug，更让整个团队的思维模型实现了高度统一。
六、 结语：抽象是软件工程师的终极武器
很多做底层硬件出身的工程师，潜意识里觉得 C++ 的虚函数表（vtable）和多态会带来性能开销，从而死抱住 C 语言的函数指针不放。 但实际上，在动辄几百兆主频的现代单片机（如 STM32H7 或高级 M4）面前，一次虚函数调用的几个时钟周期开销完全可以忽略不计，但它换来的，是工程可维护性的质的飞跃。
从繁杂的引脚电平、中断标志位，到 USB 端点、CAN 仲裁段，再到统一干净的 write() 和 read()。 这就是架构的魅力：用一层薄薄的 C++ 虚基类，将物理世界的混乱与无序，永远隔绝在逻辑的圣殿之外。
