简介：面向嵌入式与物联网开发者的SX126x系列LoRa芯片驱动源码包，覆盖SX1261、SX1262、SX1268等型号，可用于远距离、低功耗无线通信项目的底层移植、收发控制与信道活动检测（CAD）功能验证，也适合作为从SX127x方案过渡时的参考。压缩包共611个文件，约3.64MB，以C源文件（261个）和头文件（328个）为主体，并含少量汇编启动代码、Keil工程配置、调试脚本、链接脚本及说明文档，便于在STM32等平台上组织编译、烧录与调试。已有2375人学习下载，适合具备C语言与嵌入式基础、希望深入理解LoRa驱动分层与参数配置的开发者参考。内容围绕初始化配置、发送接收、错误处理和状态管理等模块展开，并提供CAD示例用于监测信道占用、减少发送冲突；读者可据此理解频率、功率、扩频因子与编码率等参数配置，快速搭建测试工程，并积累驱动移植、硬件接口验证与排错思路。
1. 一块 470MHz 模块读不出寄存器说起
SPI 接好、NRESET 拉低再放开、上电，读出来全是 0xFF——第一次碰 SX1262 / SX1268 这类 LoRa 芯片的人，八成都在这一步卡过。这套 SX126x 驱动源码要解决的就是这件事：把一份命令式 SPI 协议封装成能直接嵌入工程的 C 代码，让一颗 22dBm 的 LoRa 收发器从“上电没反应”变成“能发能收能测 RSSI”。SX1262 主打 150–960MHz 全频段，SX1268 更偏 470MHz 国内频段，两者共用同一套命令集，所以在驱动层几乎可以写成一份代码。
适合谁拿这份源码：正在做低功耗远传节点、准备把 LoRa 跑通到量产、或者手上有一份驱动但发射功率死活上不去的嵌入式开发者。下面按“分层结构 → 上电链路 → 收发实现 → 踩坑 → 二次开发”的顺序拆，代码可以直接抄。
2. 驱动的三层结构：命令层、业务层与 HAL 移植层
拿到一份 SX126x 驱动包，先别急着看main。这类驱动的写法高度统一，看懂分层，后面所有代码都是填空。
2.1 三层怎么切
| 层 | 文件 | 职责 | 换平台要不要改 |
|---|---|---|---|
| 命令层 | sx126x.c/sx126x.h | 每个 opcode 一个函数，只关心“发什么字节” | 不改 |
| 寄存器定义 | sx126x_regs.h | opcode、IRQ 位、频段参数宏 | 基本不改 |
| 业务层 | radio.c/radio.h | 收发状态机、CAD、低功耗、参数换算 | 少量改 |
| 移植层 | sx126x-hal.c | SPI 读写、GPIO、延时 | 全改 |
| 板级 | board.c | 射频开关、TCXO 电压、天线匹配 | 全改 |
命令层是一份“翻译表”，SetTxParams就是0x8E + power + rampTime，GetIrqStatus就是0x12 + 空字节 + 2 字节状态。业务层才是真正带逻辑的地方，比如“发完一包进 STDBY_RC 等下一包”这种状态迁移。
常见做法是把移植层单独抽成sx126x-hal.c，只暴露 5 个函数。换 MCU 只动这一个文件，其余原样带走——这是这份源码最值钱的地方，比贴一堆HAL_SPI_Transmit有用得多。
/* port/sx126x-hal.h —— 换 MCU 只实现这 5 个 */ void sx126x_hal_reset(void); /* NRESET 拉低 ≥100us 再释放 */ void sx126x_hal_wait_busy(void); /* 轮询 BUSY，直到低电平 */ int sx126x_hal_write(uint8_t opcode, const uint8_t *data, uint16_t len); int sx126x_hal_read(uint8_t opcode, uint8_t *data, uint16_t len); void sx126x_hal_delay_ms(uint32_t ms);参数说明：opcode是单字节命令码，data/len是紧随其后的参数区。读写接口里已经包含 NSS 的拉低拉高，上层业务代码看不到任何片选操作——这是刻意的，避免业务层手贱多拉一次 CS 把命令切碎。
2.2 SPI 时序的两个硬约束
SX126x 的 SPI 有两个和常见 Flash 不一样的地方，写 HAL 时必须照顾到：
第一，读命令要多一个空字节。发完 opcode 之后要先送一个 dummy 字节把总线“顶”一下，返回的数据才对齐。少了这个字节，读回来的全错一位。
第二，BUSY 必须等到低。芯片内部在跑校准、写 FIFO 的时候 BUSY 是高的，这时候发命令会被直接丢弃，而且不会报错。丢一条命令的后果可能是半小时后才发现的玄学。
/* port/sx126x-hal.c —— 平台相关，这里用伪 API 表示 */ int sx126x_hal_write(uint8_t opcode, const uint8_t *data, uint16_t len) { sx126x_hal_wait_busy(); /* 先等，再发，顺序不能反 */ spi_nss_low(); spi_transfer(opcode); for (uint16_t i = 0; i < len; i++) { spi_transfer(data[i]); } spi_nss_high(); return 0; } int sx126x_hal_read(uint8_t opcode, uint8_t *data, uint16_t len) { sx126x_hal_wait_busy(); spi_nss_low(); spi_transfer(opcode); spi_transfer(0x00); /* 读命令的占位字节，不能省 */ for (uint16_t i = 0; i < len; i++) { data[i] = spi_transfer(0x00); } spi_nss_high(); return 0; }逻辑说明：wait_busy放在 CS 拉低之前，而不是两条命令之间。原因是 BUSY 是芯片内部状态，跟 CS 电平无关；如果先拉低 CS 再等 BUSY，某些 MCU 的 SPI 外设会在这期间产生时钟毛刺，被芯片误判成命令起始位。血泪经验：STM32 的硬件 SPI 在 NSS 软件管理模式下这么干过一次，现象是偶发复位，查了两天。
2.3 FIFO 读写是特例
WriteBuffer(0x0E)和ReadBuffer(0x1E)的字节结构和普通命令不一样，中间多一个偏移地址。SX126x 的 256 字节 FIFO 分三个基址：0x00、0x80、0xC0，业务层用哪个都行，但读写必须成对。
/* 0x0E：opcode + offset + payload，一次可带完整个 FIFO */ int sx126x_write_buffer(uint8_t offset, const uint8_t *buf, uint8_t len) { sx126x_hal_wait_busy(); spi_nss_low(); spi_transfer(0x0E); spi_transfer(offset); /* 基址 0x00 / 0x80 / 0xC0 */ for (uint8_t i = 0; i < len; i++) spi_transfer(buf[i]); spi_nss_high(); return 0; } /* 0x1E：opcode + offset + dummy + payload */ int sx126x_read_buffer(uint8_t offset, uint8_t *buf, uint8_t len) { sx126x_hal_wait_busy(); spi_nss_low(); spi_transfer(0x1E); spi_transfer(offset); spi_transfer(0x00); /* 同样要占位 */ for (uint8_t i = 0; i < len; i++) buf[i] = spi_transfer(0x00); spi_nss_high(); return 0; }参数说明：offset要和SetBufferBaseAddress(0x8F)配置的 TX/RX 基址对上，否则写进去的数据和读出来的数据不在同一个区，现象是“发出去对端收到的全是乱码”。len受 FIFO 256 字节限制，LoRa 最大载荷 255 字节，刚好塞得下。
2.4 换 MCU 的移植顺序
我一般按这个顺序做，能最快定位是硬件还是软件问题：
- 先只实现
reset+wait_busy+read，读GetStatus(0xC0)的状态字节。芯片空闲时高 3 位应该是0x2（STDBY_RC），读到0x00或0xFF就说明 SPI 模式、时钟极性或者 NRESET 时序有问题。 - 再补
write，调SetStandby(0x80, 0x00)，然后再读一次状态，还是0x2就说明写通路通了。 - 最后接 TCXO 和射频开关，这时候才可能出现功率异常。
前三步不涉及射频，光用万用表和逻辑分析仪就能验证，比一上来就调天线快得多。很多人栽在第一步就直接去改射频参数，把简单问题复杂化了。
3. 上电初始化链路：从 NRESET 到第一条 SetTx
初始化是整份驱动最容易翻车的一段。SX126x 上电后不会自动进入可用状态，必须按固定顺序喂一串命令，顺序错了芯片不报错，只是默默不工作。
3.1 复位与 BUSY 握手
NRESET 是低有效，拉低至少 100us 再释放，之后 BUSY 会保持高电平一段时间（典型 2–3ms，模块带 TCXO 时更久），必须等它自己落下来。
void sx126x_reset(void) { nreset_low(); sx126x_hal_delay_ms(1); /* ≥100us，1ms 保险 */ nreset_high(); sx126x_hal_delay_ms(10); /* 给内部 LDO 和晶振起振留时间 */ sx126x_hal_wait_busy(); /* 关键：等 BUSY 拉低才算复位完成 */ }逻辑说明：delay(10)不是玄学，是覆盖大多数模块的晶振起振时间。有些低成本模块的 32MHz 晶振负载电容配得偏，起振要 8ms 以上，这时如果只等 1ms 就去发命令，第一条命令必然丢——而丢的恰好是SetStandby，后面整条链都建在沙子上。
3.2 SetStandby 与 SetRegulatorMode
第一梯队的两条命令，顺序不能换。
uint8_t standby = 0x00; /* 0x00 = STDBY_RC，0x01 = STDBY_XOSC */ sx126x_write_command(0x80, &standby, 1); uint8_t reg_mode = 0x01; /* 0x01 = DC-DC，0x00 = LDO */ sx126x_write_command(0x96, ®_mode, 1);参数说明：SetStandby用STDBY_RC（内部 RC 时钟）而不是STDBY_XOSC，是因为 RC 起振快、功耗低，初始化阶段不需要精确时钟。SetRegulatorMode选 DC-DC 能把发射电流从 118mA 降到 90mA 左右（+22dBm 时），代价是要外接一颗 10uH 电感。如果板子上没这颗电感，千万别开 DC-DC，现象是发射瞬间电压跌落导致 MCU 复位。
3.3 TCXO 配置：0x97 的电压档和 24bit 超时
带 TCXO 的模块必须配置SetDio3AsTcxoCtrl(0x97)，让 DIO3 引脚输出电压给温补晶振供电。这一步漏掉，芯片会一直卡在启动。
/* 0x97：电压档(1B) + 超时(3B，单位 15.625us) */ static const uint8_t tcxo_voltage = 0x02; /* 0x02 = 1.8V */ #define TCXO_TIMEOUT_MS 10 uint32_t ticks = (uint32_t)(TCXO_TIMEOUT_MS * 1000 / 15.625); /* 10ms -> 640 */ uint8_t buf[4]; buf[0] = tcxo_voltage; buf[1] = (ticks >> 16) & 0xFF; buf[2] = (ticks >> 8) & 0xFF; buf[3] = ticks & 0xFF; sx126x_write_command(0x97, buf, 4);参数说明：电压档是离散的 8 档，0x00=1.6V、0x01=1.7V、0x02=1.8V、0x03=2.2V、0x04=2.4V、0x05=2.7V、0x06=3.0V、0x07=3.3V，必须和模块上 TCXO 的规格对上。超时值 640 对应 10ms，是常用值；如果模块手册写“启动时间 15ms max”，就得改成 960 以上。超时设短了，芯片会在 TCXO 还没稳的时候就往下走，后面频率校准全偏。
3.4 包类型、频点与镜像校准
接下来三条命令决定“用什么协议、在哪个频率、校准哪个频段”。
uint8_t pkt_type = 0x01; /* 0x01 = LoRa，0x00 = GFSK */ sx126x_write_command(0x8A, &pkt_type, 1); /* 频率换算：freq = fRF * 2^25 / 32MHz */ uint32_t pll = (uint32_t)(((uint64_t)470000000ULL << 25) / 32000000ULL); uint8_t fbuf[4] = { (pll >> 24) & 0xFF, (pll >> 16) & 0xFF, (pll >> 8) & 0xFF, pll & 0xFF }; sx126x_write_command(0x86, fbuf, 4); /* SetRfFrequency */ /* CalibrateImage：按频段选两组参数 */ uint8_t cal[2]; if (freq_hz >= 470000000U && freq_hz <= 510000000U) { cal[0] = 0x75; cal[1] = 0x81; /* 470–510MHz */ } else if (freq_hz >= 430000000U && freq_hz <= 440000000U) { cal[0] = 0x6B; cal[1] = 0x6F; /* 430–440MHz */ } else { cal[0] = 0xD7; cal[1] = 0xDB; /* 863–870MHz */ } sx126x_write_command(0x98, cal, 2);参数说明：CalibrateImage的两组参数是芯片内置的镜像抑制校准系数，每个频段一对。用 470MHz 却填了 863MHz 的参数，现象是接收灵敏度掉 10–20dB，链路预算凭空少一半——这是最隐蔽的一类坑，因为通信“能用”，只是距离短。校准只在频点大幅跳变时需要重做，同一频点反复校准纯属浪费时间，还会把发射间隔拉长。
3.5 初始化完成的验收标准
发完这些命令，读一次GetStatus(0xC0)，状态字节高 3 位应该是0x2（STDBY_RC）。再读GetDeviceErrors(0x17)，返回0x0000才算干净；如果 bit0（RC64K 校准失败）或 bit4（PLL 锁定失败）被置起来，说明前面的 TCXO 或校准有问题，得用ClearDeviceErrors(0x07)清掉后重来。
我把这一步写成radio_init()的返回值，非 0 直接点亮错误灯，比默默跑下去强。
4. 收发链路拆解：参数、中断与 RSSI
初始化通了，接下来才是真正决定“能传多远、功耗多低”的部分。发射链路的每个参数都有明确的物理含义，接收链路则完全围绕 DIO1 中断展开。
4.1 发射功率：SetPaConfig 与 22dBm 的代价
SX1262 和 SX1268 的 PA 配置略有差异，但结构一样：四字节，分别是占空比、高功率上限、器件选择、PA LUT。
/* SX1262/SX1268 @ +22dBm */ uint8_t pa_config[4] = { 0x04, 0x07, 0x00, 0x01 }; sx126x_write_command(0x95, pa_config, 4); /* 0x8E SetTxParams：功率(dBm) + 上升沿时间 */ uint8_t tx_params[2] = { 22, 0x04 }; /* 0x04 = 200us ramp */ sx126x_write_command(0x8E, tx_params, 2);参数说明：paDutyCycle=0x04和hpMax=0x07是 +22dBm 的官方推荐值，改小会降功率降功耗，但不要随手改——这两个值配错会导致 PA 效率骤降、发热严重。deviceSel=0x00表示 SX1262/SX1268 系列（SX1261 是0x01）。功率字段范围是 -9 到 +22，超出会被截断。如果板子上没有匹配到 50Ω，实际辐射功率可能只有 15dBm，这时候调软件没用，得回头看巴伦和天线。
rampTime=0x04（200us）是折中值。用 10us 会让频谱边沿太陡，容易过不了杂散测试；用 3400us 又会让每包多耗几毫安时。做电池节点我一般固定 200us，够用且稳。
4.2 调制参数：带宽编码表和 LDRO 判据
/* 0x8B SetModulationParams：SF, BW, CR, LDRO */ static const uint8_t bw_code_125k = 0x40; uint8_t sf = 9; uint8_t cr = 0x01; /* 0x01 = 4/5 */ uint8_t ldro = 0x00; /* 符号时长 > 16.38ms 必须开 LDRO */ float tsym_ms = (float)(1UL << sf) / 125.0f; /* BW 单位 kHz */ if (tsym_ms > 16.38f) ldro = 0x01; uint8_t mod[4] = { sf, bw_code_125k, cr, ldro }; sx126x_write_command(0x8B, mod, 4);参数说明：带宽编码是离散表，0x00=7.8k、0x08=10.4k、0x18=15.6k、0x20=20.8k、0x28=31.25k、0x30=41.7k、0x38=62.5k、0x40=125k、0x48=250k、0x50=500k，注意不是等差也不是自然数编码，照抄错一位带宽就变了。
LDRO 那条判据是硬性的：SF11@125k 的符号时长是 16.4ms，SF12@125k 是 32.8ms，这两个组合不开 LDRO 会明显误码。SF9@125k 只有 4.1ms，开了反而浪费空口时间。写死ldro=0的驱动在 SF12 上翻车，是这个圈子里最经典的案例之一。
4.3 包头参数与 FIFO 写入
/* 0x8C SetPacketParams：前导码(2B), 包头类型, 载荷长度, CRC, IQ反转 */ uint8_t pkt[6] = { 8, /* 前导码长度，符号数 */ 0x00, /* 0x00 = 显式包头（变长），0x01 = 隐式（定长） */ 20, /* 载荷长度，隐式模式下必须准确 */ 0x01, /* 0x01 = 开 CRC */ 0x00 /* 0x00 = 标准 IQ，0x01 = 反转 */ }; sx126x_write_command(0x8C, pkt, 6); sx126x_write_buffer(0x00, payload, 20); uint8_t tx_timeout[3] = { 0x00, 0x00, 0x00 }; /* 0 = 不设超时 */ sx126x_write_command(0x83, tx_timeout, 3); /* SetTx */参数说明：显式包头模式下payloadLen会被芯片自己覆盖，填什么都行；隐式模式必须精确填，否则对端解析长度错误。前导码长度 8 是 LoRaWAN 常用值，私有协议里拉到 12–16 能提升同步概率，代价是每包多几百微秒。
SetTx的 3 字节超时单位是 15.625us，0x000000表示不设超时。做低功耗产品我不建议用 0，因为一旦 DIO1 没接好，芯片会一直停在 TX 模式，电池几个小时就见底。设一个2000ms / 15.625us ≈ 128000的上限更安全。
4.4 接收：DIO1 中断与 IRQ 状态机
接收不是轮询出来的，是靠 DIO1 拉高触发的。配置中断掩码的SetDioIrqParams(0x08)是 8 字节：IRQ 掩码、DIO1 掩码、DIO2 掩码、DIO3 掩码各 2 字节。
/* TxDone | RxDone | CrcErr | CadDone | CadDetected | Timeout */ uint16_t irq_mask = 0x0001 | 0x0002 | 0x0040 | 0x0080 | 0x0100 | 0x0200; uint8_t irq[8] = { (irq_mask >> 8) & 0xFF, irq_mask & 0xFF, /* 全局掩码 */ (irq_mask >> 8) & 0xFF, irq_mask & 0xFF, /* DIO1 映射 */ 0x00, 0x00, /* DIO2 不用 */ 0x00, 0x00 /* DIO3 不用 */ }; sx126x_write_command(0x08, irq, 8); uint8_t rx_timeout[3] = { 0xFF, 0xFF, 0xFF }; /* 连续接收 */ sx126x_write_command(0x82, rx_timeout, 3); /* SetRx */中断回调里第一件事是读GetIrqStatus(0x12)，第二件事是ClearIrqStatus(0x02)——顺序不能反，先清后读会把当前这次事件吞掉。
void radio_dio1_isr(void) { uint8_t raw[2]; sx126x_read_command(0x12, raw, 2); /* GetIrqStatus */ uint16_t irq = ((uint16_t)raw[0] << 8) | raw[1]; sx126x_write_command(0x02, raw, 2); /* 立刻清，防止重入 */ if (irq & 0x0002) { /* RxDone */ if (irq & 0x0040) { /* CrcErr 优先判断 */ stats.crc_err++; } else { uint8_t st[2]; sx126x_read_command(0x13, st, 2); /* payloadLen, startPtr */ sx126x_read_buffer(st[1], rx_buf, st[0]); rx_ready = 1; } } if (irq & 0x0001) { tx_done = 1; } /* TxDone */ if (irq & 0x0200) { rx_timeout_flag = 1; } /* Timeout */ }参数说明：GetRxBufferStatus(0x13)返回两个字节，第一个是本次收到的载荷长度，第二个是 FIFO 里的起始指针，务必用返回的指针去ReadBuffer，不要写死0x00——芯片在多次收包后会轮转基址。CrcErr要先于RxDone判断，因为两者可能同时置位，先取数据再判 CRC 就会把坏包当好消息处理。
4.5 RSSI 与 SNR 的换算
uint8_t ps[3]; sx126x_read_command(0x14, ps, 3); /* rssiPkt, snrPkt, signalRssiPkt */ int16_t rssi_dbm = -(int16_t)ps[0] / 2; int16_t snr_db = (int16_t)ps[1] / 4;参数说明：RSSI 的换算就是-rssiPkt / 2，单位 dBm，范围大概 -127 到 0。SNR 是snrPkt / 4，注意这是有符号数，SF12 下能读到 -20dB 的值，说明信号已经淹没在噪声里但还能解出来。第三个字节是“信号 RSSI”，用于评估干扰强度。我把这三个值直接挂到串口日志上，现场调天线的时候比示波器直观。
4.6 CAD：发之前先听一耳朵
CAD（Channel Activity Detection）用扩频因子本身去检测信道有没有 LoRa 前导码，比自己读 RSSI 准得多。
uint8_t cad_params[7] = { 0x04, /* 检测符号数 2^4 = 16 */ 0x16, /* detPeak，灵敏度与虚警率的折中 */ 0x0A, /* detMin */ 0x00, /* 0x00 = CAD 完成后回 STDBY_RC */ 0x00, 0x00, 0x00 /* 超时，0 = 不限 */ }; sx126x_write_command(0x88, cad_params, 7); sx126x_write_command(0xC5, NULL, 0); /* SetCad */ /* 回调里看 CadDone(0x0080) 和 CadDetected(0x0100) */参数说明：detPeak越大越不容易虚警，但也越容易漏检，0x16是 SF7–SF12 通用的稳妥值。cadSymbNum=4表示 16 个符号，检测时间随 SF 增长，SF12@125k 下大约 30ms。CAD 本身耗电不小，做电池产品要算清楚：省下的发射电流够不够抵掉这 30ms 的接收电流。
5. 避坑排查：五个真实会卡住人的现象
这一章全是“现象 → 原因 → 解决”，能省掉大量翻数据手册的时间。
5.1 读出来全是 0xFF 或者 0x00
现象：SPI 能通，但GetStatus一直返回0xFF或0x00，状态位永远不对。
原因：三个可能。一是 NRESET 释放后没等 BUSY 落下来就发命令；二是 SPI 模式选错（SX126x 只支持 Mode 0，CPOL=0/CPHA=0）；三是模块的 TCXO 没供电，芯片卡在启动。
解决：先用示波器量 BUSY 引脚在上电后有没有出现一段高电平再落低，如果没有，说明复位没生效。再确认 SPI 时钟不超过 16MHz，且 CS 在两条命令之间必须拉高一次。最后查0x97的电压档是不是和模块 TCXO 匹配。
5.2 发射正常但接收灵敏度差 20dB
现象：能发能收，但通信距离只有标称的三分之一，RSSI 读数比预期低很多。
原因：DIO2 没有配置成射频开关控制。绝大多数模块的 TX/RX 切换靠 DIO2 驱动一个 RF Switch，不配这条命令，天线根本没接到芯片上，信号是从匹配网络的残端漏出去的。
解决：初始化里补一条SetDio2AsRfSwitchCtrl(0x9D, 0x01)。
uint8_t enable = 0x01; sx126x_write_command(0x9D, &enable, 1);配完之后再测，通常能立刻看到 RSSI 抬升十几 dB。这条命令漏掉的现象太像“天线没调好”，很多人会先去改匹配网络，白折腾一周。
5.3 SF12 下丢包率奇高
现象：SF7、SF9 都正常，切到 SF11/SF12 之后误码率飙升，CRC 错包占比超过一半。
原因：LDRO 没开。高扩频因子下符号时长超过 16.38ms，接收端的时钟漂移在一个符号内累积到足以采样出错。
解决：按 4.2 的判据自动计算 LDRO，tsym > 16.38ms就置 1，收发两端必须一致。另外注意 LDRO 是调制参数的一部分，改了它就得重发SetModulationParams。
5.4 发射瞬间 MCU 复位
现象：一按发射，MCU 就重启，串口日志从头开始打。
原因：开了 DC-DC 但板子上没有 10uH 电感，或者电池内阻太大，+22dBm 发射时的 120mA 峰值电流把电压拉到 MCU 的 BOR 阈值以下。
解决：先确认硬件有没有 DC-DC 电感，没有就把SetRegulatorMode改成0x00（LDO），电流会涨到 118mA 但更稳。同时在电源脚并一颗 100uF 的低 ESR 电容，靠近芯片放。软件上还可以把rampTime从 10us 改成 200us，让电流上升慢一点，对电源冲击小很多。
5.5 长时间运行后偶发卡死
现象：跑几个小时到几天，节点突然不发了，复位才能恢复。
原因：中断里清了 IRQ 但没处理Timeout，或者 DIO1 上的中断被 MCU 的其他外设抢了没进去，导致状态机停在“等 TxDone”上。
解决：在业务层加一个软件看门狗——每次SetTx之后记录时间戳，超过预估的空口时间两倍还没收到TxDone，就强制SetStandby重新走一遍发射流程，并清一次GetDeviceErrors。这个兜底比调硬件可靠得多，我一般都会加。
6. 二次开发：把频点和协议做成可配置的
拿到这份驱动之后，真正要改的通常不是命令层，而是把它变成一个能适配多型号、多频点的配置化模块。
我习惯先抽一个radio_cfg_t结构体，把芯片型号、频点、SF/BW/CR、功率、TCXO 电压全塞进去，这样 SX1262 和 SX1268 共用一份代码，只换初始化参数。
typedef struct { uint8_t chip; /* 0 = SX1262, 1 = SX1268 */ uint32_t freq_hz; /* 470000000 / 868000000 ... */ uint8_t sf; /* 5..12 */ uint8_t bw_code; /* 0x40 = 125kHz */ uint8_t cr; /* 0x01 = 4/5 */ int8_t tx_dbm; /* -9..22 */ uint8_t tcxo_volt; /* 0x00..0x07 */ } radio_cfg_t; void radio_apply(const radio_cfg_t *cfg) { /* 1. TCXO 电压按 cfg->tcxo_volt 下发 */ /* 2. PA 配置按 cfg->chip 分支：SX1262 与 SX1268 的 deviceSel 不同 */ /* 3. LDRO 由 sf + bw 自动算，不再手填 */ /* 4. CalibrateImage 按 freq_hz 落桶 */ }改造时有三个点值得特别注意。第一，CalibrateImage的频段分桶要做成查表，别用一大串if，将来加频段直接加一行。第二，LDRO 一定自动算，别暴露给上层配置，暴露就一定会有人填错。第三，GetDeviceErrors自检要保留，每次radio_init()返回非 0 就打日志，这是现场排查的第一手线索。
验证方法很朴素：在同一个频点上用两根天线、两台设备互发一千包，统计 CRC 错包率和 RSSI 方差。改完参数之后错包率不升、RSSI 波动小于 3dB，就说明改动没破坏链路。我还会把GetPacketStatus的三个字节原样打到日志里，跑一晚上看趋势——比单次测距更能暴露问题。
从那以后我每次移植新板子，都会先只做“读状态字节”这一步，确认GetStatus稳定返回0x2再往下走，绝不跳过。这个习惯帮我省掉的调试时间，比任何调试工具都多。希望帮到你。
本文还有配套的精品资源，点击获取
