芯耀
与非AI
151
工程师实战分享｜基于米尔电子 T113i 核心板
这次做电能质量监测设备时，我们没有让一颗处理器把采样、控制、显示、存储和网络全部包下来，而是采用了GF32H737 + 米尔 T113i 核心板的双处理器架构。前端 MCU 负责实时采集和控制，T113i 运行 Tina Linux，负责界面、存储、网络和系统管理。
从 BOM 上看，多一颗处理器、多一套通信，似乎让系统变复杂了。但实际把项目做完一轮之后，我反而觉得，对于功能开始变多的电力采集设备来说，双处理器不是为了堆料，而是为了把实时性和复杂性分开。
单MCU方案为什么一开始很诱人？
刚开始做采集设备时，单 MCU 方案确实很有吸引力。硬件简单、成本直观，软件也只有一套工程。ADC、DI/DO、通信协议甚至简单界面都可以往里面放。
如果产品功能边界比较稳定，这种方案完全合理。尤其是只做采样、简单计算和少量串口/以太网通信的设备，没必要为了“看起来高级”而上 Linux。
问题在于，电力监测设备后面经常会继续长功能：本地触摸屏、文件系统、历史数据、双网口、PTP、远程升级、Web 或平台通信、更多协议。功能一多，原来清晰的 MCU 工程就很容易变成一个什么都要管的大系统。
真正难的是实时任务和复杂任务互相影响
采样和控制的要求非常明确：节拍要稳定、异常要可控、响应时间要确定。UI 和网络则完全是另一种工作模式：界面会刷新，文件会读写，网络会重传，协议栈也可能出现不可预测的阻塞。
如果所有任务都在同一颗 MCU 上跑，就需要不断做优先级、缓存、队列和异常隔离。理论上可以设计得很好，但系统越复杂，验证成本越高。
我们最后选择把两类任务拆开：GF32H737 只守住实时采集和 DI/DO 控制，T113i 负责所有“复杂但不要求微秒级确定性”的事情。这样每一侧的软件目标都更单纯。
我们的职责边界怎么划？
在这个项目里，GF32H737 负责 ADC 采样、电压电流数据整理、DI 光耦输入和 4 路 DO 继电器控制。T113i 则负责 3.5 英寸 RGB 触控界面、TF 卡存储、千兆网络、PTP 时钟同步、USB Host 扩展百兆网口，以及上层数据处理和通信。
两边通过 SPI 连接，而且我们进一步用双 SPI把持续采集数据和参数/控制命令拆开。数据通道追求连续性，控制通道追求清晰和响应，两套业务互相不抢同一条通信状态机。
这样的分工有一个很实际的好处：后面改 UI、加协议、换上传方式时，主要动 Linux 侧；底层采样链路可以尽量不改。对电力产品这种需要长期维护和迭代的设备来说，这种稳定边界非常重要。
Linux主控不是替代MCU，而是在补它不擅长的部分
我觉得工程上很容易陷入一个误区：要么觉得 MCU 什么都能做，所以 Linux 没必要；要么觉得上了 Linux，MCU 就应该被取消。实际上两者擅长的事情并不一样。
MCU 的优势是启动快、确定性强、控制直接，非常适合现场采样和控制。Linux 的优势是文件系统、网络协议栈、驱动生态、图形界面和应用管理成熟，特别适合承载复杂通信和人机交互。
我们这次用 T113i，不是为了让它替代 GF32H737 做 ADC，而是让它把千兆网口、PTP、RGB 屏、TF 卡、USB 网口这些工作接过去。让每颗处理器干自己擅长的事情，比单纯追求“只用一颗芯片”更符合项目效率。
双处理器会不会增加故障点？
会增加接口，也会增加协议，这是客观存在的代价。所以双处理器架构的关键不是“多一颗芯片”，而是边界必须足够清晰。
首先，采集 MCU 应该在 Linux 异常、重启甚至暂时离线时，仍然能够保持基本采样和安全控制逻辑。其次，MCU 与 Linux 之间的协议要尽量简单，明确数据帧、控制帧、超时和恢复机制。最后，两边的软件版本要有清晰的兼容策略。
只要这几个问题设计清楚，增加的一条处理器间通信链路，往往比把所有复杂任务塞进一个系统里更容易测试和维护。
为什么这种架构特别适合电力采集设备？
电力采集类产品往往同时具备三种特征。第一，底层采样和控制要求稳定；第二，网络、存储和界面需求越来越多；第三，设备生命周期长，后续功能迭代频繁。
这三个条件放在一起，就很适合把实时域和应用域分开。MCU 可以作为一个稳定的采集控制单元，Linux 核心板则作为一个可持续演进的应用平台。后面即使增加协议、远程运维、日志分析或者更复杂的 HMI，也不必反复改动底层采集。
T113i在这个架构里承担了什么？
我们使用的米尔 T113i 核心板，在这个项目里承担的并不是某个单一功能，而是把多个应用侧需求统一接起来：双 SPI、RGB、SDMMC、RGMII、USB Host，以及 Tina Linux 下的网络和设备管理。
千兆网络通过 RTL8211FS 实现，并进一步启用了 PTP；第二路百兆网口通过 USB 扩展；本地用 RGB 触摸屏做人机交互，TF 卡做数据存储。这样 T113i 更像是整机的“系统管理和通信中枢”，而不是传统意义上的采集控制器。
这也是我觉得核心板选型时容易被忽略的一点：你选的不是一颗CPU，而是在选一个能不能承接后续产品复杂度的平台。
什么情况下没必要上双处理器？
如果设备只做几路采样、一个串口协议，没有复杂界面、文件系统和多网络需求，那么一颗合适的 MCU 往往就是更优解。双处理器并不是通用答案。
但如果项目已经明确需要触摸屏、本地存储、多网口、PTP、远程通信，而且这些需求后面还会继续增加，我会建议尽早评估“MCU + Linux”的方式。越早把系统边界设计清楚，越不容易在后期因为一颗 MCU 上任务太多而推倒重来。
做完项目后的一个结论
这次项目让我比较明确的一点是：架构设计的目标不是让硬件最少，而是让系统长期可控。
GF32H737 把实时采集和控制守住，T113i 把 Linux 侧的显示、存储、网络和 PTP 接起来，中间用清晰的 SPI 通信协议连接。对我们这套电能质量监测设备来说，这种分工让调试和后续扩展都更直接。
如果大家正在做电能质量监测、电力采集、工业网关或者类似的边缘设备，可以先把需求分成两栏：哪些事情必须实时确定，哪些事情会不断增加复杂度。很多时候，这两栏本身就会告诉你：这个项目到底应该坚持单 MCU，还是更适合采用 MCU + Linux 核心板的双处理器架构。
