📚 课程目录第3章工程环境搭建

3. 工程环境搭建：交叉编译工具链配置、OpenCV for ARM移植、NEON指令集简介、CMake工程结构设计

说实话，很多做算法的同学，算法跑得飞起，一到嵌入式平台就懵了。我当年第一次把PC上的HDR代码往ARM板子上搬的时候，编译报错能刷满一屏。后来才明白，工程环境搭建这事儿，看着基础，其实是整个落地流程的骨架。骨架歪了，后面全白搭。

这一章，咱们就把这四块硬骨头啃下来：交叉编译工具链、OpenCV移植、NEON指令集入门、CMake工程结构。嗯，都是实战里绕不过去的。

3.1 交叉编译工具链配置

什么叫交叉编译？说白了，就是在你的x86电脑上，编译出能在ARM盒子上跑的二进制文件。你想想看，嵌入式设备性能弱、存储小，不可能在上面直接编译大型工程。

我个人习惯用Linaro GCC，它对ARM Cortex-A系列支持最好。以我常用的RK3588平台为例，配置步骤其实就这几步：

下载工具链：从Linaro官网下载 gcc-arm-10.3-2021.07-x86_64-aarch64-none-linux-gnu.tar.xz
解压到固定路径：我一般放在 /opt/toolchains/ 下
设置环境变量：把bin目录加到PATH里
验证：跑一下 aarch64-none-linux-gnu-gcc --version

关键点：工具链版本必须与目标板子的glibc版本匹配。版本不匹配，编译出来的程序跑起来会报 Floating point exception 或者 Illegal instruction。我曾经在这上面折腾了两天。

这里给一个我常用的环境变量配置脚本片段：

# 在 ~/.bashrc 或 ~/.zshrc 中添加
export TOOLCHAIN_PATH=/opt/toolchains/gcc-arm-10.3-2021.07-x86_64-aarch64-none-linux-gnu
export PATH=$TOOLCHAIN_PATH/bin:$PATH
export CROSS_COMPILE=aarch64-none-linux-gnu-
export CC=${CROSS_COMPILE}gcc
export CXX=${CROSS_COMPILE}g++

配置完记得 source ~/.bashrc 让它生效。

3.2 OpenCV for ARM 移植

OpenCV在ARM上的移植，我踩过的坑比代码行数还多。最大的坑是什么？NEON优化默认没开。你辛辛苦苦编译完，跑个图像处理，发现比PC上慢了10倍，那基本就是NEON没开。

我的编译脚本核心参数如下：

cmake -DCMAKE_TOOLCHAIN_FILE=../platforms/linux/aarch64-gnu.toolchain.cmake \
      -DCMAKE_INSTALL_PREFIX=./install \
      -DWITH_NEON=ON \
      -DWITH_TBB=ON \
      -DWITH_OPENMP=ON \
      -DBUILD_TESTS=OFF \
      -DBUILD_PERF_TESTS=OFF \
      -DBUILD_EXAMPLES=OFF \
      -DCMAKE_BUILD_TYPE=Release \
      ..

注意看 -DWITH_NEON=ON，这个必须显式打开。另外，BUILD_TESTS 和 BUILD_EXAMPLES 关掉，能省不少编译时间。我一般编译一次OpenCV完整版，在8核机器上也要40分钟。

小技巧：如果你只需要HDR融合相关的模块（core、imgproc、calib3d、photo），可以用 -DBUILD_LIST=core,imgproc,calib3d,photo 来裁剪。编译时间能缩短到15分钟以内。

移植完成后，记得在板子上跑一个简单的 cv::imread 和 cv::imwrite 测试，确认图像编解码库（libpng、libjpeg）也正确链接了。我遇到过好几次，OpenCV编译过了，但图片读不出来，最后发现是libjpeg没交叉编译进去。

3.3 NEON指令集简介

NEON是什么？ARM平台的SIMD（单指令多数据）扩展。你可以把它理解成ARM版的SSE。对于HDR融合这种像素级密集计算，NEON几乎是性能翻倍的利器。

举个例子，我们要对一张图像的所有像素做 dst = a * src + b 操作。普通C代码：

for (int i = 0; i < n; i++) {
    dst[i] = a * src[i] + b;
}

用NEON intrinsics写：

#include <arm_neon.h>

float32x4_t va = vdupq_n_f32(a);
float32x4_t vb = vdupq_n_f32(b);
for (int i = 0; i < n; i += 4) {
    float32x4_t vsrc = vld1q_f32(src + i);
    float32x4_t vdst = vmlaq_f32(vb, va, vsrc);
    vst1q_f32(dst + i, vdst);
}

看到区别了吗？普通代码一次处理1个像素，NEON一次处理4个。理论上4倍加速。实际项目中，内存访问对齐、循环展开等因素会影响，但2-3倍加速是稳稳的。

注意：NEON指令对内存对齐敏感。如果数据没对齐到16字节，性能会下降，甚至在某些平台上直接崩溃。我建议用 posix_memalign 或C++17的 std::aligned_alloc 来分配内存。

对于HDR融合，最常用的NEON指令是：

vld1q_f32 / vst1q_f32：加载/存储4个float
vmlaq_f32：乘加运算，融合的核心操作
vmaxq_f32 / vminq_f32：找最大值/最小值，用于权重计算
vaddq_f32：加法，用于累加

嗯，这里要提醒一下：NEON intrinsics的写法跟普通C差异不大，但性能调优需要结合具体的流水线特性。我一般先用纯C实现，验证正确性，再逐段替换成NEON版本，每替换一段就做一次性能对比。

3.4 CMake工程结构设计

一个好的CMake工程结构，能让你在PC上调试、在ARM上部署，来回切换不头疼。我现在的标准结构长这样：

hdr_fusion/
├── CMakeLists.txt          # 顶层CMake
├── cmake/
│   ├── toolchain_arm.cmake # ARM交叉编译工具链
│   └── FindOpenCV.cmake    # 自定义OpenCV查找模块
├── src/
│   ├── core/               # 核心算法
│   ├── io/                 # 图像读写
│   └── app/                # 主程序入口
├── include/
│   └── hdr_fusion/         # 公共头文件
├── tests/                  # 单元测试
└── scripts/
    └── build_arm.sh        # ARM编译脚本

顶层CMakeLists.txt的核心逻辑：

cmake_minimum_required(VERSION 3.16)
project(hdr_fusion VERSION 1.0.0 LANGUAGES CXX)

set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)

# 根据传入的TOOLCHAIN_FILE判断是否交叉编译
if(CMAKE_TOOLCHAIN_FILE)
    message(STATUS "Cross-compiling mode")
    set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
    set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
    set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
else()
    message(STATUS "Native build mode")
endif()

find_package(OpenCV REQUIRED)

add_subdirectory(src)
add_subdirectory(tests)

编译时，PC上直接 mkdir build && cd build && cmake .. && make。ARM上则用：

mkdir build_arm && cd build_arm
cmake .. -DCMAKE_TOOLCHAIN_FILE=../cmake/toolchain_arm.cmake
make -j$(nproc)

我的习惯：在 cmake/toolchain_arm.cmake 里，我会把交叉编译器的路径、sysroot、NEON编译选项全部写死。这样团队成员拉下来代码，一行命令就能编译，不用每个人手动配环境。

下面这张图，是我整理的本章知识体系，帮你理清各个模块之间的关系：

这张图把四个模块的关系画清楚了。工具链是基础，OpenCV和NEON是性能关键，CMake是工程化的骨架。缺一不可。

最后，我建议你把这一章的配置过程写成脚本，放到代码仓库的 scripts/ 目录下。这样不管是换电脑还是加新人，都能快速复现环境。我自己就是这么干的，省了不少时间。