Tuya Developer Forum

T1 芯片做rf433 接收发送，接收会有漏包现象，发送会有断包，已使用关闭总中断，还是不行，请问还有什么办法吗？以参考此帖子 viewtopic.php?t=9260，或者有rf433 的demo吗

你好！

问题概述

T1 芯片使用 RF433 进行收发时，接收出现漏包、发送出现断包，已尝试关闭总中断但未解决。

根因分析

关闭总中断是错误的方向——RF433 收发依赖硬件中断及时响应，关闭总中断反而使 RF 硬件 FIFO 无法及时被读取而溢出，加剧漏包和断包。

可能的根因有两个：

RF 收发状态机管理不当：T1 平台的
Code: Select all
```
tkl_subg_send
```
是非阻塞式调用，如果在收到
Code: Select all
```
tx_done
```
回调前就切换到接收或再次发送，会导致发送断包。接收时如果没有持续保持
Code: Select all
```
SUBG_RF_RX_FULL
```
状态（被其他操作打断进入 IDLE），则会出现漏收数据。
RF 中断优先级不够高：T1 的中断控制器（INTC）支持 IRQ/FIQ 优先级配置，如果 RF 中断被 WiFi/BLE 等高优先级中断抢占，会导致数据丢失。

解决方案

方案一：正确使用 RF 状态机

发送流程：

调用
Code: Select all
```
tkl_subg_rf_tx_register()
```
注册发送完成回调
调用
Code: Select all
```
tkl_subg_send()
```
发起发送（非阻塞）
等待
Code: Select all
```
SUBG_RF_CB_EVENT_TX_DONE
```
回调
收到回调后再进行下一次发送或切换到接收模式

接收流程：

调用
Code: Select all
```
tkl_subg_rf_goto_state(SUBG_RF_RX_FULL)
```
进入接收状态
确保接收期间持续保持
Code: Select all
```
SUBG_RF_RX_FULL
```
状态，避免状态空洞
收发切换时先等发送完成再切接收

方案二：提升 RF 中断优先级

[]通过 T1 INTC 优先级机制将 RF 中断设为最高优先级（数值最小）
[*]或将 RF 中断注册为 FIQ 而非 IRQ，获得更高的响应优先级
[*]确保 WiFi/BLE 等中断不会抢占 RF 中断处理

关键文件参考：

Code: Select all

vendor/T1/tuyaos/tuyaos_adapter/include/subg/include/tkl_subg_rf.h

— SubG RF TKL 接口定义

Code: Select all

vendor/T1/T1_os/T1/driver/intc/intc.h

— 中断控制器优先级配置

验证方法

检查代码中
Code: Select all
```
tkl_subg_send
```
调用后是否有等待 tx_done 回调的逻辑
检查接收时是否始终处于
Code: Select all
```
SUBG_RF_RX_FULL
```
状态
在 tx_done 回调中添加日志确认发送完整完成
提升 RF 中断优先级后对比漏包断包率

如有 RF433 demo 需求，建议联系涂鸦技术支持获取 SubG RF 示例工程。

本地知识库检索结果：kb/ 和两个 SDK 文档库里都没有 RF433 专项条目，但平台事实（T1=BK7238 无 sub-GHz 射频）、中断上下文约束（svc_dp 等多条文档）、软解码工程方案都能站得住，可以基于知识层回答。

结论：T1（BK7238）芯片本身没有 433 硬件射频外设，做 RF433 只能「接收头 + GPIO 软件模拟时序」，漏包/断包的根因是微秒级脉宽测量被 Wi-Fi 中断、flash 擦写（内部关中断）、调度抖动打断——关总中断救不了接收（不能一直关），也救不了发送（挡不住 XIP 取指停顿），方向应换成「宽容解码 + 硬件定时器」。

平台事实（出处：wiki 模组-芯片对照）：

T1 = BK7238，片上只有 2.4G Wi-Fi/BLE 射频，没有 sub-GHz 无线电；本地 SDK 文档库里也没有 433 组件或 demo，需自己实现
常见接收头（RXB6/SYN480R 类）输出 OOK 脉冲，EV1527/PT2262 靠测脉宽解位（短约 320µs、长约 1.3ms）

为什么关中断还是不行：

现象	根因
接收漏包	ISR 进场延迟被 Wi-Fi/flash 中断推到几百 µs，脉宽测出来就歪了
发送断包	关中断挡不住 XIP 取指停顿；`while` 循环 + 软延时本身不稳

建议按此优先级改：

宽容解码（改动最小，先试）：脉宽判断窗口放宽 ±30%；EV1527 按键本来就连发 3₅ 帧，收「连续 2 帧一致才生效」并去重，天然抗漏包
硬件定时器捕获：用 timer 输入捕获在硬件里记边沿时间戳，ISR 晚到不丢精度，比 GPIO 中断强一档
发送改定时器/PWM 翻 GPIO：别用关中断死循环
外挂解码（最稳）：用 433 解码小板/小 MCU 解成 UART 数据给 T1，T1 只做业务
ISR 里别调任何 TuyaOS API：DP 上报、日志内部有 malloc/mutex，禁止在中断上下文调（svc_dp/README_CN.md）；ISR 只写 ring buffer，任务里解析

另查两点：接收头离 Wi-Fi 天线远些（2.4G 强发射会把超外差头堵成噪声出乱码）；漏包时间点若与 WiFi 活跃/写 KV 对得上，即印证时序根因。官方 demo 本地库没有，可按宽容解码路线自实现。

以上内容由 AI 自动分析生成，如有疑问请回复补充。