浅析串行与并行通讯

  在嵌入式领域,组件间的通讯是逃不掉的话题,因为仅仅只有处理器核心算不上完整的嵌入式系统,一个嵌入式系统往往是由处理器和众多外部设备组合而成的,而通讯则是处理器与外设,外设与外设之间的纽带。在嵌入式领域有成千上百的通讯协议,这些通讯协议有众多的分类方式,其中一个重要的分类方式就是将通讯方式分为串行通讯与并行通讯。

分清串行通讯与并行通讯


串行通讯是指某一时刻只允许传输一个数据的通讯方式,数据按照次序依次从发送端传递到接收端。

 

并行通讯是指某一时刻允许多个数据传输的通讯方式,多个数据元素允许在多条独立的通道路径进行传输。

 

为什么常见通讯协议都是串行通讯



  要谈这个话题,首先要看一下串行通讯和并行通讯有哪些优劣。从串行和并行的接线方式就可以直观的得出,串行通讯的接线相比并行更加简单、容易,而并行通讯由于其允许在多个独立通道传输,所以速度上更有优势。

  除了以上比较显而易见的优劣性,还有一个问题需要注意——数据的次序。一个保质保量的数据需要满足无冗余、无缺失、无损坏和正确的次序这几个要求,串行通讯本来就是一位一位发送,所以由于次序而产生的错误率很低,相对的并行通讯很难满足这样的要求。要了解并行为什么次序上为什么难以保证需要从并行数据收发上入手。

为什么并行数据这么难?

如果我们有以下的并行数据线路,我们需要传输八个字节的数据,我们有两种不同的传输方法可供选择。

 

方法1:让负责数据传输的 0~7 八个数据口分别传输每个字节的内容,等传输结束后再把数据拼接在一起。

 

方法2:让负责数据传输的 0~7 八个数据口分别传输某个字节的不同位。

 

  以上两种方法相比,可能由于某些问题导致不同线路数据的收发时序不一致,就会分别产生以下两种情况,前者在其他字节传输完成后有部分字节仍未传输完成,后者则是字节某些位没有一致的传输完成,这些情况都会导致数据的质量问题。

 

  前者这种传输方法其实就是把数据分成尽量等长的部分,一部分数据传输完毕与否并不会对其他数据的收发造成影响,即使几条数据线完成时间不统一,也可以等到所有数据传递完成再拼接完成就可以了。

  后者这种传输方法是把具体数据的某个位交给一条数据线,这时候某条线路传输完成与否会延误后面数据的收发,因为要保证某个字节全部被正确的写入,比如上面的例子,首字节数据第4位传输未曾完成,那么第二个字节的数据就迟迟不能写入,更麻烦的是还需要其他的反馈机制高速发送方已完成发送位暂时不要发送数据,这就给系统带来了很大的负担。

  谈了这么多,大伙可能会想,那就用第一种方法就好了呗,那为什么还需要讲第二种方法,不过我要告诉大家的是后者才是并发通讯独特之处,前者可以看做多条串行通讯!如果给我同样八条串行数据的线路,我完全也可以在程序层面将数据分离达到前者的效果,而后者有其存在的意义。

并行收发究竟有什么用?



  仅仅从整体的数据传输效率来看,速度提升了八倍,但是从上面的例子来看也有个不可忽视的因素。对于前者,在整体数据传输完成前,没有一个字节的数据可以被读取和操作;反观后者,按照字节进行传输,可以单独对已经传输完成的数据进行处理,而无需等待所有数据传输完成。

  有了以上的分析,我们终于对并行数据传输的应用场景有个清晰的认识,如果需要的是整体的数据内容,则优先使用多条串行的方式就可以,这样提高效率的同时传输条件也不那么苛刻;如果部分数据就能达到数据处理的要求(比如前面若干字节的例子),而且对效率要求比较高则选择后者的处理方式。


 

  在很长一段时间内,都只是把串行通讯和并行通讯当做口头禅背了下来,总隐隐约约知道好像并行的处理速度比较快、效率比较高。但是从来没有分析过通讯为什么分串行、并行,从没有思考过为什么很少有并行通讯存在,今天这些的浅显的思考算是给串行和并行的通讯画上一个短暂的句号。

posted @ 2023-06-10 17:02  Spark++  阅读(166)  评论(0编辑  收藏  举报