2. 开发环境搭建

Hexagon DSP 的开发环境与常规 Android 应用开发有本质区别：它需要一套交叉编译工具链、一个能运行 DSP 镜像的模拟器或真机通道，以及一套把 Host 侧程序与 DSP 侧程序连接起来的调试机制。本节围绕“装什么、装在哪、怎么连、怎么验证”四个问题展开，目标是搭建出一个可以编译、可以运行、可以单步调试的最小可用环境。

一、Hexagon SDK 的组成与安装

Hexagon SDK 是 Qualcomm 提供的官方开发包，其核心目录结构决定了后续所有工具的使用方式。安装完成后，SDK 根目录下通常包含以下关键部分：

• tools/HEXAGON_Tools：Hexagon 交叉编译器、汇编器、链接器、模拟器（hexagon-sim）以及调试器（hexagon-gdb）。这是工具链的主体。
• incs 与 libs：DSP 侧的标准头文件与库，包括 QuRT 实时操作系统接口、FastRPC 接口、HVX 向量内建函数头文件。
• examples：官方示例工程，如 calculator、audio、fastrpc 等，是验证环境是否可用的最佳起点。
• tools/scripts：环境变量设置脚本，用于把工具链路径注入当前 shell。

安装流程通常为：从 Qualcomm 开发者站点下载对应版本的 SDK 安装包，赋予可执行权限后运行安装脚本，指定安装路径（建议路径中不含空格与中文）。安装完成后，必须执行环境初始化脚本，否则 hexagon-clang 等命令无法被找到。以 Linux 环境为例：

chmod +x Hexagon_SDK_installer.run
./Hexagon_SDK_installer.run --path /opt/Hexagon_SDK
source /opt/Hexagon_SDK/tools/HEXAGON_Tools/*/HEXAGON_Tools_setup.sh
hexagon-clang --version

最后一条命令若能打印出 Hexagon 版本号，说明工具链已可用。需要注意，SDK 版本与目标芯片的 DSP 架构版本（如 v68、v73、v75）必须匹配，否则编译出的镜像无法在目标设备上加载。

二、工具链的关键角色

Hexagon 工具链并非单一编译器，而是一条从 C/C++ 源码到 DSP 可执行镜像的完整链路。理解每个工具的角色，才能在编译报错时快速定位问题。

• hexagon-clang：交叉编译器，把 C/C++ 编译为 Hexagon 汇编或目标文件。它支持 HVX 内建函数，是向量化代码的入口。
• hexagon-llvm-objdump / readelf：查看目标文件与可执行文件的段布局、符号表，用于确认代码是否被正确放入 DSP 可加载段。
• hexagon-link：链接器，把多个目标文件与 DSP 库链接为 .so 或可执行镜像。
• hexagon-sim：指令级模拟器，可在没有真机的情况下运行 DSP 镜像，支持周期统计与缓存行为分析。
• hexagon-gdb：调试器，配合模拟器或真机调试通道实现断点、单步、寄存器查看。

Host 侧（通常是 Android 的 ARM 侧）与 DSP 侧通过 FastRPC 通信。因此一个完整的工程往往包含两部分：Host 侧的可执行程序或库，以及 DSP 侧的 .so 镜像。二者由不同的编译器编译，最终在设备上通过 FastRPC 通道连接。

三、模拟器调试通道配置

模拟器是环境搭建阶段最值得优先打通的通道，因为它不依赖真机，能快速验证工具链是否完整。使用 hexagon-sim 运行一个 DSP 镜像的基本命令如下：

hexagon-sim --mv68 --libpath=$HEXAGON_SDK/libs \
  ./libexample_skel.so

其中 --mv68 指定 DSP 架构版本，必须与编译时使用的 -mv68 一致。--libpath 指向 DSP 侧依赖库所在目录。若镜像依赖 QuRT，模拟器会自动加载对应的 RTOS 镜像。运行后若看到程序输出或正常退出，说明 DSP 镜像本身是可执行的。

要进入源码级调试，需要让模拟器以调试模式启动，再用 hexagon-gdb 连接。典型做法是：模拟器启动时加上 --gdb 参数并指定监听端口，然后在另一个终端启动 gdb 并加载同一份带调试信息的 .so：

hexagon-sim --mv68 --gdb --gdb-port 1234 ./libexample_skel.so
hexagon-gdb ./libexample_skel.so
(gdb) target remote :1234
(gdb) break example_kernel
(gdb) continue

断点命中后即可查看寄存器、HVX 向量寄存器以及内存。模拟器调试的价值在于可以精确统计周期数，例如用 --stats 参数输出各函数的执行周期，这对后续性能优化非常关键。

四、真机调试通道配置

真机调试比模拟器多出几个环节：设备必须开启开发者模式与 USB 调试，Host 侧需要 adb 可用，DSP 镜像需要被推送到设备并具备加载权限。基本流程如下：

1. 用 adb devices 确认设备已连接。
2. 将 Host 侧可执行文件与 DSP 侧 .so 推送到设备目录，例如 /data/local/tmp/hexagon_demo/。
3. 通过 adb shell 设置库搜索路径，使 FastRPC 能定位到 DSP 镜像。
4. 运行 Host 侧程序，观察 FastRPC 是否成功建立通道。

adb push libexample_skel.so /data/local/tmp/hexagon_demo/
adb push example_host /data/local/tmp/hexagon_demo/
adb shell
cd /data/local/tmp/hexagon_demo
export DSP_LIBRARY_PATH=/data/local/tmp/hexagon_demo
export LD_LIBRARY_PATH=/data/local/tmp/hexagon_demo
./example_host

若 Host 程序打印出 DSP 侧返回的结果，说明 FastRPC 通道已打通。若报错 fastrpc: unable to open device，通常是因为设备未启用 DSP 或权限不足；若报错找不到 _skel.so，则检查 DSP_LIBRARY_PATH 是否指向正确目录。

真机上的源码级调试需要借助 hexagon-gdb 与设备上的调试代理。一般做法是在设备上启动 gdbserver 或使用 SDK 提供的调试脚本，把 DSP 侧进程挂起后由 Host 侧 gdb 连接。由于真机调试涉及设备权限与厂商签名，实际项目中更常见的做法是：先在模拟器上完成算法验证与性能分析，再在真机上做集成验证与最终性能确认。

五、环境验证的最小闭环

搭建完成后，建议用一个最小示例做闭环验证：编译一个只做向量加法的 DSP 函数，Host 侧通过 FastRPC 调用它，分别在模拟器和真机上运行，确认结果一致。这个过程中需要重点确认三件事：工具链版本与 DSP 架构版本是否匹配、FastRPC 通道是否成功建立、DSP 镜像是否被正确加载。三者中任何一项不通过，后续所有开发都会受阻，因此环境搭建阶段宁可多花时间把这条链路走通，也不要带着隐患进入算法开发。