嵌入式系统基础：处理器分类与开发全流程

做嵌入式算法部署，第一件事就是搞清楚你的目标硬件是什么。我见过不少新手，算法在PC上跑得飞快，一上板子就卡成PPT——说白了，就是没搞懂处理器的脾气。

嵌入式处理器不是只有一种。MCU、DSP、FPGA、ASIC，各有各的擅长领域。你想想看，选错了平台，后面所有优化工作都是白费力气。

嵌入式处理器分类

类型	核心特点	典型应用	我踩过的坑
MCU	集成CPU+RAM+Flash，低功耗，成本低	传感器节点、电机控制、IoT终端	跑轻量级TinyML还行，CNN就别想了
DSP	硬件乘加器，SIMD指令集，流水线优化	音频编解码、雷达信号、数字滤波	定点量化做不好，精度直接崩
FPGA	可编程逻辑，并行计算，低延迟	实时推理、协议加速、原型验证	时序约束没写对，跑不到目标频率
ASIC	全定制，最高能效比，不可更改	手机NPU、AI加速卡、专用芯片	流片一次几十万，改不起

嵌入式开发流程

很多人以为嵌入式开发就是写代码、烧录、跑起来。其实没那么简单。我习惯把流程分成五步：

1. 需求分析——算力、内存、功耗、实时性，缺一不可
2. 硬件选型——根据需求选处理器，留20%余量
3. 环境搭建——交叉编译链、调试器、烧录工具
4. 算法移植——模型转换、量化、算子适配
5. 性能调优——逐层分析瓶颈，反复迭代

嗯，这里要注意：算法移植这一步最容易出问题。我曾经把一个Pytorch模型直接转成C代码，结果在DSP上跑出来的结果全是NaN——后来才发现是激活函数的数值范围没处理好。

交叉编译环境搭建

交叉编译，说白了就是在PC上编译出能在ARM/RISC-V上运行的二进制文件。你不可能在板子上装个gcc慢慢编译，那太慢了。

我常用的工具链：

• ARM GCC：arm-none-eabi-gcc，适合裸机或RTOS
• ARM Linux GCC：aarch64-linux-gnu-gcc，适合跑Linux的板子
• RISC-V GCC：riscv64-unknown-elf-gcc，新兴架构

# 以ARM Cortex-M4为例
# 1. 下载ARM GCC工具链
wget https://developer.arm.com/-/media/Files/downloads/gnu-rm/10.3-2021.10/gcc-arm-none-eabi-10.3-2021.10-x86_64-linux.tar.bz2

# 2. 解压并配置环境变量
tar -xjf gcc-arm-none-eabi-*.tar.bz2
echo 'export PATH=$PATH:/opt/gcc-arm-none-eabi/bin' >> ~/.bashrc
source ~/.bashrc

# 3. 验证安装
arm-none-eabi-gcc --version

# 4. 编译一个简单的main.c
arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -O2 -o test.elf main.c

性能评估指标

算法部署到嵌入式平台，怎么才算"跑得好"？三个指标：FPS、功耗、延迟。我一般按这个顺序评估：

指标	定义	测量方法	我的经验值
FPS	每秒处理帧数	计时器统计100帧取平均	实时视频至少30 FPS
功耗	单位时间能耗	万用表或PMIC读数	电池设备通常<1W
延迟	单次推理耗时	GPIO翻转+示波器	控制类应用<10ms

知识体系总览

下面这张图，是我自己总结的嵌入式算法部署知识体系。每次带新人，我都会先让他们看这张图：

小结

这一章的内容，说白了就是打好地基。处理器分类帮你选对工具，开发流程让你不走弯路，交叉编译环境是必备技能，性能指标则是衡量成果的尺子。

我个人觉得，初学者最容易忽略的是性能评估这一步。代码能跑不代表跑得好。我见过有人把模型部署上去，FPS只有5，还觉得"能跑就行"——这种心态做产品肯定翻车。