嵌入式平台基础：主流平台对比与选型

做SLAM算法移植到嵌入式平台，第一关就是选硬件。我见过不少团队，算法在PC上跑得飞起，一上嵌入式平台就卡成PPT。说白了，嵌入式平台没有「万能药」，ARM、DSP、FPGA、GPU各有各的脾气。

主流嵌入式平台对比

先看一张我整理的对比表，帮你快速建立全局认知：

平台	核心优势	典型功耗	SLAM适用场景	我踩过的坑
ARM Cortex-A系列	生态成熟，Linux支持好	2-15W	前端视觉里程计、后端优化	内存带宽经常是瓶颈
DSP	定点/浮点运算效率极高	1-5W	特征提取、矩阵运算	调试起来让人抓狂
FPGA	流水线并行，延迟极低	3-10W	图像预处理、前端加速	开发周期是ARM的3倍
GPU（嵌入式）	大规模并行计算	10-30W	深度学习特征、稠密重建	功耗和散热是硬伤

ARM平台：SLAM的主力军

我个人习惯把ARM Cortex-A系列作为SLAM算法的基础平台。为什么？因为Linux生态太香了。ROS、OpenCV、Eigen这些库，apt-get就能装，省去大量移植时间。

但要注意，ARM不是万能的。我在项目中遇到过一个问题：用树莓派4跑ORB-SLAM2，前端特征提取只有5fps。后来发现瓶颈不在CPU算力，而在内存带宽——ARM的L2 cache太小，频繁的像素访问把总线塞满了。

DSP：被低估的加速利器

很多人觉得DSP过时了，其实不然。TI的C66x系列、CEVA的XM系列，在特征提取和描述子计算上，效率能甩ARM几条街。

我记得有一次做视觉惯性里程计，需要在IMU数据到达后10μs内完成姿态预测。ARM上跑要35μs，换成DSP的定点实现，硬生生压到了8μs。嗯，这里要注意：DSP编程要习惯用定点数，浮点虽然支持但效率会打折扣。

FPGA：硬实时的不二之选

如果你做的是工业级SLAM，对延迟有硬性要求（比如无人机避障），FPGA几乎是唯一选择。为什么？因为FPGA的流水线架构可以做到「像素进来，特征出去」——延迟只有几微秒。

但代价也很明显：开发周期长。用HLS（高层次综合）写一个SIFT特征提取，我大概花了三周。同样的算法在ARM上用OpenCV，半天就搞定了。所以我的建议是：只把FPGA用在最关键的瓶颈环节，比如图像去畸变、金字塔构建。

嵌入式GPU：深度学习SLAM的标配

现在做基于深度学习的SLAM（比如DroidSLAM、DPVO），嵌入式GPU基本是标配。NVIDIA的Jetson系列（Orin、Xavier）是主流选择。CUDA生态成熟，TensorRT还能做模型量化加速。

但功耗是个大问题。Jetson Orin满载能到60W，散热不好直接降频。我有个项目，在Jetson上跑SuperPoint+SuperGlue，一开始帧率只有8fps。后来发现是GPU频率被温度墙限制了。加了散热片之后，帧率直接翻倍到16fps。

嵌入式操作系统选型

操作系统选型，说白了就是「要功能还是要实时」的权衡。

操作系统	适用场景	实时性	我的推荐理由
Linux（Yocto/Buildroot）	功能复杂的SLAM系统	软实时（PREEMPT_RT可改善）	生态好，调试方便
FreeRTOS	传感器驱动、低延迟控制	硬实时（μs级）	轻量，适合裸机场景
Zephyr	资源受限的MCU	硬实时	开源，支持多架构

硬件资源评估方法

选型之前，先做资源评估。我一般按这个流程走：

1. 算力评估：用perf工具跑一遍算法，统计每帧的CPU/GPU占用
2. 内存评估：用valgrind或massif分析峰值内存
3. 带宽评估：用stream benchmark测内存带宽
4. 功耗评估：用功率计测典型场景功耗

举个例子，评估ORB-SLAM3在ARM上的资源需求：

# 用perf统计CPU周期
perf stat -e cycles,instructions,cache-misses ./ORB_SLAM3

# 输出示例
# 1,234,567,890 cycles
# 987,654,321 instructions
# 12,345,678 cache-misses  ← 这个值太高说明cache不够用

知识体系总览

下面这张图，是我对本章知识结构的总结。你可以把它当作选型时的「导航地图」：

这张图的核心逻辑是：先根据SLAM算法的计算特征选平台，再根据实时性要求选操作系统，最后用资源评估方法验证选型是否合理。你想想看，是不是这个理？

---

公众号:蓝海资料掘金营，微信deep3321