📚 课程目录第2章嵌入式开发环境搭建

2. 嵌入式开发环境搭建：交叉编译工具链配置、FFmpeg与OpenH264库编译、Linux内核实时性优化、内存与CPU资源评估

嵌入式开发环境搭建，说白了就是给你的目标板子配一套趁手的工具。我刚开始做嵌入式WebRTC项目时，光环境就折腾了三天。后来总结出一套流程，基本一天搞定。这一章咱们就把这套流程拆开讲清楚。

本章核心目标：在x86主机上搭建一套完整的ARM交叉编译环境，编译出FFmpeg和OpenH264库，并对Linux内核做实时性优化，最后评估板子的资源余量。

2.1 交叉编译工具链配置

交叉编译，就是在一台高性能PC上编译出能在ARM板子上跑的程序。我习惯用Linaro提供的GCC工具链，稳定且社区活跃。

2.1.1 工具链选择

架构	推荐工具链	适用场景
ARMv7-A (Cortex-A7/A9)	gcc-arm-linux-gnueabihf	树莓派2/3、全志H3
ARMv8-A (Cortex-A53/A72)	gcc-aarch64-linux-gnu	树莓派4/5、RK3588
ARMv7-M (Cortex-M4/M7)	gcc-arm-none-eabi	MCU裸机或RTOS

我个人建议直接下载Linaro预编译包，省去自己编译GCC的麻烦。解压后配置环境变量即可。

# 下载并解压工具链（以ARMv7为例）
wget https://releases.linaro.org/components/toolchain/binaries/latest-7/arm-linux-gnueabihf/gcc-linaro-7.5.0-2019.12-x86_64_arm-linux-gnueabihf.tar.xz
tar -xf gcc-linaro-*.tar.xz -C /opt/

# 配置环境变量
export PATH=/opt/gcc-linaro-7.5.0-2019.12-x86_64_arm-linux-gnueabihf/bin:$PATH
export CC=arm-linux-gnueabihf-gcc
export CXX=arm-linux-gnueabihf-g++

小技巧：把环境变量写到 ~/.bashrc 里，每次打开终端自动生效。我习惯再加一个 alias armcc='arm-linux-gnueabihf-gcc'，敲起来快很多。

2.1.2 验证工具链

写一个简单的Hello World，交叉编译后放到板子上跑一下，确认工具链工作正常。

// test.c
#include <stdio.h>
int main() {
    printf("WebRTC on ARM!\n");
    return 0;
}

// 编译
arm-linux-gnueabihf-gcc test.c -o test_arm

// 查看文件信息
file test_arm
// 输出: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV)

注意：如果板子上跑不起来，八成是动态链接库版本不匹配。我建议编译时加 -static 参数，或者用 arm-linux-gnueabihf-readelf -d test_arm 检查依赖的so文件。

2.2 FFmpeg与OpenH264库编译

WebRTC的视频编码离不开H.264。FFmpeg负责音视频处理，OpenH264是思科开源的H.264编码器。这两者配合，才能在嵌入式设备上实现低延迟视频通话。

2.2.1 编译FFmpeg

FFmpeg的configure脚本有很多开关。嵌入式设备资源有限，咱们只编译需要的模块。

# 下载FFmpeg 4.4（我测试过最稳定的版本）
wget https://ffmpeg.org/releases/ffmpeg-4.4.tar.bz2
tar -xf ffmpeg-4.4.tar.bz2
cd ffmpeg-4.4

# 配置（只开启H.264解码和编码）
./configure \
    --prefix=/opt/ffmpeg_arm \
    --enable-cross-compile \
    --cross-prefix=arm-linux-gnueabihf- \
    --arch=arm \
    --target-os=linux \
    --enable-gpl \
    --enable-libopenh264 \
    --enable-encoder=libopenh264 \
    --enable-decoder=h264 \
    --enable-parser=h264 \
    --disable-doc \
    --disable-ffplay \
    --disable-ffprobe \
    --disable-network \
    --disable-encoders \
    --disable-decoders \
    --disable-muxers \
    --disable-demuxers \
    --disable-parsers \
    --disable-protocols \
    --disable-devices \
    --disable-filters

# 编译并安装
make -j4
make install

嗯，这里要注意：--disable-* 参数能大幅减小库体积。我做过对比，全功能编译出来的libffmpeg.so有30MB，精简后只有3MB。对于Flash只有64MB的板子，这差别太大了。

2.2.2 编译OpenH264

OpenH264的编译相对简单，但要注意ABI兼容性。

# 下载OpenH264
git clone https://github.com/cisco/openh264.git
cd openh264

# 编译
make OS=linux ARCH=arm CC=arm-linux-gnueabihf-gcc AR=arm-linux-gnueabihf-ar

# 安装头文件和库
make install PREFIX=/opt/openh264_arm

避坑指南：我曾经在编译OpenH264时忘了指定AR工具，结果链接阶段报了一堆"undefined reference"。后来发现是ar工具用了x86的，生成的静态库格式不对。记住：AR 和 CC 都要指定交叉编译版本。

2.2.3 验证编译结果

写一个简单的测试程序，调用FFmpeg解码H.264文件，确认库能正常工作。

// test_ffmpeg.c
#include <libavcodec/avcodec.h>
int main() {
    printf("FFmpeg version: %s\n", avcodec_configuration());
    return 0;
}

// 编译
arm-linux-gnueabihf-gcc test_ffmpeg.c \
    -I/opt/ffmpeg_arm/include \
    -L/opt/ffmpeg_arm/lib \
    -lavcodec -lavutil -lm \
    -o test_ffmpeg_arm

2.3 Linux内核实时性优化

WebRTC对延迟敏感，默认的Linux内核调度策略可能不够用。我一般做三件事：启用PREEMPT_RT、调整CPU隔离、优化中断亲和性。

2.3.1 启用PREEMPT_RT

PREEMPT_RT补丁能让内核抢占更细粒度，减少调度延迟。以Linux 5.10为例：

# 下载内核源码和RT补丁
wget https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.10.100.tar.xz
wget https://cdn.kernel.org/pub/linux/kernel/projects/rt/5.10/patch-5.10.100-rt60.patch.xz

# 打补丁
tar -xf linux-5.10.100.tar.xz
cd linux-5.10.100
xzcat ../patch-5.10.100-rt60.patch.xz | patch -p1

# 配置内核
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- menuconfig
# 进入: General setup -> Preemption Model -> Fully Preemptible Kernel (RT)

经验之谈：RT补丁不是必须的。如果你的板子CPU主频在1GHz以上，且WebRTC只跑一路通话，默认的"Voluntary Kernel Preemption"就够用。RT补丁会带来约5%的性能开销。

2.3.2 CPU隔离与中断亲和性

多核处理器上，可以把一个核心专门留给WebRTC的编码线程，避免被其他进程打断。

# 内核启动参数（在bootargs中添加）
isolcpus=1 nohz_full=1 rcu_nocbs=1

# 在应用层设置亲和性（使用pthread）
cpu_set_t cpuset;
CPU_ZERO(&cpuset);
CPU_SET(1, &cpuset);
pthread_setaffinity_np(thread_id, sizeof(cpu_set_t), &cpuset);

# 中断亲和性（将网卡中断绑定到CPU0）
echo 1 > /proc/irq/$(cat /proc/interrupts | grep eth0 | awk '{print $1}' | tr -d ':')/smp_affinity

2.4 内存与CPU资源评估

资源评估不是跑个benchmark就完事。我习惯用一套组合拳：先理论计算，再实际测量，最后留余量。

2.4.1 理论计算

资源项	WebRTC单路通话估算	说明
CPU (编码)	30-40% @ 1GHz Cortex-A7	H.264 720p@30fps软编码
CPU (解码)	15-25% @ 1GHz Cortex-A7	H.264 720p@30fps软解码
内存	64-96 MB	包含视频缓冲、音频抖动缓冲
网络带宽	1.5-2.5 Mbps	720p@30fps, 目标码率1Mbps

你想想看，如果板子只有128MB内存，跑完系统还剩60MB，那WebRTC一启动就快满了。这时候就得考虑用硬件编码器，或者降低分辨率。

2.4.2 实际测量

在板子上跑一个压力测试程序，用 top 和 free 观察资源占用。

# 在板子上运行
# 先跑一个空转的WebRTC实例
./webrtc_peer --null-audio --null-video &

# 查看CPU和内存
top -b -n 1 | head -20
free -m

# 查看每个线程的CPU占用
ps -T -p $(pidof webrtc_peer)

注意：测量时一定要关掉调试日志。我曾经开着 --verbose 跑测试，结果CPU占用多了15%，还以为是编码器太吃资源。后来发现是日志打印占的。

2.4.3 留余量原则

我一般按"70%红线"来规划：CPU长期占用不超过70%，内存使用不超过总容量的70%。这样遇到突发流量（比如网络抖动导致重传）时，系统还有余力处理。

总结一下：环境搭建是嵌入式WebRTC开发的第一步，也是最容易踩坑的一步。工具链配好、库编译通过、内核优化到位、资源评估清楚，后面写代码才能安心。我见过太多项目在环境上卡了一两周，最后赶工期草草上线，结果线上出问题。所以，这一章的内容，值得你花时间认真过一遍。