串口通讯协议是什么 说的大白话一点,就是串口通信时所使用的协议传输方式。
串口通讯协议有几种 呢 串行通信协议包括 系统间协议和内部系统协议。
系统间协议:用于通信两个不同设备的系统间协议。就像计算机与微控制器套件之间的通信一样。通过内部总线系统进行通信。常见的有UART协议、USART协议、USB协议。
内部系统协议:内部系统协议用于通信电路板上的两个设备。在使用这些系统内协议时,我们将不使用系统内协议而扩展微控制器的外围设备。使用系统内协议会增加电路复杂度和功耗。使用系统内协议,电路复杂度和功耗降低,成本降低,并且访问数据非常安全。常见的有I2C协议、SPI协议、CAN协议。
UART代表通用异步发送器和接收器。UART协议是具有两个有线协议的串口通信。数据电缆信号线标记为Rx和Tx。串口通信通常用于发送和接收信号。它被传输并与串口通信接收数据,而没有类脉冲。UART接收数据字节并按顺序发送各个位。
USAT协议在嵌入式系统中,通常作为 MCU 的外设; 一般来说,由芯片引脚直接引出的一般是 TTL 电平;而中间接有转换芯片的可能就是RS232电平。详情可查看:串行通讯的标准
UART是半双工协议。半双工意味着具有传输和接收数据的功能,但不能同时进行。大多数控制器在电路板上都有硬件UART。它使用一条数据线来发送和接收数据。它具有一个起始位、一个8位数据和一个停止位,表示8位数据传输一个人的信号是从高到低。例如:电子邮件、短信、对讲机,工业物联网传输设备 串口服务器 。
USART代表通用的同步和异步发送器和接收器。它是两线协议的串口通信。数据电缆信号线标记为Rx和TX。该协议用于逐字节发送和接收数据以及时钟脉冲。这是一种全双工协议,意味着同时以不同的板速发送和接收数据。不同的设备通过此协议与微控制器通信。例如电信。
USB代表通用串行总线。同样,它是两线协议的串行通信。数据电缆信号线标记为D +和D-。此协议用于与系统外围设备进行通信USB协议用于向主机和外围设备串行发送和接收数据USB通信需要基于系统功能的驱动程序软件USB设备可以在其上传输数据主机上没有任何请求的总线。现在,当今大多数设备都在使用这种技术与USB协议进行通信。像计算机一样使用USB与ARM控制器通信。USB以不同的模式传输数据。第一个是10 kbps至100 kbps的慢速模式;第二个是全速模式500kbps至10mbps,高速模式25mbps至400Mbps。USB最大电缆长度为4米。
例如:鼠标、键盘、集线器、开关、笔式驱动器。
I2C代表内部集成电路。I2C只需两条线即可将所有外设连接到微控制器。I2C只需两条线SDA(串行数据线)和SCL(串行时钟线)即可在设备之间传输信息。它是从属通信协议的主控。每个从站都有一个唯一的地址。主设备发送目标从设备的地址和读/写标志。该地址与该设备打开的任何从设备匹配,其余从设备处于禁用模式。一旦地址匹配,在主机和该从机之间进行通信,并发送和接收数据。发送器发送8位数据,接收器回复1位确认。通讯完成后,主站发出停止条件。
I2C总线是由飞利浦半导体公司开发的。其最初目的是提供一种将CPU连接到外围设备芯片的简便方法。嵌入式系统中的外围设备通常作为内存映射设备连接到微控制器。I2C仅需要两条线即可将所有外设连接到微控制器。这些称为SDA和SCL的有源线都是双向的。SDA线是串行数据线,而SCA线是串行时钟线。
I2C上拉电阻:
为什么在I2C SCL和SDA线路中使用上拉电阻。
SDA和SCL线均为漏极开路驱动器。
它可以将输出驱动为低电平,将其驱动为高电平。
为了使线路能够变高,您必须提供上拉电阻
SPI代表串行外设接口。它是摩托罗拉开发的串行通信协议之一。有时SPI协议也称为4线协议。它需要四线MOSI,MISO,SS和SCLKSPI协议用于通信主设备和从设备。主机首先使用频率配置时钟。然后,主机通过拉片选按钮选择特定的从设备进行通信。选择该特定设备并开始主机与该特定从机之间的通信。主机一次仅选择一个从机。它是一种全双工通信协议。在位传输的情况下,不限于8位字。
CAN代表控制器局域网。它是一个串行通信协议。它需要两条线CAN高(H +)和CAN低(H-)。它是由Robert bosh公司于1985年开发的,用于车载网络。它基于面向消息的传输协议。
1970年代是汽车制造商开始引入新功能的时代,例如防抱死制动,空调,齿轮控制,中央 *** 作门锁等。这些功能确保了额外的接线和复杂的设计,从而增加了成本和风险。为了克服这些问题,Robert Bosch在1980年代引入了CAN协议。此串行通信协议在1993年进一步标准化为ISO11898。正是CAN协议完全改变了高级传感器之间的通信。
CAN协议常用于汽车、飞机和医疗系统中的电子网络。常见产品有Can转以太网设备USR-CANET200和总线制智能家居系统相比,无线的好处是即插即用、免布线等。但主流的Wi-Fi、ZigBee、蓝牙在家庭的环境中都有各自的短板。网上有很多关于技术的介绍,我就不详细分析技术了,从应用上来聊聊。
Wi-Fi是基于IEEE80211的通信协议,被广泛使用在智能单品及智能家电中。原因是配网简单,用户熟悉度高,不需要额外的网关,可以和存量路由器直接通信。但Wi-Fi的问题是信道本身已经拥挤、接入数量多容易掉线,路由器能支持同时连接的设备数有限。
BLE(低功耗蓝牙技术)有低功耗、快速与手机连接的特性,但早期都是以点对点产品为主。基于低功耗特性,蓝牙智能产品集中在可穿戴设备、健康监护设备等产品中。从蓝牙41协议开始,蓝牙 mesh产品具备了ZigBee才有的自组网特征,但蓝牙mesh还处在技术积累期,尤其是要解决为了组网而功耗增加的问题。
以上两种协议在苹果的HomeKit中有完整定义,其他无线产品则需要通过“bridge”来接入。智能手机都标配这两种技术,用户都非常熟悉这些产品的配对、联网,这也是大量的智能硬件使用Wi-Fi和BLE的原因。
Zigbee是基于IEEE802154的通信协议, 它的特点是低功耗、自组网、节点数多。但手机中没有ZigBee模块,需要额外的网关接入ip网络。ZigBee mesh网络复杂、用户DIY的可能性小,可能更适用于工业物联网。早期的ZigBee智能家居产品有很多私有协议,使得产品互通困难。ZHA和ZLL做了不少互通尝试,ZigBee30也风风火火,都想解决iot时代互通问题。
请注意以上三种技术都是基于24GHz频段的,在无线设备爆发的时代,这个信道变得越来越拥挤,相互之间干扰问题也会更严重。在无线产品中,频率越高则距离越短,穿墙性越差,这也是subGHz频段越来越被重视的原因。早期的小无线产品集中在315MHz和433MHz频段,但由于频段宝贵,所以带宽很窄,因此一些成熟的通讯算法无法实现。这些早期产品给人的印象就是不稳定,抗干扰性差。随着通讯技术的发展,使用subGHz的低功耗广域网(LP-WAN)发展迅速,目前主要集中在LoRa和NB-iot两个技术标准上。利用数字扩频、纠错码、双工通讯、MAC层控制等技术使得LP-WAN既保留了低功耗、远距离、穿墙好等优点,又解决了抗干扰的问题,在iot领域有后来居上的优势。
用户并不关心誉诚智能家居系统用的是什么无线技术,只要求联网简单、稳定。各种协议并存将长期存在,短期内还看不到一统江湖的无线标准。在BroadLink我们采取Wi-Fi加LP-WAN两种技术,同时在系统层面接入BLE、ZigBee以及KNX,485总线,供参考。计讯全网通DTU_TD210支持LTE-FDD、LTE-TDD、WCDMA、EV-DO、CDMA 1x、TD-SCDMA和GSM/EDGE七大网络制式。
计讯DTU还支持I/O、ADC、TTL/RS-232/RS-485多种接口选择(可定制TTL电平串口),兼容所有串口下位机;
支持串口AT协议,可在运行过程中切换到AT状态,进行参数配置、重启控制式;
内嵌PPP、TCP/IP、UDP/IP、MODBUS-TCP、 MODBUS-RTU等多种协议,兼容厂家私有协议,可以满足物联网设备的无限入网传输需求。
MQTT 协议 是基于发布/订阅模式的物联网通信协议,凭借简单易实现、支持 QoS、报文小等特点,占据了物联网协议的半壁江山。
常用于 IOT 物联网和一些需要服务端主动通知客户端的场景。
1 导入依赖
2 创建 MqttHelper 辅助类,设置回调监听
3 连接 MQTT
连接成功或失败,以及中途的连接掉线,会触发 OnMqttStatusChangeListener 回调
4 MQTT 连接状态监听
5 MQTT 收发消息监听
onSubMessage 订阅的消息回调,因为存在订阅多个 topic 的情况,所以回调能知道是来自哪个 Topic 的消息;
onPubMessage 发布的消息回调,用于确认发布的消息是否发送成功。
6 MQTT 订阅 Topic
需要在 MQTT 连接成功后才能订阅 topic,否则订阅 Topic 不成功,收不到对应消息
7 MQTT 取消订阅 Topic
8 MQTT 发布消息
9 MQTT 断开连接
10 通知设置
由于 MQTT 启动了一个 Service,而 Android 80 以上对于后台 Service 限制时长 5 秒;所以将 MqttService 绑定到 Notification 上成为了一个前台通知;通知的标题和内容显示可以在 stringsxml 中设置,对应属性如下:
Android 80 及以上开启前台服务绑定到通知,80 以下默认不启用,可将 mqtt_foreground_notification_low_26 设为 true,将 80 以下设备也开启前台通知服务
创建 MQTT 实例时需要传送参数 MqttOptions,下面将介绍下部分参数;
1 Topic
MQTT 是一种发布/订阅的消息协议, 通过设定的主题 Topic,
发布者向 Topic 发送的 payload 负载消息会经过服务器, 转发到所有订阅
该 Topic 的订阅者
通配符 : 假想移动端消息推送场景,有的系统消息是全体用户接收,有的消息是 Android 或 iOS 设备接收, 又或者是某些消息具体推送到用户,当然, 对应的多种类型消息可以通过多订阅几个对应的 Topic 解决,也可以使用通配符;
通配符有两个, " + " 和 " # ", 与正斜杠 " / " 组合使用;加号只能表示一级Topic, 井号可以表示任意层级 Topic; 例如: 订阅 Topic为 " System/+ ", 发布者发布的 Topic 可以是 System、System/Android、System/iOS; 但是不能是 System/iOS/123, 而订阅的 Topic 如果是" System/# " 则可以收到;
注意,只有订阅的 Topic 才可以使用 通配符, 发布和遗嘱的 Topic 不能包含通配符
2 ClientID
发布者和订阅者都是属于客户端, 客户端与服务端建立连接之后,发送的第一个报文消息必须是 Connect 消息,而 Connect 的消息载荷中必须包含 clientID 客户端唯一标识;
如果两个客户端的 clientID 一样, 则服务端记录第一个客户端连接之后再收到第二个客户端连接请求,则会向一个客户端发送 Disconnect 报文断开连接, 并连接第二个客户端, 而如果此时设置了自动重连, 第一个客户端再次连接,服务端又断开与第二个的连接, 连上第一个客户端, 如此将导致两个客户端不断的被挤掉重连
注意: clientID 使用的字符最好是 大小写字母和数字, 长度最好限制在[1, 23] 之间;
3 遗嘱消息
可选参数, 客户端没有主动向服务端发起 disconnect 断开连接消息,然而服务端检测到和客户端之间的连接已断开, 此时服务端将该客户端设置的遗嘱消息发送出去
应用场景: 客户端因网络等情况掉线之后, 可以及时通知到所有订阅该遗嘱 Topic 的客户端;
遗嘱 Topic 中不能存在通配符
4 Session
客户端和服务端之间建立的会话状态, 一般用于消息保存, 如果设置清除 Session,则每次客户端和服务端建立连接会创建一个新的会话,之前连接中的消息不能恢复,
而设置不清除会话, 对应发布者发送的 qos 为 1和2 的消息,还未被订阅者接收确认,则需要保存在会话中, 以便订阅者下次连接可以恢复这些消息;
注意: Session 存储的消息是保存在内容中的, 所以如果不是重要的消息,最好是设置清除 Session, 或者设置 qos = 0;
5 心跳包
标识客户端传输一次控制报文到下一次传输之间允许的空闲时间;在这段时间内,如果客户端没有其他任何报文发送,必须发送一个 PINGREQ 报文到服务器,而如果服务端在 15 倍心跳时间内没有收到客户端消息,则会主动断开客户端的连接,发送其遗嘱消息给所有订阅者。而服务端收到 PINGREQ 报文之后,立即返回 PINGRESP 报文给客户端
心跳时间单位为秒,占用2个字节,最大 2^16 - 1 = 65535秒(18小时12分钟15秒),设置为 0 表示不使用心跳机制; 心跳时间一般设置为几分钟或几十秒即可,时间短点可以更快的发出遗嘱消息通知掉线,但是时间短会增加消息频率,影响服务端并发; 微信长连接为 300 秒,而三大运营商貌似也有个连接时间最小的为 5 分钟。
6 qos
服务质量等级 qos 对应两部分,一是客户端到服务端发送的消息, 一是服务端到客户端订阅的消息; 从发布者到订阅者实际 qos 为两段路中 qos 最小的。
qos 可选值 0(最多交付一次)、1(最少交付一次)、2(正好交付一次);
qos = 0 :接收方不发送响应,发送方不进行重试;发送方只管发一次,不管是否发成功,也不管接收方是否成功接收,适用于不重要的数据传输;
qos = 1 :确保消息至少有一次到达接收方,发送方向接收方发送消息,需要等待接收方返回应答消息,如果发送方在一定时间之内没有收到应答,发送方继续下一次消息发送,直到收到应答消息,删除本地消息缓存,不再发送;所以接收方可能收到1-n次消息;适用于需要收到所有消息,客户端可以处理重复消息。
qos = 2 :确保消息只一次到达接收方,发送方和接收方之间消息处理流程最复杂;
Mqtt Qos 深度解读 和 MQTT协议QoS2 准确一次送达的实现
7 payload 负载消息
字节流类型, 是 MQTT 通信传输的真实数据
8 保留消息
发布消息时设置, 对应参数 retain, 服务端将保留对应 Topic 最新的一条消息记录; 保留消息的作用是每次客户端连接上线都会收到其 Topic 的最后一条保留消息, 所以可能存在网络不稳定,频繁掉线重连,每次重连重复收到保留消息;
可以向对应的 Topic 发送一条 空消息,用于清除保留消息。
MQTT 服务搭建 Apache Apollo 服务器 搭建 MQTT 服务
Github 仓库
mqtt 协议
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)