4. 开发环境搭建：Keil/IAR工程配置、驱动库移植、SPI通信调试、中断配置
开发环境搭建这一步，说简单也简单，说坑也多。我见过不少工程师，芯片选型、硬件设计都搞定了，结果卡在IDE配置上，一卡就是两三天。说白了，工具链没理顺，后面所有调试都是白搭。
这一章，我把UWB模组联调中最常见的环境搭建问题，以及我个人习惯的做法，一次性讲清楚。
4.1 开发工具选择：Keil还是IAR？
先聊个老生常谈的问题：Keil MDK和IAR Embedded Workbench，到底选哪个？
我的建议是：看芯片厂商的官方SDK支持情况。比如DW1000的官方驱动库，Keil和IAR的工程模板都有，但有些国产UWB芯片只给了Keil的例程。你非要拿IAR去硬怼，移植起来会多花不少时间。
| 对比项 | Keil MDK | IAR EWARM |
|---|---|---|
| 编译器 | ARMCC v6（AC6） | IAR C/C++ Compiler |
| 代码密度 | 中等 | 优化后更小（-Oz） |
| 调试体验 | J-Link / ST-Link 原生支持 | I-Jet / J-Link 均可 |
| 工程模板 | .uvprojx | .eww / .ewp |
| 常见坑点 | AC6对C99支持不够彻底 | 浮点运算库需手动链接 |
我个人习惯用Keil，因为大部分UWB模组的参考代码都是Keil工程。但如果你对代码体积有极致要求，IAR的优化确实更狠。
4.2 工程配置的“三板斧”
不管用哪个IDE，工程配置的核心就三件事：芯片型号、时钟树、堆栈大小。这三样搞错了，后面全是白费功夫。
4.2.1 芯片型号与启动文件
选对芯片型号是第一关。比如STM32F103系列，有ZE、VE、RE等后缀，Flash和RAM大小都不一样。选错了，编译器链接脚本会报错，或者程序跑飞。
启动文件也要对应。我记得有一次帮同事排查问题，他用的STM32F407，结果启动文件是F405的。程序能编译通过，但一跑就进HardFault。折腾了半天，最后发现是启动文件里的中断向量表偏移不对。
4.2.2 时钟树配置
UWB模组对时钟精度要求很高，尤其是SPI通信的时钟极性（CPOL）和相位（CPHA）必须和模组匹配。我建议在工程初始化阶段，先确认系统时钟频率，再用示波器量一下SPI的SCLK波形。
举个例子，DW1000的SPI时钟频率最高支持20MHz，但很多MCU的SPI分频器是2的幂次。如果你的系统时钟是72MHz，分频后可能是36MHz（超了）或18MHz（可用）。
// 以STM32F103为例，SPI1初始化
SPI_InitTypeDef SPI_InitStructure;
SPI_InitStructure.SPI_Direction = SPI_Direction_2Lines_FullDuplex;
SPI_InitStructure.SPI_Mode = SPI_Mode_Master;
SPI_InitStructure.SPI_DataSize = SPI_DataSize_8b;
SPI_InitStructure.SPI_CPOL = SPI_CPOL_Low; // 时钟空闲低电平
SPI_InitStructure.SPI_CPHA = SPI_CPHA_1Edge; // 第一个跳变沿采样
SPI_InitStructure.SPI_NSS = SPI_NSS_Soft;
SPI_InitStructure.SPI_BaudRatePrescaler = SPI_BaudRatePrescaler_4; // 72MHz/4=18MHz
SPI_InitStructure.SPI_FirstBit = SPI_FirstBit_MSB;
SPI_Init(SPI1, &SPI_InitStructure);
4.3 驱动库移植：别直接复制粘贴
很多工程师拿到UWB模组的驱动库，第一反应就是直接复制到自己的工程里。嗯，这样做十有八九会出问题。
为什么？因为驱动库通常依赖特定的硬件抽象层（HAL/LL库），而你的工程可能用的是标准外设库（SPL）或者裸机寄存器操作。直接复制，编译会报一堆未定义标识符。
我的做法是：
- 先梳理依赖关系：打开驱动库的头文件，看看它引用了哪些MCU相关的头文件。
- 抽象接口层：把SPI读写、GPIO控制、延时函数这些底层操作，封装成独立的接口文件。比如
uwb_spi.c、uwb_gpio.c。 - 逐模块移植：从最简单的初始化函数开始，每移植一个函数，就编译一次，确保没有错误。
4.4 SPI通信调试：从“黑盒”到“白盒”
SPI通信是UWB模组联调的重头戏。我见过太多人，SPI初始化代码写完了，读写函数也调了，但就是读不到正确的寄存器值。这时候，别急着怀疑模组坏了，先做一件事：用逻辑分析仪抓波形。
你想想看，代码里的SPI配置对不对，波形一看便知。SCLK频率对不对？MOSI上的数据对不对？CS片选信号有没有拉低？这些信息，逻辑分析仪都能告诉你。
4.4.1 SPI读写函数的标准写法
UWB模组的SPI通信，通常遵循“先写地址，再读写数据”的协议。地址字节的最高位表示读写方向（1=读，0=写）。
// DW1000 SPI 读写函数示例
uint8_t uwb_spi_read_reg(uint16_t reg_addr) {
uint8_t addr_high = (reg_addr >> 8) & 0xFF;
uint8_t addr_low = reg_addr & 0xFF;
uint8_t data;
// 拉低CS
UWB_CS_LOW();
// 发送地址（读操作，最高位置1）
spi_send_byte(addr_high | 0x80);
spi_send_byte(addr_low);
// 发送一个哑字节，同时接收数据
data = spi_send_byte(0x00);
// 拉高CS
UWB_CS_HIGH();
return data;
}
4.4.2 常见SPI通信失败原因
- 时钟极性/相位不匹配：这是最常见的问题。UWB模组的数据手册里会明确写出SPI模式，一定要仔细看。
- CS片选时序不对：有些模组要求CS在发送地址前先拉低，并在整个通信过程中保持低电平。如果CS在字节之间被拉高，通信会中断。
- 时钟频率过高：UWB模组的SPI最高频率通常是20MHz，但有些模组在高温或长走线情况下，10MHz都可能出错。我建议先降到1MHz测试，稳定后再逐步提高。
4.5 中断配置：别让中断“打架”
UWB模组的中断引脚，通常用于通知MCU有数据接收完成、发送完成、或者错误发生。中断配置看似简单，但坑不少。
我曾经在一个项目里，同时用了UWB模组的中断和定时器中断。结果UWB中断一触发，定时器就不准了。查了半天，发现是中断优先级没配好。UWB中断的优先级设得太低，被定时器中断抢占了，导致数据接收超时。
4.5.1 中断优先级分配原则
| 中断类型 | 建议优先级 | 说明 |
|---|---|---|
| UWB数据接收中断 | 最高（0或1） | 数据接收有时效性，错过就丢了 |
| UWB错误中断 | 高 | 需要及时处理，避免模组死锁 |
| 定时器中断 | 中等 | 允许少量延迟 |
| 串口中断 | 低 | 数据可以缓冲，优先级最低 |
4.5.2 中断服务函数的“黄金法则”
中断服务函数（ISR）里，只做最必要的事：读取状态、清除标志、设置事件标志。千万不要在ISR里做复杂的计算或者延时操作。
// UWB中断服务函数示例
void UWB_IRQHandler(void) {
uint8_t status;
// 1. 读取中断状态寄存器
status = uwb_read_reg(SYS_STATUS_ID);
// 2. 判断中断类型
if (status & SYS_STATUS_RXFCG) {
// 接收完成，设置事件标志
uwb_rx_event = 1;
}
// 3. 清除中断标志
uwb_write_reg(SYS_STATUS_ID, status);
}
4.6 本章知识体系总览
下面这张图，把开发环境搭建的核心流程串起来了。你可以把它当作一个检查清单，每完成一步，就打个勾。
这张图里的每一步，都是我在实际项目中踩过坑之后总结出来的。你按照这个顺序来，至少能避免80%的常见问题。
4.7 本章小结
开发环境搭建，说白了就是“磨刀不误砍柴工”。工具选对、工程配好、驱动移植干净、SPI波形调通、中断优先级理顺，后面UWB模组的联调才会顺畅。
嗯，这一章的内容就到这里。记住，遇到问题别慌，先检查基础配置，再怀疑硬件。很多时候，问题就出在你觉得“肯定没问题”的地方。