"); //-->
本文从UART串口型WIFI模组的”透传“概念的本质入手,解释了”透传“的实际机理,点出了UART串口型模组的“透传”,其目的是为了避免低波特率的UART接口的低效通信,但同时“透传”恰恰又是其“通信可靠性不高、通信不灵活-做服务器无法支持多客户端、也不利于大块数据传输"等局限性的根源。
何谓“透传””透传“是一些UART串口型WIFI模组等部件上常见的概念。单片机等主机通过串口向模组发送的任何数据,都会被模组直接转化无线TCPIP协议包的数据内容,直接发送出去,而不必重新包装;而通过WIFI/TCPIP所接受到的数据内容,也直接通过串口发送给主机,而不必再进行协议的解析。看起来好像串口的数据完全直接对接TCPIP协议的payload数据域,所以称之为“透传”。在透传方式下,不再能使用任何查询或控制指令,一切与主机UART接口所交互的,都被当成是“有效载荷”的“数据”。
UART串口型WIFI为何一般都要支持所谓的“透传”UART串口型WIFI模组需要支持所谓的透传的目的,是为了确保串口通信的效率,这对于本身波特率较低的UART串口型WIFI模组来说,显得尤其重要。我们对照一下非透传方式下的UART串口的串口通信,就比较容易理解了(其实,UART串口型WIFI模组的通信,不仅仅包括所谓的“透传”模式进行通信,也包括非透传模式进行通信)。
比如,假设我们希望通过串口发送一个数据,通过非透传模式,则可能需要如下方式通过串口发送字节串:
AT+CIPSEND=<link>, <len>, <data>\r\n
可以看到,我们的实际目的只是发送其中的<data>部分,但是每次发送前,都需要额外地向串口额外传送一大串字符串 ”AT+CIPSEND=<link>, <len>“。对于串口这类慢速的设备来说,这种字符串的写入,是比较浪费和低效的。
设想一下,假设我们只需要多次发送5个字节,对应的AT命令是
AT+CIPSEND=0,0,12345\r\n
可以看到,总共需要向串口传送22个字节(包含\r\n),但从串口通信的角度来看,效率就降低到了串口通信速度的 5/22!这对于本身波特率不高的UART串口通信来说,这一点对于有效吞吐速度的负面影响越发显得相当严重。如果我们每次都需要多次发送数据,固定字节串“AT+CIPSEND=0,0,”都需要被重复发送,这种低效率的浪费,将导致UART串口型WIFI模组的有效吞吐速率,在本身因为UART波特率受限而不快的基础上,再打一个很大的折扣。
既然每次发送的“AT+CIPSEND=0,0,"都是重复一样的,那为何不能采取一种策略,就是只要向串口输入一次,以后由模组自动”加上“或”理解“成带有这些重复的固定串,这样,以后只需要输入数据部分,之前的固定串部分不用重复输入,于是就可以大大节省慢速串口的浪费而提高效率了。
这就是所谓的透传的含义,即,只需要输入一次那些固定字节串(对应的是我们”进入串口透传“模式之前做执行的AT指令),以后再写入串口的数据,就自动都当成解析<data>了,从而确保了通信的高效。因此,“透传”是慢速的UART串口型WIFI模组,确保速度不会因为低效而进一步降低的一个手段。
UART串口型WIFI采用“透传”方式的弊端局限性 -- 导致通信的可靠性降低和功能受限从上面的分析可以发现,一旦进入透传模式,以后所有串****互的数据,都会自动转化为TCPIP协议包的”数据“域,也就意味着,所有的控制查询等”指令“将不再有效。因此,当我们在做”透传“时,如果想执行某些查询(比如查询当前的网络连接状态、或者通信的成功与否)或控制(比如选择另外某个客户端上进行发送),就必须先退出透传模式,进入非透传模式,来执行这些查询或控制。这也就是我们所知道的,透传模式和非透传模式的切换。
即,透传方式下的数据通信和非透传方式查询控制,不能同时并存,这导致了在收发数据的同时,无法通过查询或控制状态,来确保通信的可靠性,并影响通信包的长度,最终限制可靠通信的速度。比如,正在透传通信的过程中,如果出现网络中断或者阻塞,就无法通过相关的指令(只有在非透传模式下才可以执行的命令)查询得到,而必须先中止当前的传输来查询得到。这对于网络通信来说,会大大降低或限制其通信的可靠性、对长包的兼容性、以及有效的通信速度。这也是为何UART串口型WIFI模组很难做到较高速度下的可靠通信。
又比如,当透传模式下的WIFI模组作为TCP服务器来使用时,就无法支持多个客户端通信了,因为TCP服务器一般需要区分所接收到的数据,来自哪个客户端,以及切换指定向哪个客户端发送数据,这些,都需要在数据通信的同时,进行必要的查询和控制,这是透传模式下,所无法实现的。
对于这个问题的处理,采用ESP8266芯片的串口型WIFI模组,在透传模式下,基本上都直接禁止了对TCP服务器的支持,以避免逻辑混乱;而采用TI CC3200方案的某些知名厂家的串口型WIFI模组,则采用不加区分的客户端方式,也就是说,做TCP服务器时,实际只支持一个客户端。
总结之,UART串口型WIFI模组进行串口透传具备以下局限性:
1、通信可靠性受限,因为无法及时获取当前的通信状态,并进行相应的处理
2、通信包的长度和速度受限,因为可靠性降低了,单个包的长度和速度就无法太快
3、通信的功能受限,比如透传模式下,无法支持多客户端
因此,UART串口型WIFI模组做透传,一般多用在非多客户端、对速度、包长、可靠性要求不高的IoT控制场合,可靠性通过上层应用层的握手和重发发包来进行补偿。
USB、SDIO、SPI等接口的高速WIFI模组为何一般不推荐用“透传”?通过上面对UART串口型WIFI模组的透传分析,很容易就知道了这个问题的答案:
(1) USB/SDIO/SPI等接口本身的波特率速率,一般都远远高于UART UART,所以,不存在UART串口本身因为速率太慢成为瓶颈而需要确保效率的问题。这些接口的WIFI模组的短板,一般不在于这些主机接口的波特率,而往往在于现有WIFI 射频技术本身在环境下的实际吞吐局限,或者模组本身内部的处理效率,所以,在主机接口这里进行类似UART那样的效率提升优化的相对价值不大。
(2)不采用透传方式,还可以规避因为透传而导致的上述局限,从而可以自由的一边进行长数据通信的高速进行,一边又可以自由的进行查询控制确保通信的可靠性和灵活性。
(3)USB、SDIO、SPI接口的高速型WIFI模组可以自由的进行长包发送和同时支持多个链接以及多个客户端。
所以,在这些接口类型的模组上,询问是否支持”透传“,类比询问驾驶飞机是否支持手动挂档。在手动挡汽车上,可能需要挂档换挡以及踩离合等严格的顺序或配合流程,但对于飞机驾驶,则不存在这类话题。
*博客内容为网友个人发布,仅代表博主个人观点,如有侵权请联系工作人员删除。