刘慈欣在其封神之作《三体》里描绘过三体人的沟通方法：俩人就这么站着不说话，四目相交，天雷引着地火，脑电波你来我往。没有时延，不必等候，顷刻间便心与心相印，魂与魂深交，想来就非常夸姣。
相比之下，人类经过“言语”把隐晦的考虑躲藏在幽微的心底，审时度势，鼓舌如簧，说口是心非的话，撒掉以轻心的谎。
大刘在《三体》里，将此视为地球人类对三体人的一大优势。上兵伐谋，兵以诈立，在国际这座漆黑森林中，只需长于躲藏和假装，才干更好地生计。
是的，言语是一门躲藏实在的艺术。
其实，它不只在人类国际如此，在电子设备之间仍然如斯。在电子设备之间，它有一个专业性的称谓：通讯协议。
一
电子工程师对“通讯协议”这个词汇耳熟能详，如数家珍。平常挂在嘴边的就有USB、RS232、CAN、LIN、ModBus、RS485、SPI、I2C、Zigbee、红外、蓝牙、WiFi……
“通讯协议”也许是一个界说含糊的词汇，由于，严厉说起来，上面罗列的都是通讯规范，或有线或无线，或广域或局域，或长途或短距，并且它们大多仅仅界说了物理层、链路层协议，当然有的还包含了传输层和会话层。
可是笔者今日想要跟咱们评论的则是根据这些通讯链路之上的使用层协议。
使用层协议和终端使用密切相关，就拿笔者比较了解的蓝牙来说，针对车载免提有HFP协议，针对电话本传输有PBAP协议，针对耳机有A2DP、AVRCP协议……
除了这些针对特定场景详细使用拟定了交心协议的通讯规范之外，有许多场合是需求工程师自己拟定使用协议的，比方今日笔者要跟咱们共享的测验工装上位机和下位机之间的通讯协议。
二
一把钥匙一把锁，一杆钢笔一只笔帽，倚天剑得配个剑鞘，量产产品必定需求测验工装一套。
测验工装咱就不多费翰墨了，总归便是上位机和下位机之间用串口或许USB，然后用类似于下面的老套通讯协议互发报文：
报文头(设为0x55+0xaa)+id(报文的ID)+data_len（数据长度）+data+checksum
咱们伙对这种款式的通讯协议必定是熟得不能再熟了，以至于或许视而不见，底子没有意识到这儿有哪些不对劲。
想想看，假如这种通讯协议下的报文流出了问题，咱们想搭眼看看哪里出了错，是很难一看就看出个所以然的。
报文背面的信息就好像蒙了一层面纱，犹抱琵琶半遮面，千呼万唤不出来。
咱们需求把协议文档翻出来，一条一条地对比才干知道这儿的id究竟对应的是哪一条详细的测验项，这儿的数据究竟表明什么意思。
不过好在，咱们只需严厉地依照报文格式封装和解析这些报文，并确保报文的消费（解析）速度高过出产（接纳）速度，干完这些dirty work之后咱们就不需求关怀它是不是那么模糊难辨了。
究竟，终究履行这些协议的都是核算机和电子设备，而这正是它们的强项。
所以，直到现在，我仍然能够想起几年前选用这种方法做测验工装时的那种心境：
九月里，平平无聊，全部都好，只缺烦恼。
直到有一天，我和报文里的内容打起了交道。
三
原本，韶光悠悠，年月静好，全部的全部都充满了美好的滋味。
小张依照上文那种报文格式把某个测验项的恳求发下来，我发动详细的测验，把测验数据发给他，他依照测验项的详细功用逻辑，经过测验数据判别测验是否经过。
时刻滴滴答答，客户端（上位机）和服务器（下位机）的恳求和呼应也没有出过岔。
可是不知怎的，许是我改了改程序，又或许小张动了动代码，那天下午呈现了本该测验经过的测验项失利的状况。
于是乎，天高气爽，艳阳高照，我和小张打起了嘴炮。
顶着冲冠的怒发，小张污我有的报文会漏发，我不留情面地说他的水平不到家，不知道用个buffer把接纳的报文先缓存一下下。
为了证明报文不会漏发，我用工装上剩余的串口接上电脑上的串口帮手，两个串口的数据一起发，在串口帮手的界面上把数据给他抓了一下。
然后，我俩对着电脑看了一瞬间，各位看官呢，就一瞬间，咱们哥俩就懵圈啦！
那么多0x55 0xaa，谁知道后边那个id和数据表明的啥意思呀。面临这样蒙着面纱的数据，谁看谁懵圈吧！
无法自证洁白的我茫然地看着界面里的数据排得鳞次栉比，一时刻觉得无法招架。侧过头来，瞥见了小张无意识中翻开的大嘴巴，‘真像是一个大傻瓜’。再转过头来，看了不大会儿数据又觉得目炫。
目炫是必定的，由于这儿的数据报文原本就不具有可读性嘛。
聚成了是一团火，横竖它能很好地干活，可是散开了则是满天星，对着你一闪一闪亮闪闪，让你找起问题来火冒金星。
它又如浮萍在水，如淡云在天，只需劲风拂来，便是个萍乱云散的地步。
其实说究竟，想天然地解读这种不具有可读性的通讯协议是不是有些傻？
荒唐的感觉越来越盛，对通讯协议的诘问也越来越深化，然后我天然而言地提出了一个关键性的问题：通讯协议可不能够具有可读性？当然能够，蓝牙的使用协议(profile)不便是可读的吗？怎样赋予它可读性？文本化！
就这样，一个呼吸之间，脑海里问题刚刚显现，答案就呈现在眼前，犹如天外飞仙。
我忽然感到很敬服自己。
禅门大德劝导座下弟子时，经常说一句：‘脱了衣服去！’通讯协议文本化，何曾不是脱掉了衣服，揭开了它的面纱？！
我把从心底瞬间涌上来的心情，压缩成一句话，终究把它一字一顿地说了出来：
万物皆有灵，只需引发它们的灵性。
话音甫落，小张的嘴巴张得更大了。
四
在两个电子设备之间选用文本式进行通讯，似乎它们就脱离了无情种智，进入了有情众生的国际。
向小张遍及了这个思维之后，我旋即拟定了一个可统一各个测验项的通讯协议。
上位机建议测验恳求，报文内容为“TestReq XXX\r\n”，其间的XXX代表详细的测验项，比方要测验信号强度，XXX=RSSI，比方要测验1号继电器，XXX=RELAY1……
下位机回来测验成果，测验成功时报文内容为“TestResult XXX OK\r\n”，测验失利时报文内容为“TestResult XXX ERR\r\n”，这儿的XXX便是上述所谓测验项称号。
详细解析时也很简略，先经过换行符\r\n把一条独立的报文提取出来，然后把报文头“TestReq ”或许“TestResult ”查找出来，然后就定位到了XXX的方位，把它读取出来即可。
封装报文和解析报文也都变得无比地简略，由于C言语有字符串函数支撑上面这一系列操作！
这样一来，在通讯链路上传输的数据都是可读的，并且报文经过换行符进行距离，是不是漏发，是不是报文中心的数据发生了过错，都一望而知了。
后来，在文本化通讯的协助下，小张的问题也找到了。
本来，测验工装上位机软件规划时，对每个测验条目都加了超时约束，当它的核算机上翻开许多软件时，测验工装上位机软件的实时性就变差了，有的时分就主动触发了超时，标记为测验失利。
恩，小张这个规划思路当然有必定的问题，可是这不是本文要探求的主题：）
五
央视主持人大赛里有一期节目，里边有一个擂台标题是“做新闻是内容重要仍是方式重要”。两边唇枪舌战，鼓舌如簧，纷繁站在自己抽签抽到的立场上引经据典，这边说内容重要，那边说方式重要。我其时看得那个着急啊，这些单纯的读书人啊，莫非你们不知道，内容很重要，方式也很重要嘛！
就像本文评论的通讯协议相同，选用具有可读性的文本方式既能很好地满意两边交互，又能明明白白地显现给在一旁监控它运转的工程师，两全其美，岂不美哉！
