- 博客(42)
- 资源 (2)
- 收藏
- 关注
RSS订阅原创 嵌入式设计模式之策略模式（2）
本文介绍了一种基于策略模式的嵌入式设备多协议通信设计方案。该方案通过定义统一的通信策略接口(CommunicationStrategy)，实现了UART、I2C、SPI等不同通信协议的模块化封装。上下文类CommunicationManager负责动态切换协议策略，自动处理资源初始化和释放。该设计具有协议透明性、运行时动态切换、易于扩展等优势，特别适用于需要与多种传感器通信的嵌入式系统。典型应用场景包括多模通信设备、传感器融合系统和协议适配器等，为嵌入式中间件和硬件抽象层开发提供了灵活的解决方案。
2026-04-13 13:46:41
21
原创 嵌入式设计模式之策略模式（1）
本文探讨策略模式在嵌入式系统开发中的应用价值。传统嵌入式代码常面临条件分支臃肿、动态配置困难、硬件资源冲突等问题，导致代码维护困难、扩展性差。策略模式通过将算法封装为独立对象，实现了三大改进：1）消除复杂条件判断，通过接口统一调用；2）支持运行时动态切换行为策略；3）解耦算法与硬件实现，提升测试性和复用性。典型应用场景包括传感器控制、通信协议切换、资源管理等，使系统能够根据电量、信号强度等环境因素自动调整策略。该模式符合开闭原则，新增功能只需添加策略而无需修改现有代码，显著提高了嵌入式系统的灵活性和可维护性
2026-04-13 11:42:22
45
原创 Aliro协议规范文档与BLE开发指南
Aliro是由CSA发布的标准化协议，支持NFC和BLE两种传输方式，可实现用户设备与读卡器之间的安全访问控制。协议核心包括访问协议、信任框架、传输协议和访问文档四部分。基于BLE的开发流程主要分为：1)BLE广播发现；2)GATT服务发现与连接建立；3)L2CAP通道建立与协议协商。认证流程分为快速阶段和升级阶段，通过证书机制验证身份，使用加密算法保障通信安全。协议支持主动/被动开门触发方式，读卡器根据Kpersistent或AccessDocument做出开门决策。开发需满足BLE5.2以上硬件要求，并
2026-04-10 09:03:54
329
原创 2026年4月10日科技行业热点新闻速递
这一100,000量子位处理器标志着量子计算的转型时刻，使以前无法计算的问题成为可能。增加的量子位数量结合改进的错误纠正，意味着量子计算现在可以用于解决现实世界中的问题，如化学、材料科学和复杂优化。这一进展也标志着真正的AI辅助科学发现的开始，机器可以提出人类研究人员可以验证和发展的新数学证明。关键趋势包括具备复杂推理能力的AI系统成熟、量子抗性安全措施的部署，以及可持续计算技术的持续发展。：2026年，AI行业见证了神经网络推理系统的重大突破，该系统能够执行数学证明和复杂逻辑推理。
2026-04-10 08:53:11
445
原创 AI正在悄悄改变我们的生活：从“普通人“到“AI助手“的蜕变之路
AI正在深刻改变普通人的日常生活，从健康管理到工作效率提升，从学习方式革新到社交陪伴。通过个性化服务和情感智能，AI已从单纯工具转变为生活伙伴，帮助用户实现主动健康预防、高效工作、智能学习等。未来AI将与人类深度融合，渗透到生活各个场景，成为提升生活质量而非取代人类的智能助手。关键在于合理利用技术，让AI真正服务于人类需求。
2026-04-09 13:47:46
364
原创 WiFi诊断以及相关机制介绍
本文提出了一种基于netlink机制的WiFi诊断数据采集方案，通过应用层与驱动层双向通信实现网络状态监测。系统包含在线诊断和实时状态检测两大模块，支持网络性能测试、连接参数采集及环境干扰分析。采用socket通信方式建立netlink通道，通过握手协议确保连接可靠性。设计了三个核心查询接口：获取WiFi速率（协议速率和吞吐量）、通信质量（收发成功率等）及环境参数（信噪比、RSSI值）。方案采用异步通信机制，设置5秒超时限制防止阻塞，并利用互斥锁和条件变量确保线程安全。该方案解决了传统打印输出方式用户感知差
2026-03-17 20:19:19
375
原创 NB-IOT导入评估测试方案
本文介绍了NB-IoT（窄带物联网）相关术语及测试方案。关键术语包括eDRX（扩展不连续接收）、PSM（省电模式）及T3324/T3412定时器。测试方案涵盖传导测试（频率误差、发射功率等）、功能测试（入网、PSM模式等）、组网测试（网络注册性能）、功耗测试（各模式电流）和稳定性测试（长时间运行）。测试需使用专用设备，通过串口连接模块，并关注运营商网络覆盖情况。测试方法包括横向（竞品对比）和纵向（参数对比）比较，重点评估模块在不同运营商网络下的性能表现。
2026-03-10 09:40:05
397
原创 ZigBee Touch Link协议测试和说明
本文介绍了ZigBee TouchLink协议的工作原理及测试过程。ZigBee LightLink(ZLL)协议通过TouchLink实现设备间的直接配网，无需网关。协议定义了发起者(Initiator)和目标者(Target)两种设备类型，详细说明了配网流程：发起者扫描目标设备、创建或加入网络的过程。测试部分展示了使用博流芯片开发ZLL设备的方法，包括目标设备和发起设备的制作，以及多种网络场景下的配网测试结果。测试发现当存在多个目标设备时，建议采用逐个配网方式以避免干扰。文章还提供了抓包分析方法和信道切
2026-03-09 20:25:03
340
原创 ZigBee网络管理相关需求
摘要：本文针对Silicon Labs EFR32系列ZigBee方案存在的网络管理问题进行分析，重点探讨信道切换和节点重入网机制。在WiFi干扰严重时，提出基于通信失败率的信道切换策略（30秒内连续2次失败或累计10次失败触发），并设计了信道选择标准。针对ZED节点入网失败问题，建议采用分级rejoin机制（ZED每5分钟，ZSED每30分钟）。同时分析了休眠节点通信、数据缓存、路由选择等常见问题，为50节点内的小型网络提供了优化方案，平衡了网络稳定性和通信质量需求。
2026-03-09 20:16:35
355
原创 芯科路由相关机制说明QA
打开EMBER_APS_OPTION_ENABLE_ROUTE_DISCOVERY的option选项，发送应用数据后，可以建立路由表信息，如果设备反馈应用层数据后，可以恢复路由表信息。网关路由表建立需要依赖设备上报（router节点和zed节点）应用层数据（ZCL层），接收到设备的应用层数据后自动建立路由信息。网关给节点A发送应用层数据，通过B节点寻找路由后发送给A节点，A节点返回应用层数据，此时将网关将建立A和B的Source Route Table信息。A <----> B <----> 网关。
2026-03-09 19:57:30
203
原创 BLE概率性数据解析失败分析和解决
摘要：本文分析了BLE设备概率性数据解析失败问题，发现是由于快速回连过程中加解密密钥不一致导致。根本原因是设备重启后从Flash恢复的密钥信息中连接号未正确更新，导致不同设备连接号冲突。提出了两种解决方案：应用层在断开时同步保存密钥状态，或SDK在添加linkid时检查并修正重复连接号。建议异常时清除密钥信息并重新认证。该问题暴露了SDK在多连接场景下对异常情况处理的不足，需加强密钥管理的健壮性。（150字）
2026-03-09 09:08:39
374
原创 扫地机产线测试异常问题分析和解决
摘要：针对扫地机新型号在产线测试中频繁出现的WiFi异常问题，分析发现主要存在两类问题：SDIO异常导致WiFi掉卡和STA连接数超限引发驱动异常。通过临时方案增加WiFi状态检测机制，并优化驱动代码消除崩溃打印。根本解决方案采用白名单机制限制非法基站连接，同时修改STA清单管理逻辑。经测试验证，修复方案有效解决了产线异常问题。文章还提出了配网流程优化建议，包括双向认证机制和STA清单管理改进方案，为类似问题提供参考思路。
2026-03-09 09:07:54
391
原创 BLE主机接收WiFi列表概率性异常问题分析和解决
本文分析了BLE主机在接收WiFi列表时概率性崩溃的问题。通过压力测试发现，多连接场景下主机SDK存在异常，具体表现为JSON解析时访问空指针导致崩溃。深入分析发现，从机在发送WiFi列表数据时，序列号6的报文使用了错误的加密密钥，原因是全局密钥变量在多任务处理中被覆盖。解决方案是改用临时变量保存密钥，避免全局变量被修改。测试表明该方案有效解决了问题。该问题反映了多任务开发中变量同步的重要性，需要在架构优化与资源限制间取得平衡。
2026-03-06 09:00:00
374
原创 芯科SDK系统时间分析和改进
本文分析了芯科ZigBee模块系统时间实现的问题。在SOC/NCP模式下，SDK使用RTC或gettimeofday获取系统时间，但当系统校时后可能导致时间判断异常，使线程长时间休眠。通过两种解决方案对比：方案1过滤异常时间值；方案2改用clock_gettime(CLOCK_MONOTONIC)获取设备启动时间，避免校时影响。最终采用方案2从根本上解决问题，确保系统时间不受用户校时干扰，测试验证通过。建议开发者在SDK移植时注意该问题，从根源优化代码兼容性和可移植性。
2026-03-05 17:00:00
337
原创 BLE多连接压力测试死机分析和解决
目前这种情况和上面的情况非常类似，因为现在数据接收在BLE数据接收回调函数中，属于原厂底层数据接收线程（recv_thread），Task优先级28，BLE数据处理在新创建的Task中进行处理，Task优先级是25。在当前情况下，即AES加解密都没有互斥锁保护的情况下，进行压力测试验证，确认是否存在卡死的情况。在实际用户场景中，BLE存在多连接的场景，比如1个主机连接多个从机，或1个从机被多个主机连接的情况，如智能锁BLE作为主从1体，作为主机可以同时连接其他智能锁，也可以被手机或键盘等其他主机连接。
2026-03-05 09:30:00
387
原创 BLE打流概率性崩溃异常排查和分析
本文分析了BLE打流过程中概率性崩溃问题的排查过程。通过崩溃日志定位到SDK代码中订阅列表尾地址异常被修改的问题，经测试缩小范围到Ping测试环节。深入排查发现是由于RSSI计算函数中变量类型错误（u8代替s8），导致数组越界修改了订阅表地址。解决方案是将变量类型改为s8，并强调了数据类型规范使用的重要性。整个排查过程展示了从崩溃现象到根本原因的逐步分析思路，包括日志分析、测试范围缩小、变量跟踪和类型验证等关键步骤。
2026-03-04 15:07:17
378
原创 AES解密崩溃排查和分析
本文分析了蓝牙设备AES解密崩溃问题。当设备使用错误密钥解密时，PKCS7填充剥离函数未对异常数据进行校验，导致指针越界访问或返回异常长度值。问题根源在于PKCS7的cutting函数缺乏对解密数据有效性的判断。解决方案包括：1)限制填充字节范围在0x01-0x10；2)检查数据长度是否满足填充要求。优化后，异常数据将返回0长度或合理长度值，避免崩溃。该问题具有普遍性，提醒开发者在AES实现中需考虑异常情况处理，并建议完善设备间密钥同步机制。
2026-03-04 11:42:34
348
原创 内存问题-字节对齐
本文探讨了开发中常见的字节对齐问题。32位系统默认4字节对齐，64位系统默认8字节对齐，但协议处理时需注意特殊对齐要求。通过#pragma pack指令可手动设置对齐方式。文章分析了1字节和4字节对齐对结构体内存分配的影响，指出不同对齐方式间的数据复制可能导致异常。以ZigBee平台为例，不同厂商协议栈采用不同对齐方式（博流多用1字节，芯科/泰凌微多用4字节），混合使用时易引发内存异常甚至崩溃。案例显示，当应用层使用4字节对齐而底层协议使用1字节对齐时，结构体转换可能导致指针赋值错误和内存访问异常。开发中需
2026-03-03 19:48:01
310
原创 内存问题-柔性数组
柔性数组是C99标准引入的特性，允许结构体最后一个成员为未知大小的数组。其特点包括：需前置其他成员、sizeof不计算其内存、需用malloc分配大于结构体的内存。在Zigbee协议案例中，柔性数组简化了属性列表管理，相比指针方案减少了内存分配次数和碎片，避免了二次释放风险，且更节省内存空间。指针方案存在使用复杂、易内存泄漏、产生更多碎片等缺点。柔性数组提供了更高效、安全的内存管理方式。
2026-03-03 19:24:10
198
原创 芯科ZigBee网关概率性发送数据失败原因分析和解决
摘要：本文分析了Telink外置PA模块ZigBee网关在节点数超过16个时出现概率性发送失败的问题。通过排查发现，当节点从邻居表删除后，源路由表信息失效导致发送异常，只有节点重新上报数据更新源路由表后才能恢复。该问题源于芯科协议栈缺陷，在节点超过邻居表容量（16个）时会出现。最终解决方案是升级协议栈版本至6.7.10，修复了源路由表失效问题。文章强调了问题定位的重要性，避免采用临时规避方案可能带来的长期隐患。（150字）
2026-02-27 09:46:12
555
原创 BLE传输WiFi列表的问题分析
本文分析了BLE配网过程中WiFi列表上报出现的中文乱码和显示异常问题。研究发现主要原因是：1）不同路由器采用GB2312/UTF-8编码导致中文乱码；2）手动拼接JSON格式时未处理特殊字符转义；3）JSON库内存消耗过大（20个热点约10KB）。解决方案包括：优先使用JSON标准库、增加异常测试用例、优化内存分配策略。针对内存受限设备，建议将JSON处理迁移至WiFi模块，BLE仅作数据透传。通过方案优化可有效解决WiFi列表的接收和显示问题，同时降低内存消耗。
2026-02-13 10:06:37
994
原创 芯科ZigBee网关数据发送延时问题分析和优化
本文分析了ZigBee网关数据发送延时问题及其优化方案。测试发现单包数据发送延时在100-1000毫秒间，平均500毫秒，主要原因是系统调度时间过长（默认1秒）。通过将系统调度时间缩短至10毫秒，并采用定时器机制优化缓存数据处理，使第一包数据发送延时降至20毫秒内。同时保留200毫秒的包间发送间隔，确保多包发送时的稳定性。最终方案在不修改系统调度机制的前提下，通过应用层定时器实现了发送延时的显著优化，兼顾了系统性能和移植性。
2026-02-13 10:00:12
656
原创 FreeRTOS内存问题分析和排查
本文针对FreeRTOS系统中的内存管理问题展开分析，提出了一系列调试方法和解决方案。文章首先指出FreeRTOS缺乏完善的内存检测工具，导致内存泄漏和踩内存问题难以定位。系统分析部分详细介绍了FreeRTOS的5种内存管理方式，并推荐使用系统自带的堆栈溢出检测和内存分配失败回调功能。对于内存泄漏问题，作者提出改进方案：通过重定义malloc/free回调函数，记录调用者地址、分配大小等信息，并支持实时查询内存状态。针对踩内存问题，文章列举了常见原因（如指针未初始化、越界访问等）和排查方法，建议结合core
2026-02-12 10:24:49
787
原创 RS预览失败问题分析和解决
摘要：某自研扫地机器人(RS2)在使用WiFi6路由器时出现预览失败问题。经排查发现，WiFi6路由器与RS2的rtl8192fs网卡存在兼容性问题，导致服务器推送的TCP数据包最后4字节被概率性截断。通过原厂提供的补丁修复FCS机制缺陷后，问题得到解决。验证测试表明，使用tcpdump抓包是复现该问题的有效方法，而TCP客户端接收数据方式难以复现。该案例为类似WiFi6兼容性问题提供了排查思路，但老网卡与新路由器的兼容性测试仍需进一步验证。
2026-02-12 10:24:30
723
原创 Bluez-BLE配网在IOS系统上绑定问题分析和解决
摘要：本文分析了BLE配网在iOS系统上出现的绑定问题。当iOS设备连接BLE时，系统会弹出绑定请求，而安卓设备无此现象。通过抓包分析发现，iOS设备会发送认证请求并触发设备端的加密等级调整。进一步排查发现，设备端主动请求电池电量信息导致认证流程被触发。解决方案包括：1) 禁止设备在低加密等级时自动升级；2) 取消设备对iOS电池电量的请求。最终实现BLE配网功能正常运作，同时指出协议设计阶段应充分考虑此类兼容性问题。文中展示了如何利用Hcidump、无线抓包等工具进行问题定位的方法。
2026-02-11 11:05:48
1049
原创 BLE从机更新连接参数失败问题分析和解决
比如，主机连接间隔是100毫秒，从机希望更新到150毫秒，但是从机只发起了150毫秒的更新请求，但是没有更新完成的回调和异常的错误打印，连接间隔依然还是100毫秒。所以也可以排除业务上不合理的设计导致的问题。此时，连接间隔的更新请求数据包的event值也是1202，对于主机来说，在刚发送LL_CHANNEL_MAP_IND报文（信道表更新）的时，马上接收到了连接参数更新请求。同时，主机在instant参数尚未释放之前，没办法处理新的需要使用instant的协议，包括连接参数更新，PHY更新，信道更新等。
2026-02-11 10:29:43
920
原创 WiFi设备连接AP隐藏SSID出现断网问题分析
摘要：测试发现设备在连接隐藏SSID路由器时出现断网或长时间无法连接的问题。通过分析发现，隐藏SSID的路由器不会响应不携带SSID信息的ProbeRequest。Linux系统下使用wpa_supplicant工具时需设置scan_ssid=1以强制携带SSID信息；RTOS驱动如rtl8188已自动兼容此需求。排查时需确认驱动是否支持隐藏SSID，并根据返回状态判断是干扰问题还是驱动缺陷。解决方法包括优化ProbeRequest机制和调整抗干扰参数。（149字）
2026-02-10 08:51:34
581
原创 关于WiFi配网概率性失败问题解决和分析
摘要：针对两款IPC设备在特定路由器环境下WiFi配网失败的问题，经过排查发现是由于RTOS系统移植的RTL8188驱动存在缺陷，无法正确处理AP桥接模式下多个相同SSID路由器的识别。问题表现为设备在扫描网络时未能记录各SSID对应的MAC地址，导致四次握手失败。解决方案是修改驱动使其优先选择信号最强的SSID并记录其MAC地址，经测试验证后发布固件更新成功解决问题。后续将增加AP桥接场景的测试用例，完善驱动移植验证流程。
2026-02-10 08:51:09
844
原创 IPC产线上WiFi批量测试失败问题排查
摘要：某型号IPC在产线测试中出现2.5%的WiFi模块不良问题。经排查发现：（1）部分WiFi模块未完成校准即流入生产；（2）RTOS系统驱动移植存在缺陷，包括内存分配未做参数校验、文件读取函数逻辑错误等问题。解决方案包括：修复驱动代码（增加参数校验、优化错误处理）、完善生产流程（加强模块校准管控）、增加产测拦截机制。经验教训：需加强模块生产管理、提高代码健壮性、完善异常处理机制。问题最终通过固件更新和生产流程优化得到解决。
2026-02-06 13:43:43
700
原创 WiFi在TKIP加密情况吞吐量低问题排查和分析
摘要：针对IPC设备视频卡顿问题，经测试发现采用WEP/TKIP等老旧加密方式时WiFi吞吐量仅0.5M（正常需2M以上），导致视频卡顿。对比测试显示其他厂商设备在相同加密方式下可达3-4M吞吐量。分析表明该WiFi模块在老加密算法下速率协商过于保守（发送速率仅1M）。通过调整11b/11g协商机制和速率切换阈值，优化后吞吐量提升至3M以上，满足视频流畅需求。问题根源在于模块对老旧加密方式的支持不足，经原厂确认后通过协议参数调整解决。
2026-02-06 13:43:18
892
原创 使用API调用wpa-supplicant失败原因分析和解决
摘要：本文分析了WiFi模块开发中通过system/popen接口调用脚本时wpa_supplicant启动失败的问题。研究发现，脚本中使用"&"后台运行方式会导致子进程退出时wpa_supplicant也被终止，而改用"-B"参数使wpa_supplicant作为守护进程独立运行后问题解决。该案例提示开发人员需深入理解系统调用机制和参数含义，避免因进程关系导致的服务异常。建议类似场景统一使用"-B"参数确保后台服务稳定运行。（149字）
2026-01-30 11:27:05
907
原创 IPC使用WiFi预览视频卡顿问题定位和分享
本文档系统分析了定制设备使用WiFi预览视频卡顿问题的技术根源，提出了针对性解决方案，并总结了测试与开发流程的改进方向。
2026-01-30 11:26:27
877
原创 Silicon labs ZigBee网关串口指令失效排查和解决
摘要：本文分析了ZigBee网关在测试模式下AT指令无响应的问题。通过排查发现，问题源于协议栈中NDEBUG宏定义关闭导致assert断言失效，进而使串口数据处理函数中的关键write命令未执行。解决方案是移除assert中的函数调用，并全面检查代码中类似情况。案例表明：1）原厂代码可能存在设计缺陷；2）assert中的逻辑在release版本中可能失效；3）框架变更需充分验证。该问题排查过程采用了版本回退和二分法等有效手段。
2026-01-29 09:51:05
679
原创 WiFi产品创建softAP失败问题分析和解决
摘要：某项目使用RTL8192FS WiFi模块时，发现WLAN1在信道12创建SoftAP失败。分析发现是由于中国区信道规划（CN）默认将12/13信道设为被动扫描模式。通过修改驱动代码，将1-13信道的scan_type设置为1（支持主动扫描），解决了问题。同时发现模块因单射频限制，WLAN0和WLAN1必须工作在同一信道，且SoftAP创建依赖于STA连接的信道状态。最终建议：1）修改信道规划支持全信道；2）注意单射频信道同步特性；3）更新驱动版本解决缺陷。
2026-01-29 09:45:11
691
原创 PSE芯片驱动移植过程中IIC问题定位分享
硬件驱动调试时，尽可能让硬件人员提供原理图和PCB图。针对需要开发的驱动程序，了解基本的通信原理和可能发生问题的应对措施；开发驱动过程中，需要认真的仔细阅读芯片文档资料。部分芯片厂商，资料可能不全，需要提出问题才能进一步提供资料。本例中芯片就是一个例子。在软件异常情况下，可以先进行模块测试，或者局部测试，将问题定位到最小化，最后找到问题根源；在软件排查和经验不足情况下，可以借助测试工具，如示波器，万用表等。
2026-01-28 14:47:10
577
原创 芯科（Silicon labs）ZigBee系统时间分析和改进
本文分析了芯科ZigBee模块在系统时间实现上的缺陷问题。当使用gettimeofday函数获取系统时间时，若在运行过程中进行时间校准，会导致任务调度异常甚至"死机"现象。文章提出了两种解决方案：方案1通过过滤异常时间差来规避问题；方案2则从根本上修改时间实现方式，采用clock_gettime(CLOCK_MONOTONIC)获取设备启动后的计时时间，不受系统时间校准影响。经过验证，方案2能有效解决问题且更具兼容性和移植性。该问题在最新SDK版本中尚未修复，开发人员需注意优化。
2026-01-28 11:27:45
578
原创 芯科网关设备入网异常排查和分析
稳定性测试的ZigBee网关，下面连接了24个Router节点的ZigBee测试模块，一直都在正常通信和工作。偶然情况下，为了验证一个router节点的入网问题，我发现router节点始终没有入网成功。一开始，以为当前信道干扰太大导致的，切换到干扰较少的26信道进行验证测试，发现还是不能正常入网。于是我更换其他的router节点进行测试验证，发现也是存在同样的问题，不能入网且设备最后主动离网。同时，这些设备添加到其他网关上都是正常的，没有出现失败。
2026-01-27 14:01:25
617
原创 基于BLE的无线串口的设计方案和思路
BLE串口工具可以通过串口指令开启BLE远程串口，接管设备串口命令等功能。这种情况下设备的串口需要注意下，是否需要支持这样的功能，如果设备的BLE模块和主机通过串口连接，可能会存在和主机断开的问题。5、 设备的命令透传也是相同的情况，如果支持串口命令输入并且可以支持BLE串口工具的远程透传命令。再次开启BLE串口功能，BLE串口工具需要重复上述的步骤。PC串口和BLE串口工具使用物理串口连接，BLE串口工具和设备通过BLE连接。4、 设备在开启BLE串口后，所有的串口日志全部转发到BLE串口的TX通道上。
2026-01-27 10:25:51
503
原创 BLE HID协议测试验证
设备要实现无APP自动重连和绑定，那么设备必须注册相关HID的UUID。以测试demo为例，直接使用平台的HID遥控器为例。具体没有实现的限制，实际并不会正常使用。设备如果还需要支持某公司的GATT标准，那么需要再增加该公司相关的GATT协议部分。测试固件中只增加1路write通道进行测试验证。
2026-01-13 11:04:14
649
原创 BLE随机可解析地址使用和测试验证
手机和设备绑定后，每次广播的地址只会显示绑定那次的广播地址（是不是这样可以让使用人不会连接错误的设备？比如，上面图中的绑定时候设备的广播地址是“5D:AD:A9:8B:CA:C7”,手机连接并且绑定后，后面设备广播地址更新后，这个显示地址一直都是这个。默认情况下，随机可解析地址在广播状态下会定期进行更新，例如本款测试模块默认15分钟更新一次随机地址，可修改成1分钟更新一次，方便测试验证。设备重启后，更新随机可解析地址，使用新地址进行广播，这时候手机还是显示之前的广播地址。上述完成修改后，重新烧写程序。
2026-01-09 10:02:10
467
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人