
1. 无线模块选型时为什么WiLink 8值得放在备选清单里做嵌入式无线产品这些年我踩过最大的坑不是软件而是选型。曾经有一款手持终端主控已经选了一颗不带Wi-Fi的Linux SoC评估过板上集成射频方案也评估过外挂模块最后折腾了一圈还是用回了TI WiLink 8系列的模块形态。原因不复杂WiLink 8不是单纯的“Wi-Fi蓝牙二合一”芯片它在接口、驱动成熟度、共存处理和认证资料方面都做得比较完整对于需要快速落地的产品来说可以省掉大量底层的射频和协议栈功夫。先说清楚这个系列是什么。WiLink 8是TI德州仪器的无线连接方案家族覆盖Wi-Fi 802.11 a/b/g/n/ac以及Bluetooth/BLE双模协议。产品形态有QFN裸芯片和集成好晶振、匹配网络的模块两大类常见型号包括WL1801、WL1805、WL1807、WL1811、WL1815、WL1831、WL1835、WL1837、WL1857等。面向的场景也很广从车载信息娱乐系统、医疗设备、工业手持终端到扫地机器人、智能家居网关都有人用。很多人一看到“模块”就默认这是给单片机扩展无线用的但WiLink 8的实际主力战场其实是Linux应用处理器它通过SDIO跑Wi-Fi、UART跑蓝牙主机端跑Linux内核驱动BlueZ协议栈处理蓝牙。这种方案的好处是主控不用换软件栈用的都是标准接口。我个人的选型评估有一个固定清单第一Wi-Fi频段和吞吐量是否覆盖产品需求第二蓝牙版本是否匹配目标应用第三主控有没有可用的SDIO/UART尤其是SDIO不是所有SoC都方便外扩第四驱动对当前Linux内核版本的支持情况第五温度范围和车规/工规需求第六认证资料和参考设计的完整度。WiLink 8系列在这几项上表现比较平均特别是WL1837和WL1857这类双频蓝牙的型号很多行业客户用了很多年资料和问题反馈都沉淀得不错比拿一颗新芯片从零开始省心。不过它也绝不是没有缺点的方案。比如接口是SDIOUART不是现在很多主控更顺手的USB接口再比如驱动虽然mainline里有部分支持但完整的固件、配置工具和性能调优还是依赖TI官方处理器SDK。这些问题会在后文专门讲。2. 硬件连接与射频布局把WiLink 8当成合作伙伴而不是外设2.1 SDIO和UART先搞清楚主机和模块之间怎么握手WiLink 8模块的硬件连接看起来很简单Wi-Fi用SDIO蓝牙用UART但细节非常多。SDIO接口至少要接CMD、CLK、D0-D3四根数据线的其中一部分如果是SDIO 2.0通常跑50MHz4-bit模式吞吐量更高。这里要注意和主控的SDIO控制器时钟、电压匹配WiLink 8的I/O电压是1.8V很多主控的SDIO默认是3.3V电平转换或者主控侧改成1.8V模式是必须做的否则模块会进入反复初始化失败的状态。我见过不少硬件工程师把VIO直接拉到3.3V结果Wi-Fi长期无法注册网络最后查出来是I/O电压超标导致模块工作不稳定。蓝牙走的是标准HCI UART通常用UART2或者任意一个支持流控的串口接四根线TXD、RXD、CTS、RTS。CTS/RTS必须接不要省。蓝牙HCI包对字节时序敏感没有硬件流控的话系统稍微调度抖动就会出现指令超时或者ACL数据丢失。实际调试时如果发现蓝牙偶尔能搜到设备但连不上大多数情况就是流控没接对。2.2 电源、时钟与复位时序错一步模块就哑火WiLink 8模块供电一般不复杂但上电时序必须对。一般来说需要给VBAT供电I/O域VIO也要独立受控。不少参考设计里用一颗LDO给VBAT供电再用一颗小LDO或者主控侧GPIO控制VIO的EN。上电顺序要求VIO先稳定然后再给VBAT或者至少一起上不能先VBAT后VIO。原因和芯片内部ESD保护回流有关顺序反了会概率性造成模块不起振。时钟方面多数WiLink 8模块板载了晶振直接用就可以但外部输入时钟的版本需要注意。如果用的是QFN自己设计晶振电路那就得关注晶振的精度和负载电容RF性能对晶振频偏非常敏感。 我建议做前几版硬件时直接选模块形态把晶振、匹配电路都交给模块厂家处理等方案稳定了再考虑做QFN降成本。复位引脚也要单独接出并加RC延迟不能和主控复位共用同一个电阻电容直接拉死。模块内部固件需要在上电后有一段时间完成加载如果你的复位信号释放太早模块日志会出现“Failed to load firmware”之类的错误。遇到这种情况可以先量一下复位释放到模块SDIO CMD引脚开始通信之间的时间间隔正常应在10ms到100ms量级。2.3 天线选型与射频布局No Clear ZoneNo ServiceWiLink 8作为外挂模块天线的选择直接决定整机性能。模块本身通过IPEX座或者邮票孔连接天线天线形式可以是PCB天线、陶瓷天线或外置棒状天线但不管哪种必须保证天线区域下面完整的参考地平面和净空区。最容易犯的错是把天线放在PCB边缘后走线经过天线正下方或者在模块背面铺了一块不连续的地。实测中这样的设计会让Wi-Fi灵敏度下降6到10dB距离直接缩短一半以上。对于一个标称-90dBm灵敏度的方案表面看指标不错实际现场丢包丢到你怀疑人生。天线走线还有一点要特别注意从模块天线引脚到天线匹配网络走线阻抗要控制在50欧姆左右并且不要打太多过孔。过孔会引入寄生电感对高频损耗很大。如果板厚、层叠选择有问题至少要做阻抗仿真或者干脆把天线座放在模块附近尽可能缩短这一段传输线。另外天线尽量远离高频接口和屏蔽罩尤其是金属屏蔽罩不能距离天线太近否则天线谐波会被严重吸收。3. 软件集成从内核模块到蓝牙配对的完整路径3.1 先把Linux内核模块编译出来那个“building kernel modules”的坎WiLink 8在Linux下使用兼容cfg80211/nl80211的驱动架构驱动由TI提供常见的有wl18xx、wlcore等模块。厂商SDK里通常会预编译好但如果你想用它适配自己的内核就需要重新编译内核模块。很多人第一次走这个流程会卡在一个非常基础的错误提示“error: an error occurred while performing the step: building kernel modules”。这句话的直译就是编译内核模块的某个步骤失败了但真正原因往往不在这句话而在它前面的几行。最常见的两种可能一是内核源码目录没有配置过也就是缺少.config文件和编译生成的头文件二是当前的交叉编译工具链版本和内核源码要求不匹配导致编译器找不到某个标准头文件或内联函数定义。我建议的处理顺序是先确认内核源码已经用你目标板卡的默认配置编译过一次确保include/generated/autoconf.h以及Module.symvers这些文件存在。再确认使用同一个交叉编译工具链编译内核不要让内核用arm-linux-gnueabihf-然后模块用全志的工具链这种组合经常会出现隐性问题。进入TI提供的驱动目录运行make ARCHarm CROSS_COMPILE... KERNEL_PATH...注意KERNEL_PATH要指向内核源码根目录不是/lib/modules/$(uname -r)/build下的任何预编译目录。编译成功后把生成的.ko文件拷贝到根文件系统的/lib/modules/内核版本/wireless/目录下再运行depmod -a。很多开发者会跳过第1步以为模块编译不需要事先构建内核结果是各种宏定义缺失报错位置五花八门。编译流程虽然繁琐但每一步都有明确的输出只要把日志从下往上读定位到最底下的第一个error问题基本就解决了。3.2 “cannot find module”不代表模块不存在在目标板上执行modprobe wl18xx时遇到modprobe: module wl18xx not found第一反应都是去查路径。但还有个很容易忽略的原因模块编译用的内核版本和运行内核版本不一致depmod在生成模块依赖时会把内核的vermagic写进依赖文件只要不一致modprobe就拒绝加载。你手动执行insmod /lib/modules/.../wl18xx.ko可能还会碰到“Invalid module format”就是版本校验失败。如果是这种问题不要硬改模块代码更不要用--force跳过校验正确的做法是重新用目标板当前内核的编译环境去编模块。另外如果用的是TI处理器SDK自带的内核最好直接用SDK里的build脚本不要自己从kernel.org拉一套内核来配。因为TI的驱动补丁可能没有完全进入mainlineSDK内核才有完整的板级配置和固件文件。WiLink 8模块在运行时还依赖固件文件比如wl18xx-fw-4.bin存放在/lib/firmware/ti-connectivity/目录下。如果modprobe加载驱动成功但dmesg里提示“Failed to request firmware”那就是固件文件缺失或者路径不对。这个坑也很隐蔽因为驱动编译和固件是完全两回事往往编译过了运行才会暴露。3.3 HCI UART和蓝牙协议栈把“Serial Bluetooth Terminal”用起来Wi-Fi驱动跑通后蓝牙调试是另一个环节。Linux下蓝牙协议栈一般用BlueZWiLink 8的蓝牙通过HCI UART挂在串口上。硬件上连接后软件上需要先用hciattach把串口初始化为HCI设备比如hciattach /dev/ttyS1 texas 115200 flow注意这个命令里的texas是驱动对应的HCI UART协议名波特率默认是115200但实际模块支持更高速度比如921600。如果你在设备树里配置了蓝牙也可以用hci_bcm这种方式直接注册但需要确保串口的clk和device-wakeupGPIO设置正确。调试蓝牙时我建议把串口工具接在UART_TX/RX上用一根USB转TTL线查看HCI层的数据。这里并不是要截获应用层数据而是通过看HCI事件码判断模块是否正常开机。比如手动往串口发送HCI Reset命令01 03 0C 00如果模块返回一个04 0E 04 01 03 0C 00的事件包说明模块固件已经跑起来了。这个技巧在模块连不上、配不上对的时候特别有用可以快速区分是模块没有工作还是上层协议栈的问题。手机上用的“Serial Bluetooth Terminal”这类工具本质就是通过SPP或BLE串口透传调试数据对嵌入式开发者来说也可以反过来验证模块的SPP通道是否正常。4. 现场问题复盘热点、GPS与连接不稳定的实际案例4.1 移动热点起不来的根因网络接口没被当成可用接口有朋友在基于WiLink 8的板子上跑Linux想用Wi-Fi做一个AP热点但每次使能AP都失败系统甚至提示“我们无法设置移动热点因为你的电脑未建立以太网、Wi-Fi或手机网络数据连接”。这个报错虽然常见于Windows其实在嵌入式Linux里也有对应的逻辑hostapd启动前系统需要判断无线网卡是否支持AP模式、接口是否处于UP状态并且完成了IP配置。WiLink 8驱动是支持AP模式的但往往需要双重确认第一iw list输出里要能看到AP字段第二接口不能还在managed模式下就直接启动hostapd。正确的步骤是iw dev wlan0 set type ap ip link set wlan0 up如果iw list里没有AP模式那多半是固件加载版本不对或者内核配置里没有启用CONFIG_CFG80211的P2P/AP支持。还有一种情况是SDIO接口的电源管理进入runtime suspend导致网卡在启动AP时无法唤醒。可以在设备树里把cap-power-off-card关掉再试。热点启动后还要记得配DHCP服务否则设备能连上去但拿不到IP就会一直转圈。很多人在hostapd.conf里只写了ssid和wpa_passphrase忘记配置interfacewlan0和drivernl80211结果服务起不来。用hostapd -dd /etc/hostapd.conf这种前台调试模式输出会直接告诉你卡在哪一步。4.2 蓝牙GPS输出从串口波特率到SPP透传一类很典型的应用是蓝牙GPS接收机GPS模块连到主控的UART主控通过WiLink 8蓝牙做SPP透传把NMEA语句发送给手机。这个方案在户外设备上很常见但每次联调都能遇到几个相同的问题。第一个问题是串口波特率不匹配。GPS模块默认波特率有可能是9600也可能是38400而主控串口默认配置经常是115200。如果你打开“Serial Bluetooth Terminal”连接后一片空白先用逻辑分析仪直接抓主控侧UART的波形确认波特率是否匹配。这种原始验证方法在链路复杂时非常有效比拿着手机配对、找软件问题要快得多。第二个问题是流控。GPS数据是连续不断的一旦蓝牙SPP连接的backlog满了UART侧如果没有开启流控GPS数据就会丢。WiLink 8的蓝牙UART我前面强调过CTS/RTS必须接就是为了在这类场景下避免底层丢包。如果硬件已经没法改也可以在软件里把UART接收改成队列节流处理但不能完全消除背压长期运营还是会出问题。第三个问题是Mobile APP侧从SPP切到BLE。很多现成的蓝牙串口工具默认走BLE连接而WiLink 8的SPP是在经典蓝牙BR/EDR上跑的两者不通用。连接前先在APP里选择“Classic Bluetooth”模式再看是否能看到SPP UUID。这个问题和模块无关但却是现场最常被误判为模块故障的原因。4.3 2.4GHz Wi-Fi和蓝牙的共存WiLink 8的PTA也不是万能的WiLink 8在硬件层面做了Wi-Fi和蓝牙的共存仲裁但双频段同时工作时2.4GHz Wi-Fi和蓝牙仍然是互相抢占空中的。实际测试中蓝牙扫描期间Wi-Fi数据帧延迟明显升高Wi-Fi下载大文件时蓝牙鼠标也会有偶发卡顿。这不是模块坏了而是2.4GHz频段的物理限制。解决共存问题的思路有三个层面。第一是合理安排蓝牙扫描窗口比如降低Le scan window和Le scan interval的比率让扫描在Wi-Fi空闲时进行。第二是打开Wi-Fi侧的省电和BSS最大闲置时间设置避免Wi-Fi进入链路保护模式和蓝牙反复抢占。第三是硬件上尽量拉开天线距离或者使用支持天线分集和外部PA方案的WiLink 8参考设计。不过实际产品通常做不到完全隔离最后我会优先保证对延迟更敏感的一路往往是蓝牙音频稳定。5. 量产与长期维护Demo跑通后才是真正的开始5.1 模块化方案给认证省下的时间比你想象的多用WiLink 8模块形态做产品很大程度上是为了射频认证。模块本身如果已经通过FCC、CE等认证那么你的整机可以沿用模块的射频报告只需要补做天线和EMI相关的测试认证周期可以压缩一大截。但这里有个前提不能随意更换天线型号。同一个模块换一根增益更高的天线就会导致认证失效。我见过一个项目工程师为了省成本换了一根PCB天线结果项目在FCC认证阶段被卡了两个月。如果预算允许选模块时尽量选和你的目标天线接近的评估套件型号来做参考设计。TI的评估板资料里通常会标注天线类型和厂商照着抄能少走很多弯路。千万不要只拿模块参考原理图然后自己瞎画天线匹配网络射频匹配不是靠经验猜的要靠网络分析仪和频谱仪调。5.2 温度、ESD和长期可靠性WiLink 8的工作温度范围一般能覆盖-40到85摄氏度不同型号有差异但整机环境温度高时射频性能会下降。我做过一个户外设备夏天太阳直射时Wi-Fi速率掉得很厉害后来发现是模块PCB局部温度接近85度晶体振荡器频偏变大导致OFDM子载波间干扰增加。解决方法是把模块放在通风孔附近并降低主控对模块的灌胶覆盖面积。ESD防护也要特别注意。蓝牙天线的引入路径很容易把静电带进SoC在模块电源、复位、任何外部接口上都要加TVS管。哪怕模块自身有一定防护能力也不能当作整机ESD的依据特别是一些工业手持设备用户经常在干燥环境下手持操作静电放电不过是一个很大的风险隐患。5.3 软件供应链维护别让长期项目死在固件依赖上最后再讲一个偏管理层面的经验WiLink 8的驱动和固件是跟着TI处理器SDK走的如果你的产品生命周期超过三年建议从项目一开始就锁定SDK版本并且把当前使用的固件文件、内核补丁单独保存到公司的代码仓库。不要只依赖上游网站下载因为几年后链接变更或者产品EOL你可能会发现自己手里只剩一个二进制文件而源补丁已经找不到了。另外Linux内核版本升级时WiLink 8的适配问题会暴露出来。每次升级都要回归测试Wi-Fi与蓝牙的共存场景尤其是蓝牙SPP和BLE同时使用的情况。不要因为内核补丁看起来能编译过去就直接合入主线那样大概率会在某次系统休眠唤醒后蓝牙一直卡在controller missing的状态。根据我个人经验WiLink 8系列最大的价值在于它是“已经验证过的参考路径”。作为工程师我们在实际开发中更需要的不是最前沿的参数表而是稳定可靠的资料、好复现的坑位解决方法和能直接跑通的参考设计。这些WiLink 8恰好都能给你。如果你正在评估外挂Wi-Fi/蓝牙模块完全可以先拿一块官方评估板把SDIO/UART接好用默认SDK把热点和SPP透传跑通再决定要不要继续往前推进。