第二章 嵌入式系统基础与选型

各位同学，咱们今天聊点实在的。做CT影像链，第一步不是写代码，而是选芯片。选错了，后面全白干。我见过太多项目，方案看着漂亮，一上硬件就翻车。说白了，嵌入式选型就是个「匹配游戏」——你得知道CT系统要什么，再去找能给的处理器。

2.1 嵌入式处理器分类：MCU、MPU、DSP、FPGA

先捋清楚这四类处理器的区别。很多人混着用，其实它们各有脾气。

2.1.1 MCU（微控制器）

MCU就是「小全能」。集成了CPU、内存、外设接口，一片搞定。我习惯用它做控制类任务，比如CT机里的电机驱动、温度监控。优点是功耗低、成本低、开发简单。缺点是算力有限，跑不了复杂算法。

• 典型代表：STM32、NXP i.MX RT系列
• CT中的角色：传感器数据采集、运动控制、电源管理
• 避坑指南：我曾经在一个项目中用MCU做实时滤波，结果采样率一高，CPU直接跑满。后来才明白，MCU不适合做密集计算。

2.1.2 MPU（微处理器）

MPU是「大管家」。它本身不带太多外设，需要外接DDR、Flash。算力强，能跑Linux。CT系统的上位机、图像重建前的预处理，我一般用MPU。你想想看，CT一秒钟扫几百张投影图，数据量多大？MCU根本扛不住。

• 典型代表：ARM Cortex-A系列、Intel x86
• CT中的角色：数据缓存、网络通信、人机交互
• 个人经验：我记得有一次选型，为了省成本用了低端MPU，结果图像传输带宽不够，导致重建延迟。嗯，该花的钱不能省。

2.1.3 DSP（数字信号处理器）

DSP是「数学狂人」。它的架构专门为乘加运算优化，做滤波、FFT、卷积特别快。CT影像链里，原始数据的预处理——比如去噪、校正——我习惯交给DSP。为什么？因为CT数据是典型的信号流，DSP处理起来如鱼得水。

• 典型代表：TI C6000系列、ADI SHARC系列
• CT中的角色：原始数据滤波、坏像素校正、增益校准
• 注意：DSP编程门槛高，调试麻烦。我建议团队里至少要有一个人懂汇编优化。

2.1.4 FPGA（现场可编程门阵列）

FPGA是「硬件加速器」。它用逻辑门实现算法，延迟极低、并行度极高。CT系统里，最吃算力的部分——比如反投影重建、高速数据接口——我几乎只用FPGA。为什么？因为CT探测器一秒钟产生几Gbps的数据，CPU根本来不及处理。

• 典型代表：Xilinx Kintex/Zynq系列、Intel Cyclone系列
• CT中的角色：高速数据采集、实时重建加速、接口桥接
• 避坑指南：我曾经在FPGA上实现了一个复杂的重建算法，结果时序跑不过。后来发现是代码风格太「软件化」，没有考虑硬件并行性。FPGA编程，思维要转个弯。

2.2 CT系统中嵌入式平台选型依据

选平台，不能光看参数表。你得问自己三个问题：实时性够不够？功耗压得住吗？算力匹配吗？

2.2.1 实时性

CT系统对实时性要求极高。探测器一曝光，数据就得在微秒级内被处理。如果延迟大了，图像就会产生伪影。我个人习惯把任务分成硬实时和软实时：

• 硬实时：探测器数据读取、电机同步控制。必须用FPGA或RTOS保证确定性延迟。
• 软实时：图像重建、网络传输。可以用MPU+Linux，但要做好优先级调度。

你想想看，CT扫描时，球管在转，床在动，探测器在采数据。任何一个环节延迟，都会导致图像错位。嗯，这里要注意：实时性不是「快」，而是「可预测」。

2.2.2 功耗

CT机不是手机，但功耗依然关键。尤其是移动CT或术中CT，电池供电，功耗直接决定续航。我建议从三个维度评估：

• 峰值功耗：满负荷运行时，散热能不能扛住？
• 待机功耗：CT不扫描时，系统能不能进入低功耗模式？
• 能效比：每瓦能提供多少算力？FPGA通常比CPU高一个数量级。

2.2.3 算力

算力不是越高越好。够用就行，留点余量。CT影像链的算力需求，我习惯这样估算：

• 数据采集：探测器通道数 × 采样率 × 位宽。比如1024通道、1kHz采样、16bit，就是16Mbps。
• 预处理：每个通道需要做滤波、校正，算力需求大约是数据率的10倍。
• 重建：这是大头。一个512×512的图像，用FDK算法重建，大约需要10^9次乘加运算。

说白了，算力选型就是「算清楚账」。我建议先做原型验证，用实际数据跑一遍，再定方案。

2.3 主流平台对比

市面上平台很多，但CT领域常用的就那几款。我挑三个典型代表说说。

2.3.1 ARM Cortex-A/R/M系列

系列	定位	CT中的角色	我的评价
Cortex-M	MCU，低功耗	传感器控制、电机驱动	稳定可靠，开发简单
Cortex-R	实时MPU，硬实时	数据采集、实时控制	延迟低，但生态不如A系列
Cortex-A	应用MPU，高性能	图像处理、网络通信	生态丰富，但功耗高

我个人习惯：控制用M系列，实时采集用R系列，上层应用用A系列。各取所长。

2.3.2 Xilinx Zynq

Zynq是「ARM+FPGA」的异构方案。我特别喜欢它的一点：ARM跑Linux做调度，FPGA做硬件加速。CT系统里，我常用Zynq做数据采集和预处理。举个例子：

// Zynq上FPGA部分实现高速数据采集
// 探测器数据通过LVDS接口输入
// FPGA做串并转换、坏像素校正
// 然后通过AXI总线传给ARM处理

// 伪代码示意
always @(posedge clk) begin
  if (data_valid) begin
    // 串并转换
    parallel_data <= {serial_data, parallel_data[7:1]};
    // 坏像素校正
    if (bad_pixel[channel])
      corrected_data <= interpolate(neighbor_data);
    else
      corrected_data <= parallel_data;
  end
end

2.3.3 TI TDA4VM

TDA4VM是TI针对ADAS和机器人推出的平台，但用在CT上也挺香。它集成了ARM Cortex-A72、Cortex-R5F、DSP和加速器。我习惯用它做中低端CT的主控：

• A72：跑Linux，做人机交互和网络通信。
• R5F：做实时控制，比如电机同步。
• DSP：做图像预处理，比如滤波和校正。
• 加速器：做简单的重建加速。

说白了，TDA4VM就是「一芯多能」。但要注意，它的算力上限不如Zynq+独立FPGA。如果CT要求高分辨率重建，还是得上FPGA。

好了，这一章就聊到这儿。下一章咱们讲CT影像链的硬件架构设计，到时候会用到今天讲的这些选型知识。记住，选型不是终点，是起点。