因为串口收发数据, 没有开始结束的标志. 因此发送一段命令, 是否结束, 需要靠解析命令的格式来进行. 这也就是为什么很多 GPS, GPRS, 4G 通信模块 使用 AT+ 指令的接口, AT 就是一个命令的开头, 按一定的格式, 来判断是否接收到了完整的命令, 这种常使用 ASIC 编码通信.
还可以通过时隙来判断, 比如, 收发端约定, 两个命令间隔必须大于 0. 5 秒, 那么只有超过 0. 5 秒时, 才去判断指令是否发送完毕, 这种模式一般跟第一种一起用. 因为很多链路不保证通信速率, 因此可能造成通信延迟.
这也就是很多 AT 指令设计了回应口令的机制. 即, 发送端发送一个命令后, 接收端如果接收完整, 那么回应一个 OK, 发送端如果没收到这个回应, 那么发送端将尝试重发. . . .
另外可以通过, 在指令前后加一个校验, 比如包格式, 内带长度, CRC, CHEKKSUM 等信息, 来校验指令的完整性, 这个一般用在可靠性要求高的通信上, 常用二进制数据通信.
这样, 通过通信过程的控制个约定机制, 来保证发送数据的完整和可靠.
1 个回答
撰写答案
请登录后再发布答案, 点击登录
相关问题
热门文章
热门问题
等待解答
推荐专家
2 个答案 1 次被采纳
2 个答案 0 次被采纳
25 个答案 11 次被采纳
2 个答案 0 次被采纳
83 个答案 33 次被采纳
主要这块我想用 json, 我想过用格式校验, 但是一旦发了一个错误的 json 比如我就发一个{ , 就会导致后面接收的所有 JSON 都没法处理, 所以必须加个时间校验, 之前习惯的做法是, 超过 5ms 没有新数据进来就判断接收到一整包数据, 就算用 AT 指令判断个 rn 发一个错误的数据之后 再发 AT 指令也是会解析失败, 需要下一条指令才能正常处理
你可以在 json 外面加上一个封装, 比如 json: [*]rn , 以 "json: "作为开始的判断字符串, 以 "rn"作为结束的判断字符串, 然后解析取出中间的 "[]" 的内容, 脱去方括号, 然后再交给 json 的 parser
你可以在 json 外面加上一个封装, 比如 json: [*]\r\n , 以 "json: "作为开始的判断字符串, 以 "\r\n"作为结束的判断字符串, 然后解析取出中间的 "[]" 的内容, 脱去方括号, 然后再交给 json 的 parser 来解析.
嗯嗯, 这个办法是可以, 不过还是想传输的格式光是 JSON
串口是底层协议, 不能用底层协议直接传输业务层内容. 如果 TCP, 它的底层也是做了封包, 在解封包后, 再交给上层处理, 你看到的纯数据是因为底层协议栈给处理好了.
而串口, 需要你自己来做这些事.
嗯嗯 另外一个想法就是自己通过间隔判断, 不想间隔任务再去单独判断时间, 想的有没有那个接口可以查询运行时间, 通过这个相减去判断数据间隔, 做封包
你可以通过接收字符设定一个最近的收到数据的时间变量, 随时检查当前时间和最近接收字符的时间变量的差, 是否大于一个设定值来判断, 是否停止发送了一段时间.
这样做, 其实效率变低了, 用时间等待来控制数据发送的完整性. 不如用包头尾的协议来检查完整性效率高. 效率高也意味对应用数据的通讯速度快.