关于SDK中的蓝牙中断

we_2946009406

看到mesh/main.c ⽂件， irq_handler 函数中 BLE 相关中断的处理⼊⼝ irq_blt_sdk_handler()，发现该函数似乎被封装了无法查看内容

请问如果确实有接收到上位机的蓝牙指令，该中断是否有相关标志位被置位，或者有相关变量参数让我能够第一时间判断是否成功接收到了指令？网上搜了一下相关帖子太少了没找到

TL_SHENGFENG

你需要做什么？

we_2946009406

TL_HSF 发表于 2024-12-30 14:56
你需要做什么？

您好，目前的项目是蓝牙控制灯板，因为显存分辨率高了、显示图像复杂以后，在更新显存的循环要循环较长时间，若在循环途中蓝牙中断接收到指令后，也需要在外部判断是否接受到指令，此代码是串行执行，导致并不能在接收蓝牙指令的第一时间重新开始新的显示

现在的想法是SDK的蓝牙中断irq_blt_sdk_handler是否有标志位之类的好让我判断是否确实接收到的蓝牙指令，从而退出当前的循环或者复杂代码，从头开始执行显示的代码

TL_SHENGFENG

你的上位机是什么，用什么接口发的指令，接口不一样所对应的中断也是不一样的

we_2946009406

TL_HSF 发表于 2024-12-30 19:20
你的上位机是什么，用什么接口发的指令，接口不一样所对应的中断也是不一样的
...

新年快乐，上位机使用的是 telink 的 sdk 中的

android/src/main/java/com/telink/ble/mesh/foundation/MeshService.java

中的

public boolean sendMeshMessage(MeshMessage meshMessage)

TL_SHENGFENG

adv_filter_proc 在里面根据指定的内容进行判断就行

we_2946009406

TL_HSF 发表于 2025-1-6 10:41
adv_filter_proc 在里面根据指定的内容进行判断就行

好的谢谢，那就拿这个adv_filter_proc函数举例，我发现https://wiki.telink-semi.cn/tools_and_sdk/Driver/doc/kite/html/md__project_1__table_of__content_03__t_s_i__core__features.html或是SDK开发手册都没有提到这个函数的用法，那我应该从哪里了解呢？还是说我只能去看这个函数源码来了解？

另外目前项目遇到两个问题：
1、两块泰凌微的板子，与上位机连接后成为了一主一从的节点。目前我们的理解是为了提高主从从节点的命令接收的同时性，主节点会调用转发函数（被添加到程序的多处地方提高转发及时性）去将接收到的上位机指令第一时间转发给从节点。若代码在运行到一个耗时较长的循环时，就无法及时转发，此时主从节点根据上位机指令的接收时间就存在较大差异。
· 我们想到一个尝试性的解决方案是在telink_sig_mesh/vendor/mesh/main.c的检测蓝牙中断irq_handler中，在irq_blt_sdk_handler()后添加“转发函数”和“判断是否有指令到来函数”，这样主节点在接收到上位机指令的第一时间能够转发指令，从节点也能第一时间接收到转发来的指令，同时两个节点也能第一时间判断到有指令来，退出当前循环。但实测下来在中断中添加转发函数会导致设备认领时死机，具体在何处卡死尚未研究。
· 另一个方案就是只能尽可能在更多的地方，甚至是复杂循环的内部添加转发函数
所以想问下SDK中是否有合适的函数或者方案去解决这个问题

2、主节点相较于从节点是否有在执行一些较为复杂的代码？我们用两块泰凌微各自驱动显示屏，抛开第一点提到的接收指令的时间差外，两块板应保持一致的进度显示。但是实测下来发现主节点所驱动的显示屏动态图像进度和从节点比会越来越慢。
我们的一个猜测是主节点要与上位机通讯所以会导致显示图像慢些，为了验证这个猜想，我们先通过上位机指令让两块板子同时（几乎）显示动态图像，随后关闭上位机（断开上位机的连接），但是发现这种现象仍然存在。

TL_SHENGFENG

adv_filter_proc需要你自己去看下源码是怎么处理的。
1.对于gw node而言，收到上位机的指令是不会跑中断函数的，而是在执行loop里的app_hci_cmd_from_usb_handle，对上位机发出的命令进行处理转发的。另外，你把转发函数放在中断里面，肯定会出现死机的，因为中断栈很小的。这里你说的“耗时较长的循环”，大概是多久呢。
2.要看两个节点的耗时，可以在loop的前后进行打桩，就能看出来