简介面向STM32平台的SX126x系列LoRa芯片驱动源码包适配SX1261、SX1262、SX1268等新一代LoRa芯片涵盖芯片初始化、数据收发、错误处理、状态管理等完整驱动模块适合有一定嵌入式基础、正在评估或部署该系列芯片的开发者。压缩包内共611个文件以261个C源码、328个头文件为主并配有少量Keil工程文件、链接脚本、PDF说明文档及bin示例整体大小3.64MB目录结构清晰便于按需筛选。已有2370人学习下载。C源码负责具体驱动逻辑头文件定义寄存器地址与接口Keil工程可直接打开编译省去手动建工程的时间。开发者可快速完成移植大幅缩短LoRa功能开发周期源码对低功耗模式、频点设置、扩频因子、编码率等参数均有封装并覆盖STM32L0/L1/L4等多系列HAL库方便在不同项目中复用。压缩包内的CAD示例工程演示了信道空闲检测流程适合物联网网关、远距离传感器等低功耗场景能够帮助嵌入式工程师快速完成驱动的调试与二次开发。1. 换芯片最怕驱动翻车SX126x为什么不能照搬SX1278的代码新来的同事把SX1278的驱动改了两行寄存器地址就烧到SX1262的板子上结果射频指示灯亮着网关一个字节都收不到。这事很典型凡是照着SX127x那套寄存器思维去读SX126x数据手册的人第一次上电多半要交学费。SX126x是Semtech新一代LoRa收发芯片覆盖150MHz到960MHz频段支持LoRa与FSK双调制常出现在LoRaWAN节点、手持终端和环境监测网关里。注意搜“LoRa微调”搜出来的多半是AI模型训练那跟射频芯片完全是两个方向。下面把SX126x驱动源码的分层思路、STM32最小收发例程、参数配置顺序以及几个真实踩坑点一次讲透适合正在做芯片替换选型、准备把协议栈radio层换成SX126x驱动的嵌入式工程师。2. SX126x驱动源码怎么拆命令状态机、HAL层和Busy握手2.1 从SX127x到SX126x变的不是寄存器地址是操作范式SX127x系列的操作方式很直接往寄存器地址写值配置调制方式、频率、功率再往FIFO写数据切发送或接收模式完事。寄存器手册就是一本地址字典驱动源码本质上是“地址掩码移位”的堆积。SX126x把这套玩法整个翻了一个面。SX126x内部是一个命令状态机主机通过SPI发送操作码opcode和参数来驱动状态切换。操作码后面跟随的参数有时多达十几字节而且大部分命令需要芯片内部的无线电状态机处理完才能接收下一条命令。芯片用一个专用的Busy引脚告诉主机“我正忙着别打扰我”。这套设计带来了一个质变驱动源码不再是对着寄存器位逐个操作而是变成“拼装命令参数、等待Busy释放、发操作码、等结果”的流程控制。还有一个关键差异。SX127x的LoRa和FSK调制分别使用不同的寄存器组切调制方式要重配一大片寄存器。SX126x直接用SetPacketType命令在LoRa和FSK之间切换所有调制参数归口到SetModulationParams、包格式归口到SetPacketParams。可维护性好了但前提是驱动架构必须跟着改拿老代码硬套必然翻车。2.2 驱动源码的标准分层命令层、平台层和Radio抽象拿到一份SX126x驱动源码先别急着看细节第一件事是认清分层。常见做法是把源码拆成三层平台抽象层HAL、命令层、Radio抽象层。平台抽象层处理的是SPI收发、NSS拉高拉低、Busy电平读取、DIO1中断回调注册以及RST复位引脚操作。这一层是整个驱动里唯一跟具体MCU绑死的部分从STM32换到ESP32只改这里。命令层把SX126x数据手册里的每一条命令封装成函数参数拼装、Busy等待、发送opcode、解析返回值都在这一层完成。Radio抽象层则面向协议栈业务提供Init、Send、Receive、Wakeup这类高层接口LoRaWAN协议栈里的radio驱赶通常就是这一层要实现的接口。很多人在移植官方LoRaMac-node的radio驱动时找不到方向就是因为没分清这三层改频率参数去改了Radio抽象层改SPI时钟却去动了命令层最后出问题回溯困难。下面的代码是平台抽象层里最基础的SPI字节收发所有命令都建立在它之上。// sx126x_hal.c 平台相关实现以STM32的HAL库为例 uint8_t SX126xHAL_ReadWriteByte(uint8_t byte) { uint8_t rx 0; // 单字节SPI收发SCK速率先压到1MHz链路稳定后再往上提 HAL_SPI_TransmitReceive(hspi2, byte, rx, 1, HAL_MAX_DELAY); return rx; }这里有一个参数要留意hspi2对应的SPI外设CPOL和CPHA必须匹配SX126x手册要求的SPI模式4。极性反了命令发出去芯片根本不会理你而Busy引脚可能一直拉低让你误以为是芯片坏了。SCK速率建议初始化阶段控制在1MHzSX126x的SPI标称能到16MHz但走线长、电平转换器慢时高速跑容易丢字节先低速跑通再提速是射频驱动移植的基本操作。2.3 一条命令的完整生命周期读Busy、发opcode、收Status理解SX126x驱动的核心是搞懂一条命令从软件到射频芯片之间的完整旅程。以设置待机模式为例整个过程分成三个严格的阶段。第一阶段主机把NSS拉低表示“我要占用SPI总线”。第二阶段主机必须等到Busy引脚变为低电平才能发送命令。很多初学者忽略这个步骤直接把操作码写进SPI运气好能成但在芯片内部状态机还忙时这条命令会被直接吞掉。第三阶段主机发送操作码和参数随后NSS拉高命令进入执行队列芯片会在Busy引脚上出现一段高电平脉冲表示正在执行。// sx126x_cmd.c 命令层写命令的统一入口 static void SX126x_WriteCommand(SX126x_t *radio, uint8_t opcode, uint8_t *params, uint16_t len) { // 1. 拉低NSS占用SPI总线 SX126xHAL_SetNss(0); // 2. 等待Busy释放超时保护防止死等 uint32_t timeout 10000; while (SX126xHAL_GetBusy()) { if (--timeout 0) break; } // 3. 发送操作码和参数 SX126xHAL_ReadWriteByte(opcode); for (uint16_t i 0; i len; i) { SX126xHAL_ReadWriteByte(params[i]); } // 4. 释放总线 SX126xHAL_SetNss(1); }很多人移植驱动时卡在“等Busy”这一步。Busy引脚必须接MCU的一个普通GPIO输入不能悬空也不能直接接地。因为SX126x上电瞬间总线状态不稳定上拉电阻和足够长的等待时间缺一不可。上面的超时保护也不是随便写的射频芯片因为校准失败或电源跌落而异常时Busy可能永远拉高没有超时机制的话整个系统直接死机。养成每个等待都加超时的习惯能给后面省下大量排错时间。3. 在STM32上跑通第一版SX126x驱动SPI、初始化和收发例程3.1 管脚与SPI配置时钟从1MHz起步DIO映射别接错SX126x需要主机连接的引脚比SX127x少很多典型配置是六根NSS、SCK、MOSI、MISO、RST、BUSY外加一个DIO1用于中断通知。DIO2和DIO3在大多数应用中不接MCUDIO2被配置为射频开关控制后输出给外部射频前端DIO3则用于控制TCXO供电。这正是SX126x省引脚的地方但也埋了一个坑如果板子上DIO2没接到射频开关而驱动里又把DIO2当普通GPIO去初始化射频通路死活打不开。用STM32CubeMX配置SPI时我会把SPI模式设为Mode 0CPOL0CPHA1在英文手册对应的是SPI Mode 0数据宽度8位高位在前。MISO上最好加一个10kΩ上拉因为部分模块在SPI空闲时会输出高阻上拉能让电平稳定。初始化顺序上先初始化GPIO和SPI外设再拉低RST做复位然后才能开始发命令。// main.c 硬件初始化片段 void lora_hw_init(void) { // MX_SPI2_Init 里已经把 SCK1MHz 配置好 // NSS、BUSY、RST、DIO1 全部配置为 GPIO // 复位脉冲低电平保持10ms保证芯片完成上电复位 HAL_GPIO_WritePin(RST_GPIO_Port, RST_Pin, GPIO_PIN_RESET); HAL_Delay(10); HAL_GPIO_WritePin(RST_GPIO_Port, RST_Pin, GPIO_PIN_SET); HAL_Delay(10); }这里的关键是RST引脚复位后至少要等10ms再操作SPISX126x内部上电复位和晶振起振需要时间。有些模块用的是TCXO版本复位后还需要额外延时让DIO3控制的电源稳定输出。硬件上如果RST引脚没有RC延时电路软件里的10ms延时就是唯一保障别省。3.2 初始化序列复位、校准、调制参数和包参数的先后SX126x的初始化顺序在数据手册里没有单页汇总得从命令列表里自己整理。实践下来稳定的顺序是复位、SetStandby、Calibrate校准、SetPacketType选LoRa、SetRfFrequency设频率、SetModulationParams设调制参数、SetPacketParams设包参数、SetDio2AsRfSwitchCtrl开启射频开关控制最后SetTxParams设发射功率。// radio_init.c 完整的初始化序列 void lora_radio_init(uint32_t freq_hz) { SX126x_t radio {0}; // 1. 进入待机模式使用RC时钟功耗低且启动快 SX126x_SetStandby(radio, SX126x_STDBY_RC); // 2. 校准全部模块官方推荐0x7F表示全部校准 SX126x_Calibrate(radio, 0x7F); // 3. 选择LoRa调制SX126x的PacketType决定后面所有参数含义 SX126x_SetPacketType(radio, PACKET_TYPE_LORA); // 4. 配置射频频率这里传的是实际频率值寄存器换算在内部做 SX126x_SetRfFrequency(radio, freq_hz); // 5. 调制参数SF7, BW125kHz, CR4/5, 不开低数据率优化 ModulationParams_t mod { .SpreadingFactor LORA_SF7, .Bandwidth LORA_BW_125, .CodingRate LORA_CR_4_5, .LowDatarateOptimize 0 }; SX126x_SetModulationParams(radio, mod); // 6. 包参数8字节前导码、显式包头、开启CRC、IQ不反转 PacketParams_t pkt { .PreambleLength 8, .HeaderType LORA_PACKET_EXPLICIT, // 显式包头方便调试 .PayloadLength 16, // 固定长度模式下有意义 .CrcOn 1, .InvertIQ 0 }; SX126x_SetPacketParams(radio, pkt); // 7. DIO2复用为射频开关控制很多翻车事故就是漏了这一步 SX126x_SetDio2AsRfSwitchCtrl(radio, true); }几个参数要重点解释。Calibrate命令会在Busy上产生一个较长的低电平等待有些实现不等Calibrate完成就继续配参数导致后续命令被丢弃。SetPacketType放在SetRfFrequency之前没有严格强制关系但放前面可以避免不同调制下频率配置语义的混淆。SetDio2AsRfSwitchCtrl在复位后必须重新配置因为芯片复位会把该选项清回默认值。PacketParams里的PayloadLength在显式包头模式下只是预留值实际长度由每包自带的头部字段决定这对后面调试非常友好。3.3 最小收发例程发送与接收的临界条件初始化完成后发送一包数据和接收一包数据的代码并不复杂。发送的完整动作是把payload写入FIFO配置DIO1中断源为TX_DONE调用SetTx再等中断。// lora_send.c 发送一包数据阻塞等待发送完成 uint8_t lora_send(uint8_t *buf, uint8_t len) { // 1. 数据写入芯片FIFO从偏移0开始 SX126x_WriteBuffer(radio, 0, buf, len); // 2. 清掉历史中断防止残留标志导致误判 SX126x_ClearIrqStatus(radio, SX126x_IRQ_TX_DONE); // 3. 把DIO1映射为TX_DONE中断 SX126x_SetDioIrqParams(radio, SX126x_IRQ_TX_DONE, SX126x_IRQ_TX_DONE, 0, 0); // 4. 启动发送timeout0表示无超时限制 SX126x_SetTx(radio, 0); // 5. 轮询DIO1引脚等待发送完成 while (!HAL_GPIO_ReadPin(DIO1_GPIO_Port, DIO1_Pin)) { // 实际产品建议加超时防止射频芯片异常死等 } return 0; }SetTx的timeout参数很多人理解错这里单位是符号时间symbol time不是毫秒也不是字节数。LoRa模式下符号时间由SF和BW共同决定。0表示不启动超时发送一旦开始就一直进行到结束适合发送固定短包。如果你在协议栈里看到有人把timeout填成0xFFFFFF那是给接收用的持续监听模式两者语义不同混用会出奇怪问题。接收最小实现是把DIO1映射为RX_DONE然后调用SetRx并传入接收超时。// lora_recv.c 接收一包数据单次接收模式 uint8_t lora_recv(uint8_t *buf, uint8_t *len) { // 1. 清中断映射RX_DONE SX126x_ClearIrqStatus(radio, SX126x_IRQ_RX_DONE | SX126x_IRQ_CRC_ERROR); SX126x_SetDioIrqParams(radio, SX126x_IRQ_RX_DONE, SX126x_IRQ_RX_DONE, 0, 0); // 2. 启动单次接收timeout0表示只收一次收不到就回到STDBY SX126x_SetRx(radio, 0); // 3. 等DIO1变高 while (!HAL_GPIO_ReadPin(DIO1_GPIO_Port, DIO1_Pin)) {} // 4. 读取中断状态判断是正常接收还是CRC错误 uint16_t irq SX126x_GetIrqStatus(radio); if (irq SX126x_IRQ_CRC_ERROR) return 1; // 5. 从FIFO读出数据 SX126x_ReadBuffer(radio, 0, buf, len); return 0; }这个接收函数的关键边界在于SetRx的timeout0是“单次接收”模式不是“无限接收”。很多从SX127x迁过来的代码会习惯性把接收放在一个while(1)循环里每次处理完再调用一次SetRx。而在SX126x上单次接收收到一包后芯片自动回到待机必须再次调用SetRx才能继续收下一包。如果想一直挂在接收状态要把timeout设置为0xFFFFFF但代价是芯片无法自动进入休眠功耗会明显高出几个量级。4. 把射频参数调到链路能通频率、调制、功率的配置顺序与取值4.1 频率怎么算0.953674Hz/LSB和寄存器反推SX126x的SetRfFrequency命令接收的是一个与频率成正比的整数值不是频率本身。芯片内部用32MHz晶振作为参考经过分频和倍频后生成射频频率寄存器值和实际频率的关系如下// freq_calc.c 频率寄存器换算 uint32_t freq_to_reg(uint32_t freq_hz) { // SX126x参考晶振32MHz寄存器2^25计数范围内对应整个频段 // 1 LSB 对应的频率是 32e6 / 33554432 0.953674 Hz double reg (double)freq_hz * 33554432.0 / 32000000.0; return (uint32_t)(reg 0.5); // 四舍五入减少频偏 }反过来寄存器值换算成实际频率是 reg * 32e6 / 33554432。很多人把寄存器值按1Hz/LSB去理解设置433MHz时算出了整整偏了接近46Hz的寄存器值这个误差在调试窄带通信时足以让接收端灵敏度下降几个dB。实际部署中更常见的问题是两边模块频率配置不一致一个433000000Hz按整数算另一个433000000.2Hz按浮点算发射频率误差虽小但如果接收端用了高Q值滤波器灵敏度损失在临界距离上会被放大。设置频率时还有一点容易被忽略必须等芯片进入STDBY模式后再写频率不要等芯片正在收发过程中去改。典型做法是每次频率变更前先调用SetStandby改完后再根据需要进入发送或接收状态。这与SX127x的操作习惯一致但很多SX126x的命令实现里少了这步导致频率写在错误的状态机上。4.2 调制参数组态SF/BW/CR的取值对链路预算的影响调制参数是LoRa物理层的核心SX126x里通过SetModulationParams一次配齐扩频因子、带宽、编码率外加低数据率优化开关。常见的取值组合如下。场景扩频因子SF带宽BW编码率CR空闲信道数据率适用距离密集城区快速上报7125kHz4/5约5.4kbps1~2km视距郊区综合覆盖9125kHz4/5约1.7kbps3~5km远距离低速率12125kHz4/8约0.3kbps5km以上SF增大一倍有效数据率约减半但接收灵敏度提升约3dB。带宽从125kHz加倍到250kHz灵敏度反而下降约3dB因为噪声基底变宽。CR是纠错编码4/5对应每个4bit数据附加1bit冗余4/8冗余更高抗干扰更强但吞吐更低。这三个参数在通信双方的驱动里必须完全一致否则接收方解调器无法捕获信号。低数据率优化LowDatarateOptimize是SX126x里一个很容易配错的参数。当符号时间超过约16ms时LoRa调制中原本用于定时的前导码会受晶振漂移影响此时必须开启这个优化。判定条件不复杂SF12、BW125kHz时符号时间约32.8ms必须开SF12、BW500kHz时符号时间约8.2ms可以关。很多环境监测节点在SF12BW125配置下没开LDO导致室内短距离通信正常、户外远距离丢包率暴涨就是这个参数在作怪。// 计算符号时间用于决定LowDatarateOptimize double symbol_time_us (double)(1UL spreading_factor) / bandwidth_hz * 1000000.0; if (symbol_time_us 16000) { mod_params.LowDatarateOptimize 1; // 符号时间大于16ms必须开 } else { mod_params.LowDatarateOptimize 0; }这个参数需要在通信双方都配成相同值否则接收端会因为在错误的定时窗口内采样而完全收不到。低于10kbps的场景我都建议按上面这个公式现场算别凭经验拍脑袋。4.3 发射功率别信寄存器PA选择与实测校准SetTxParams命令里的功率参数单位是dBm取值范围-9dBm到22dBm但芯片内部实际配置的是PA的驱动幅度。SX126x有两组PAPA_LP低功率模式用于-9dBm到14dBmPA_HP高功率模式用于14dBm以上。选错PA会导致输出功率严重失真比如在PA_HP下设置10dBm实际量测可能达到17dBm发射谱带外杂散超标。// tx_power.c 根据功率选择PA并设置 void lora_set_tx_power(int8_t dbm) { uint8_t pa_sel 0; // 默认PA_LP uint8_t params[2] {0}; if (dbm 14) { pa_sel SX126x_PA_HP; // 高功率必须选HP } params[0] pa_sel; params[1] (uint8_t)dbm; SX126x_SetTxParams(radio, params[0], params[1]); }实际部署中最大的坑还不是PA选择而是“设置成功≠实测达标”。驱动里写20dBm频谱仪上看可能是18dBm或者21dBm这与板子的射频匹配网络、天线阻抗、供电电压都有关系。尤其是电池供电的LoRa节点电池电压跌到3.3V以下时PA的输出会明显压缩标称22dBm根本推不上去。正确的做法是在开发阶段就用频谱仪做一次功率校准表把“驱动参数→实测功率”整理成一张表贴在产品文档里。量产时驱动里的功率参数只作为期望值真正以频谱仪或功率计的量测为准。没有频谱仪时至少用带峰值检波的接收模块对比RSSI也能发现明显偏差。5. SX126x驱动移植避坑指南5个烧板废时间的真实案例5.1 DIO2没配成射频开关天线端口量不到功率现象初始化明明成功了TX_DONE中断也正常触发但频谱仪在天线端口只能看到非常弱的泄漏信号输出功率比设置值低了20dB以上。原因SX126x的输出级后面通常接了一个射频开关用于在发射和接收之间切换通路。这个开关由DIO2控制但DIO2默认被配置为通用中断引脚。如果不调用SetDio2AsRfSwitchCtrl使能射频开关始终处于接收通路发射信号被完全隔离。解决在初始化序列里加入SX126x_SetDio2AsRfSwitchCtrl(radio, true)必须在每次复位后重新调用因为复位会把该配置恢复到默认状态。5.2 跳过Busy握手程序卡死在“等状态机”现象程序运行到第一次调用SetStandby或Calibrate时停滞调试器显示代码卡在一个while循环里。换一片芯片也一样且与电压无关。原因SX126x在执行部分命令时内部状态机需要持续几毫秒到十几毫秒的时间。早期移植时如果只发送操作码而不等待Busy释放芯片会直接丢弃后续命令。更隐蔽的是NSS时序问题NSS拉高必须给足时间太快的连续访问会让芯片误判帧边界。解决严格按照“拉低NSS→等Busy低→发数据→拉高NSS”的顺序执行。增加超时保护超时后打印错误标志位而不是死等。SPI时钟先降到1MHz验证时序排除走线干扰后再提速。5.3 频率计算差一点点扫频仪看到偏了400kHz现象两块模块配置同样的“433000000”用频谱仪测量发射中心频率却是433.4MHz左右误差达到400kHz量级。接收端开同样带宽偶尔能收到但RSSI比标称差很多。原因直接把十进制频率值当成寄存器值写入SetRfFrequency。寄存器1LSB对应约0.953674Hz400kHz误差意味着寄存器值差了约42万这正好是把频率和寄存器值混为一谈的典型数量级。解决用4.1节的公式换算并且在驱动源码里把换算函数单独抽出加上单元测试。每次改频率都用这个函数计算后再下发不要手工预计算。5.4 收发两端的IQ极性不一致CRC永远过不了现象节点A和节点B用同一套驱动代码A发给B正常反过来B发给A时CRC全部失败。检查SF、BW、CR、频率全部一致无线环境也干净。原因LoRa调制中有IQ极性反转机制用于区分上行和下行链路防止同频自干扰。驱动里的InvertIQ参数在收发两端不一致时接收端的解调星座图翻转数据符号能解出来但CRC校验码对不上。解决自组网场景中把收发两端的InvertIQ固定为0LoRaWAN场景严格按协议设置上行0下行1。改动后两端必须重新上电同时生效。5.5 FixedLength模式的包长度错配收到一堆空包现象使用固定长度包模式PayloadLength配成16但上层协议每一包实际长度在8到32字节之间变化。接收端经常收到CRC错误或者RX_DONE中断触发但读出来的数据全是0xFF。原因固定长度模式下芯片严格按照PayloadLength配置的字节数接收。发送端实际发送的包长小于配置值时接收端会继续在噪声里搜数据补满长度最终CRC必然错误。显式包头模式则每包自带长度信息不存在这个问题。解决开发调试阶段无脑用显式包头模式让芯片自动解析长度。等协议完全固定、每包长度确实不变时再改固定长度能在极端低功耗场景省下几个字节的解调时间。6. 让节点学会“先听后发”用CAD把接收功耗降下来6.1 CAD参数怎么设符号数、带宽和灵敏度取舍CADChannel Activity Detection是SX126x独有的信道活动检测功能芯片在极低功耗下监听前导码检测到LoRa信号才唤醒主机进入正式接收。CAD一次的电流在微安级相比持续RX的十几毫安差距是数量级的。SetCadParams命令的核心参数是CAD符号数通常配2到4个符号配得太少误检率升高配得太多检测周期变长会漏掉短前导码信号。// cad_init.c 初始化CAD参数 uint8_t cad_params[7]; cad_params[0] 4; // CAD符号数4个符号兼顾灵敏度和误检 cad_params[1] LORA_SF7; // 必须与正式接收的SF一致 cad_params[2] LORA_BW_125; // 带宽一致 cad_params[3] LORA_CR_4_5; // 编码率一致 cad_params[4] 0; // 无CAD超时 cad_params[5] 0; // 保留参数 SX126x_SetCadParams(radio, cad_params); SX126x_SetDioIrqParams(radio, SX126x_IRQ_CAD_DETECTED, SX126x_IRQ_CAD_DETECTED | SX126x_IRQ_CAD_OK | SX126x_IRQ_CAD_TIMEOUT, 0, 0);CAD的参数有一个强制要求SF和BW必须与即将接收的报文完全一致否则检测不到。编码率影响较小但建议保持一致。如果系统里有两种SF配置比如SF7和SF10交替使用CAD只能对其中一种生效需要在切换SF后重新调用SetCadParams。6.2 用DIO1中断处理CAD结果不靠轮询省下主控时间CAD完成后芯片会通过DIO1上报结果主控在中断里判断到底是检测到信号还是超时。检测到信号就立刻调用SetRx进入正式接收检测超时则直接回Sleep等待下一轮唤醒全程不需要主控轮询。// cad_irq.c DIO1中断里处理CAD结果 void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin) { if (GPIO_Pin DIO1_Pin) { uint16_t irq SX126x_GetIrqStatus(radio); if (irq SX126x_IRQ_CAD_DETECTED) { // 检测到LoRa前导码立刻开接收窗口 SX126x_SetRx(radio, 0); } else { // 没信号回睡眠等待下一个唤醒周期 SX126x_SetSleep(radio, SX126x_SLEEP_RC_XOSC); } } }这个流程是典型低功耗LoRa节点的收包策略主控定时休眠周期性唤醒做一次CAD没有下行数据就继续睡。配合周期计时器一套双向通信节点的平均电流可以压到10uA以下。我最早给环境监测节点做这套逻辑时就是漏了DIO2的射频开关配置CAD检测正常却收不到实际数据最后用万用表量射频开关的供电才定位到问题。那之后我养成了一个习惯每一版SX126x驱动跑通的第一件事先做一个回读自检确认Busy握手和命令通路正常再调射频别直接拿实物去怼距离。希望这些思路和代码能帮你省下当初我交的那一天。本文还有配套的精品资源点击获取
